When I create an archive file and attempt to upload the app using the "Distribute App" button, the upload fails with the error "Automatic signing cannot update bundle identifier...". (The detailed message is below.) When creating an archive file in Xcode, I unchecked "Automatically Manage Signing" and proceeded with the archive. The message says "Font Enumeration," but other apps with the same option enabled upload successfully. Therefore, I believe the "Font Enumeration" option is not the issue. I tried creating a new provisioning file, but it still doesn't work. I deleted all DerivedData files from my Mac storage, restarted Xcode, and tried again, but it still doesn't work. This keeps happening only for certain targets (specific apps) in Xcode. Does anyone know how to fix this? Xcode is the latest version. Message: Automatic signing cannot update bundle identifier "com.xxxxxx.xxxxxx". Automatic signing cannot update your registered bundle identifier to enable Font Enumeration. Update your bundle identifier on https://developer.apple.com/account and then try again.

In the first Xcode 16 beta, none of my SwiftUI previews work - they all just crash on start up. Has anybody run into this and found a workaround? Have tried all the usual steps of cleaning the project/restarting Xcode.

After exerting a custom model with nms=True. In Xcode, the outputs show as: confidence: MultiArray (0 × 5) coordinates: MultiArray (0 × 4) I want to set fixed shapes (e.g., 100 × 5, 100 × 4), but Xcode does not allow editing—the shape fields are locked. The model graph shows both outputs come directly from a NonMaximumSuppression layer. Is it possible to set fixed output dimensions for NMS outputs in CoreML?

I'm facing an issue with Xcode Cloud. Every branch I push to my GitLab repository is not appearing as selectable when I try to create a build with my workflow. Additionally, if I try to update the workflow from Xcode, it crashes every time I save the changes. Any help would be appreciated. Translated Report (Full Report Below) ------------------------------------- Process: Xcode [32110] Path: /Applications/Xcode.app/Contents/MacOS/Xcode Identifier: com.apple.dt.Xcode Version: 26.2 (24553) Build Info: IDEApplication-24553000000000000~2 (17C52) Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.apple.dt.Xcode [58945] User ID: 501 Date/Time: 2026-02-19 13:11:54.9987 -0600 Launch Time: 2026-02-19 13:03:37.7725 -0600 Hardware Model: Mac16,5 OS Version: macOS 26.2 (25C56) Release Type: User Crash Reporter Key: 61D7E2DA-E724-EFE2-6A01-25079BFCA2D1 Incident Identifier: B3D4A277-7CB5-4696-A00F-057929659F41 Sleep/Wake UUID: 2D4F6C41-716C-4B47-8D40-27FD2D74A8AE Time Awake Since Boot: 440000 seconds Time Since Wake: 15967 seconds System Integrity Protection: enabled Triggered by Thread: 9, Dispatch Queue: com.apple.root.user-initiated-qos.cooperative Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6 Terminating Process: Xcode [32110] Application Specific Information: abort() called Thread 0:: Dispatch queue: com.apple.main-thread 0 AppKit 0x19ffb8250 __51-[NSWindow(NSDisplayCycle) _postWindowNeedsDisplay]_block_invoke + 0 1 CoreFoundation 0x19afe4604 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 2 CoreFoundation 0x19afe4544 __CFRunLoopDoBlocks + 396 3 CoreFoundation 0x19afe3988 __CFRunLoopRun + 2356 4 CoreFoundation 0x19b09de34 _CFRunLoopRunSpecificWithOptions + 532 5 HIToolbox 0x1a7ad3790 RunCurrentEventLoopInMode + 316 6 HIToolbox 0x1a7ad6ab8 ReceiveNextEventCommon + 488 7 HIToolbox 0x1a7c60b64 _BlockUntilNextEventMatchingListInMode + 48 8 AppKit 0x19f8fcb5c _DPSBlockUntilNextEventMatchingListInMode + 236 9 AppKit 0x19f3f6e48 _DPSNextEvent + 588 10 AppKit 0x19fec1d0c -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 11 AppKit 0x19fec1a18 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72 12 AppKit 0x19f3ef780 -[NSApplication run] + 368 13 IDEKit 0x10cf3f630 -[IDEApplication run] + 192 14 AppKit 0x19f3db6dc NSApplicationMain + 880 15 dyld 0x19ab7dd54 start + 7184 Thread 1:: com.apple.NSEventThread 0 libsystem_kernel.dylib 0x19af02c34 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x19af15028 mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x19af0b98c mach_msg_overwrite + 484 3 libsystem_kernel.dylib 0x19af02fb4 mach_msg + 24 4 CoreFoundation 0x19afe4ba0 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x19afe34f8 __CFRunLoopRun + 1188 6 CoreFoundation 0x19b09de34 _CFRunLoopRunSpecificWithOptions + 532 7 AppKit 0x19f486a34 _NSEventThread + 184 8 libsystem_pthread.dylib 0x19af45c08 _pthread_start + 136 9 libsystem_pthread.dylib 0x19af40ba8 thread_start + 8 Thread 2: 0 libsystem_kernel.dylib 0x19af02c34 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x19af15028 mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x19af0b98c mach_msg_overwrite + 484 3 libsystem_kernel.dylib 0x19af02fb4 mach_msg + 24 4 CoreFoundation 0x19afe4ba0 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x19afe34f8 __CFRunLoopRun + 1188 6 CoreFoundation 0x19b09de34 _CFRunLoopRunSpecificWithOptions + 532 7 Foundation 0x19d232964 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 8 DTDeviceKitBase 0x118331930 +[DTDKRemoteDeviceConnection startServiceBrowsers] + 148 9 Foundation 0x19c7fd7a0 __NSThread__start__ + 732 10 libsystem_pthread.dylib 0x19af45c08 _pthread_start + 136 11 libsystem_pthread.dylib 0x19af40ba8 thread_start + 8

