Update 10/2011: Watch the WWDC 2011 video on in-app purchases. This clarifies some of the points in this post and introduces a handful of useful fields in the receipt.
I think Apple’s documentation on checking receipts for auto-renewable in-app subscriptions is a little sparse. I overlooked this paragraph when first reading the documentation and wasn’t aware of its ramifications.
The response also includes an additional latest-receipt field; if the user’s subscription is active and was renewed in a transaction that took place after the transaction you provided to the App Store, the latest-receipt field includes a new base-64 encoded receipt for the latest renewal for this subscription. Your server can use this new receipt to maintain a record of the most recent renewal.
Here’s a sample response where receipt and latest_receipt are identical, we’re inside the first subscription period.
When your app is launched regularly, everything is just about the same as with good old-fashioned non-consumable subscriptions. The app receives restored transactions to verify via your server.
When the app isn’t launched, you may still want to be able to stay in sync with the user’s subscription, even when he is not running the app. You can have a scheduled task on your server that can periodically replay the last known receipt to Apple, and if the latest_receipt differs from the receipt you just sent, you can send it right back to Apple to get the latest renewal date.
latest_receipt_info is not documented, so it might be a safer bet to actually use latest_receipt’s contents.
Use the purchase_date within the latest_receipt to calculate the current subscription period. The length of time for every period is not contained within the receipt date, so you need to calculate it from your product_id or item_id.
By doing this, you can maintain accurate subscriber stats on the server or grant paying users web access to content originally purchased in the app.