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.

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.

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.