Apple platforms make it easy to distribute your app to a variety of compatible devices, so it’s important to maximize your app experience on each platform you support. Here are some tips from App Review to help you understand how device compatibility impacts your app’s distribution — and how to make sure your apps shine on every platform they’re on. Understand device compatibility There are many ways an app built for one Apple device can run on other Apple devices: Apps designed for iPhone can run on iPad devices in compatibility mode if there are no dependencies on iPhone device capabilities. Compatible iPhone and iPad apps can run unmodified on Macs with Apple Silicon. Compatible iPhone and iPad apps can run unmodified on Apple Vision Pro. Xcode provides options to configure settings for apps on multiple platforms. You can specify which platforms your app’s target supports in the Supported Destination field. However, it’s important to note: People may still be able to run your app on a device even if you remove it or don't include it as a Supported Destination in Xcode. For example, as long as an app designed for iPhone doesn’t depend on a capability that’s only available on iPhone, it can be downloaded from the App Store onto iPad. Adding or removing iPad as a Supported Destination in Xcode won’t change that app’s availability on iPad. To view examples of cases where it's appropriate to restrict availability, see Restrict device distribution below. Follow compatibility best practices 1. Plan and test for compatibility modes so your app works on every device where it can be downloaded. Do: Use Xcode simulators to verify basic functionality across different device types. Leverage TestFlight with external testers who have access to a wide range of Apple devices. Don't: Don’t submit for review without testing your app’s behavior in compatibility modes. Don’t assume removing a supported destination in Xcode prevents distribution to that device type. 2. Build adaptive interfaces that work across device variations. Do: Build interfaces that respond to different screen sizes and orientations. Adapt features based on available hardware, providing alternatives for a consistent experience. Don't: Don’t design rigid interfaces that assume only one type of device or input method. Don’t let your app crash or become unusable when optional hardware is unavailable. Restrict device distribution Wherever possible, it’s best to make your app available on multiple platforms to increase its reach and provide people with a consistent experience across devices. But there are cases where it does makes sense to restrict an app’s availability. For example: iPhone apps that rely on iPhone-specific hardware won’t function as expected on iPad. Use the UIRequiredDeviceCapabilities key in the information property list file to specify hardware dependencies. Note: Apps should only use the UIRequiredDeviceCapabilities key for genuine hardware dependencies, not to indicate distribution preferences. Navigation- or camera-based apps are not well suited for visionOS. Learn more about managing availability of iPhone and iPad apps on Apple Vision Pro. Apps that rely heavily on touch inputs that can’t be replicated on a keyboard are not well suited for macOS. Learn more about restricting distribution to Apple Silicon devices. Learn more about how to configure multiplatform apps in Xcode. Support If you need more assistance, explore these support options: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review appointment through Meet with Apple. Appointments are available during local business hours on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board.

