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)

Seems like there is an issue in Xcode 27 beta 4 & 5 where DeviceHub doesn't show iOS 16 devices or simulators. I've checked the filters to ensure I haven't hidden anything and the are listed in the Xcode destination dropdown.

After upgrading to Xcode 16 and iOS 18 SDK, my Objective-C project has serious BOOL value errors only on iOS 18 Simulator. The same code works perfectly on real iPhone devices and Mac Catalyst. When getting BOOL return values from methods or assigning system API results to BOOL properties, it generates unexpected negative large numbers. Since C language treats all non-zero values as true in if() judgment, our business logic is completely broken. Could you please explain what underlying changes in iOS 18 Simulator or Xcode 16 compiler caused this BOOL parsing problem? Thank you.

Hey all, the codex sign in isn't working for me in Agents. I am using the 26.5 release candidate version. It always says "Not Signed In". I have completed the Sign In process multiple times. Anyone else seeing this? I have filed Feedback FB22732574

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?

Hi, I am unable to sign into the sandbox account on the simulator. Settings > Developer > Sandbox Apple Account > Sign in Xcode: 26.6 (17F113) Xcode Simulator: 16.0 (1063.4) I have even tried on Device Hub on Xcode 27. I vaguely remember being able to sign into the simulator using Questions: Is anyone able to sign into Sandbox account on the simulator / device hub? Is there any workaround? Is this a known issue?

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.

Recently, with Xcode 26.6, we've been unable to install apps on some physical devices (iPhone, iPad). Some devices work fine. An alert saying "Install Application not available" appears. I reported it through Feedback Assistant, but someone from Apple replied that it's an issue with Xcode 27.0 beta and told me to install the latest Xcode 27. However, I'm actually using Xcode 26.6. The issue is still unresolved, so if anyone learns anything, I'd appreciate it if you could share an update.

I am trying to upgrade my app to use Xcode 26 and I cannot get my tests to launch. I am trying to launch tests to the simulator, and I always get this error after 300 second timeout: "encountered an error (The test runner hung before establishing connection.)" There are no other errors getting logged. I can run to the same simulator just fine, and in Xcode 16 the tests launch with no issues. The tests also run fine on an actual iPhone. Thanks in advance.

Everything has been updated. Countless reboots and reinstalls. Yet Xcode still won't open. Keep getting "Xcode quit unexpectedly dialog" with buttons to Reopen, Ignore, Report. Any suggestions on what lingering file is killing Xcode on open? Thanks!

When I try to download the metal toolchain 26.6 (17F109) in Xcode it just stays on preparing to download. Does anyone have an idea on how to fix this? I'm on macOS 26.6.1 (25G76)

Xcode 26.6 It's showing crashes from the App Store Analytics. But no crash logs from Xcode Organizer. I have tried to sign out and log in to Xcode again. I also changed the folder /Library/Developer/Xcode/Products and View > Reload the Organizer. Nothing helps. It's still empty for all versions.

Can iOS 26.6 + Xcode 26.6 be used for automated testing? Are there any successful case studies?

