Do we still need "Restore purchases" button with app receipt mechanism?

On "Validating Receipts Locally" page we can see the following text:


When an application is installed from the App Store, it contains an application receipt that is cryptographically signed, ensuring that only Apple can create valid receipts.


Also inthis post two people pointed out that a receipt is provided on an install.

So, why do we need "Restore purchases" button? On SKReceiptRefreshRequest page we can see the following text:


The SKReceiptRefreshRequest class allows an app to refresh its receipt. With this API, the app can request a new receipt if the receipt is invalid or missing.


So we need this button to refresh app receipt? Is it provided on install or not? Why should it be missing or invalid after install on new device? Hackers can modify app receipt, of course, but we can validate it with App Store and then fire SKReceiptRefreshRequest in case it's invalid or missing. Do we really need to provide "Restore purchases" button to end user?

1) If a user purchases an IAP on device 1 they need some way to get the IAP to also appear on device 2.

2) >The SKReceiptRefreshRequest class allows an app to refresh its receipt. With this API, the app can request a new receipt if the receipt is invalid or missing.

When the app does this the user is prompted to log into their iTunes Account. You can't do that without the user asking for it.

And further to the above...

>So we need this button to refresh app receipt? Is it provided on install or not? Why should it be missing or invalid after install on new device?


The receipt may be missing depending on how the app was installed on the device (i.e. from synching to iTunes or directly over the internet).

Yes, still need for any 'restorables'. See 3.1.1 in the app review guide (emphasis mine):


3.1.1 In-App Purchase: If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP. Any credits or in-game currencies purchased via IAP must be consumed within the app and may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases. Please remember to assign the correct purchasability type or your app will be rejected. Apps should not directly or indirectly enable gifting of IAP content, features, or consumable items to others. Apps distributed via the Mac App Store may host plug-ins or extensions that are enabled with mechanisms other than the App Store.

> 1) If a user purchases an IAP on device 1 they need some way to get the IAP to also appear on device 2

After reading this I tested it by purchasing auto-renewable subscription on device 1 and refreshing the receipt on device 2 and the IAP appears on both so maybe I didn't get your point.

> When the app does this the user is prompted to log into their iTunes Account. You can't do that without the user asking for it.

My app (supports >iOS 7) offers non-consumable IAP only (auto-renewable subscriptions and another non-consumable product).

I couldn't find a reason why keep using [[SKPaymentQueue defaultQueue] restoreCompletedTransactions] when SKReceiptRefreshRequest brings up all IAP in a single receipt.

Can I restore purchases(after user taps 'restore purhcases' button) with SKReceiptRefreshRequest only or am I missing something?

My point is that you need to provide the user with a method of asking the app to restore their purchases to a new device. You can't surprise the user by refreshing the receipt without their knowing it because that will prompt a log-in request from the app store. So you need something like a button that says 'refresh purchases'. Once that request has been issued by the user you can either restoreCompletedPurchases OR refresh the receipt. But you must do one or the other; and you can't do either without an explicit request from the user.


The restoreCompletedTransactions request is a better approach for an auto-renewable subscription because it will cause future renewals to generate a transaction that will be sent, in the background, to this device. If you just refresh teh receipt that will not cause a transaction to be sent to this device the next time there is a renewal. That means that the issue in the first paragraph will not arise again if you restoreCompletedTransactions but it will arise, again and again on each renewal, if you refresh receipt over and over again.

After a user restores an auto-renewing sub to a new device, that device will automatically receive updates about subsequent renewal transactions. But does the first device (i.e. the one on which sub was originally purchased, before it was restored on a second device) continue to recevie the same updates? And more specifically, if updates detailing latest renewal transactions are being sent to both devices - is the receipt data being sent to both devices identical, with same Transaction ID value for latest renewal transaction? The Restore process generates new transaction IDs for each restored transaction, but I don't understand what happens with the receipts that follow or how that works across mutliple devices. Thanks in advance for any light you can shed here.

New transactions are sent to all devices that originally purchase or subsequently restore an autorenewable subscription. In a restoreCompletedTransaction the original transaction.transactionIdentifier is unique but it is not in the receipt.


I never tested the various transactionIdentifiers for renewals but I believe (never tested, just surmise):

The transaction.transactionIdentifier in updatedTransactions is unique for each device.

It is, however, NOT necessarily in the receipt -

What is in the receipt is the transactionIdentifier that went to the purchasing device

Do we still need "Restore purchases" button with app receipt mechanism?
 
 
Q