Some Macs recently received a macOS system update which disabled the simulator runtimes used by Xcode 15, including the simulators for iOS, tvOS, watchOS, and visionOS. If your Mac received this update, you will receive the following error message and will be unable to use the simulator: The com.apple.CoreSimulator.SimRuntime.iOS-17-2 simulator runtime is not available. Domain: com.apple.CoreSimulator.SimError Code: 401 Failure Reason: runtime profile not found using "System" match policy Recovery Suggestion: Download the com.apple.CoreSimulator.SimRuntime.iOS-17-2 simulator runtime from the Xcode To resume using the simulator, please reboot your Mac. After rebooting, check Xcode Preferences → Platforms to ensure that the simulator runtime you would like to use is still installed. If it is missing, use the Get button to download it again. The Xcode 15.3 Release Notes are also updated with this information.

I constantly manually allow Codex to read Xcode 27 skills, but I don't want to allow it to read from any arbitrary directory, so I didn't enable always allow AgentRead. Question is in the title

MacBook Air (Apple silicon), macOS 26.6.2 (25G83). I have a persistent CoreSimulator/MobileAsset issue. I do not have an Xcode project, Simulator devices, or an active need for iOS Simulator runtimes. Using Apple’s signed CoreSimulator simctl binary, I removed iOS 18.4 (22E238) and iOS 18.5 (22F77) through the documented: simctl runtime delete workflow, after simctl reported each runtime as Ready, Verified, and Deletable. Immediately after deletion, the runtime registration and mounted runtime image disappeared. However, after a normal Mac restart or later CoreSimulator service activity, both runtimes reappear under new image UUIDs and are automatically mounted read-only again. The underlying Apple MobileAsset parents remain present and report NeverCollected: iOS 18.4 / build 22E238: about 8.9 GiB iOS 18.5 / build 22F77: about 8.9 GiB The related CoreSimulator dyld cache also rebuilds to about 7.1 GiB. I have not manually deleted protected Apple assets, killed Apple services, or modified mounts. The only removal attempted was Apple’s own simctl runtime delete command. Expected result: After a successful documented runtime deletion, the runtime should remain unregistered and unmounted, and the Apple-managed backing storage/cache should become reclaimable through a supported process. Observed result: The same runtime builds return after restart/service activity, with new UUIDs and automatic mounts, while their retained MobileAssets remain. Could Apple please advise why CoreSimulator/MobileAsset reconciliation is re-registering deleted runtimes, whether NeverCollected prevents supported cleanup, and what supported procedure can permanently remove or reconcile these unused runtimes? Useful read-only checks: SIMCTL_PATH=/Library/Developer/PrivateFrameworks/CoreSimulator.framework/Versions/A/Resources/bin/simctl "$SIMCTL_PATH" list runtimes "$SIMCTL_PATH" runtime list -v du -skx /Library/Developer/CoreSimulator/Caches/dyld

Hi everyone, We're running Xcode/Swift CI builds inside macOS VMs (Tart / Apple Virtualization Framework) on a 32-core Apple Silicon host. While investigating VM build performance, we noticed a consistent pattern: assigning 24 vCPUs to the VM produces faster overall build times than assigning 26-30 vCPUs, despite the host still showing idle CPU capacity. With higher vCPU allocations, the build starts by utilizing the CPUs well, but later stages show a noticeable drop in CPU utilization and overall build throughput. In contrast, the 24-vCPU configuration maintains more stable CPU usage and completes the workload faster. This was observed repeatedly with the same Xcode/Swift workload. The result seems counterintuitive because the VM is not exhausting the available host CPU resources. Our testing identified 24 vCPUs as the current sweet spot, even though the host provides 32 physical cores. Has anyone observed similar behavior? Some questions I have: Do Xcode builds stop scaling efficiently beyond a certain vCPU count? Are there known scheduler or virtualization effects when assigning nearly all host cores to a macOS VM? Is there a commonly recommended practice to leave a number of host cores unassigned, even when the host appears mostly idle?

