Why would Mac app store review see a 'damaged app' in its testing when it can't be reproduced?

Question

Created Nov ’20

Replies 2

Boosts 0

Participants 2

This is mainly a Mac app issue, though it's perhaps related to a similar issue with iOS app receipt validation on App Store review testing.

I'm stuck in app store rejections because they are seeing a 'damaged app' error trying to launch my app on some of their test environments. I cannot reproduce in numerous attempts.

Has anyone else been stuck this way (esp. recently) and if so what did you do to resolve?

My app runs perfectly if I compile without app store code and notarize it myself, on a variety of systems. It's universal (M1 and intel), tested on all the above, both admin and standard accounts, so that makes me think the issue is only in the StoreKit / receipt-validation code.

The app does local receipt validation in a very standard way, requesting the receipt if it's absent. I've tested this with the exact app submitted (and rejected) to app store review, exported from the Xcode organizer, and in my testing the app successfully refreshes or validates the receipt. At worst (e.g. if offline) it prompts to log in with the apple ID. I'm using a sandbox App Store account to test.

I've never seen a 'damaged app' error happen even when I manually delete the receipt. The worst I've seen is a notarization error if I copy the app to a different machine (since app store archived build is not notarized, docs state that App Store will notarize it).

Since there's no Mac TestFlight I can't download the actual binary that App Store review is testing which presumably has modifications (at least, notarization). And their error reports are very vague, just a screenshot of the error and generic testing advice.

I can't be the only one who has been in this situation, and although I've used a DTS support ticket I don't know how soon they'll get back to me. Any helpful knowledge is appreciated!

Boost

Answer 1

Etresoft OP

Nov ’20

The app does local receipt validation in a very standard way, requesting the receipt if it's absent.

I wasn't aware that there was any "standard way" to do this. What do you mean "requesting the receipt"?

The only thing you should be doing is exiting with a 173 result. The operating system will refresh the receipt and try to launch again. If it keeps failing the receipt validation, then you'll get the "damaged app".

0

Answer 2

ccorbell OP

Dec ’20

Just thought I'd post a follow up on this, though the root cause is still unresolved.

As Etresoft guessed I *was* making some improper StoreKit calls. The error(173) documentation and sample code seemed older to me than more recent StoreKit documentation which advertises itself as being supported on Mac - see for example SKReceiptRefreshRequest, which says "Mac OS 9.0+" in its Availability - https://developer.apple.com/documentation/storekit/skreceiptrefreshrequest - sim. for may other StoreKit functions which are actually iOS only. It's a little confusing to have a framework called 'available' on an OS where it isn't actually supported.

At any rate, my Mac app (which has no IAP) now does not include any StoreKit calls at all nor does it link in the frame work; it only attempts to validate the receipt when present locally using openssl calls to decrypt and the Apple cert to validate, and calls error(173) if receipt is missing or invalid.

This still triggers the 'app damaged' error in App Store test review, but not anywhere else. Working with DTS we saw it occur with the app installed via the App Store .pkg, but I have never reproduced it with my own notarized build of the app tested on various machines through simple drag-install to /Applications - there everything works as expected including prompt for Apple ID, download of sandbox receipt, validation of receipt signing and contents, etc.

My DTS ticket is still open, this looks like a bug in the App Store. The only workaround for me is to not validate my receipt (just ensure its presence), but obviously that's not a secure solution if I'm going to prevent free use of the app on unauthorized machines. According to DTS the error is being caused by the App Store treating my bundle ID as unregistered, but it's clearly registered (an earlier version of the app is already shipped), so it's being investigated as an App Store / StoreKit issue.

0