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.

On Xcode 26 and earlier versions, two-finger touches were possible on Simulator by holding down the option key. On Xcode 27 with Device Hub, this is no longer possible. While the trackpad can be used for pinch and rotate gestures, two-finger taps and two-finger pans are not possible. This is a major regression that renders our app basically unusable in Device Hub. We rely on two-finger tap and pan gestures to navigate our 3D models. Not being able to do this in Device Hub and in Xcode previews would be a huge loss. Is this actually no longer supported or am I missing something?

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 ?

I have been trying for 24 hours to upload app, and first time this has happened in 8 years and 100+ uploads. Please help. Validate App and Upload both hang indefinitely at "Preparing" in Xcode Organizer. No error is ever returned — the progress bar freezes and the operation never completes or times out. Transporter 1.4.5 fails identically. Key detail: archive 2.4.3 (build 123), which Apple accepted and processed on Sept 10, 2026, now hangs the same way when validated. Same machine, same Xcode, same Apple ID. This rules out the archive, its signature, and its provisioning profile. Already ruled out: two independent networks (home Wi-Fi and iPhone cellular hotspot); the archive itself (known-good build 123 fails identically); Xcode install (27.0 / 27A266a, xcode-select verified correct); Apple ID session (signed out and back in three times); full reboot. macOS 27.0 (26A428) on MacBookPro18,4. Last successful upload Sept 10, 2026. 100+ prior archives uploaded without incident over several years. macOS has updated twice since Sept 10. Separately: Transporter 1.4.5 crashes on macOS 27.0 with an unhandled exception in TransporterKit while drawing its activity queue (EXC_BREAKPOINT via +[NSApplication _crashOnException:]).

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?

For the life of me, I cannot find how to bring up the Siri Remote in the Apple TV Simulator in Xcode 27 Device Hub (Beta). Is it no longer available? I have always seem to have had issues using the computer's keyboard for navigating my tvOS apps. Maybe it's me, but the Siri Remote always worked perfectly fine. I hope the remote will make a reappearance in the next beta... ?

Is anyone else having issues uploading an archive to App Store Connect? I went to validate an archive of my app, and seems to hang during validation. I've tried just validating the app, and tried Transporter as well. It hangs on the analyzing app. How to troubleshoot?

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.

I am using Coding Intelligence, powered by Claude, in the first production release of Xcode 27.0 (in MacOS 26.7). Initially it was working ok. But after less than a day, it now crashes every time it needs to ask for permission for any shell command. And each time I restart things, it burns through a ton of tokens. ☹️ Any suggestions? (I'll file a bug report right now…)

Xcode 27 keeps failing to download the Documentation, it shows "Preparing to download" and spins the camomile endlessly. I checked logs (with help of AI) and found this: Xcode queries com.apple.MobileAsset.AppleDeveloperDocumentation. Metadata catalog loading suceeds. Then asset resolution loops with: MAQueryTooManyResults - Asset load result ... 13 (MAQueryTooManyResults) Also CSSMERR_CSP_VERIFY_FAILED from mobileassetd during this sequence. In my /System/Library/AssetsV2 I have 3 old .asset files all from Xcode 26, the last one updated on Jun 12. But I don't think it's the reason for the error. What would you suggest to recover the documentation?