My application was rejected due to "missing restore mechanism". I don't understand because I put the restore button in a UIAlertView.
Yes, the functionality that Apple is asking you to put into your app is to provide a "restore" ability.
If one deletes your app (which they paid for) and wants to restore it later, they've still paid for it. And that's the functionality you need to make happen.
Here is a tutorial that talks about what to do, in terms of code.
You must add Restore button whenever you used in App purchase in your app.
as per apple documentation there is several types of in app purchases. one of them is "non-consumable n app purchase". Nonconsumable inapp purchase means the user have to paid for that only once, he do not need to paid for the same item again.
But now question is that if user deletes your app from device then how can he get his/her product back without any type of payment. for this purpose apple recommends to the developer to add the RESTORE button in app when there is in app purchase.
http://www.raywenderlich.com/21081/introduction-to-in-app-purchases-in-ios-6-tutorial
The above link is for in app purchase where you can find extra information about restore and some helpful code.
Hope this help someone.
Related
According to Apple doc, calling restoreCompletedTransactions() prompts user for App Store password:
Don't automatically restore purchases, especially when your app is launched. Restoring purchases prompts for the user’s App Store credentials, which interrupts the flow of your app.
I tried quite a few apps but never observed this behavior. One example is bear, a freemium note taking app. When I pressed its "restore purchase" button, it just went ahead to query and then showed an alert saying that there was no purchase information for me.
I wonder how is this implemented? I guess it stores users purchase information on its own server so it queries its own server, instead of App store. But the question is how it identifies me? (Note Bear app doesn't require user to create an account to use the app. I just downloaded the app and didn't do anything in it yet.). I know iOS has DeviceCheck API, but I think that only identifies a device, instead of an user, right?
Thanks for any help.
Note: Bear app's "restore purchase" button can be found by going to its side menu, pressing setting button at the bottom, pressing "get Pro!" button.
You need to be signed in with Apple ID in order to download apps and make purchases, that's how they match it.
I searched a lot and did not find a concept for "In-App Purchases restore"
in our application all users can't used without login by email and pass, and all purchases saved in our system to enable multiple platform so the button of restore purchases is mandatory with this case or not?
The App Store Review Guidelines says:
Any credits or in-game currencies purchased via in-app purchase may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases.
So yes, a restore mechanism is mandatory.
Apple of course doesn't say it needs to be a button. Perhaps you can implement it without any user input; for example at first app startup.
Also, a restore method is mandatory, regardless of where/if you store a purchase. I mean, if you wouldn't have a backend system, you are still required to have a restore mechanism.
(It's good to read all App Store Review Guidelines.)
When a user of an iOS app purchases a non-consumable item, then installs that app on a new device, it is possible for them to again go through the standard purchasing logic for that item. The app store will ask them if they wish to spend $0.99 on the item, but if they click "Yes", it will inform that they already own that item, and ask if they wish to download it for free.
I would like to track new purchases in my analytics, and not have them conflated with re-purchased items that a user receives for free. Unfortunately, it seems that this behavior is indistinguishable from a genuinely new purchase, (to the client app). Apple seems to say as much: "Note: If the user attempts to purchase a product that’s already been purchased, rather than using your app’s restoration interface, the App Store creates a regular transaction instead of a restore transaction. The user isn’t charged again for the product. Treat these transactions the exact same way you treated the original transactions."
In discussing this issue, most posts (and Apple's documentation) say that I should offer a 'Restore Transactions' button to the users. I do offer this button, but it is always possible for users to circumvent this logic, and go through the traditional purchasing route. This is where my tracking will become inaccurate.
Do I have any options? Thanks!
I am pretty sure you don't have any options for tracking a new purchase versus downloading a previous purchase for free when a user does an in app purchase. I have looked into this for the same reason of analytics and I could not find a way to do it. IAP is set up to make sure that you honor purchases made by the same iTunes account on other devices.
If your users are required to have an account specific to your app to make a purchase you could use that to know if they already have made the purchase or not. But requiring an account for purchase can lower your conversion rate.
I have a magazine app, and I want to provide users a one year auto-renewable subscription, and for non-subscribed users, they can use non-consumable IAPs to pay for each issue and then download it. What is the best way to implement it?
For auto-renewable subscription I don't think it's a problem. I can follow the tutorial at http://www.viggiosoft.com/blog/blog/2011/10/29/at-newsstand-and-subscriptions/ to finish this part. But for the non-consumable IAP part, I'm not sure. Do I need to add all the non-consumable IAPs for future issues before I submit the app? If I do this, how could Apple review my IAPs, because the future issues are not prepared at the reviewing time. Or, can I add non-consumable IAPs after my app is published to the App store? For example, every time when a new issue is ready in our server, we add a new non-soncumable IAP in iTC, and also set the product id to the issue in the server. When the non-subscribed user click that issue, the purchase for the specified product id will start. Is it possible?
After some research I found that the best way to implement it is to set up a new non-consumable IAP at each time when you want to publish a new issue.
The only problem is that, each IAP needs to be submitted for review, and before it is approved, the users who try to buy the issue will get an error message: "Cannot connect to the iTunes store". I haven't figured out how to know that the IAP is in review, so I can popup a nicer message like "Issue is review, please wait" other than a confusing error message.
I have a magazine app, and I want to provide users a one year
auto-renewable subscription, and for non-subscribed users, they can
use non-consumable IAPs to pay for each issue and then download it.
What is the best way to implement it?
You should accept your solution, but here is another case, maybe it helps you or others:
The subscribers can have they magazines, which are not in at iTunes Server, but at your hosting. Those magazines not need to bypass the apple review.
It depends whether you want a user to be able to permanently have a record stored in their app receipt of the issues they have bought. You might want this, if you want a user to be able to delete the app, with all associated content, then later re-install the app, and be able to download the specific back issues they purchased previously—all without having any user account on your own server. The use of a non-consumable in-app purchase also enables you to give them access to these issues across multiple devices that are signed in to that Apple ID, again without having to run your own user account-server combination to track purchased issues.
If these features don't matter to you, then there is a solution you could consider that is much simpler where you don't have to keep creating new in-app purchase products. Have a consumable in-app purchase product that is called something like Purchase One Issue. When a person buys this product, they get one credit and they can use this to select the issue they wish to be given access to. Your app then gives them access to that issue. You could also of course reverse this process in the UX: they pick the issue, click buy, you send them into the purchase process for the Purchase One Issue product, and you automatically give them access to the selected issue since they already selected it.
Note: consumable in-app purchases are not stored in the app receipt, so a user couldn't use this approach to 'restore previous purchases'. In scenarios where this is acceptable however, this is a much less labour intensive approach once set up.
I want to create an app that will be displayed as FREE on the App Store, but upon opening it, users are required to do and in-app purchase to be able to access any of the content. I am reading the App Store Review Guidelines, but I am not sure if Apple allows this since the users will not be able to see anything on the app unless they subscribe to it.
The reason I need this is because my client wants the app to be sold at $0.99/year and I don't think this can be done by setting only via Price Tier.
Create a membership only app.
You must sign in to use the app (you can give apple a test account)
then you can manage the membership on your own servers. Or allow them to sign up with the in app purchase.
(enable both the user login and the in app purchase to get a user login, then you can give apple a "test" account that requires no purchase)
They will test your in app purchases anyhow so make sure you follow all the rules on Re-Activating in app purchases, this way if the user comes back and reloads their purchase and they have 2 months left you are sure the app will still allow them.
As long as you dont try to accept credit cards from the app, and use their in app purchase system you should be fine.
If you want to enable users to purchase their account from your server, you cannot allow the purchase from the app. The login however can enable the app without the purchase (and the test account should) but in app purchase should allow them to attach their purchase to the account they use.
I think im rambling now so I hope thats enough clarification.
What you can do is present a demo of the app as a feature before the user buying in-app purchase.just a screen extra. So that Apple does not reject it.
The other option is:
If you have a login/password app, you can tell apple that your app requires login before any feature can be given, only if your in-app thing is login related.