I have two apps; one is a subset of functionality of the other. The smaller app has about 170 Swift files. The larger app has these files plus about 120 more. So I would expect the larger app to take around twice as long to build. Instead, the smaller app takes less than a minute to build while the larger app takes over 13 minutes to build; to be exact, it takes 15.3 times longer. While reviewing the build report, I noticed that the smaller app compiles the Swift files in batches, with each batch taking around 10 seconds, but with up to 17 batches running at once. In contrast, the larger app compiles all 290 Swift files in one giant batch, so apparently there is no multithreading of the Swift compilation (see screen shots below). The difference in the number of batches the smaller app compiles at once roughly corresponds to the difference in overall build time. Is there a build setting I can change to make the larger app compile Swift files in multiple smaller batches as the smaller app is doing? I checked SWIFT_COMPILATION_MODE and it's the same in both apps (Incremental for debugging and Whole Module for release) but I don't know what other settings I should check.

A Mac reboot fixed it for a few images, but then it went black again.

Has anyone notices persistent UI lockups when attempting to perform even the most basic tasks with Claude Code? I'm at a total loss here. I've noticed that the lockups tend to happen more often when the Claude Agent is asking me a question. I've tried removing stale data, disconnecting / reconnected the agent, force quit and restart. Nothing solves this.

Hi, I’m trying to test an independent watchOS app on an Apple Watch Series 6 Cellular that is set up for a child using Apple Watch For Your Kids (Family Setup). My current environment: Apple Watch Series 6 Cellular watchOS 26.6 The Watch is set up for a child using Apple Watch For Your Kids / Family Setup Xcode 26.6 Parent iPhone running iOS 27.0 Developer Mode is enabled on the parent iPhone The Family Setup Watch does not appear as a development device in Xcode/CoreDevice There is no Developer Mode option visible on the Family Setup Watch For comparison, I also have another Apple Watch used for normal development, and that Watch can be detected by the development environment. The issue appears specific to the child’s Family Setup Watch. I would like to understand the Apple-supported development and testing workflow for this configuration. Specifically: Is an Apple Watch set up using Apple Watch For Your Kids / Family Setup expected to be available as a direct Xcode development device? If direct Xcode deployment is not supported, can an independent watchOS app be installed and tested on a Family Setup Watch through TestFlight? If TestFlight is supported, what is the correct workflow for installing the beta on the child’s Family Setup Watch / child Apple Account? Is there another Apple-supported testing or distribution method developers should use for this scenario? I’m specifically asking about an independent watchOS app that can operate without the parent iPhone nearby, rather than a Watch app that depends on an iPhone companion app. I’d also appreciate clarification on the distinction between direct Xcode development deployment and TestFlight/App Store distribution for Apple Watch For Your Kids. Thank you.

Hello, I am playing around with MailKit in Xcode... just created a new App with MailExtension target. When I run it, it's asking if I want to test it with Mail, however, I cannot see the extension in the Mail Settings for enabling it... I a totally newbie here.... what am I missing?

Hi, I’m testing the new NowPlaying framework on iOS 27 using Xcode 27 and an iPhone 17 Simulator, and I’m seeing some behavior that I’m trying to determine is a Simulator issue or something incorrect in my implementation. I have a local AVPlayer playing an MP3 and a MediaSession conforming to MediaSessionRepresentable. The session publishes MusicContent with static artwork, AnimatedArtwork using the .tall aspect ratio, a MediaPlaybackSnapshot, and commands for play, pause, previous, next, and seek. The strange behavior is: I start playback and call requestToBecomeApplicationPrimary(). It succeeds and isApplicationPrimary becomes true, but isSystemPrimary remains false. I lock the Simulator for the first time. There is no Now Playing UI or metadata. I unlock it and return to the app. After recreating/re-registering the MediaSession and calling requestToBecomeApplicationPrimary() again, isSystemPrimary sometimes becomes true. When I lock the Simulator a second time, the Now Playing UI finally appears and the animated 3:4 artwork works correctly. However, the Lock Screen card still does not show the expected play/pause/previous/next buttons. It only shows the title, artist, progress bar, and volume control, despite those commands being included in commands. When the second session succeeds, the framework also starts requesting the artwork as expected: applicationPrimary: true systemPrimary: true Animated preview requested: (1206, 1608) ratio: tall Static artwork requested Animated video requested: (1206, 1608) ratio: tall Calling requestToBecomeSystemPrimary() directly has also consistently returned: internalFailure Playback itself continues correctly throughout all of this. So I’m trying to understand whether anyone else is seeing similar behavior with the iOS 27 Simulator: MediaSession becoming application-primary but not system-primary on the initial playback Now Playing metadata only appearing after a lock/unlock/re-registration cycle media commands being supplied but playback buttons missing from the Lock Screen requestToBecomeSystemPrimary() returning internalFailure I have not yet tested the same build on a physical iOS 27 device, so I’m particularly interested in whether this is currently a known Simulator limitation/bug or whether there is another step required when publishing a local playback MediaSession. Thanks!

