xcode github

Just checked new Xcode 26.2 with iOS 26.2 and the debug builds startup time indeed improved significantly. We still have ~7 seconds of initial sluggishness (difference between debug executable on/off), but it's way better than it was before! 👍 While I appreciate the movement in the right direction, this still represents a substantial regression from the prior baseline, ~1s in Xcode 16. A reduction in severity isn’t a resolution. If Xcode is to remain viable for professional workflows, startup and initial responsiveness need to return to the Xcode 16 baseline.

Just checked new Xcode 26.2 with iOS 26.2 and the debug builds startup time indeed improved significantly. We still have ~7 seconds of initial sluggishness (difference between debug executable on/off), but it's way better than it was before! 👍 That’s not an improvement, that's a partial rollback of a huge regression. On Xcode 16 it was ~1s. That was the baseline. Seven seconds of launch + long initial sluggishness in debug is still absurd. Stop celebrating “less bad.” This shouldn’t be acceptable and Xcode 26 is still unusable for any serious work.

@axl411 allowsUltraConstrainedNetworkAccess This property seems to have been added for support on Xcode 26.1+. Hopefully this means that we can use URLSessionConfiguration to control if our URLSession requests can go through with ultra constricted network is being used. Fingers crossed...

Looks like it fixed in Xcode 26.2

Thanks for sharing @Alexander Vasenin! @guillaume-amo asked: This is good news, but why is an update of iOS required? You can think of LLDB as a client-server architecture. In Xcode, your use of the debugger is the client side of the infrastructure involved in enabling the debugger. On the other side of the infrastructure is a server process (called debugserver) that the client is talking to. It's this component that is receiving the debugging commands from the client, managing the Mach task port that allows for a debugger to attach to a running process to inspect and manipulate its state, and sending all of the information and commands back and forth to the LLDB client in Xcode for you to view. While on iOS, the debug server happens to be on a different device than where the debugger client is running, the same architecture is at play if you are working on a macOS app. If you are debugging on the same Mac as where Xcode is running, the client and server components just so happen to

Does Apple suggest that developers transition to arm64-only and drop support for arm64_32 devices? No — Apple Watch Series 9 and later, and Apple Watch Ultra 2 and later all support the arm64 architecture. There are many Apple Watch devices that run watchOS versions your app likely supports beyond that list, so you need to keep the arm64_32 architecture around for those devices. As noted in the announcement, you'll want to use the Standard Architectures build setting for your watchOS app, and that will automatically build the right set of supported architectures for your app, which will include arm64_32 as well as arm64. If we add support for both arm64_32 and arm64, the binary will almost certainly exceed the 75 MB app size limit, and potentially violate the size constraints for each architecture slice as well. What size constraints per architecture are you thinking of? The Maximum build file sizes documentation lists such a requirement for iOS apps in the iOS 7 and 8 time frame, but that isn't relevant for

Reproducible with Xcode 26.2 (17C52) FB21322904