I'm also hitting this issue, exactly as described when trying to add a new widget target to an existing Multiplatform app. Did you ever find a solution?

checking the signedDate field I can see that the specific example transaction I am looking at was signed 2023-09-12. So I guess technically the certificate was valid when it was signed. I would need some more time to investigate signed dates of other transactions that were failing. The problem is that this is for an annual subscription that is valid for 10 more months so the server may very likely re-check the transaction again if it is sent up from the client. I just assumed that either transactions would get re-signed or that the certificate expiry would be far enough in the future that this wouldn't be an issue. If I am understanding correctly it seems like we need to be checking that the signedDate is within the window of certificate validity rather than the current date. Does that sound right?

Yep we are seeing this too. It's still present in Xcode beta 6 / macOS Sonoma beta 3. I filed feedback as FB12883392 if anyone wants to cross reference. as suggested by @treastrain_dev switching the OS version to Ventura seems to resolve the issue for now for us as well, thanks for the tip.

I have submitted this to Apple as FB12509606 - "Transaction.updates stream closes immediately and Transactions missing" I have a suspicion that this might be a different manifestation of the same problem discussed in this SO post

We also are seeing something similar to this. On macOS it seems like for some customers that the Transaction.updates sequence returns immediately. The result of this is that they must then restore purchases to regain access. Using code similar to the below: Task.detached(priority: .background) { logger.log("starting listening for transaction updates") defer { logger.warning("stopped listening for transaction updates") } for await verificationResult in Transaction.updates { logger.log("processing transaction update") ... } } } I can see this in logs from some customers that "stopped listening for transaction updates" gets logged almost immediately after "starting listening for transaction updates". I can't see any errors thrown so I'm still unable to to figure out under what conditions this happens. My first guess was maybe them being signed out of the App Store but I was unable to reproduce this at all in testing.

Yes, we are also facing this issue, hopefully there is a workable solution.

Thanks Quinn, this helped me get it working. Just to note two additional things that I found confusing in the process. The defaults command line tool doesn't really help here, as far as I can work out it can't be used with App groups. When using defaults read group.UUU myKey I get The domain/default pair of (group.UUU, myKey) does not exist Is that expected? The Mac Native side logs a scary message when trying to access values, but does in-fact seem to find the value still. Not sure how concerned I should be able this. [User Defaults] Couldn't read values in CFPrefsPlistSource<0x600003978680> (Domain: group.UUU, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd

We now maintain a patched version of opusfile that supports decoding of up-to 16 channels and I can confirm it works great on iOS.

I am also struggling quite a bit with something very similar: We have an ambisonics renderer that requires 16 channels. Everything works fine using AVAudioFile to read a wav file with AVAudioChannelLayout.init(layoutTag: kAudioChannelLayoutTag_HOA_ACN_SN3D | 16) into AVAudioPCMBuffer I can't find any compressed formats that iOS is able to read at 16 channels. Whilst it seems possible to create an aac file with up-to 48 channels iOS doesn't seem able to decode anything with more than 8 channels (7.1) as far as I can tell? We considered using 2x8 channel aac files, reading them into 2 buffers and then joining them but have been unable to figure out how to merge them back to 16 channels with the correct layout. I'm currently experimenting with trying to use Opus for the compression but my experiments here have also been unsuccessful so far. Any help anyone can give on how we could go about getting 16 channels of compressed audio out of a file (or files) and into an AVAudioPCMBuffer with kAudioChannelLayoutTag_HOA_ACN_SN3D | 16 layout would be very amazing.

20 hours later and the errors magically stopped just as quickly as they started. Who knows? I'm just glad whatever it was seems to be at least partially resolved for us for now at least and I can finally get some sleep. zzz

As of May 3rd we have suddenly started seeing a lot of 21104 status codes in response to verifyReceipt calls (been like this for the last 20ish hours and still on-going) with no obvious reason why or pattern as to what receipts are causing it. Once a receipt hits this state it seems to be stuck with that code and no amount of retrying seems to help. No idea what is going on but it's causing us some serious issues.

We also found this this happened for the first time today. Exactly the same issue except our download_id was nil. Weird thing is that the bundle_id isn't just null but its the string "null" Also note: the receipt from the users device was correct but this issue was present in the unified receipt sent from the App Store INITIAL_BUY event callback. I am pretty certain it's a bug on Apple's end but nothing conclusive yet.