Thanks for the clarification as I was wondering the same - currently migrating from legacy StoreKit to StoreKit2 API and using Transaction.updates. Just a follow-up question: Would there be a double-charge if KID purchased again while the first transaction is pending (and later PARENT approved)? I'd expect the framework to dismiss the second purchase...

Hey Quinn, thanks a bunch for confirming - you're really an asset of these forums 😉 Right, I will just check by adding the macOS platform to the iOS ASC entry and upload a "new" macOS build as mentioned. Just too bad there is (still) no way to remove an additional platform item from ASC if it's not used... Cheers!

Awesome! I totally missed the first option in the "Products" menu ... and was wondering why enabling "Show always" for the simulators had no effect. Changed the "Product" option to show both architectures, and the - Rosetta-based - iOS 13 simulators are showing up. Thanks, you made my day!

I just installed Xcode and the iOS 13.7 simulator on my Intel Mac Mini: After switching the simulator to "show always" it can be selected as a Run Destination and works. Looks like these "older" simulators are not listed on Macs running with Apple Silicon, like my 14" MBP. I'd consider this a bug...

I wasn't following up as the customer's demand wasn't confirmed. But to my knowledge the only official way would be a separate app version. Didn't hear anything back from Apple, but found a corresponding blog entry by another developer in the same boat.

Thanks for the insights, Rich, very helpful - as mentioned in my thread, too. Could you point us to a documentation for the current recommendation: "[...] Instead the advise now is to have the app continue along with the assumption that the user has no access to first time in-app purchase support, or to support for restoring previous purchases."? So far the docs are still reflecting exit(173), not marked as deprecated.

Working again without any code change at May 18th, 8:15 pm CEST: obviously Apple has fixed the backend, but no official confirmation of the issue, no response on bug reports, no corresponding system status … Apple, please work on your developer community management.

Working again without any code change at May 18th, 8:15 pm CEST: obviously Apple has fixed the backend, but no official confirmation of the issue, no response on bug reports, no corresponding system status … Apple, please work on your developer community management.

Yep, I'm doing the same - commenting out receipt checks. Unfortunately I recently changed IAP processing in my app, and now releasing it is massively delayed as I cannot test properly. What really annoys my is Apple's ignorance with regards to this issue: No official comment in any discussion, no response to my bug report, and the Developer System Status is still reporting everything "green". That sucks...

Filed a duplicate feedback FB10014055

+1 ... Building my app with macOS 12.3.1 (M1) and Xcode 13.3.1, and no receipt is retrieved after exiting with 173. Tried App Store log out / log in (sandbox and regular account) as well as reboot to no avail.

Thanks, Quinn! The quarantine step was keeping me from testing a Universal App after airdropping from the M1 development device to test machines. But I realized that "Automatic Development Signing" doesn't required device IDs registered ... at least I could run the app in several VMs, not registered as devices . Greetings, Mattes

Yep, that's why I mentioned it in my original post...

Hey Claude, Thanks a lot for the workaround ... works well. I already filed a RADAR this morning (FB9666237) Greetings, Mattes

Sorry for not responding so long, I didn't receive any notification about your reply... I wasn't facing any issue building a static XCFramework using the mentioned repository. Unfortunately I didn't documented the steps it took, but based on its README I must have used the command line ./create-framework.sh xcstatic HTH, Mattes