We need guidance regarding the Python runtime bundled with Apple Command Line Tools. Environment: macOS Tahoe 26.5.2 (25F84) Xcode 26.6 (17F113) Device type: Mac Command Line Tools Python path: /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/ Version confirmed locally with: /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/bin/python3 --version Output: Python 3.9.6 Our vulnerability-management platform, Qualys, reports this Apple Command Line Tools Python runtime as vulnerable under QID 387170, referencing CVE-2022-4303 and CVE-2023-0286. The detection points to: /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/Resources/Python.app My understanding is that this runtime is bundled and managed by Apple as part of Command Line Tools, and that manually replacing or modifying this framework is not a supported remediation path. Installing a separate standalone Python version also does not remediate the finding at this Apple-managed path. Could Apple or the community confirm the supported approach for this scenario? Specifically: Is Python 3.9.6 intentionally bundled with the current Command Line Tools release for this macOS/Xcode version? Has Apple applied security fixes or backports to this bundled Python runtime that are not reflected in the upstream Python version number? Is updating Command Line Tools/Xcode the only supported remediation method for this component? Is manually replacing or modifying the bundled Python framework unsupported? Is there any known mitigation or official guidance for vulnerability-management exceptions while waiting for an Apple-provided update? I have also filed this through Feedback Assistant: FB23893693. Any official Apple guidance or reference to existing documentation would be very helpful, as we need to provide an auditable response to our internal security and audit teams.

Whenever I click the blue project button below for my ios application (in an attempt to get to Signing & Capabilities), my Xcode application crashes. I've tried the following: Deleting xcuserdata folder under project.xcworkspace Purging derived data in ~/Library/Developer/Xcode/DerivedData Clearing Xcode preferences with defaults delete com.apple.dt.Xcode

Each time I launch a Debug version of the app on iOS Simulator, I see the Launch Screen presented and then about a 30-second delay before the app is responsive and debug output appears in the console panel. Filed FB22345091

Hello. I have just updated to Xcode 27 to support this version, however... my app is a navigation app with CarPlay support... The I/O > External Displays option through the Simulator helps a lot when testing it, but I’ve noticed it is now gone Why? Who thought this was a good idea? Some of us support apps that are beyond a simple ToDo app So now I have to go back to the previous version of Xcode, or what?

I can't use cloud-based AI providers, so I'm very excited about the potential of local models with Xcode's Coding Assistant. I've been playing around with a local MLX model, and have been generally pretty satisfied with it. But I'm curious - what features am I missing out on by using a local model instead of a larger, cloud-based model? Is Xcode's ability to run tests, build the project, etc. limited by the use of a local model? Does it limit the ability to do more complex agentic workflows? If so, how? Basically, local models in Xcode seem to be working pretty well for me, and I'm curious to know what cloud-based models can offer that I don't already have.

When I archive and distribute any iOS app from Xcode 27.0 RC on macOS 27.0 Golden Gate, the upload stalls indefinitely at “Preparing to upload [App].ipa”. The archive, signing, provisioning, IPA packaging, and App Store Connect authentication all complete successfully. This is reproducible with multiple unrelated iOS projects on the same machine, so it does not appear to be caused by a specific app, signing configuration, asset, or bundle identifier. Cancelling the upload is the only way to exit the stalled state. I also checked with ChatGPT Codex if it can narrow down the issue. It states: "The failure occurs when Xcode launches the swinfo utility from the ContentDelivery framework to generate the asset description.swinfo crashes with SIGSEGV / exit code 139. The crash report reports:Thread stack size exceeded due to excessive recursion". But I actually never got an error message during the upload itself, it just hangs indefinitely at "preparing to upload..." (Tried it several times up to 36h). This issue is new since I updated to macOS Golden Gate and xCode 27 RC. Xcode Cloud is the only working option right now to upload a Build to App Store Connect. Anyone experiencing the same issue and found a solution? What I already tried: Revoke and renewed my Apple Distribution certificate. Delete xCode, Installed it again (I also installed xCode 27.2 Beta which I knew would not work to upload an app to App Store Connect from a Beta version). Created a brand new project and tried to upload this. Also hang at "preparing to upload..."

