iOS app receipt validation failing

We have several apps live in the iOS store using code to validate the app receipt locally, using the techniques introduced with iOS 7 and documented here :


https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateLocally.html#//apple_ref/doc/uid/TP40010573-CH1-SW2


However I have noticed an alarming rate of failure of this code lately, up to the point that we're having trouble even passing App Store review in our last updates, since the code even fails for them. Basically, it looks like the initial receipts on app install/update are invalid, forcing us to refresh it explicitly (which is a bad user experience, forcing the user to enter their App Store login info). This in turn leads to a bad user experience, looking a lot like a bug to the App Review team, even with our own attempts to mitigate this.


Once the receipt is refreshed, the validation passes just fine, so it is likely not a problem with our validation code, but rather seems to be a problem with the way Apple installs the receipts upon app install or update. Maybe they changed something about the format for initial receipts, but if that is the case there has been no updates to the documentation since last year. Maybe there will be explanations about this at the current WWDC?


Has anybody else experienced something similar? In the past this seemed to be happening intermittently (rarely enough that this wasn't a problem with App Review). Lately this seems to have been failing much more consistently, and even happens on my own devices now. Even worse is that I don't see a way to test this properly as this is expected behavior in the developer sandbox. Validation works fine with a refreshed receipt in both testing and production environmens. It is just not supposed to happen in production, yet it does - and way too much.


We're seriously considering getting rid of receipt validation in our apps if Apple can't make it work properly - which is a shame as besides the piracy protection it really helped keeping track of the user's past purchases simply by inspecting the receipt, and thus avoiding the need to do a "restore purchase". It would be nice to be able to keep doing that, but if this just doesn't work at all out of the gate, then I'm afraid that it's not worth bothering with.

Replies

Hi there,


I seem to be having the same issue you are describing but only on Testflight for now. (my post - https://forums.developer.apple.com/thread/4997 )


I thought this wasn't suppose to happen in live production environment. Are you seeing this in live environment recently? Had this never happened before?

We've had the same problem. Apple's documentation says a receipt is provided on an install (doesn't say anything about an update), but our code tripped up because the receipt wasn't there. It seems like in the last couple of iOS updates that the receipt isn't sent along with the app, and I guess we're supposed to ask for it manually - which isn't the greatest idea, as you mention, since it presents the App Store sign-in dialog. On TestFlight for us this failed with an error code 100 in the delegate method - (void) request:(SKRequest *)request didFailWithError:(NSError *)error. We thought it was because of TestFlight; now I'm not so sure that it isn't something inside Apple.


We changed receipt checking to tell us what was going on, and submitted a new build to see what would happen. That's how we found out that the receipt is missing. Other than asking every user to sign in to the App Store (and making sure that, if an error occurs, we don't ask again and again and again) I'm not sure how we can proceed.