The issue was a symlink in my app: The Info.plist points to a file for the app icon. That file is a relative symlink to an existing icon file. This used to work for many years, and the Finder has no problem with it, either. Just Apple's recent verification process stumbles over it, without sending an error msg about it to me.

To anyone filing bug reports: Please leave a copy at https://openradar.appspot.com/ so that others can see what the problem is you reported.

I can't seem to edit the message now that I know a bit more. So, here's a reply instead. Turns out that the basic receipt validation does not use SHA-256. The message rather seems to come up when my app quits with exit code 173 due to the receipt being invalid (as in when the app was copied from a different Mac, and now the GUID doesn't match). Whereas older macOS versions would then re-fetch a new receipt (and optionally ask the user to authenticate again), this doesn't apparently happen any more (WhyTF not? Why not keep the old method and only use the new method when the app makes it known to support the new method?!) Forcing a re-fetch of the receipt by simply deleting and re-installing the app from the MAS doesn't appear to work either as the receipt appears to be cached somewhere (again WTF - why isn't macOS being cautious here and falls back to downloading it when the app keeps returning 173???) It appears the app now has to explicitly request a new receipt. With SKReceiptRefreshRequest, which is already deprecated, but no alternative is offered (I don't do in-app purchases and also don't use Xcode/Swift but something different that doesn't offer access to these classes). Searching for the error message turned up other reports where people ran into this problem with old programs that cannot be launched any more just because of this receipt caching that apparently doesn't fix itself. I can't understand why macOS is handling this so badly. Is that just ignorance or thoughtlessness on behalf of the responsible dev team at Apple or is there some good reason why macOS can't give older apps and their long-time users a break here? Or me, who has to spend hours to keep the app working just to keep up with such changes (another one is that suddenly in Tahoe right-clicks into the menu bar item don't register any more if the mouse is at the top edge of the menu bat - which totally violates basic UI concepts established over 40 years ago). This year isn't going well so far for me.

This is getting worse - a person who gets this error sent me the receipt file, and it turns out that the receipt file is fine, meaning that the validation shouldn't even fail, and thus the app not exit with 173. And since my app doesn't use any in-app purchases either, I'm now clueless what's actually causing this. In other words: What exactly causes this message to appear?

Ahh, finally found the right answer here: https://github.com/iterate-ch/cyberduck/issues/16031 Basically, the default behavior of hiding the actual Mac's MAC address is the cause for the problem ("Privaty Wi-Fi Address"): If the Mac rotates or replaces the primary network interface's MAC address, and my code still uses the old code that would fetch the MAC from the higher level APIs, it would get the wrong MAC, and then fail the receipt check. To fix this, the MAC has to be fetched from IOKit registry, e.g. as shown in https://developer.apple.com/documentation/appstorereceipts/validating-receipts-on-the-device or https://lapcatsoftware.com/articles/2023/11/4.html

Any help? Anyone else seeing crashes with the AddressBook preview?