I tried to upload my build into testflight with XCode -> Product -> Archive -> Distribute App but this error keeps showing up: "No Team Found in Archive, Use the Signing & Capabilities editor to assign a team to the targets and build a new archive." However, my Apple ID IS connected and the bundle ID is the same as in my App Store Connect. What can I do? I tried deleting all archives, restarting Xcode & my Mac, still nothing happend. I can't get it to upload...

Hi everyone, I’m currently running macOS 27.0 beta (26A5388g) on my Mac, along with the latest Xcode 27 beta, and I’ve recently started experiencing a serious issue where multiple macOS system services are repeatedly crashing. Initially, I started getting repeated “intelligencetasksd quit unexpectedly” notifications. At first it happened occasionally, but it has now become extremely frequent. After dismissing one crash notification, another system service often crashes shortly afterward. I’ve also seen services related to Intelligence / intents crashing. The notifications keep appearing one after another to the point where I’m barely able to use the Mac normally — including difficulty typing and interacting with applications. The issue is not limited to Xcode. It appears to affect macOS system services themselves. System information Mac: Mac15,2 (Apple silicon) macOS: macOS 27.0 beta, build 26A5388g Xcode: Xcode 27 beta Issue started: After running the macOS beta for some time; it has progressively become more frequent Main process initially crashing: intelligencetasksd Path shown in crash report: IntelligenceTasksEngine.framework/Support/intelligencetasksd Exception: EXC_BREAKPOINT (SIGTRAP) I have attached a screenshot of the crash report showing the intelligencetasksd crash. Has anyone else experienced this on macOS 27 beta? Is there a known issue with the new Intelligence/Intents services, or is there a recommended way to reset/rebuild the relevant system components? At this point the repeated crashes are making the Mac extremely difficult to use, so I’d really appreciate any troubleshooting steps or information about whether this is a known beta issue. Thanks!

I tried to upload my build into testflight with XCode -> Product -> Archive -> Distribute App but this error keeps showing up: "No Team Found in Archive, Use the Signing & Capabilities editor to assign a team to the targets and build a new archive." However, my Apple ID IS connected and the bundle ID is the same as in my App Store Connect. What can I do? I tried deleting all archives, restarting Xcode & my Mac, still nothing happend. I can't get it to upload...

Hello! I'm new to xcode and am developing an iOS app. I hit the following error when build my app: MY_SHA no identity found Command CodeSign failed with a nonzero exit code I have generated my certificate through xcode. I can see the Certificate and the private key in Keychain -> login. But it's not that private key is under the Certificate. They are listed in parallel. The certificate appears in Certificate tab but not in My Certificate Tab. Would that matter? security find-certificate -a -Z | grep -A1 "Apple Development" Gives me the certificate. But security find-identity -v -p codesigning give 0 valid identity found. Could you help me figure out what could be the reason for this? I've been stuck for several days now. Thank you so much!

