Instruments is crashing when the swiftui instrument is stopped (the session is finished) and the transfer begins from device to device: Crashed Thread: 11 Dispatch queue: com.apple.swiftuitracingsupport.reading Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [1633] I've tried removing derived data, reinstalling xcode, updating xcode (I originally thought this might be the issue -- I needed to update to 26.2 from the 26 RC -- the update didn't fix crash or change the crash report), and restarting both devices. I'm running Instruments/Xcode 26.2 on a MacBook Pro 15 (2018) running Mac OS 15.7.2 (24G325) with an iPhone 16 Pro Max running 26.2. Hoping someone else might have seen this or could help me troubleshoot. I find the swiftui instrument be helpful and like to use it :) I can post a complete crash report as well.
Search results for
xcode github
93,983 results found
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
This is a known issue in Xcode 26 and later. When using XCTest in Xcode 26 and later, a test failure will cause the test runner process to terminate and relaunch before continuing to the next test if all the following conditions are met: The test class is written in Swift, The test’s continueAfterFailure property is set to false, Either the test method is async or the async overload of setUp or tearDown is overridden, and The test encounters a failure. Under these conditions, the first issue recorded by each affected test will cause the test runner process to be terminated after its tearDown sequence finishes. A new test runner process will then be launched, and execution will continue with the next test. This applies to any XCTAssert calls which fail, all calls to XCTFail, and failures encountered by UI automation API calls. This change was made to XCTest in order to improve reliability, since the XCTestCase.continueAfterFailure API uses Objective-C exceptions and can cause problems when us
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags:
Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.
Topic:
Programming Languages
SubTopic:
Swift
Tags:
The developer downloads page now lists an Xcode 26.1 which was released on 11th Dec (the original Xcode 26.1 was posted on 3rd Nov). Strangely, this new Xcode 26.1 has a CFBundleShortVersionString of 26.1.1, and a DTXcodeBuild of 17B55 % ls -ln total 4413136 -rw-r--r--@ 1 503 20 2259523057 16 Dec 19:01 Xcode_26.1_Apple_silicon.xip % xip --expand Xcode_26.1_Apple_silicon.xip xip: signing certificate was Software Update (validation not attempted) xip: expanded items from /Users/me/Downloads/temp/Xcode_26.1_Apple_silicon.xip % plutil -p Xcode.app/Contents/Info.plist | grep CFBundleShort CFBundleShortVersionString => 26.1.1 % plutil -p Xcode.app/Contents/Info.plist | grep DTXcodeBuild DTXcodeBuild => 17B55 17B55 does correspond to the original Xcode 26.1 final release. The Xcode 26.1.1 release that was previously posted had a DTXcodeBuild of 17B100, though. The pairing of 26.1.1 and 17B55 looks new and probably a packaging error?
Topic:
Developer Tools & Services
SubTopic:
Xcode
Hi @Umeki, To enable all the technologies and access all the signals Apple has made available to comply with regional age assurance requirements, starting with Texas, you must build your app against the iOS 26.2 and iPadOS 26.2 SDKs and later, with Xcode 26.2 (17C52) and later. To view the latest Xcode versions and SDKs, see here. As of iOS 26.2 and iPadOS 26.2, age assurance includes the following signals: Declared Age Range API — Determine whether a person using your app is in an applicable region that requires additional age-related obligations. When a child account, or their parent or guardian, chooses to share age information, the Declared Age Range API will return the age band or age category, depending on legal requirements in the region. The API will also provide information about the method used to confirm the age band or category, whether parental controls are enabled, and whether the user is eligible for age gated features. For more details, see the following documentation: AgeRan
Topic:
App & System Services
SubTopic:
General
Tags:
Hi @skitudeiosdevelopers, You wrote: [...] What is the correct and Apple-approved approach for handling age verification and restricting access for minor users on iOS versions prior to 26, given that the Declared Age Range API is not available on those systems? To enable all the technologies and access all the signals Apple has made available to comply with regional age assurance requirements, starting with Texas, you must build your app against, you must build your app against iOS 26.2 and iPadOS 26.2 SDKs with Xcode 26.2 (17C52). View the latest Xcode versions and SDKs here. Existing adult accounts and child accounts for kids and teens will not be affected. To learn more, see Next steps for apps distributed in Texas. Cheers, Paris X Pinkney | WWDR | DTS Engineer
Topic:
App Store Distribution & Marketing
SubTopic:
General
Tags:
Thanks for the post and the details, the error is not about having the latest version of Xcode, looks like you do have it as Xcode Version 26.2 (17C52). The error message you're encountering, ITMS-90426: Invalid Swift Support - The SwiftSupport folder is missing., indicates that your app submission to App Store Connect is missing a required folder named SwiftSupport. So this is extremely interesting to me for sure. When archiving your app, ensure there are no build warnings about folders. Go to > , and then check the Organizer to ensure everything is correctly packaged. If your app uses Swift Package Manager, ensure that all packages are updated and correctly integrated. Sometimes issues arise from improperly configured packages? I believe this issue is always about packages you are using. Can you check that? read until the end where a post from an Apple engineer will give you more information. If you're manually managing your app bundle, ensure the folder is present in the archive's stru
Topic:
App Store Distribution & Marketing
SubTopic:
TestFlight
Tags:
Thank you for your responses and comments. It appears after reading so many people getting that in Xcode 26.2 that there is an issue in the latest build released, as I understand from your feedback. I have not been able to reproduce the issue myself, but this indicates that I have more work to do today to determine the steps to reproduce the problem using the latest Xcode 26.2 release with the simulator. I appreciate your assistance in providing this information. I have the FB number and will provide the engineering team with all the details from this thread after I have summarized everyone’s input. Albert Pascual
Worldwide Developer Relations.
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags:
We are getting the above mentioned error while uploading to TestFlight. We have used a Swift Class to request for the Age Range via DeclaredAgeRange Framework. We have exposed Swift class and a helper function to be available in Objective-C layer. We have enabled the following build settings SWIFT_OBJC_INTERFACE_HEADER_NAME = Common-Swift.h; SWIFT_OBJC_BRIDGING_HEADER = Common-Bridging-Header.h ; ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES Also we are compiling the application using latest available Xcode release 17C52 Is there anything else we need to do to resolve the error?
Topic:
App Store Distribution & Marketing
SubTopic:
TestFlight
Tags:
Swift
TestFlight
Declared Age Range
I have verified that in Xcode, my main target Runner has a bundle identifier of com.mycompany.pushnotifications and my extension target has a bundle identifier of com.mycompany.pushnotifications.pushnotificationsmessageextension I unzipped my .IPA file and see Payload/Runner.app/pushnotificationsmessageextension.appex In my uncompiled app, I looked in the pushnotificationsmessageextension/Info.plist file and see the following NSExtension NSExtensionPointIdentifier com.apple.usernotifications.service NSExtensionPrincipalClass $(PRODUCT_MODULE_NAME).NotificationService
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Problem Summary After upgrading to iOS 26.1 and 26.2, I'm experiencing a particle positioning bug in RealityKit where ParticleEmitterComponent particles render at an incorrect offset relative to their parent entity. This behavior does not occur on iOS 18.6.2 or earlier versions, suggesting a regression introduced in the newer OS builds. Environment Details Operating System: iOS 26.1 & iOS 26.2 Framework: RealityKit Xcode Version: 16.2 (16C5032a) Expected vs. Actual Behavior Expected: Particles should render at the position of the entity to which the ParticleEmitterComponent is attached, matching the behavior on iOS 18.6.2 and earlier. Actual: Particles appear away from their parent entity, creating a visual misalignment that breaks the intended AR experience. Steps to Reproduce Create or open an AR application with RealityKit that uses particle components Attach a ParticleEmitterComponent to an entity via a custom system Run the application on iOS 26.1 or iOS 26.2 Observe that particles render at
Problem Summary After upgrading to iOS 26.1 and 26.2, I'm experiencing a particle positioning bug in RealityKit where ParticleEmitterComponent particles render at an incorrect offset relative to their parent entity. This behavior does not occur on iOS 18.6.2 or earlier versions, suggesting a regression introduced in the newer OS builds. Environment Details Operating System: iOS 26.1 & iOS 26.2 Framework: RealityKit Xcode Version: 16.2 (16C5032a) Expected vs. Actual Behavior Expected: Particles should render at the position of the entity to which the ParticleEmitterComponent is attached, matching the behavior on iOS 18.6.2 and earlier. Actual: Particles appear away from their parent entity, creating a visual misalignment that breaks the intended AR experience. Steps to Reproduce Create or open an AR application with RealityKit that uses particle components Attach a ParticleEmitterComponent to an entity via a custom system Run the application on iOS 26.1 or iOS 26.2 Observe that particles render at
Just checked new Xcode 26.2 with iOS 26.2 and the debug builds startup time indeed improved significantly. We still have ~7 seconds of initial sluggishness (difference between debug executable on/off), but it's way better than it was before! 👍 While I appreciate the movement in the right direction, this still represents a substantial regression from the prior baseline, ~1s in Xcode 16. A reduction in severity isn’t a resolution. If Xcode is to remain viable for professional workflows, startup and initial responsiveness need to return to the Xcode 16 baseline.
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags:
Just checked new Xcode 26.2 with iOS 26.2 and the debug builds startup time indeed improved significantly. We still have ~7 seconds of initial sluggishness (difference between debug executable on/off), but it's way better than it was before! 👍 That’s not an improvement, that's a partial rollback of a huge regression. On Xcode 16 it was ~1s. That was the baseline. Seven seconds of launch + long initial sluggishness in debug is still absurd. Stop celebrating “less bad.” This shouldn’t be acceptable and Xcode 26 is still unusable for any serious work.
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags:
I have found that following code runs without issue from Xcode, either in Debug or Release mode, yet crashes when running from the binary produced by archiving - i.e. what will be sent to the app store. import SwiftUI import AVKit @main struct tcApp: App { var body: some Scene { WindowGroup { VideoPlayer(player: nil) } } } This is the most stripped down code that shows the issue. One can try and point the VideoPlayer at a file and the same issue will occur. I've attached the crash log: Crash log Please note that this was seen with Xcode 26.2 and MacOS 26.2.