Hello, I built my app in Xcode and used IOS 26 latest frameworks like Foundation Models. But some of this frameworks don't work properly in Swift Playground(MyApp.swiftpm) and cause crashes. My question is can I submit a MyApp.xcodeproj file and choose Xcode 26 as a software to run my app ? Thank you in advance.

Hi all, I’m facing a device-specific issue in a live production iOS app distributed privately via the App Store . The app crashes immediately after login on one client’s iPhone, while the same account works fine on other devices. There’s no crash log generated in Analytics, and the app just pops to the home screen. Environment: App: Production app on App Store iOS version: 26.3 Devices: Only one device exhibits the crash; other iPhones work fine Login flow: App calls an API and writes the response to a local SQLite database immediately after login Distribution: App Store (Privately). The user is install via the redemption codes. Observations: All users on the problematic device crash immediately after login. The crash does not occur on any other devices, including the same iOS version. The client had already uninstalled and reinstalled the app via App Store cloud download, but the crash persisted. No crash log appears in Analytics or Xcode (process just terminates). Device restart had not been attempted before reinstall. App does not use Keychain tokens; local DB is only SQLite in the app sandbox. Hypotheses so far: Corrupted binary or cached app installation on that device SQLite database corruption or write failure Device-specific OS/environment issue (temp files, file locks, provisioning) iOS watchdog silently terminating the app during post-login DB write Language / region differences unlikely Questions: Is it possible for a device to retain a corrupted app binary or cached installation even after uninstall + cloud download reinstall from the App Store? Can uninstalling, restarting the device, and reinstalling guarantee a fresh binary and sandbox? Are there any known iOS behaviors where a local SQLite write could trigger an instant crash on one device only, without generating crash logs? Any other suggestions for diagnosing this device-specific post-login crash in a live production environment? Thanks in advance for any guidance — this issue is affecting a client’s live usage, and we’d like to understand the root cause and best way to resolve it safely.

While testing record creation in public CloudKit database for authenticated user I am able to do so without any issues. But for devices missing iCloud account or authentication expired I am seeing the below error: ▿ <CKError 0x97a959200: "Permission Failure" (10/2007); server message = "CREATE operation not permitted"; op = 67331DE3AF3DD666; uuid = 1F3ACD4F-A799-4CD4-ADF0-EDE9E12F2DCB; container ID = "***"> _nsError : <CKError 0x97a959200: "Permission Failure" (10/2007); server message = "CREATE operation not permitted"; op = 67331DE3AF3DD666; uuid = 1F3ACD4F-A799-4CD4-ADF0-EDE9E12F2DCB; container ID = "***"> I am unable to add create/write permission to _world security role in dashboard. Is this something not supported by Cloudkit? Only authenticated iCloud users will be able to create and write data to public database as well?