Translated Report (Full Report Below) Process: Xcode [3530] Path: /Applications/Xcode.app/Contents/MacOS/Xcode Identifier: com.apple.dt.Xcode Version: 26.6 (24959) Build Info: IDEApplication-24959000000000000~2 (17F113) Code Type: ARM-64 (Native) Role: Background Parent Process: launchd [1] Coalition: com.apple.dt.Xcode [1786] User ID: 501 Date/Time: 2026-08-17 23:51:47.2077 +0100 Launch Time: 2026-08-17 23:51:47.0576 +0100 Hardware Model: MacBookPro18,2 OS Version: macOS 26.6.2 (25G83) Release Type: User Crash Reporter Key: A48FA3EB-7CA7-3507-8300-E41E5EDD5284 Incident Identifier: 7B4676E3-9607-4890-B61E-04DE788BC3C3 Time Awake Since Boot: 1000 seconds System Integrity Protection: enabled Triggered by Thread: 0, Dispatch Queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6 Terminating Process: Xcode [3530] Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x189cb05e8 __pthread_kill + 8 1 libsystem_pthread.dylib 0x189ceb8d8 pthread_kill + 296 2 libsystem_c.dylib 0x189bf1978 abort + 148 3 libsystem_c.dylib 0x189bf1a94 abort_report_np + 84 4 Xcode 0x102238ed0 main.cold.1 + 36 5 Xcode 0x102238e1c main + 340 6 dyld 0x1899204e4 start + 6992 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0x0000000000000073 x5: 0x000000000000002e x6: 0x000000016dbc7248 x7: 0xfffff0003ffff800 x8: 0x05371949b50970d8 x9: 0x05371948437bd158 x10: 0x0000000000000002 x11: 0x00000000fffffffd x12: 0x0000000000000000 x13: 0x0000000000000000 x14: 0x0000000000000000 x15: 0x0000000000000000 x16: 0x0000000000000148 x17: 0x00000001f7d6b358 x18: 0x0000000000000000 x19: 0x0000000000000006 x20: 0x0000000000000103 x21: 0x00000001f672a260 x22: 0x0000000102a04ce0 x23: 0x00000001f6731908 x24: 0x0000000000000001 x25: 0x000000016dbc76a0 x26: 0x00000001f672ba70 x27: 0x0000000000000000 x28: 0x0000000000000000 fp: 0x000000016dbc73c0 lr: 0x0000000189ceb8d8 sp: 0x000000016dbc73a0 pc: 0x0000000189cb05e8 cpsr: 0x40001000 far: 0x0000000000000000 esr: 0x56000080 (Syscall) Binary Images: 0x102238000 - 0x10223bfff com.apple.dt.Xcode (26.6) <8025d4bb-71ea-3f57-bade-2e3c847b6cf3> /Applications/Xcode.app/Contents/MacOS/Xcode 0x189ca7000 - 0x189ce42e7 libsystem_kernel.dylib () /usr/lib/system/libsystem_kernel.dylib 0x189ce5000 - 0x189cf1b3b libsystem_pthread.dylib () /usr/lib/system/libsystem_pthread.dylib 0x189b79000 - 0x189bfa1e7 libsystem_c.dylib () /usr/lib/system/libsystem_c.dylib 0x189900000 - 0x1899b34ff dyld () <74e52480-c2bd-3c8d-812d-95fe2b74a096> /usr/lib/dyld 0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???

I can't find the "Show live issues" that was under "General > Issues > Show live issues [toggle]" It is present in Xcode 26.6 but not in Xcode 27 beta 5

Hi, I have listed below the Feedbacks for Xcode 27, please have a look at it, considerable time was spent on filing these feedbacks, thanks! Environments All of them were tested on the environment: macOS 26.5.1 (25F80) Xcode 27.0 beta (27A5194q) Feedbacks FB23133706 (Git stage tab) FB23132869 (markdown - code block) FB23132403 (markdown - search) FB23078039 (stash - slow / unresponsive) FB23077930 (stash - allow multiselection) FB23055381 (Run destination - Clear recents) FB23041713 (SwiftUI preview - SwiftData) FB23033844 (Bundle ID) FB23033231 (Device Hub - sizes)

I have an app with a Widget Extension. Both the main app and the widget extension link against the same Swift Package, which contains a localization bundle (String Catalog) used by SwiftUI views inside the package. To make the package's views follow the app's configured language (rather than the system language), I set CFBundleAllowMixedLocalizations to NO in the Info.plist of each target (main app and widget extension). Behavior in the main app: This works as expected. If the app only supports Korean, the package's views display Korean text even when the system language is set to English. Behavior in the widget: The same views (from the same package) display English instead of Korean, even though the widget extension has the identical CFBundleAllowMixedLocalizations = NO setting and the widget's view code lives entirely in the package — not in the widget extension target itself. Question: As far as I understand, widgets are supposed to follow the host app's language setting. Given that both targets have the same Info.plist configuration, why would the widget extension resolve localized strings differently from the main app for code in the same package? Is this expected behavior for widget extensions specifically, or a bug? Is there a recommended workaround to force a widget extension (and by extension, the Swift Package code it runs) to use the app's language instead of the system language?