I like to use Window Tabs, setting them up with appropriate panels when working on SwiftUI views, writing tests, etc. Many times now, I open a project in Xcode only to discover the main window is very small, what was expanded in the project outline is incorrect, and the window tab bar is hidden. Showing the window tab bar then just shows a single empty tab named "New Editor". Since I didn't add any new files today or change project settings (nothing would have changed the .xcodeproj package of files), I restored a backup and that opened up a-ok. Though I first saved the bad project. In analyzing differences between the two .xcoeproj files, I can only imagine this an issue with UserInterfaceState.xcuserstate. Though it's not practical at all to see what the changes are due to different ordering. I did notice that the bad .xcodeproj version had a massive Base64 encoded block for some IDENavigatorModeSolitary entry. The working project had a much smaller encoded block. Anyone else run into this? For those that are now using the new JSON project files, has this still been an issue?

The iOS 17 simulator does not respond at all when I try to interact with it. The simulator is not frozen as I can still control appearance and launch apps via the right sidebar. Things like the home button and clicking on the screen simply don’t work. I am using Xcode 27 beta 6. Feedback ID: FB24674634

M4 Mac Mini: Xcode generates private keys with wrong label - codesigning impossible Background This is a follow up to my November 2024 thread "Keychain issues after installing backup on new Mac" which was closed because I had a temporary workaround. That workaround using my wife's MacBook Air for signing is not sustainable. I used AI assistance to determine the root cause. My DTS case 102877839447 is open but has not yet been forwarded to a DTS engineer. Environment Mac Mini M4, macOS 15.4.1 (Build 25E253) Xcode 26.4.1 (17E202) Team ID: Q23726668V (Computerade Products) Working comparison machine: MacBook Air, macOS 15.3 Precise Bug — Reproducible Every Time Every time Xcode generates a new certificate and key pair on my Mac Mini: Certificate: Apple Development: Michael Birch (9KD5TCGGHG) ✅ Private key: Apple Development: Michael Birch (Computerade Products) ❌ The key uses the organization name instead of the certificate identifier. They never pair as a valid codesigning identity. security find-identity -v -p codesigning always returns 0 valid identities. Cryptographic Evidence The internal application labels confirm the keys are cryptographically unrelated to their certificates: Key internal application label: 53C26EB056997276B5E938258D00665ACABD1F0F Certificate public key hash: 57cd1af4a9162f26b1a6d750e05a63a2166b75ff These do not match ❌ Confirmed Eliminated As Causes Keychain search list corruption — found and fixed Partition list — set correctly Access control — set to allow all applications Full Disk Access — granted to Xcode Xcode caches and preferences — completely cleared Login keychain — completely reset Orphaned certificates and keys — all removed SIP enabled, system fully up to date Valid P12 Import Also Fails A p12 exported from the working MacBook Air and cryptographically verified as a matched pair also fails on the Mac Mini: security import returns MAC verification failed Keychain Access import returns OSStatus -2 Importing certificate and key separately as PEM files succeeds but they are not recognized as a valid identity pair despite matching application labels A3F3F193B7896DA9055353F59AB450778CB09AE7 Question Is there a known issue with M4 Mac Mini keychain infrastructure where private keys are generated with incorrect internal application labels? Is there a lower level diagnostic or fix beyond what the security command provides? The problem is specific to my Mac Mini M4 and persisted thru more than a year of Mac OS and xCode updates.

Hi Team, My Mac has already been upgraded to macOS 27 and currently has Xcode 27 installed. However, I have a development requirement to use Xcode 26.5 as well. Is there any supported way or workaround to install and run Xcode 26.5 on macOS 27? If it is not supported directly, what would be the recommended approach to use Xcode 26.5? Thanks, Reshma

Hello I cannot seem to get past the final step in pairing my Ultra Watch 3 to Xcode 27 RC1.. I have tried this on a Mac Mini M4 and a Mac M1.. Both Macs are running 26.6.2 In both cases, XCode seems my iPhone and I am able to deploy to that physical iPhone. I have my iPhone connected via a USB cable. When going into Developer Mode on the watch and then opening up the "Pair Nearby Device" in Device Hub, I can see either my M1 or my M4 (depending on which one is trying to connect), I can select it, it asks for a pass code and then asks me to pair. When I do, it simply returns back to the previous screen asking if I'd like to pair again.. Any ideas ?

