App review rejected because of verify receipt problem

Guideline 2.1 - Performance We noticed that with a valid receipt installed, your app quits on launch. The Console reports the app "Exited with exit code:173"and the OS states the app "is damaged and can't be opened." This generally indicates that the app is not verifying its receipt correctly.

Out app has auto renew subscription defined and the subscription review was rejected too.

Out app use on device receipt validation according to the Receipt Validation Programing Guide Document. We use openssl to verify signature of PKCS7 package against Apple Root Certificate, parse ANS1 objects, verify BundleID, App version, Hash from receipts and call exit 173 when validation failed as document says.

We have tested Developer Build in sandbox env and Release Build from Test Flight, and can not re-produce the error. We have told out test result to the app review team, but they still had the same error and can't gave more technical information.

I guess there may a simple setting somewhere or may be different env between us and app review team? But I can't figure it out.

Is there any one have the same problem? Or Is there something i have missed?Thanks for any help!

Post not yet marked as solved Up vote post of Chend Down vote post of Chend
1.7k views
Posted by
Chend
Reply
Add a Comment

Replies

We have the opposite problem with local receipt validation. Receipt validation in App-Review works, but in test environment it fails with 'App is damaged', which is also thrown when there is no mas_receipt. And according to this thread: https://developer.apple.com/forums/thread/705761 this is the expected behavior (unfortunately)

Greetings Brigitte

Posted by
Brigitte
Up vote reply of Brigitte Down vote reply of Brigitte

  • Thanks Brigitte. Did you find which field in receipt cause the verify error eventually? The signature of pkcs7 object, or bundle id, or app version, or hash of mac address?

    —
    Chend

  • None of this. We don't get a receipt in sandbox-test-environment.

    —
    Brigitte
Add a Comment

We are stuck with Guideline 2.1 for months as well, our app is none-consumable. so not entirely similar to Chend. After weeks of struggling, we've noticed that one significant difference of App Review and Testlfight, local Xcode testing.

The receipt is not there. (or maybe a very long delay after our refreshRequest() which time-out our App).

When our app load receipt in Xcode/Storkit, the receipt will be around 2K, which is malformed when validated against sandbox or buy(production).

When app loads receipt in TestFlight, the receipt will be 6K, which is 21007 from buy and 0 from sandbox.

Our app can handle that

We still stuck with the review, main reason, the app now will time out and prompt "no receipt" when absence.

If that's not good enough, let us know how we should improve. the review team keep post "Guideline 2.1" as their "reason" for rejection... that does not help much....

If receipt absence or delay matters, , the Xcode/storkit should help us test that first before this endless dance between our dev and review team. and provide clear and crisp guideline how we should handle the receipt delay or absence!!

We have to figure out that the absence or delay by adding more logics into the App to defend against it by ourselves. Review team just post the guideline, and they might even think we have not do any receipt validation. We did using cloud functions.

Still stuck here, our app has not been released!

We appreciate all the great work that Xcode storkit team deliver to make in-app purchase development and testing so much easier.

Maybe we are spoiled by that, but the receipt validation part is something that frustrates our developers and stalling our business.....

Hope someone can see this and at least make the review process more friendly so we can move this forward, still waiting and haven't see the light at the end of the tunnel yet. fingers crossed...

Posted by
sharkdada
Up vote reply of sharkdada Down vote reply of sharkdada
Add a Comment