I’m seeing a regression in Xcode 26.4 where Interface Builder will not allow connecting IBOutlets or IBActions. Symptoms: The usual gutter circle/dot does not appear next to IBOutlet / IBAction in the code editor Because of this, I cannot: drag from storyboard → code drag from code → storyboard The class is valid and already connected to the storyboard (existing outlets work) Assistant Editor opens the correct view controller file Important: The exact same project, unchanged, works perfectly in Xcode 26.3. I can create and connect outlets/actions normally there. ⸻ Environment Xcode: 26.4 macOS: 26.4 Mac Mini M4 Pro 64G Ram Project: Objective-C UIKit app using Storyboards This is a long-running, ObjC, project (not newly created) ⸻ What I’ve already tried To rule out the usual suspects: Verified View Controller Custom Class is correctly set in Identity Inspector Verified files are in the correct Target Membership Verified outlets are declared correctly in the .h file: @property (weak, nonatomic) IBOutlet UILabel *exampleLabel; Opened correct file manually (not relying on Automatic Assistant) Tried both: storyboard → code drag code → storyboard drag Tried using Connections Inspector Clean Build Folder Deleted entire DerivedData Restarted Xcode Updated macOS to 26.4 Ran: sudo xcodebuild -runFirstLaunch Confirmed required platform components installed Reopened project fresh ⸻ Observations In Xcode 26.4 the outlet “connection circles” are completely missing In Xcode 26.3 they appear immediately for the same code Existing connections still function at runtime — this is purely an Interface Builder issue ⸻ Question The gutter circles appearance has always been flaky in Xcode over the 13+ years I've been using it but now with 26.4 they have completely disappeared. Has anyone else seen this in Xcode 26.4, or found a workaround? At this point it looks like a regression in Interface Builder, but I haven’t found any mention of it yet.

[Q] Is it a known issue that the Xcode static analyzer hallucinates past results? Basically, the issue I've been observing for a few releases of Xcode now (including 27b) is that if you run a static analysis, fixes the reported issues and re-run a static analysis, you will get exactly the same results as with the first run. It's as if Xcode did not take into account the fixes. If you clean the builds (cmd + shift + K), and run the analysis again, this time, you will get up-to-date results.

I've been trying for months to get Gemini 3.5 Flash to work with Xcode 27 Beta (1-3) agentic coding but have failed. Xcode currently uses Gemini CLI v0.42.0 from last year, so it can't call Gemini 3.5 Flash even though all that needs to change is a few characters in the API call. Gemini users are currently forced to choose between 3.1 Pro and 3.1 Flash Preview--both weren't the best choices two months ago, but with the release of 3.6 Flash which is better at coding that 3.1 Pro and miles cheaper, these choices are now unsuitable for any serious workload. I live in Hong Kong, where OpenAI and Anthropic services aren't offered, so Google is the only (native) AI provider for Xcode agentic coding. The cost issue from funneling all the work into 3.1 Pro is terrible especially with some agent bugs that have yet to be ironed out. Given Apple's close partnership with Google on AI, I'm genuinely surprised that after 4 Betas we're still using a Gemini CLI from 2025 that forces users to choose between two very unappealing models. Xcode is basically forcing Google users to switch to OpenAI/Anthropic. Questions: I'd like to know if this will be fixed soon and whether Google users should expect slower updates (i.e. be forced to use older models). Does anyone know of any workarounds?

