Since updating to 14.2 beta 2 I see the following error when trying to sign in to the TestFlight App on macOS. "Password reuse not available for account" It seems like it possibly affecting the AppStore too, from the device logs I see: Error Domain=AMSErrorDomain Code=2 \"Password reuse not available for account\" UserInfo={NSLocalizedDescription=Password reuse not available for account, NSLocalizedFailureReason=The account state does not support password reuse.}" I've tried signing out of the App Store to fix it but now I can't sign into either the store of TestFlight. I've also tried, multiple restarts and safe mode. Things seem fine on other platforms. Is this a known issue? Are others seeing it? Any ideas for how to reset things or what the error might be referring to?

We send StoreKit 2 signed transactions to our server for validation and processing. As part of this process, as recommended by Apple, we validate the certificate chain against the "Apple Root CA - G3 Root" certificate found here: https://www.apple.com/certificateauthority/ As of 24th September we started noticing this validation erroring because of expired certificates in the JWT. On further investigation we see the first cert in the chain, with the common name "Prod ECC Mac App Store and iTunes Store Receipt Signing", appears to have expired at "Sep 24 02:50:33 2023 GMT" I checked and calling the App Store API at "inApps/v1/subscriptions/" with the same transaction id also returns the subscription with the same expired certificate in the chain so I am confident that this is a genuine transaction issued by Apple. For now we have been forced to disable validating the expiry date of intermediate certificates to work around this. I'm however really surprised I haven't found anyone else discussing this or any documentation around how to handle this situation. Is it expected that the App Store JWS would contain an expired certificate and what is the guidance on how to proceed in this situation?

We have code similar to the following in our App. 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") ... } } } This code gets run on App launch. From looking at logs for some customers in production, on macOS 13.4.1, it seems as though "stopped listening for transaction updates" gets logged almost immediately after "starting listening for transaction updates" and before any "processing transaction update" messages. My original guess was that maybe this was caused by the user being logged out of the AppStore but this doesn't seem to be the case and I have been totally unable to reproduce it. A customer suggested that it happens every time they received an App update from from the App Store but the may be correlation rather than causation. I can see from looking at the customers logs that they also don't appear to have an AppTransaction available when this situation happens. My question is, under what conditions can the Transaction.updates stream get closed early like this? What action should we take in this scenario? Would restarting the stream again lead to an infinite start/stop loop?

I have 2 Apps. A sandboxed native Mac App written in AppKit/SwiftUI. A Catalyst App. I would like them to be able to communicate with each other. I assumed I would be able to do this using a shared App Group but I can't get it to work and I think this is because the App Group naming conventions appear to be different. As far as I can make out: A Mac App uses App groups prefixed with the team ID A Catalyst App uses the iOS App groups which are prefixed with group. I have tried multiple combinations of different prefixes to try and make this work but without success. I have been "testing" this by using UserDefaults(suiteName: appGroup) and then attempting to read write values between the 2 Apps but without success so far. My questions are: Is sharing an App Group between Catalyst and native technically possible? If it is possible what is the magic combo of App Group prefixes that makes it work? If it is not possible then do I have any other options for communicating between a sandboxed Mac App and a Catalyst App?

We have an ambisonics renderer that requires 16 channel audio. Everything works fine using AVAudioFile to read a wav file with AVAudioChannelLayout.init(layoutTag: kAudioChannelLayoutTag_HOA_ACN_SN3D | 16) into AVAudioPCMBuffer but the raw wav files are huge. I can't find any compressed formats (lossy or lossless) 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? I 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 Ogg/Opus for the compression as an alternative but my experiments here have also been unsuccessful so far. Any help anyone can give on how I 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.