Hello all, Yesterday, I found out that there's 60GB's of old simulator volumes on my mac in /Library/Developer/CoreSimulator/Volumes/. When I try to delete those through Xcode Settings -> Components under Other Installed Platforms, it looks like they are deleted, but after restarting my Mac, they simply return. I tried the solution proposed here (which is to delete the dmg files in /Library/Developer/CoreSimulator/Images/), but in my case, there are no dmg files in there. So it looks like they were properly deleted, unlike those in /Library/Developer/CoreSimulator/Volumes/. I could obviously try to delete the dmg files in /Library/Developer/CoreSimulator/Volumes/, but that doesn't work according to a post on reddit that I'm not allowed to show here (It's called 'Deleted 240GB of Xcode simulators multiple times but they keep remounting - how do I permanently remove them?') And I wonder if it's a safe thing to do. Do you have any suggestions for how to remove the old volumes correctly and permanently?

It looks like the other thread got locked. I would still like to be able to uncheck the box for "Connect via network" so I can develop with my iOS 17+ devices normally with Xcode 15. Or a method to use Xcode 14 with iOS 17+ without CoreDevice or whatever the problematic API is.

Environment: Xcode 27 (macOS 27.0, build 26A428) iOS 27.0 simulator (build 24A434), tested on iPhone 18 Pro CoreSimulator 1174.9.2 Large app target: dozens of linked frameworks (first-party SPM modules plus several third-party SDKs) it occurred on xcode 26 also Description: SwiftUI canvas previews consistently crash XCPreviewAgent with EXC_BAD_ACCESS / SIGSEGV when rendering previews for a fairly large app target, across multiple different SwiftUI views (not tied to one specific file's code). Workaround found: the crash does not occur when "Use Legacy Preview Execution" is enabled (Xcode's preview settings). With the default (non-legacy, JIT-based) preview execution path, it crashes reliably; switching to legacy execution, previews render normally. Possible contributing factor — project size / timing: we suspect the size of the project may also be a factor, independent of the crash itself. The new (non-legacy) execution path recompiles/JITs the app for the canvas on every preview, and for a target this large that process takes noticeably longer than it does under legacy execution. It's plausible that on top of the crash described below, the new path is also more prone to timing out or failing under load on larger projects, simply because there's more to JIT-compile and load within whatever time budget the preview agent allows. We can't fully separate "crashes because of X" from "runs out of time because of project size" from the crash logs alone, but both seem worth flagging since they may share the same root cause in the new execution path's handling of larger binaries. Crash signature #1 (default preview execution, first attempts): Crashing Thread: 0 libswiftCore.dylib swift_conformsToProtocolMaybeInstantiateSuperclasses(...) 1 libswiftCore.dylib swift_conformsToProtocolWithExecutionContext 2 libswiftCore.dylib swift::_conformsToProtocol(...) 3 libswiftCore.dylib swift::_checkGenericRequirements(...) Termination: SIGSEGV / Segmentation fault: 11 Crash signature #2 (default preview execution, after removing an unrelated third-party SDK dependency from the previewed module, to rule it out as a cause): Crashing Thread ("com.apple.xojit_executor.wrapper_functions"): 0 libobjc.A.dylib readClass(objc_class*, bool, bool) 1 libobjc.A.dylib map_images_nolock 2 libobjc.A.dylib map_images 3 libobjc.A.dylib _objc_map_images 4-7 <unsymbolicated / anonymous image, source="A" (Absent) in the crash report> Exception: EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS In the second case, the crash log's usedImages list shows the frames above the objc runtime resolving to an image with no path, no resolvable UUID, and "source": "A" — this appears to be the dynamically JIT-compiled preview binary that XOJITExecutor builds and hot-loads for the canvas (rather than a normal on-disk framework), and the crash occurs while the Objective-C runtime is registering classes from it during _objc_map_images. What we've ruled out: Not caused by the specific SwiftUI view being previewed — reproduces across multiple unrelated views in the same target. Not caused by a specific third-party SDK: we removed a heavyweight closed-source analytics SDK dependency from the previewed module entirely (confirmed via successful xcodebuild build with zero references left), and the crash still occurred with an equivalent signature under default preview execution. Confirmed via symbolicated .ips crash reports in ~/Library/Logs/DiagnosticReports/XCPreviewAgent-*.ips that the crashing frames are inside Apple's own preview infrastructure (libobjc.A.dylib, libswiftCore.dylib, XOJITExecutor), not in application or third-party framework code. Confirmed the failure is specific to the new (non-legacy) preview execution path: enabling "Use Legacy Preview Execution" eliminates the crash entirely, with no other changes. Question for the community: Has anyone else seen SwiftUI Previews crash with a libobjc/map_images or swift_conformsToProtocol* segfault specifically on Xcode 27 / iOS 27 simulator with the new (non-legacy) preview execution path, for apps with a large number of linked frameworks? Does project size/build time make the new execution path more likely to fail or time out for anyone else? Is "Use Legacy Preview Execution" the recommended workaround until this is fixed, or should this be filed separately as Feedback?