Mac App Store shows error: "Application is damaged, remove it and download again from App Store."

The affected customers are starting to leave one-star reviews

Oi vey, that’s not good.

Does anybody have an idea what could suddenly be going wrong with the
installation from the Mac App Store?

Not off the top of my head. If no one else chimes in I’m going to recommend that you open a DTS tech support incident so that I, or one of my colleagues, can help you investigate this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

Does anybody have an idea what could suddenly be going wrong with the installation from the Mac App store?

That is the initial setup where the App Store installs the receipt. There are a number of things that could cause such a problem. The only time I've encountered it is in development when I'm trying to run developer signed versions or I've screwed up the receipt validation logic. Possible external factors could be various "security" or "clean up" apps. They can wreak havoc with signatures, the operating system, or networking.

If you can get any of them to contact you directly instead of leaving one-star reviews, you could inquire about what 3rd party system modifications they have installed. Just remember that most of them likely have no idea what software they have installed. They may need help.

After some sweat and tears we have found the reason for the installation failures with the Mac App Store:
At some point in the last weeks, Apple must have changed the format of the date values in its ASN.1 receipt files. They used to look like "2020-10-03T07:12:34Z". Now they contain millisceonds like in "2020-10-03T07:12:34.567Z". Apple's receipt field specification ( https://developer.apple.com/library/archive/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html ) only states that dates follow RFC 3339, which does not specify if there should be milliseconds or not.
To parse the receipt dates, our apps used an NSDateFormatter with the following format: "yyyy-MM-dd'T'HH:mm:ss'Z". Because of the format change, our app failed to parse the millisecond-containing dates and therefore regarded the app receipts as being invalid and then decided to terminate with exit code 173, as specified by Apple in https://developer.apple.com/library/archive/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateLocally.html
macOS then recreated the app-receipt and started our app again. This led to a background loop, which after a couple of minutes gets terminated by the system with said damage/reinstall alert.
To make it even harder for us developers, Apple still sends out receipts containing dates WITHOUT milliseconds if an app has been originally bought before October.

So my fellow developers: Make sure you harden your code for validating subscription receipts against two different date formats.

The RFC 3339 does include an optional milliseconds. However, I just tried this with my own app using the App Store sandbox and a free app on the production sandbox. The date fields on both receipts do not have milliseconds.

It seems like a change on this scale would break an awful lot of apps. I'm looking into supporting the milliseconds field, but I see no evidence that this is an emergency. Could there be some other explanation for what you are seeing?

When parsing receipts from the Mac App Store, we have been seeing ones with milliseconds and ones without. Even in the same receipt, there are dates with and dates without.
However we do not understand the pattern behind this.
We also have more than twenty customers reporting this problem, and counting.

When parsing receipts from the Mac App Store, we have been seeing ones with milliseconds and ones without. Even in the same receipt, there are dates with and dates without.
However we do not understand the pattern behind this. 
We also have more than twenty customers reporting this problem, and counting.

No one else is reporting a problem with this.

Which fields, specifically, are showing milliseconds? In the receipt specification page that you posted, there is one field, "Subscription Expiration Date" that is documented as being in milliseconds. Is that the only field where you are seeing this? Or are there others?

After seeing the public tweet about this issue I dug into it myself out of curiosity and because I was concerned my own receipt validation might be vulnerable to the problem. In my analysis I did find some dates that are now including milliseconds, but only in and undocumented field for the receipt file. If @depth42 is using the receipt file data for the "original purchase date" (not receipt download date), then that might explain it. Unfortunately this has never been exposed publicly through the receipt file format, though it is publicly exposed through the server-side receipt validation API.

I did find some dates that are now including milliseconds, but only in and undocumented field for the receipt file. If @depth42 is using the receipt file data for the "original purchase date" (not receipt download date), then that might explain it. Unfortunately this has never been exposed publicly through the receipt file format, though it is publicly exposed through the server-side receipt validation API.

The original purchase date is documented and is documented to be in both methods.

@Etresoft are you sure you're not thinking of the web API response? The local receipt file does not have any documented field for the original purchase date of the app.

In the sandbox, this issue occurs from time to time following the call to
exit(173)
The reason for the Finder alert has typically stemmed from the app bundle Identifier not being found when the Finder sends a request to the sandbox App Store Server for a temporary appStoreReceipt. In the outgoing request, the app bundle identifier is sent. If there is no match on the App Store, no receipt is returned and the Finder presents this alert when the app is relaunched.

This issue should not be happening in the production environment. This is a bug report issue to be submitted using the Apple Developer Feedback Assistant web site.

rich kubota - rkubota@apple.com
developer technical support CoreOS/Hardware/MFI

In the receipts we encountered, the milliseconds occurred in the original purchase date filed. Here is one of those receipts:
https://www.icloud.com/iclouddrive/0dSTgclIPHq__JEvWHvi2n9OQ#AppStoreReceipt

Thanks @Etresoft. Our code converted the ASN.1 variant into a JSON representation. The code was written on the base of an early example which made use of the attribute with type "18" which is indeed undocumented by Apple. The ASN.1 variant does not offer a documented access to the app original purchase date, only for in-app purchases.

As a side-note: The transactions of StoreKit.framework are a nice absctraction, but when having to work with subscriptions they are leaky. Having to manually parse ASN.1 receipts just to get the expiry date for a subscription is cumbersome and - as you have seen -error prone.

The transactions of StoreKit.framework are a nice absctraction, but when having to work with subscriptions they are leaky. Having to manually parse ASN.1 receipts just to get the expiry date for a subscription is cumbersome and - as you have seen -error prone.

Maybe a different question and/or forum would be a good idea. I haven't used subscriptions so I can't say anything about them. I don't know what "leaky" means. It sure looks like there is a "Subscription Expiration Date" in the receipt. Apple also has some server-to-server functionality that may help.