Product Xcode Version 26.3 (26C5131e) Platform macOS / iOS Simulator / iOS Device Classification Bug / Incorrect UI Behaviour Reproducibility Always (persists across restarts, scheme recreation, DerivedData clearing) Date Encountered February 20, 2026 Hardware Mac mini (M2) running macOS Test Device iPhone SE (2nd generation), iOS 26.3 Summary In Xcode 26.3, attempting to run an iOS app on any simulator destination using Cmd+R fails with the error: "A build only device cannot be used to run this target. Please select an available device or choose a simulated device as the destination." This occurs despite the selected destination being a valid iOS Simulator (not a "build only" device). The same project builds successfully using Cmd+B within Xcode and builds, installs, and runs correctly via the command line using xcodebuild, xcrun simctl, and xcrun devicectl. Steps to Reproduce Open a valid iOS project in Xcode 26.3. The project in question has target name "h", product name "DiabetesHbA1cPrediction", bundle identifier "com.diabeteshba1c.DiabetesHbA1cPrediction", with IPHONEOS_DEPLOYMENT_TARGET set to 26.0. In the scheme/destination picker toolbar, select any iOS Simulator destination (e.g. iPhone 16, iPhone 17 Pro, or any other available simulator). The destination name appears correctly in the toolbar without any "build only" annotation. Press Cmd+R (Product > Run). Xcode immediately displays the error: "A build only device cannot be used to run this target." Press Cmd+B (Product > Build) instead. The build succeeds with no errors. Expected Behaviour Cmd+R should build and launch the application on the selected simulator, just as it does in previous Xcode versions. The user had been running simulators successfully for the prior week before this issue appeared. Actual Behaviour Xcode refuses to run the app, treating every simulator destination as a "build only device." The error appears instantly upon pressing Cmd+R, before any build activity begins. Cmd+B succeeds normally, confirming the project and scheme configuration are valid. Workarounds Attempted (All Failed) The following troubleshooting steps were performed, none of which resolved the Xcode UI issue: Changed IPHONEOS_DEPLOYMENT_TARGET across multiple values (26.2, 18.0, 26.0) in all build settings within project.pbxproj. Deleted and recreated the Xcode scheme (removed .xcscheme files from xcshareddata and xcuserdata, let Xcode auto-create a new scheme). Deleted the entire DerivedData folder (rm -rf ~/Library/Developer/Xcode/DerivedData). Selected multiple different simulator destinations (iPhone 16, iPhone 16 Pro, iPhone 17 Pro) — all produced the same error. Verified the scheme’s Executable setting (confirmed it was set to the correct .app target). Changed "Show Run Destination" setting between Automatic and Always. Quit and restarted Xcode completely. Confirmed that simulator device names in the destination dropdown appeared normally, without any "build only" suffix. Working Workaround: Command-Line Build and Deploy The project builds, installs, and runs correctly when using command-line tools, confirming the project configuration is valid: Simulator deployment: xcodebuild -scheme h -destination 'platform=iOS Simulator,name=iPhone 16' build xcrun simctl boot 7F0DF8DA-E4A3-41B2-A2E4-B1F528753189 xcrun simctl install booted xcrun simctl launch booted com.diabeteshba1c.DiabetesHbA1cPrediction Result: App launched and ran correctly in the simulator. Physical device deployment (iPhone SE 2020, iOS 26.3): xcodebuild -scheme h -destination 'id=00008030-001128DC2E51402E' build xcrun devicectl device install app --device xcrun devicectl device process launch --device com.diabeteshba1c.DiabetesHbA1cPrediction Result: BUILD SUCCEEDED, app installed and launched on the physical device without issue. Key Observations The disconnect between Xcode’s UI-based Run (Cmd+R) failing and the command-line build/deploy succeeding with identical configuration strongly suggests this is an Xcode IDE bug in the run destination resolution logic, not a project configuration issue. Cmd+B succeeds in Xcode itself, meaning the build system correctly recognises the project, scheme, and destination. The failure occurs specifically in the “run” pathway where Xcode evaluates whether the destination supports execution. The simulator dropdown shows destination names without any "build only" label, yet Xcode internally treats them as build-only when the Run action is invoked. This behaviour started occurring in Xcode 26.3. The same project and simulators worked correctly in the preceding week under the same Xcode installation. Environment Xcode version: 26.3 (26C5131e) macOS: Running on Mac mini (M2) iOS SDK: 26.3 Available simulator runtimes: iOS 18.6, iOS 26.2 Physical test device: iPhone SE (2nd generation), iOS 26.3 Project type: SwiftUI iOS app with HealthKit integration Signing: Automatic, with valid provisioning for both simulator and device

