Xcode

Thanks for verifying this on your side. Please find the answers to your queries. iOS’s Apple Watch version:
The paired Apple Watch is running watchOS 10.6.1 on a physical device. It is paired with an iPhone running iOS 18.x. Regarding the minimum deployment target: 
You are correct that the watch app’s minimum deployment target is set to watchOS 10.0, 9.6 was typo error.
The issue I am reporting is that Xcode still displays the error “watchOS version lower than deployment target” even though the physical Apple Watch is running 10.6. This should satisfy the 10.0 deployment requirement, but Xcode continues to block installation. So we are observing the unexpected behaviour with the below configuration : Physical device: watchOS 10.6 Deployment target: watchOS 10.0 Xcode error: “watchOS version lower than deployment target” The error should not appear. Additionally, I’m still seeing the same issue even on the latest environment: Xcode 26.1.1 macOS 15.6 I performed a clean buil

I update to the latest Xcode : Version 26.1.1 (17B100) Toolchain: Swift 6.2 Release 2025-09-11 (a) and MacOS to the latest : 26.1 (25B78) and still have the same crash problem, I give the crash report to an AI to summarize it : Primary Issue Assertion Failure in Scheme Execution: The crash occurred during scheme execution operations, specifically when Xcode was trying to create an execution operation for running a scheme. Key Technical Details Crash Location Thread 0 (main thread) crashed with SIGABRT (Abort trap: 6) Trigger: Assertion failure in IDEScheme class Specific Method: -[IDEScheme _executionOperationForSchemeOperationParameters:build:onlyBuild:buildParameters:title:buildLog:dontActuallyRunCommands:restorePersistedBuildResults:deviceAvailableChecker:error:actionCallbackBlock:] Crash Sequence Assertion triggered in IDEScheme operations Assertion handler called abort() Main thread terminated with abort signal The crash appears to be an internal Xcode assertion triggered by in

You’re combining two background execution technologies — background tasks and URLSession background sessions — and its not clear why. When you use a background session, your app doesn’t need to run in the background for the transfer to make progress. Rather, a system process (currently nsurlsessiond) does the transfer on your behalf. Can you explain why you’ve add background tasks into the mix? As to what’s going on with your current code, I have a bunch of debugging hints for you. First, you’ve not clearly separated your build configuration (Debug or Release) from your code signing (Apple Development or Apple Distribution for TestFlight). Teasing those apart can yield useful results, because it tells you whether the issue is with the way that your code is built or the way that it’s distributed. I talk about this in more depth in Isolating Code Signing Problems from Build Problems. Second, you’re testing background code from Xcode. This can be useful in limitation circumstances, but it can also be ve

I have news! Xcode 26.2 beta 2 is now available, and it contains improvements to the debugging infrastructure that will result in improved launch times with the debugger attached. To reap the benefits, you'll need to update iOS to 26.2 beta 3 for your app debugging. The bug report from @isaacweisberg and @amo_marty was helpful to us, so I do want to thank you for collecting those details that helped us understand the issue. — Ed Ford,  DTS Engineer

It would be helpful to format the output of that command using Markdown backticks so it's a bit clearer to read here. Based on how I'm interpreting the unformatted output, you will need to figure out where AUChangeSkinShell is coming from in your app, and make sure that library is built with a recent version of Xcode. If that's not a class you directly have in your codebase, you may want to check for it in any third-party libraries your app depends on. You can also use grep to search your codebase (and third-party dependencies) for that string to see where it turns up. — Ed Ford,  DTS Engineer

Correct, both were exported from the keychain with password foo. The key material added from xcode was not touched in any other way. I have tried to create a new account alias on my macbook, have it import both keys. The account is not associated with my iCloud. I marked that certificate as trusted manually. Can't get a valid identity from that account either.

Thanks for the reply! Just to clarify, even though the main app is built with Flutter, the Live Activity and widget extension are fully native Swift/SwiftUI and built in Xcode. The issue seems to be on the ActivityKit/WidgetKit side rather than the Flutter side. I’ve gone through Apple’s Live Activity tutorial and everything works except the actual UI rendering (Dynamic Island shows a black capsule even though the regions contain simple Text/Image views with no errors). I’m mainly hoping someone who’s run into a similar ActivityKit rendering issue can point out anything I may be missing in the widget extension setup. Any insights are appreciated!

Hello @SteveTalkowski ! Thank you for your question. The root cause of your issue is a bit technical so I hope you'll bear with me. You're seeing an issue related to the different ways USD can be rendered on your system. Different renderers support different feature sets of the USD spec and unfortunately RealityKit's USD renderer does not support vertex animation. In some contexts, macOS will display USD files using a renderer called Storm (you can search online for Hydra Storm), and this is not the same renderer used by Xcode or your app, which uses RealityKit to render USD. Because Storm supports vertex animation while RealityKit does not, you'll see your animation playing in some contexts and not others, and you won't be able to use this particular type of animation in a RealityKit app. This is confusing, but hopefully the link above helps explain everything. You've authored your asset correctly! Unfortunately, RealityKit does not support this particular type of animation. I recommend sending us f