Reputation: 8497
My app contains 1000 different items. All of them are part of the installed package (none of them has to be loaded after installation is complete). The items are displayed one by one. The first 50 items are for free. The rest is only available if the user did purchase a noconsumable InApp-Product.
When my app starts it looks in the keychain (this is where I store this info) if the product is purchased. If YES
, then the apps InApp-Payment-screen never will be displayed and all features are fully available. (I call this “case 0” for further references).
If the keychain does not contain this information this can mean one of two things:
Case 1
The user did not pay for the product (neither on this device nor on any other). In this case I have to display the InApp-Payment screen after the 50th item and there the user can decide if he wants to pay for the additional 950 items or if he has enough with the 50 free items.
Case 2
The user did already purchase the product (either on an other device or on this device before it has been reset, or ...). In this case I will receive the product-ID of the previous purchased product by calling [[SKPaymentQueue defaultQueue] restoreCompletedTransactions]
. When I receive it, the productID will be stored in the keychain and from now on the app should behave exactly as in case 0. This means: When the user reaches the 50th item he should not notice that there is anything special. He just can go on using the app and watch item 51 and all other items after that. The InApp-Payment screen should never be shown and the user has to be given full access to all items.
As far as I can imagine there is only one way to distinguish between case 1 and 2. The only way to find out which of both cases is true is to call restoreCompletedTransactions
before reaching the 50th item. If the call returns my productID it is case 2, if not then case 1. I have to make this call before the user reaches the 50th item because if case 2 is true the payment-dialog must not be shown.
But – and here comes my problem – when the app calls restoreCompletedTransactions
the user will be prompted for the password of his apple-ID. But the user can’t see any reason for being prompted, because – depending to which item I did bind this call – either he just did start the app, or he is just watching item #49 (which is nothing special compared to the 48 items before) or he is watching one of the items before #49.
Now imagine a user who is not willing to pay. Maybe he even has deactivated InApp-Payment for his device. But every time he uses the app and comes to a specific item (lets say it is the very unremarkable item #37) he is prompted for his password. If I was this user I would think the app has a bug or it even wants to spy my password!
So please do you have any ideas how to deal with this usecase without alienating the user?
btw
Making the call of restoreCompletedTransactions
only if [SKPaymentQueue canMakePayments]
is YES
is a bad idea. If I do so a user who has purchased the product before (maybe on an other device) and now on this device has set InApp-Payment = OFF
gets no chance to consume his already paid product. And it would not help if a user has set InApp-Payment = ON
Upvotes: 0
Views: 133
Reputation: 428
From a user point of view I think you are correct assuming never create a prompt for the password without having the user initialize the request first. In that case I believe it would be a good idea to simply include a button in the in-app payment screen, or before it next to a button that takes to to the screen that asks the user to restore transactions.
I think any situation where case 2 would occur the user would understand why their previously purchased in-app purchases aren't showing.
But I think you may also never encounter case 2 if your storing the purchased values in the keychain and if that is synced to iCloud, all their devices will see it and when you remove an app the keychain values don't get removed (from what I can tell).
Upvotes: 1