Hello! Because the compilers used by different versions of Xcode 26 may be different, and I find that my app may not be able to ensure that all versions of Xcode 26 are successfully compiled. For example, my app can run on Xcode26.3 but will report an error at 26.4 (I have fixed it now). So I want to confirm which version of Xcode the jury uses to run my app, whether it is a known version or the latest version in the future. Thanks!

Hi! I have a Catalyst app that embeds command line utility. So the project has two targets: Catalyst target, this target depends on #2 and embeds it into its bundle. macOS target, the command line tool. Both targets have package dependency to the same package. I used this to embed the CMD tool. Everything builds, runs and works fine until I try to archive the project. Archiving stops early with such error: error: Multiple commands produce '/Users/kse2/Library/Developer/Xcode/DerivedData/PkgTest-clngkndczxoprpdlwefqqiqlryjt/Build/Intermediates.noindex/ArchiveIntermediates/PkgTest/IntermediateBuildFilesPath/UninstalledProducts/macosx/MacrosForSwift.o' note: Target 'MacrosForSwift' (project 'MacrosForSwift') has a command with output '/Users/kse2/Library/Developer/Xcode/DerivedData/PkgTest-clngkndczxoprpdlwefqqiqlryjt/Build/Intermediates.noindex/ArchiveIntermediates/PkgTest/IntermediateBuildFilesPath/UninstalledProducts/macosx/MacrosForSwift.o' note: Target 'MacrosForSwift' (project 'MacrosForSwift') has a command with output '/Users/kse2/Library/Developer/Xcode/DerivedData/PkgTest-clngkndczxoprpdlwefqqiqlryjt/Build/Intermediates.noindex/ArchiveIntermediates/PkgTest/IntermediateBuildFilesPath/UninstalledProducts/macosx/MacrosForSwift.o' What I have tried to fix archiving: Changing PkgTestCMD target to be on Catalyst/iOS instead of macOS. This works but I'm not sure how to properly run CMD tool with iOS SDK (if this correct at all): I need the main thread to be 'unblocked' and be active while background tasks exist. Adding an aux framework that act as container for the package. Doesn't work. Splitting targets into different projects, making workspace and cross-project reference. Doesn't work. My understanding is that archiving attempts to produce .o files for both Catalyst and macOS simultaneously, due to PkgTest being Catalyst and PkgTestCMD being macOS targets. How to archive such a project? Is there a way to separate archiving of CMD and main app? Maybe separate .o files into different directories. Simple building and running the project works, why archiving doesn't want to? I have a test project for the issue: PkgTest. main branch is the source project, DepFramework contains attempt #2, Workspace—#3. Thank you!

I'm on macOS Sequoia Version 15.7.3 (24G419) and using Xcode Version 26.2 (17C52). In my Xcode project, Transaction.updates and Product.SubscriptionInfo.Status.updates don’t seem to emit updates reliably. The code below works consistently in a fresh Xcode project using a minimal setup with a local StoreKit Configuration file containing a single auto-renewable subscription. class InAppPurchaseManager { static let shared = InAppPurchaseManager() var transactionTask: Task<Void, Never>? var subscriptionTask: Task<Void, Never>? init() { print("Launched InAppPurchaseManager...") transactionTask = Task(priority: .background) { for await result in Transaction.updates { print("\nReceived transaction update...") try? await result.payloadValue.finish() } } subscriptionTask = Task(priority: .background) { for await result in Product.SubscriptionInfo.Status.updates { print("\nReceived subscription update...") print("state:", result.state.localizedDescription) } } } } I initialise it in: func applicationDidFinishLaunching(_ aNotification: Notification) { _ = InAppPurchaseManager.shared } I do not build any UI for this test. I open StoreKit Transaction Manager then click Create Transaction → select the product → choose Purchase (Default) → Next → Done. The console shows that it detects the initial purchase, renewals and finishes each transaction. It also works even if I do not add the In-App Purchase capability. In my actual project, the initial purchase is detected and finished, but renewals are not detected. Subsequent transactions then appear as unverified, presumably because the updates are not being observed so the transactions are not being finished. What can I do to make this work reliably in my actual project? For context, in the actual project: I have a StoreKit Configuration file that is synced with App Store Connect The In-App Purchase capability is enabled The configuration file is selected in the scheme The products in App Store Connect show “Ready to Submit” Loading products works: try await Product.products(for: ...) Also, I use ProductView for the purchase UI. The first purchase works and is detected and finished, but subsequent renewals are not finished because the updates do not seem to be emitted.

