this is fixed in the os26 betas. 🎉

I tried checking the "Clean" option in the Xcode Cloud Workflow settings and since then I have had 3 builds all install fine on macOS. I can't be 100% certain this actually fixed it but maybe it's caching related? Might be worth giving it a try and reporting back.

Yes! We are experiencing the same issue. We have a cross platform app that builds on Xcode cloud for iOS, macOS & tvOS. The builds complete without any errors in Xcode cloud. Since a week or so ago the macOS builds sometimes (~50% of the time??) update fine through TestFlight but other times have the behaviour described above of spinning for a couple of seconds and then failing to install. If a build exhibits this behaviour as far as I can tell it always has this behaviour (on an M! MacBook Pro at least) sometimes a second build of the same code installs fine but not always so it seems like there is maybe some element of chance in the build pipeline and/or TestFlight distribution. As far as I can tell when this happens the iOS and tvOS builds are installable and work as expected so it seems like the issue maybe isolated to macOS.

We also face this issue. We are using AVAudioEngine for audio playback and manually control MPNowPlayingInfoCenter. We use AVPlayer for some silent background videos in app but when doing so the video player controls the playbackState with no way to opt-out. After filing a DTS, feedback and lab I am fairly sure there is no solution for this currently unfortunately. I filed FB9837867 and am crossing my fingers for some progress. Our current work-around which is not ideal is to set MPNowPlayingInfoCenter.default().nowPlayingInfo = nil whenever we pause the audio playback. This seems to somewhat work but also has some other not great side-effects. @Rodrigue2g Did you find any better solutions since posting this? I would encourage you to file feedback and mention FB9837867 as well!

I have a reply from Apple and I think I now understand why you might be seeing this error. TestFlight builds are associated with an Apple Account email address that may be different from the address that was invited. You need to remove the email in ASC and wait 90 days for all builds to expire before it can be re-used by a different email address. Because I can't practically afford to wait 90 days for the builds to all expire my work-around was to add a second Apple account I have to our internal team and then invite that account to TestFlight builds. It seems to have worked and I'm hoping in 90 days time I can switch back to using my main account.

For anyone from Apple reading this I have filed FB16736749 which includes sysdiagnoses and details of the accounts involved.

I am also seeing this after using the newly released account purchases migration. In my case: I have a work email for ASC. That email is part of an internal team I have an old "purchases only" account that I was signed into TestFlight as and was able to use the internal team TestFlight builds fine. I have a personal primary Apple account that I am signed in for iCloud etc. The steps I went through: removed all apps from TestFlight on my purchases account. did the purchases migration flow signed out of my purchases only account and into TF with my primary account. Tried to re-add my TestFlight internal builds via a new invite email (sent to my work email as this is the "internal" ASC one) On trying to accept the invite I get the message: "The apple account you are currently signed with, [1] does not matching the one which is associated to this invitation. You can sign in to TestFlight with the original Apple Account, [2] or request new invitation from the developer" where [1] is my primary account I am signed in with and [2] is the old now defunct purchases only account. Note, neither of which is the actual address the invite was sent to. @nnagesh I have no idea how to resolve this, did you manage to find a solution?

Thanks, I have submitted a non-redacted version of this report as FB16727474

I think the issue here is Sequoia. Builds from Xcode 16 RC running on Sonoma (even on Xcode cloud) submit fine but builds from Sequoia RC do not. hopefully apple willl fix it 🤞

Great, thanks for the explanation, this was really helpful and gave me the confidence to use unchecked Sendable in this instance. I understand how it got here now but it's an awkward API that is pretty hard to use safely out of the box from Swift 6.

I have experimented a little more. I can reproduce this issue by: create a new project in Xcode 16 beta 6 with default settings Include any reference to NSDecimalRound() Build an Archive build from Xcode Launch the App. Here is the code I am adding to trigger the crash: public extension Decimal { func rounded(_ roundingMode: Decimal.RoundingMode = .plain) -> Decimal { var result = Decimal() var number = self NSDecimalRound(&result, &number, 0, roundingMode) return result } } This seems very bad so I have filed FB14900250 but this is a pretty big blocker for us to be able to ship anything right now.

Thanks for getting back to me. I'm not sure if you missed something or I wasn't clear enough above but I am building with Xcode 16 beta 6 already. Here is some more complete info on the environments I see the crash: Xcode cloud - macOS 14.5 + Xcode 16 b6 - distributed via TestFlight: CRASHES on macOS 14.5.1 launches on macOS 15 beta Intel Mac - macOS 14.5 + Xcode 16 b6 - Xcode attached debug build: launches on macOS 14.5.1 Intel Mac - macOS 14.5 + Xcode 16 b6 - Local Archive build launched locally CRASHES on macOS 14.5.1 launches on macOS 15 beta Intel Mac - macOS 14.5 + Xcode 16 b6 - Local Archive build distributed via TestFlight CRASHES on macOS 14.5.1 launches on macOS 15 beta So it seems like the issue is not tied directly to Xcode cloud or TestFlight but is in fact present in all archive builds built on macOS 14.5.1 + Xcode 16 b6 and run on macOS 14.5.1. Hopefully that makes the situation clearer. I also note that the crash includes Foundation14NSDecimalRound. I audited our code and we do make calls to NSDecimalRound and include references to Decimal.RoundingMode from inside an SPM module within the the same codebase.

I've had a play and I don't think my sending proposal would help here either because of the previous call to audioFile.read() the compiler won't allow it to be sent. For now I have boxed the buffer inside an @unchecked Sendable but I wish there was a nicer way to make this API work.

This seems to be fixed in Xcode 16 beta 5 🎉

We are also seeing this error. Unfortunately the workaround doesn't quite work for us because we are using GRDBQuery, which itself has a dependency on GRDB.swift which is outside of our direct control. Hopefully it can be fixed properly in Xcode soon!