“Damaged” Mac App Store Apps
The Mac App Store places a receipt file in each purchased application. The receipt includes a certificate the application uses to validate that receipt to be sure you’ve made a bona fide purchase. That certificate is only valid for a limited amount of time – in our experience, up to about 25 months, though sometimes significantly less, which could indicate the App Store renews these certificates every so often. So, when you see this “damaged” message out of the blue, it’s almost surely because the certificate in the receipt has expired. You could set the date on your Mac back a bit to work around it, but you really want to straighten things out so you don’t have to go through that fun every time you sit down to use an application.
Usually, as long as your current Apple Account has a valid purchase for the application in question, you won’t ever see the “damaged” message because the application will tell the Mac the receipt’s invalid, the Mac will automatically refresh your receipt, and you’re on your way. You should only see the message in those three cases we outlined above.
Are any other Mac developers observing a surge of support requests for “<App> is damaged and can’t be opened. Please re-download it from the Mac App Store” recently?
It started yesterday, out of the blue. macOS 15, 14, 13 and 12 as well…
I am not seeing this personally, and I’m not sure what’s going on here, but there are multiple reports of problems launching Mac App Store apps.
This bug thread suggests that some receipt validation code needs to change because Sequoia adds MAC address randomization. This post and other sources suggest that it’s important to use StoreKit 2 instead of validating receipts directly, although perhaps that only pertains to IAP. Apple’s sample code does not seem to have changed.
Previously:
- EagleFiler 1.9.15
- Error -609 Launching App From the Mac App Store
- Resolving Trusted Execution Problems
- Receipt Validation With SHA-256
- New Receipt Validation Sample Code
- Distributing Mac Apps Without Notarization
- “Damaged” Apps That Can’t Be Opened
Update (2024-10-08): Sam Rowlands (tweet):
The OWStoreKitBridge is the latest Mac App Store receipt verification code from Ohanaware. It uses a whole new design to fit in with Apple’s StoreKit, now that the classic Mac receipt verification functions have been moved to legacy.
Update (2024-10-15): See also: this thread.
Since
exit(173)is the macOS counterpart toSKReceiptRefreshRequeston iOS, I guess it falls into the same deprecation category. However, they say that the original API will continue to work. But then,exit(173)has had long phases of not working at all (example), so I’m not surprised if it’s been cut.
I would like to move to
AppTransaction, but last time I checked it didn’t support volume purchases (VPP). For apps bought in Apple School Manager, it showed an Apple ID login prompt instead.
exit(173)now shows the “API no longer available” alert when I run a build from Xcode 16 on macOS 15, but it still actually refreshes the receipt anyway.I wonder in which circumstances exactly this alert is shown. Maybe only when using the sandbox environment?
8 Comments RSS · Twitter · Mastodon
I saw this happening for Canouflage a lot in recent months. The app hasn’t been updated in years, so an expired receipt does indeed sound reasonable. Maybe the problem doesn’t happen for apps that are regularly updated.
Uninstalling and installing again sounds stupid but it always helps.
Based on issues we saw with our own apps' receipt checking (among other things, for crossgrading purposes), my current working theory is that receipts mass-expired on October 1st or 2nd, causing problems in the scenarios Keith described, and possibly also if you aren't online when launching an app with an expired receipt.
I've seen that too for some apps (usually those that offer buyable upgrades to their feature sets). The worst is when it happens on your no-longer-supported version of macOS, the App Store no longer works properly, and you suddenly are left w/o the apps, because you can't even re-download them because the currently offered version no longer runs on your version of macOS. Planned obsolescence by design. That's why I no longer buy anything from the App Store at all.
> Just delete and re-install it
Is awful user experience. It gives a customer the impression that devs are hacks or doing something wrong when it's Yet-Another-Apple-Bug projected onto us. Another bug Apple will probably never fix (like the quarantine xattr bug).
Since billions in revenue doesn't motivate Apple to fix things, how about bad PR? Maybe customer support pages should take a tone trashing Apple with a header "THIS IS AN APPLE BUG". Include instructions for a fix, then a mailto link a customer can click addressed to Tim Cook with a populated bug report. For every Apple bug we have to deal with, Apple execs should hear about it.
Just ran into this myself, the receipt is generated with a different MAC address than the one we're able to get.
The workaround (which I borrowed from Cyber Duck) is to use IOKit to read the MAC address. Waiting on Apple to approve one of my apps with this fix and then I'll have to update the others.
IMHO, this is just another reason to avoid shipping apps on the Mac App Store. I suspect at some point the IOKit solution to become broken and then how are we supposed to validate receipts?
Apple wants us not to parse the local receipts on device.
> It turns out that an on-device purchase using StoreKit 2 doesn’t automatically update the App Store receipt, even though the app receives a notification from the App Store servers after a successful purchase.
Well, I’m not going to want to use a server to validate receipts for every app. And local receipt validation is good enough in many cases. They really ought to support this. Also outside MAS apps often use the Mac address to set a limit on app installs so i’m sure this change is affecting some apps outside the Mac App Store as well.
