Are in-app purchase receipts included in the App Store receipt on initial install on a new device?

I’m pretty sure you will get the IAPs in the local receipt on a second device.

There may be some odd corner-cases where you don’t, so do have a “restore purchases” button.

I also watched that video. It wasn’t very helpful. They didn’t say anything about local receipt validation, when it would clearly be simpler than implementing server infrastructure in many cases. The paranoid half of my brain thinks this is a message to us that that functionality is going away soon.

@endecotp I'm not sure why they recommend a server side approach to proactively restore in app purchases since that can be affected by network conditions if the receipt includes previous app purchases on initial install. Would be nice to know officially if this is the case or not.

There may be some odd corner-cases where you don’t, so do have a “restore purchases” button.

Indeed I do have a restore in app purchase button. Back when iTunes backups included apps I assume the receipt would need to be refreshed when installed on a new device. I assume this is still true if the the user installs the app using third party backup software instead of downloading from the App Store.

To your question, yes, the app receipt after a new install on a 2nd device after you had already subscribed would contain the past purchase. Note that if the 2nd device already has the app installed before the 1 set device made the purchase, then it would not. The app receipts on all the users devices may not all be up to date, which is why VerifyReceipt is used to get the latest status and transactions.

Local receipt validation wasn’t discussed specifically because it won’t have the latest purchase status reliably, therefore you can’t create this experience accurately.

Therefore to create such an experience you will either need to adopt StoreKit2 or use verifyReceipt with app receipts.

To your question, yes, the app receipt after a new install on a 2nd device after you had already subscribed would contain the past purchase. Note that if the 2nd device already has the app installed before the 1 set device made the purchase, then it would not.

Thanks a lot for sharing this information. I had no idea using using server receipt validation also implicitly refreshed the receipt. For the case of Auto renewable subscriptions especially this is a bit of a bummer. I was expecting/hoping StoreKit would push an auto-renewable subscription purchase to all devices logged in with the same Apple ID via SKPaymentQueue, but it does not until at least the first iAP receipt for the subscription is active on the device.

Couldn't a manual call to -restoreCompletedTransactions on SKPaymentQueue achieve the same thing at launch (if determined that no iAP receipt is present). This is a single method call and the code would be way simpler. I'm aware that using server side receipt validation has other benefits but I'm specifically referring to proactively restoring in app purchases.

Local receipt validation wasn’t discussed specifically because it won’t have the latest purchase status reliably, therefore you can’t create this experience accurately. Therefore to create such an experience you will either need to adopt StoreKit2 or use verifyReceipt with app receipts.

I can still think of a way that this won't provide exactly the user experience I was hoping for.

1. On app launch use server-side receipt validation.
2. Install the app both on two devices, an iPhone and an iPad. Launch the app on both devices.
3. Subscribe to an auto renewable subscription on an iPhone.
4. Since the app is already running on the iPad, server side receipt validation already finished before the purchase made on the iPhone completed, so the user still needs to use the "Restore in app purchases button" manually

If the server pushed auto renewable subscription purchases to all devices logged in with the same Apple ID developers wouldn't have to worry about such timing issues. I suppose it would be possible for developers to manually implement this with either with their own server or CloudKit, but it would be really nice if StoreKit just did it.