My question is not about the programming part, but the UI best-practices for IAP.
Situation: I have a single IAP ("Unlimited version") for my app, where I have a "Purchase" button, which will show inactive and change the text to "Activated" when purchased.
In case of a reinstall, the "Purchase" button would restore directly, which got my app rejected because of "Guideline 3.1.1 - Business - Payments - In-App Purchase" which says in the end, that automatic restores do not comply and a "Restore" button needs to be displayed.
So I added a check for previous purchases when entering the Settings page which is showing the "Purchase" button which will then change the button text from "Purchase" to "Restore". However, this is not instantly (depending on the connection), so this version also got rejected.
Objective: For a seamelss user experience, I didn't want to show both "Purchase" and "Restore" buttons next to each other for a single IAP line. On the other hand, if checking for previous purchases right at app startup, this could raise a AppStore login request (then unrelated to user action), which would also be awkward.
Question: does anyone have experience whether a button showing "Buy / Restore" would be accepted by AppStore Review? Or how do you usually position Restore button? I understand that, for apps with multiple IAPs it makes sense, to have ONE Restore button, but in my case it doesn't look right, because the user must know/decide whether he already purchased the IAP or not (which is completely unnecessary).
Thanks for any advice.
Related
After reading Apple's terms with my average English I understand that all application who sell non-consumable item need to use the IAP and insert a "restored button" if not the application is rejected by apple.
My user need to be connected to an account to play in my game and the IAP is attached to his account. And the non-consumable item is a money that he can spend. So I can't add a "restore button"...
So my question is, compared to my project do I really have to install a restore button? And if yes, how?
Update
I found my answer :
Apple documentation
So I don't need a restored button because I've sell consumable item.
The simplest solution is to look, how other similar apps work.
Add a restore button somewhere in settings. User taps the restore button.
If user is logged in, then his balance is automatically restored from the account on your server and you just tell him, that his balance is restored.
If he is not logged in, you should tell him, that he should login to restore his balance and then show him a login view.
All this should be reproducable by AppStore's app tester.
Is "Restore Purchase" button mandatory for iOS App submission. I have included Auto-renewable purchase in my application. I am showing the purchase screen First then only user can use my application.
if "Restore Purchase" button is mandatory, I need to show that button when it is required right?. so Is there any way to find out when "Restore Purchase" button should show?
Or else , can we show "Restore Purchase" button without considering whether user already purchased or not
FYI,
I tried to get the receipt from the Bundle.main.appStoreReceiptURL.
Then I tried to verify the receipt. If It is successfully verified, I
know the user has purchased or else I will show the purchase screen
Is it correct?
can we show "Restore Purchase" button without considering whether user already purchased or not
The whole point of the Restore Purchase button is that you are in a situation where you don't know whether the user has purchased. Only the Store knows that, and you have to let the user communicate with the Store through your app.
So, if you know that the user has purchased, fine, you know it, and there is no need for a purchase dialog / offer or a Restore button. But if you don't know it, then you know nothing. Any time you offer the user a chance at a purchase, you must offer a Restore button as well.
When user had purchased your app earlier and due to some reason he/she has uninstalled from his/her device or he/she wants to install in some other device with same apple ID(In order to enjoy purchased benefits). Over here, restore button comes into picture. Whenever we install an app from appstore, sometimes purchase verification get fail and app show itself in a normal form so overcome this situation(or any other where purchase has failed and user feels that it is being purchased), apple has asked the developer(you can see this thing in their documentation also) to provide a restore button.
Now coming to your point
"I tried to get the receipt from the Bundle.main.appStoreReceiptURL. Then I tried to verify the receipt. If It is successfully verified, I know the user has purchased or else I will show the purchase screen"
As long as you are taking the receipt data from this URL(appStoreReceiptURL) and verifying it correctly(hope you are verifying it from the apple server) everything else is fine. On the basis of that you can show or hide the restore button.
I've working code to make or restore purchase. I'm able to buy and restore.
My idea is to put two buttons on purchase screen: "Buy" and "Restore".
I want to eneble/disable those buttons depending on purchase status.
Simply:
If user not bought yet -> "Buy" enabled and "Restore" disabled
If user bought alredy -> no purchase screen :)
If user bought alredy and reinstal app - "Buy" disabled and "Restore" enabled
Of course I'm using standardUserDefaults but problem starts whe user reinstal app. My question is how to get purchase status from appStore (purchased or not yet)?
You shouldn't do this because Apple requires to always have a restore button or your app will get rejected.
You also shouldn't disable or hide the buttons depending if something was bought or restored.
If the user presses the buy button on a product he already bought he just gets the product for free again, you are never charged twice.
So I wouldn't even bother trying to do this. It also properly makes your users experience more confusing. Better to have a consistent shop experience that doesnt change all the time. Also users might be thinking there is a bug in your game because all they see is a button that doesnt work.
Maybe put a little tick or something next to the buy button if you want to indicate to the user that he already bought the item. You must have some sort of bool or other property that gets set, and saved in NSUserDefaults, once a product was bought. Just use that property to add or remove the tick/indicator.
If you are wondering how to handle the restore button on first press you should use the restore completed delegate method. There you can basically show 2 UIAlertControllers.
1 if nothing restored because nothing was previously bought and 1 that the restore was successful. Check this question I have answered recently for sample code. Restore Purchase : Non-Consumable
"We found that your app offers In-App Purchase/s that can be restored but it does not include a "Restore" feature to allow users to restore the previously purchased In-App Purchase/s. To restore previously purchased In-App Purchase products, it would be appropriate to provide a "Restore" button and initiate the restore process when the "Restore" button is tapped"
I have had an app update rejected because I don't have a restore button for my in-app purchase. What I don't understand is -- when I first show the iAP to the user, I don't know if they have already made the purchase or not. Am I still supposed to show them the restore button?
For a question on how to implement the restore button, see Apple reject because of In app purchase not implement restore.
Imagine this: The user has your app and buys the IAP. They then get a new device and install your app. The first thing they want to do on the new device is tap on your "Restore Purchases" button so they get back their paid for content.
This assumes of course you are talking about non-consumables or perhaps subscription type purchases.
Basically, any app that sells non-consumables must have a "Restore Purchases" button. You should always show the button. Of course the user may tap the button and there may be nothing to restore. This is fine. Simply display a message telling the user that there was nothing to restore.
I was wondering how I give the user the new add-ons after they purchase them. Lets say that one of my IAP's is a new tab in a tab-based application. I'm under the impression that the process is something like this:
Submit an update to my app, adding in the IAP support.
Submit my app to iTunes Connect's "Manage IAP's", with the new tab implemented in the program.
When the user clicks "Buy Now" in the IAP screen, the app will grab the version of itself with that feature implemented off of iTunes Connect.
Sorry if this is confusing, I'm having a hard time wording what I'm trying to say. Any help would be great, thanks!
Number 3 is wrong. The user will download the version of your application that supports both IAP and the new tab feature. Your app itself will have to determine whether to show the tab or not.
That is, when the user makes the purchase, you show the tab. There won't be two separate versions of your application on iTunes.
Depending on the purchase type, you can store a local flag or receipt on the device indicating that the user has purchased something. The next time your app runs, you check the flag or receipt and then show the tab only if the user had purchased the feature.
See: In-App Purchase Programming Guide