This was maddening: I had written a very long and detailed prompt, then went to select "Codex" from the drop down menu at the top "start a new conversation", and it wiped out the entire prompt I was working on. Well, of course it did: that drop down is part of the "Start a new Conversation" icon button, but it's position is too far away from the actual icon to infer that is its purpose. It should be a popup that shows the current choice for model (GPT-5, GPT 4.1, Codex). ANOTHER lost prompt problem. If you have a prompt-in-progress (AI is maybe building some code), and Xcode crashes, it might not save that prompt for when you re-launch. And how might that happen? Well, there's still numerous ways using the coding assistanty might crash. One I've notice is if you switch out to another app, or if you invoke a screen capture, it might crash.

When building in Xcode on MacOS Tahoe, it seems it is no longer possible to dynamically specify a "small" size toolbar for NSToolbar/NSToolbarItem. It works in MacOS code compiled and linked on earlier systems. I don't want to use "SFSymbol", or "templates". I have over 60 custom-made .png toolbars, in individual Image Set files, at the previous requisite sizes of 24x24 / 48x48, and 32x32 / 64x64. Sure -- I can configure an NSToolbar with whatever size .png assets I want. I just can't dynamically switch between the two groups of sizes. According to the Apple Coding Assistant, the only solution is to change the image names of each of the NSToolbarItems at runtime. OK -- but even when attempting that, the NSToolbarItems refuse to take on their smaller size... ...unless: they are attached to a custom view NSToolbarItem with an NSButton of style "Bevel". I have about 10 of those, and YES -- I CAN change those to a "small" size. Is this REALLY what I'm forced to do?! The Apple Coding Assistant just runs me around in circles, making coding suggestions that include properties that don't exists. I've gone around and around on these issues for over a week -- it can't be this hard, right? Is there no way to make multiple NSToolbar objects, one for "large" and one for "small"?

Could you help me with resolving this issue, please. I've got following trace: ksmemory_notifyUnhandledFatalSignal EXC_BAD_ACCESS (KERN_INVALID_ADDRESS) Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x000000000000002b Crashed: com.apple.main-thread 0 KSCrash 0xbff8 ksmemory_notifyUnhandledFatalSignal + 12 1 KSCrash 0xcd6c handleSignal + 100 2 libsystem_platform.dylib 0x4178 _sigtramp + 56 3 libsystem_kernel.dylib 0x42f8 mach_msg2_internal + 76 4 libsystem_kernel.dylib 0x4214 mach_msg_overwrite + 428 5 libsystem_kernel.dylib 0x405c mach_msg + 24 6 CoreFoundation 0x46868 __CFRunLoopServiceMachPort + 160 7 CoreFoundation 0x1d848 __CFRunLoopRun + 1188 8 CoreFoundation 0x1ca6c _CFRunLoopRunSpecificWithOptions + 532 9 GraphicsServices 0x1498 GSEventRunModal + 120 10 UIKitCore 0x9ddf8 -[UIApplication _run] + 792 11 UIKitCore 0x46e54 UIApplicationMain + 336 12 UIKitCore 0x172938 -[UIScrollView contentInset] + 588 13 AppName 0xed9440 main + 4386804800 (AppDelegate.swift:4386804800) 14 ??? 0x189f76e28 (Missing) It appears that a variable or object is attempting to access another object that has already been deallocated. Based on the stack trace, the issue was likely detected while layout was in progress. Our analytics show this happens generally on app launch and occasionally during normal use. Unfortunately, I couldn't gather additional diagnostic data. I tried to reproduce the issue using the Leaks tool and enabled runtime diagnostics (Address Sanitizer, Malloc Scribble, Zombies), but without success. I may be overlooking something — any suggestions would be greatly appreciated. Thank you in advance

