My iOS app has in-app purchases (consumable) and shows ads periodically. The idea is to remove ads after user has purchased anything. But in-app items are consumable, so after user re-installs the app, I would be unable to determine if he has purchased anything using [[SKPaymentQueue defaultQueue] restoreCompletedTransactions];, right? And I would bomb him with ads again...
What would you suggest to find out that the user has purchased anything already?
Well when a user re-installs your app (i.e. delete it and install it again) there is no immediate way of knowing what purchases did he made. That's why Apple requires your app to provide a way to restore previous purchases so that when the user performs this operation he restores these purchases for free.
For consumable items you might need to use a server for managing the purchases such that when the app loads it checks with the server which purchases the user has made and immediately enable the relevant content.
I do not know if mandatory but "Remove Ads" IAP should be non-consumable so the user will only need to purchase it once (Otherwise I believe users will complain or just won't buy it).
Some creative ways can be found here : iPhone - in-App purchase consumable correct approach
As an improvement on the situation, you could store the fact that a purchase was made in NSUserDefaults. That won't survive if the user uninstalls and reinstalls the app, but at least it survives if the user buys a new phone and restores a backup to transfer everything to the new phone.
You could have a look at Cloud Kit as well, which would store information per AppleId. It's a bit overkill for the problem, but it means you can use Apple's servers instead of your own for free. There would be a difference that if a user installs your app on six devices, makes a consumable purchase on one device, ads will stop on all of them.
Related
We're designing an iPad app at the moment which offers in-app purchases for non-consumable items.
As the scope of the project has expanded, we want to allow the option to sign in to an account, and then sign out of that account and into another - similar to how one could on an app like the Facebook app.
My question is: is it possible to link Apple's in-app purchases to one of our system's user accounts, so that a User may sign in to a different device and access their purchases, but if another User signs in to my device, they cannot access my purchases (despite the device being signed in to my Apple ID)?
Any suggestions welcome
All completed in app purchases are tied to the Apple ID that was used at the time of the transaction. Since non-consumable in app purchases can only be purchased once, you can't use those. So, the only option would be to use consumable in app purchases and keep track of which system user account made the purchase. You need to store those purchase records on an external server somewhere though, since Apple will have no way of telling you which purchase went to which of your internal users. If you lose that purchase history your users will have to buy the item again, and probably not be very happy.
I am implementing In-App Purchase in my app and test around the existing apps to get some ideas. But I found a scenario which I am quite confused on it.
I have installed an iOS app and purchased the particular levels. Later I uninstall this app, sign out from existing iTunes store account and sign in again with another apple id, then reinstall that app again (same app). Here i can again i need to purchase the particular levels.But my doubt is In-App purchase method we can use based on the purchase Apple ID or Device token ?
If the user can purchased with Apple ID ,then the user can login with another device they no need to purchased again but one user can purchase app and user can login to another users Devices is the one problem..!why because another users no need to purchase.
And if we set the Device token, based on the in-app purchase user can only login that device only ,they can't login another devices with same Apple ID,here it is a problem.
I am quite confused on it... so is the purchased items tied on device if we use multiple apple ids on same device?
I understand that I can restore my purchased items on different devices using same apple id. But how about multiple apple id on multiple devices? If I have 2 apple id associated on an device, I use one of them purchased item, but later I use these 2 apple id login to another device, am I still need to pay again to download items I have purchased on previous device?
Please let me know if my questions are not clear... I hope someone can give some idea on sharing purchased items against different devices and apple ids.And which one use the in-app purchase.
Any suggestions and comments are welcome. Thanks a lot.
IAPs fall into two categories - consumable, and non-consumable.
Non-consumable purchases (purchase level 10-15 of a game, upgrade to pro, etc) are synced across devices by the system, and are restored by the system. They are tied to the Apple ID.
Consumable purchases (purchase 5 gold coins) are NOT synced or restored. Your application needs to remember that the purchase has been made, and store information about that so that a backup and restore correctly restores the user's state. If the user uninstalls and then reinstalls, they have lost any previous consumable purchases (but they will retain all non-consumable purchases, and your application can query for these). You can, of course, sync all information about consumable purchases to your own server, but you would then need to have the user create an account with you. This would allow you to sync consumables between devices.
The Device ID (which you can't get, anyway) has no relevance.
See https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html for more discussion.
If the IAPs are non-consumables (or autorenewables) they can be 'restored' by the user (i.e. the app would execute a restoreCompletedTransactions or refreshReceipt). I believe that the username/password log-in required to restoreCompletedTransactions (or refreshReceipt) must be the same username/password as the person who downloaded the app onto the device. Given that requirement, I still believe that a single 'purchaser' can share their single purchase of a non-consumable IAP on many devices.
I'm researching how to properly implement the functionality to remove ads in my app when the user makes any IAP and have that functionality restorable.
The way i'm seeing the first part done is to simply put a value in the user defaults that the user has made a purchase and check it before displaying ad. No problem.
But i don't know how to do the restorable part because all my products are consumables. How can I restore this value when the user reinstalls the app? Because as i understand the only record of a consumable is on the device and cannot be restored by apple correct?
Any help would be greatly appreciated, thanks!
You cannot do this purely through store-kit APIs, as there is no restorable purchase record as you say. I can see a couple of options -
You could enable iCloud for your app and persist data to the user's iCloud account, however this won't work for users who don't have iCloud.
You could have the users register an account on your server and use that to store their purchase history (or provide a Facebook login etc).
If a user deletes and re-installs your app then they need to make another in-app purchase to remove the ads - Profit!
guys I've implemented an in-app purchase using PARSE. Now there is no restore button in my app . My DB, hosted on the PARSE cloud has a an attribute called "hasMadePurchase" in my User's table which is checked every time the user tries to make a purchase. The attribute is set to yes as soon as a successful purchase has been made.
Now with that, do I need a restore purchases button for the app to get it through the app store? Cause clearly, even if the user changes his/her device deletes and re-installs the app or whatever he/she will still be able to get all his/her purchases back.
If yes, than what do I need to implement in my restore function? (which would basically do nothing, other than making fake calls, i don't know i am kinda lost)
A restore purchases button is needed only if the app offers non-consumable IAPs, e.g. unlocking content. Our game got rejected recently exactly for this reason - we were offering weapon unlocks and we were missing the restore purchases button.
If you are offering non-consumable IAPs then you can start by looking into [[SKPaymentQueue defaultQueue] restoreCompletedTransactions] and go from there. Basically, this fetches the list of all IAP SKUs that have been previously purchased by the user.
My app got rejected because of restore button on non-renewing in app purchase. Do i have to remove restore button ? If i have to do so then how user will restore his purchases.Please help.
Non-renewing subscriptions are consumable. Therefore they cannot be restored. A restore button therefore makes no sense. You also need some kind of authentication/login system for the user. (See below for detailed explanations.)
Sources:
consumable vs. non-consumable in app purchases
non-renewing subscriptions
Update from WWDC2017: In Session #303 App Store Engineer Pete Hare explains at 3:00 that a non-renewing-subscription can be seen as "a consumable product with an expiry date on it"
There has been some debates in the comments wether non-renewing subscriptions are consumable or not, so I want to say something about it. "Consumable" means that you can consume them multiple times. Like "30 minutes of talking" in a voice-over-IP telephony application. On the other hand, there are non-consumables that you can buy only once. Like when you unlock all levels in a game app. You buy it once, and when you reset the device and redownload the app, you should be able to restore the purchase, so that you don't have to pay twice to unlock all levels. Furthermore, if you don't tap the restore-button in this case but just buy the "unlock all levels" package again, it works, but you will not be charged by apple a second time. That's why it is called non-consumable. It's some kind of metapher. An apple is "consumable". Once it is consumed, it is gone. A chair is non-consumable. You have it as long as you don't destroy it or give it away.
So, it makes sense to regard a non-renewing subscription as non-consumable. If you buy it a second time, you shouldn't pay twice, you should just use the old subscription you already have. If you reset the device, you should be able to restore the subscription once you re-download the app. The restoration is just not done by Apple but by the app itself.
I still regard non-renewing subscriptions as consumable though. I use a simple definition of consumable vs. non-consumable: An in-app-purchase is consumable, when, from the point of view of the StoreKit API, it can be purchased multiple times in the same week by the same user. All consumable IAP-items cannot be restored through the StoreKit. All non-consumable IAP-items can be restored through the StoreKit.
So, the developer is himself responsible for restoring the in-app-purchase of a non-renewing subscription, right? No, sorry. How would the app restore the in-app-purchase of a non-renewing subscription? Suppose I have an iPod and I subscribe to 1 month of listening to the Foo-radio. Now I want to also listen to the Foo-Radio on my iPad. Soo, I install the Foo-App on my iPad and tap the "restore" button. Well... what is the "restore" button supposed to do? How can it know if I already have purchased a "Foo"-subscription or not, and how long it will still be valid? Answer: it can not. This approach does not work.
In order for a non-renewing subscription to work, you have to login the user first, to tie the subscription to some online account. Username/Password, Open-ID, Login via Gmail, Facebook, etc. all would work. Then, when the user purchases an n-r subscription you have to store the fact that he subscribed on some server and link it to his account on the server. You also have to prevent the user from buying the n-r subscription when he is not already logged in. Let's continue with my iPod/iPad-example above. I download the app on my iPad, I login with Facebook, and voila, I can use the "Foo"-subscription now. There is no need for a "restore" button, because the app should check at login-time which subscriptions the user has.
There will be some additional problems to deal with. (1) For example, nothing prevents the user from logging in into 200 devices. Here the problem is not a user with 200 devices, but a university with 1000 students where 180 students share the same account. (2) If the server crashes, some people will probably lose their subscriptions. Problem (1) can potentially lead to decreased income. Problem (2) can lead to angry and unhappy customers.
From Apple: "Non-renewable subscriptions. Subscriptions that don’t involve delivering episodic content. Examples include access to a database of historic photos or a collection of flight maps. It’s your app’s responsibility to make the subscription available on all of the user’s devices and to let users restore the purchase. This product type is often used when your users already have an account on your server that you can use to identify them when restoring content. Expiration and the duration of the subscription are also left to your app (or your server) to implement and enforce." [Italics and bold added] https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html
Apple Reviewer's current-similar response about Non-Renewing Subscriptions "Your app offers Non-Renewing Subscriptions and this purchasability type must have its own restoring function - if you have removed it please re-implement it. Furthermore, your app must also offer a function, such as account creation, such that purchases can be tracked across all of a user's devices. Please implement a login feature as well as a restore mechanism prior to resubmitting your revised binary for review."