Jack Humphries Jack Humphries - 6 months ago 21
iOS Question

How to deal with the length of Grand Unified Receipts?

I have an app that contains many different auto-renewing subscriptions. When the user subscribes to a new subscription, the receipt (a Grand Unified Receipt) is uploaded from the app to my server, where it is then sent to Apple and the details returned and interpreted.

I've noticed that when users are subscribed to many subscriptions, this receipt can become very long. Additionally, the receipt will naturally become long on its own as the subscriptions auto-renew every month and the new entries are inserted into the receipt.

Thus, the receipt's size could potentially become megabytes large, which imposes large data demands on the user's cellular service and requires a nontrivial amount of processing time on my server (to loop through all of the entries in the receipt to find the one that needs to be recorded).

Does anyone have advice for dealing with this issue?


Yeah this is a problem, but you only need to send your server one receipt for the iTunes user for your app for non-consumable or subscription purchases, in other words, an initial receipt validation enables you to access subsequent transactions by validating the latest_receipt string against Apple's servers.

The most efficient way would be to send your server the receipt for the users first purchase and for any subsequent purchase you can just send the transaction_id property on the SKPaymentTransaction class.

Note though that in my tests consumable purchases don't work this way, they are present in the in_app array of the receipt but subsequent receipts won't contain it anymore. So you will have to send your server these receipts if you want to validate them.