In Xcode 27 Beta 4 (27A5228h), building a project that has a SwiftPM binary target (xcframework) linked directly from both an app target AND a framework target that is embedded in that app fails with "Multiple commands produce" errors. The same project and pbxproj builds successfully in Xcode 27 Beta 3 (27A5218g), so this is a regression introduced in Beta 4. Steps to Reproduce Create a new iOS App project. Add a Framework target (e.g. "SampleCommon") and embed it into the app. Add a SwiftPM dependency for a package that vends a binary xcframework product. Confirmed with airbnb/lottie-spm 4.6.1 (https://github.com/airbnb/lottie-spm). In "Frameworks, Libraries, and Embedded Content" of the app target, add the SwiftPM product (Lottie) with "Embed & Sign". In "Frameworks and Libraries" of the framework target, add the same SwiftPM product (Lottie). Build the app scheme for iOS Simulator. Expected result Build succeeds. The xcframework is embedded exactly once into the .app bundle. This is the behavior in Xcode 27 Beta 3 and Xcode 26. Actual result Build fails with: error: Unexpected duplicate tasks error: Multiple commands produce '.../<App>.app/Frameworks/Lottie.framework/Lottie' error: Multiple commands produce '.../<App>.app/Frameworks/Lottie.framework' Two Copy tasks are emitted for the same output path in the app target: Copy from Build/Products/Debug-iphonesimulator/PackageFrameworks/Lottie.framework Copy from SourcePackages/artifacts/lottie-spm/Lottie/Lottie.xcframework/ios-arm64_x86_64-simulator/Lottie.framework Additionally, an auto-generated target named "Lottiedynamic-product" emits duplicate MkDir / ProcessInfoPlistFile tasks for PackageFrameworks/Lottie.framework, which suggests the packaging path for binary xcframework products has been duplicated in Beta 4. Regression Xcode 27 Beta 3 (27A5218g): builds successfully Xcode 27 Beta 4 (27A5228h): fails with the above errors Xcode 26.x: builds successfully Minimal reproduction The issue reproduces on a 2-target Xcode project (app + framework) with airbnb/lottie-spm added and linked from both targetstory captures the smallest triggering diff: pattern1: app links Lottie only -> BUILD SUCCEEDED pattern2: framework links Lottie only -> BUILD SUCCEEDED pattern3: both app and framework link Lottie -> BUILD FAILED (only on Beta 4) Only the framework target's packageProductDependencies and Frameworks build phase entries differ between the succeeding and failing states. Workaround Link the SwiftPM binary product from only one target (either the app or the framework, not both). If only the framework tarl gets the framework transitively at runtime. Impact Any project that uses a SwiftPM binary xcframework and organizes code across multiple linked targets (a very common pattern for larger apps) is blocked from adopting Xcode 27 Beta 4. Environment Xcode 27.0 Beta 4 (27A5228h) macOS 26.5.2 Package: airbnb/lottie-spm 4.6.1 Destination: iOS Simulator (iPhone 17, latest)

I am experiencing an App Store submission issue after updating my Mac development environment. A build of my iOS app can be uploaded and appears in App Store Connect/TestFlight, but when I try to use the build for App Review, it is rejected because it was built using a beta version of Xcode. I am currently using Xcode 27 beta because of the macOS environment installed on this Mac. I have been advised that I may need to return the Mac to a stable macOS/Xcode environment and rebuild the app. This is particularly concerning because the app and its development data already exist on this Mac, and reverting the development environment may require a full backup and OS reinstallation. I would like to know: What is the officially supported procedure to return to a stable macOS and Xcode environment without losing development data? Which stable Xcode version should be used to rebuild the app for App Store submission? Is there any supported way to submit the existing build, or must it be rebuilt completely with a non-beta Xcode? I would also like to know whether other developers using the current beta environment are experiencing the same App Store Connect submission restriction. I would also like clarification regarding responsibility and remediation in this situation. If a development environment provided through Apple’s software update or beta distribution results in an existing application becoming unable to be submitted to App Store Connect, what responsibility does Apple assume for the resulting disruption to developers? In particular, if resolving the issue requires backing up development data, reinstalling macOS, reinstalling Xcode, and rebuilding the application, does Apple provide an official recovery procedure or support for developers affected by this situation? I believe this is important not only for my application, but also for other developers who may encounter the same issue. I would appreciate an official clarification from Apple regarding both the technical solution and Apple’s policy for developers affected by this problem. Thank you.

I’m seeing a major change in reported memory usage (and eventual termination due to memory pressure) when running a Core ML workload built with Xcode 27 on iOS/iPadOS 27. The source code, model files, and MLModelConfiguration are unchanged. Only the Xcode/SDK version used to build the app differs. On the same iPad running iPadOS 27: Xcode 26 build: model loading and prediction complete normally, with a relatively small reported application footprint. Xcode 27 build: the application footprint grows continuously as models are loaded and can exceed 5 GB. The app is eventually terminated unless models are unloaded very aggressively or the increased-memory-limit entitlement is used. I also tested an Xcode 27 build on a device running iOS 26. Its reported peak was only around 300 MB. This suggests the change requires both an Xcode 27-linked binary and the iOS 27 runtime. The workload consists of several compiled Core ML models using .cpuAndNeuralEngine. Loading models sequentially instead of concurrently does not materially change the final footprint. Releasing each MLModel after use does reduce it, so this appears to be model or Neural Engine residency being charged to the application rather than a conventional heap leak. I noticed that the iOS 27 release notes mention Neural Engine memory now being attributed to the application instead of the system. However, I’m unclear about the practical consequences of that change. If the same Neural Engine resources were already physically resident on iOS 26, I would have expected them to contribute to system memory pressure even when they were not attributed directly to the application. Instead, the older configuration runs comfortably, while the Xcode 27/iOS 27 combination approaches or crosses the application’s per-process memory limit. A few additional observations: The problem is more likely to occur after Core ML has already compiled and specialized the models. Cached model loading is much faster and the footprint grows quickly. The first uncached run can survive model preparation because specialization spaces the loads farther apart. Under Instruments, the app often does not terminate, presumably because profiling slows the workload enough to change the peak. os_proc_available_memory() decreases in line with the newly reported footprint. With the increased-memory-limit entitlement, the workload completes, but the reported footprint still reaches several gigabytes. Has anyone else observed a large Core ML memory increase specifically with an Xcode 27 build running on iOS 27? In particular, I’m trying to understand: Is this purely a change in how existing Neural Engine memory is accounted for, or does the new runtime also retain or allocate more memory? Is the new accounting used for the application’s jetsam/per-process memory limit? Is this behavior intentionally gated by the linked SDK version? That would explain why an Xcode 26 build behaves differently on the same iOS 27 device. Should applications now treat the Neural Engine residency of every loaded MLModel as part of their process-memory budget and unload models accordingly? Are there recommended APIs or Core ML loading strategies for controlling this residency? Any confirmation that others are seeing the same Xcode 27/iOS 27 behavior—or clarification of the intended memory-accounting model—would be very helpful.

I'm unable to use the Claude Agent in Xcode 26 (stable release) running on macOS 27 beta 5. Steps to reproduce: Open Xcode 26 Settings > Intelligence Select Claude Agent Expected: The Account section loads and allows me to sign in / manage my Claude account. Actual: The Account row shows a loading spinner indefinitely and never resolves, so I can't sign in or use the Claude Agent at all. Environment: Xcode 26 (stable), macOS 27 beta 5. Is this a known incompatibility with macOS 27 beta 5? Is there a workaround (e.g. clearing a cache or re-adding the account) to get the Claude Agent account section to load?

My app start up has became horrid. It takes 1 minute to open SQLlite database for my rust core. Impossible to work... I have Address Sanitizer, Thread Perf Checker and Thread Sanitizer disabled...

I’m seeing a reproducible issue in both Xcode 26 and Xcode 27 where Coding Assistant appears to stop autocompleting when a project contains a larger number of Swift Package dependencies. Symptoms: Autocomplete suggestions from Coding Assistant stop appearing. File targeting with @ stops working. The issue typically appears shortly after opening the project If I start a brand-new chat immediately after opening the project, Coding Assistant sometimes works briefly before failing Reducing or removing Swift Package dependencies fixes the issue I’ve created a sample project that reproduces the problem and have also filed Feedback Assistant report: FB23341243 The issue seems related to package count or project complexity rather than any specific package, although I haven’t yet identified the exact threshold that triggers it. Has anyone else run into this or has anyone found a workaround?