I've installed Xcode 26.3 on Sequoia 15.7.3 but I'm not seeing any of the AI options showing in Xcode that I see in usage/example videos. For example that AI icon in the top left hand corner isn't visible, and if I select Settings there is no Intelligence section, yet there is in all the demo videos. Why am I not seeing any of these new features?

Hello, We are experiencing a recurring issue when running iOS apps in the Rosetta simulator on Xcode 26. Environment: Xcode: 26.0 macOS: 15.7.3 Simulator: Intel-based (Rosetta) simulators Languages: Both Swift and Objective-C Issue: When launching an app in a Rosetta simulator, the app frequently freezes or fails to run. In many cases, Xcode reports that the debugger has lost connection. Xcode error message: Lost connection to the debugger on “iPhone 12”. Domain: IDEDebugSessionErrorDomain Code: 22 Failure Reason: Message from debugger: lost connection Console log: assertion failed: GPR thread_set_state is unimplemented for NewThread (ThreadContextRegisterState.cpp:920 host_gpr_state_from_guest_state) Observed behavior: Rebuilding after fully quitting the simulator sometimes resolves the issue temporarily. Disabling Scheme > Run > Debug executable allows the app to run normally, but debugging (breakpoints, etc.) becomes unavailable. The issue does not occur: On real devices On ARM-based simulators When building with Xcode 16 using Rosetta Has anyone encountered this issue with Xcode 26 and Rosetta simulators? Is this a known bug, and are there any recommended workarounds besides disabling the debugger or restarting the simulator? Thank you in advance for any insights or guidance.

We are encountering a build and archive failure in Xcode after updating our development machine to macOS 26.2. Environment: macOS: 26.2 Xcode: 16.2 iOS Deployment Target / Runtime: iOS 18.5 App Type: Production iOS app (App Store distribution) Issue: Before updating macOS, the project built and archived successfully. After the macOS 26.2 update, archiving fails consistently, even though no major changes were made to the project code or configuration. Certificates, provisioning profiles, and signing settings are correctly configured. The issue appears to be related to the macOS/Xcode environment rather than application logic. Steps to Reproduce: Open the existing iOS project in Xcode 16.2. Select the App Store distribution scheme. Attempt to Archive the project. Archive/build fails. Expected Result: Successful archive allowing upload to App Store Connect. Actual Result: Archive fails after macOS 26.2 update. Additional Info: This post is linked to Apple Developer Technical Support Case-ID: 18413014.

Following is an error I encounter when trying to run a foundation model function in simulator. Error Domain=FoundationModels.LanguageModelSession.GenerationError Code=-1 "(null)" UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=ModelManagerServices.ModelManagerError Code=1026 "(null)" UserInfo={NSMultipleUnderlyingErrorsKey=(\n)}" )} Its a swift playground I'm building in xcode and works fine in the preview and on a real device too but since it's my submission for the swift student challenge I need it to run on the simulator. I have updated my macOS to latest version of Tahoe(26.3) and Xcode is also on latest version. The simulator I run the playground is also on ios and iPadOS 26. I have set my region to US and have turned on Apple Intelligence on my mac too. Any suggestions on how to fix the issue?👾

Are there workarounds for the following bugs in Xcode 16.3? I'm looking for workarounds instead of trying newer versions of Xcode because, from what I read, the Xcode release notes do not mention these issues being fixed. First bug: Resizing a NSSplitView in the UI Editor is buggy. When you try to use the divider, it just does not work as expected. In the case of a vertical split, the bottom view gets shrunk whatever you try to do. Second bug: When you type: (IBAction) in the source editor, you get the following buggy template (extra ')' on the right): - (IBAction)<#selector#>:(id)sender)