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 🤞

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

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?

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

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.

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!

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.

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.

this is fixed in the os26 betas. 🎉

Thanks for the confirmation. Unfortunately the ergonomics of the completion hander version are a little awkward for my use case because of other asynchronous logic and concurrency calls. I will use @preconncurrency for now and hope that the API issues can get resolved soon. I have filed this as: FB19576198 (no idea where I was supposed to file this as I couldn't find an option for TVServices so I set it as "‌Something else not on this list" but hopefully it makes it to the right people!)

I have filed feedback with a sysdiagnose for this: FB20023111