Mac App Store: "***.app" is damaged and can't be opened-CodePudding

We do receive customer support request for our Mac App Store version where they report only getting an alert "Appname" is damaged and can't be opened. Deleting the app and downloading it fresh from the Mac App Store doesn't solve the problem. A reboot of the system seems to help, but the error seems to reappear after some time.

* is damaged and can't be opened. Delete * and download it again from the App Store.

Mac App Development: "***.app" is damaged and can't be opened is unrelated as it is about development and/or testing of an app. This also seems to break on every uneven macOS release.

So far we where not able to find a common cause for this Mac App Store issue.

We are using receipt validation code from Apples Receipt Validation Programming Guide.

CodePudding user response：

Exit If Validation Fails in macOS

If validation fails in macOS, call exit with a status of 173. This exit status notifies the system that your application has determined that its receipt is invalid. At this point, the system attempts to obtain a valid receipt and may prompt for the user’s iTunes credentials.

If the system successfully obtains a valid receipt, it relaunches the application. Otherwise, it displays an error message to the user, explaining the problem.

Do not display any error message to the user if validation fails. The system is responsible for trying to obtain a valid receipt or informing the user that the receipt is not valid.

So it seems the receipt validation fails on a valid receipt and the app calls exit with a status of 173. The system successfully obtains a receipt, it relaunches the application, and again the app calls exit with a status of 173.

Now we are presented with the "Appname" is damaged and can't be opened. alert.

Note that the system seems to cache this result, after double 173 exit, no further launch will be attempted when you double click the app, it will just show the alert again.

The reason for the receipt validation error appears to be a missing MAC address (computer’s GUID).

Without a changelog or tech note it is hard to tell exactly, but based on the Wayback Machine it seems that Apple added new Validating Receipts on the Device sometime around Sept 2021. The new code does seem to address the issue.

Compared with the code from the legacy documentation, the new code is does not only look for build-in en0, but also falls back to en1 or non-build-in en0.