No MAS receipt after exit(173)

Might be related to a potential MAS outage, as I'm also facing issues validating my app (like mentioned here: "Error Analyzing App Version" https://developer.apple.com/forums/thread/705599)

I have already considered a report. And a lot of other developers too, I guess ('Similar reports: More than 10'). The last time this happened it took 2 or 3 month till the problem was fixed. And not for long...

Greetings Brigitte

This can be avoided by disabling the submission of debug symbols ... Had the same issue months ago on my M1, now it's back.

Currently bypassing the issue by 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...

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.

Here we go again: Just changed my IAP validation code and the app is reported as damaged after exiting with 173 and no receipt is delivered. Xcode Version 13.4.1 (13F100) on macOS Monterey 12.4 (21F79).

Apple, it sucks...!

It turns out that if the mac StoreKit app detects that the appStoreReceipt is missing, don't call exit (173) just keep on going. This is a sandbox only issue. When a successful in-app purchase is made, the App Store always updates the appStoreReceipt which the app process can use to validate the purchase.

I can think of a couple of reasons for wanting the appStoreReceipt to be present:

1. to determine if the user is eligible for promotional or first time purchase access. In this case, assume that the user has no free trial access and move on.

2. to determine if the user purchased an earlier version of the app - so as to implement paid-to-freemium support - if the receipt is missing assume this is a new user that must pay to access premium content. If you need to check the app logic to check the value of original_application_version, do so after making a successful in-app purchase, when there will be an appStoreReceipt to validate.

3. as a convenience method to update (restore) services to a user. In the production case this will work without issue. In the sandbox environment, rely instead on the user pressing a "Restore" button which triggers the app to make the restoreCompletedTransactions call.

4. there are those apps which use the presence and validation of the appStoreReceipt to verify that the app was installed from the App Store. For this use case, the App Attest service is recommended.

rich kubota developer technical support CoreOS/Hardware/MFI

Thanks for your answer, Rich, my team is one of those who are using the local receipt validation just to check if the user downloaded our apps from the macOS Appstore, but:

• DCAppAttestService is available for macOS 11 or newer. What should we do with older systems?
• The documentation about local receipt validation (https://developer.apple.com/documentation/appstorereceipts/validating_receipts_on_the_device) isn't marked as deprecated and describes the process quite clear: If verification fails, exit with 173. This works for years and it even works sometimes for the last months. So don't you think it is a bug, that Apple should fix? Will Apple fix it?

Greetings Brigitte

Thanks for your reply, Rich, really much appreciated! Providing a freemium app I'm fine with removing the receipt validation at launch. IAP processing is handling a missing receipt now gracefully like no purchase (doing nothing), and the "Restore Purchases" option pulls the receipt ... so I'm good for now.

Nevertheless it has a smell that the sandbox environment is not acting like production, and testing cannot be done with full code coverage. In addition - as Brigitte mentioned - the exit(173) is still documented as the proposed step when no receipt is present - especially to check for a legit app at launch. DCAppAttestService cannot cover this for existing apps with support of older macOS versions (like mine).

the document on local receipt validation is still valid. There is an important distinction with the issue here and what the document states. - note the overview - When users install apps from the App Store, the app contains a cryptographically signed receipt created by Apple that’s stored inside the application bundle, which you can then validate. This statement is 100% correct. There is always an appStoreReceipt present when the app is installed from the App Store. This is not the case when the app is installed via Xcode, TestFlight or other sandbox mechanism. The use of exit (173) has been documented to trigger a "temporary" appStoreReceipt to be written to the app when none is present. If there is a bug report issue, it's with this call. As macOS has evolved, the exit (173) mechanism has demonstrated it's fragility.

I understand that the obstacle which this issue creates - that of getting the app through App Review. I wish there was a simple solution.

rich kubota

it occurs to me that the solution is - test the current version of macOS. If 11 or greater, then implement DCAppAttestService. Let's move forward with the times.

rich kubota