We've just run into what seems to be the same issue - we have app A and app B. Totally separate in App Store Connect, with separate bundle IDs, but they are built from the same codebase. They are listed separately on the Xcode 27 new workflow dialog. Creating a product for the first one works fine. Creating a product for the second one seems to skip the "we found an app which matches your identifier" screen and instead seems to hook the new workflow directly into the product that was just created, even though that product has nothing to do with the workflow being created. We've tried playing with target names, product names, clearing the local Xcode Cloud manifest, restarting Xcode, rebooting, and so on, but for some reason Xcode never seems to look for the other identifier, it keeps (incorrectly) picking up the previous product as the valid product for the new workflow. This problem is heavily compounded by the fact that there is no way to create an Xcode Cloud product from the web interface or ASC API - the seemingly only way to create a product is via Xcode, which currently seems to be broken, making this a major issue for us right now.

Same issue here. Exact same config worked fine in beta 2.

Same :(

@pegasusspiele I don't think that's the case, as I've selected Tahoe and Xcode 26 for the build environment in those workflows. The fact that the error at the end refers to Icon Designer definitely implies to me that the toolchain is the most recent one.

@DTS Engineer Thanks for your response, but that thread is about shipping App Store builds to customers, so it answers a different question. My question is specifically about submitting builds to TestFlight (e.g. alpha and/or beta testing). What I'm not sure about given the feedback from Xcode Cloud is whether support hasn't been added yet for Icon Composer assets in TF, or if I need to add more assets along with the new Icon Composer asset on TF uploads. The docs seem to imply just the Icon Composer asset is needed, but then there's this error that seems to imply that there are news to come about that..?

Can confirm that this is happening on iOS 18.0 RC with Xcode 16 RC when in Swift 6.0 mode and optimisations enabled. When optimisations are not enabled, or if we're in Swift 5 mode, the crash does not occur. From what I see the crash is with an assert - so the issue may be an assert in iOS that assumes the asynchronous renderer is being tied to a specific dispatch queue, and the optimised build possibly does not tie the renderer into a specific dispatch queue, as it possibly uses an actor. I hope this additional input helps. It would be a shame if we can't compile for Swift 6.0 for iOS 18.0, I hope this gets fixed... Edit: Found the exception text too: EXC_BREAKPOINT: BUG IN CLIENT OF LIBDISPATCH: Assertion failed: Block was expected to execute on queue [com.apple.main-thread (0x1eee64a80)] > com.apple.main-thread

It seems to be corrected now for me. Just started Xcode in the morning and the usual download, which should start and fail, succeeded.

Submitted FB FB15092093 for this

Same here

Same here

Same here!

Having exactly the same issue

I think in my case I found a workaround, and I'm posting it here in case it works for others too - I had SWIFT_REFLECTION_METADATA_LEVEL set to "None" for release builds. Setting this back to the default (All) seemed to do the trick and let appintentsmetadataprocessor extract the info during the archiving step. There's probably a more elegant solution, like telling the compiler to emit reflection data only for the file containing the app intents definition, so if anyone finds this workaround helpful and has a better way to do it, please shout :)

I am getting this as well. Xcode 14.0.1, running on Monterey 12.6 release (21G115) Does anyone know of a workaround? (Filed this as FB11602587)

Same issue here