I am currently using Xcode 16 (16A242d) and testing on an iPhone 7 running iOS 12.1.3. However, when I try to launch the app on the device, it crashes immediately. Below are the crash logs from the iPhone 7: 错误 11:54:55.731858+0800 kernel Sandbox: assertiond(62) System Policy: deny(1) file-read-metadata /private/var/mobile/Library/DuetExpertCenter/caches/ATXCacheFile-_ATXAppPredictor-TotalScore 错误 11:54:55.731897+0800 kernel Sandbox: assertiond(62) System Policy: deny(1) file-read-metadata /private/var/mobile/Library/DuetExpertCenter/caches 错误 11:54:55.754498+0800 kernel Sandbox: duetexpertd(132) deny(1) mach-lookup com.apple.proactive.ActionPrediction.predictions 错误 11:54:55.756102+0800 duetexpertd Unable to remove recent engagement cache file. Error: Error Domain=NSCocoaErrorDomain Code=4 UserInfo={NSFilePath=, NSUserStringVariant=, NSUnderlyingError=0x100db60a0 {Error Domain=NSPOSIXErrorDomain Code=2}} 错误 11:54:56.571640+0800 symptomsd Attempt to add an app with insufficient id, info { BKSApplicationStateAppIsFrontmost = 1; BKSApplicationStateExtensionKey = 0; SBApplicationStateDisplayIDKey = "com.igetcool.app"; SBApplicationStateKey = 8; SBApplicationStateProcessIDKey = 696; SBApplicationStateRunningReasonsKey = ( { SBApplicationStateRunningReasonAssertionIdentifierKey = UIApplicationLaunch; SBApplicationStateRunningReasonAssertionReasonKey = 10000; } ); SBMostElevatedStateForProcessID = 8; } 错误 11:54:56.829372+0800 assertiond [IGCProject:696] SyscallError: setpriority(PRIO_DARWIN_ROLE, 696, 3): No such process 错误 11:54:56.944833+0800 dasd Activity not tracked as being started, ignoring it 错误 11:55:06.153790+0800 symptomsd Attempt to add an app with insufficient id, info { BKSApplicationStateAppIsFrontmost = 1; BKSApplicationStateExtensionKey = 0; SBApplicationStateDisplayIDKey = "com.igetcool.app"; SBApplicationStateKey = 8; SBApplicationStateProcessIDKey = 697; SBMostElevatedStateForProcessID = 8; } 错误 11:55:06.430433+0800 assertiond [IGCProject:697] SyscallError: setpriority(PRIO_DARWIN_ROLE, 697, 3): No such process 错误 11:55:13.158889+0800 symptomsd Attempt to add an app with insufficient id, info { BKSApplicationStateAppIsFrontmost = 1; BKSApplicationStateExtensionKey = 0; SBApplicationStateDisplayIDKey = "com.igetcool.app"; SBApplicationStateKey = 8; SBApplicationStateProcessIDKey = 699; SBMostElevatedStateForProcessID = 8; } 错误 11:55:13.416290+0800 assertiond [IGCProject:699] SyscallError: setpriority(PRIO_DARWIN_ROLE, 699, 3): No such process I am trying to understand what is causing this issue. Even after archiving and installing the app, it still crashes. According to the official documentation, Xcode 16 is supposed to support iOS 12, but this issue persists. I would like to know the possible reasons for this behavior.

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.

Hi everyone, I'm trying to run a Mac app UI tests on our CI servers (Mac minis). The servers are logged in, but the lock screen is active (aka, the active process is the com.apple.loginwindow). UI tests end up failing with: Failed to activate application (current state: Running Background) Is there any way to run Mac UI tests on a server like this without having to disable the lock screen? Our admins will likely not accept that solution, and I agree with them. Aside from running a full VM just for the UI tests, I can't find any solution. Thank you, Miguel Arroz

Sometime recently our XCUITests started to hang after awhile and so I had filed this Feedback ticket. With the release of Xcode 15.3 I re-ran the test in the project I had attached to that Feedback ticket (which taps a "Go!" button which pushes a new view controller and then verifies the value of a UILabel) and the tests are running crazy slow on a device now running iOS 17.4. It has been half an hour and only 14 of 100 iterations have been run. Anyone else experience severe performance degradation in their XCUITests with Xcode 15.3?

Filed FB24179855 for this. Posting here so others hitting similar limitations can track and/or reference it (Apple's triage reportedly weighs duplicate count). Issue <stdbit.h>, the C23 standard header for bit-manipulation utilities (stdc_leading_zeros, stdc_count_ones, stdc_bit_width, etc.) from C23 §7.18, is not present in the macOS SDK libSystem. Worth noting this is a libc/SDK gap, not a compiler gap. Apple Clang accepts -std=c23 fine, and <stdckdint.h> (also C23, also library-level, e.g. ckd_add) is already present and working correctly. So C23 library headers are clearly being landed in libSystem incrementally. stdbit.h just hasn't made it in yet. If anyone's found a workaround (other than falling back to __builtin_clz/__builtin_popcount etc.) or has visibility into whether this is scheduled, would be good to hear. Repro #include <stdbit.h> int main(void) { return stdc_leading_zeros((unsigned)0); } $ /usr/bin/cc -std=c23 repro.c repro.c:1:10: fatal error: 'stdbit.h' file not found 1 | #include <stdbit.h> | ^~~~~~~~~~ 1 error generated. Environment Apple clang version 21.0.0 (clang-2100.1.1.101) Target: arm64-apple-darwin25.6.0