I am creating an app in which i have an in-app purchase functionality. I am using non-renewable type of subscription but i have to give the support for restoring the subscription in multiple devices.
After going through multiple documents, i found out using iCloud to be the better way to implement it and provide subscription content for user's multiple devices. Finally i decided the following design to be implemented:
User explores the app
Clicks on In-App purchase button option
Check for iCloud availability
iCloud Available :
Continue with the purchase in usual way
iCloud not available :
Show Alert view : "Sign in to iCloud required to access the subscribed content on your other device", with options "OK" and
"Continue anyway"
Click OK :
Remains on the same page
Click "Continue anyway" :
Continues with the purchase
If already purchased and iCloud available, update the iCloud receipt
On successful purchase, we get the transaction receipt. We will store this receipt in the iCloud (One time store in iCloud at the time
of purchase) using key value storage and also in the user defaults
Purchase successful.
User launches the app from another device
Check for any transaction receipt in the user defaults. If available, verify and proceed accordingly
If no receipt available in user defaults, Check for iCloud availability
iCloud Available :
Check if any transaction receipt is available
If available, verify the receipt. If the receipt is valid, provide subscribed content
If not available, no action required and proceed normally
iCloud not available :
Show alert view : "Please sign into your iCloud account to enjoy your subscription content, if any" with options "OK"
Inside the app, user switches on the option "subscribe to HD addition", will check for his subscription
ISSUE :
User purchases the app without logging into the iCloud
Launches the app from another device
He is not able to get the subscribed content
The only way to handle this scenario in a perfect way, considering all the test scenarios, is to store user's iCloud credentials into the user defaults, which i am not sure can be done/is recommended/is allowed. Any kind of suggestion is most welcome.
Also, I would need people's kind views over the above mentioned steps that whether it will be the right way to proceed with or not. Kindly suggest if i can improve it or can have a better way.
I made an App that uses iCloud NSUbiquitousKeyValueStore(which has similar selector like NSUserDefaults) to sync consumable type of IAP item.
You can check repos on Github like MKiCloudSync to see how it works.
When using NSUbiquitousKeyValueStore, there's no need for App to know the iDevices' iCloud status.
In my case, if someone holds 2 devices, device 1 has iCloud login but device 2 not, I'll ignore device 2.
Related
I'm working on an iOS app where a user must sign up/sign in to an account for my app. To be able to use my services I want users to pay via in-app purchases (auto-renewing in my case). This would then tie their IAP to their account (they created with us) to be able to use on any other iOS device.
Case 1:
For example if a subscription was bought on phone A for an account, when signing on to phone B (using the same account) shouldn't make the user pay again.
Case 2:
Or if a subscription was bought for account A on a phone, when signing up for account B on the same phone should make the user pay for account B.
Basically I want an in-app purchase to tie to my account (rather than a apple device/Apple account which is how it works to my understanding.)
I understand that their are receipts which is probably part of the answer to my question. Or if this a limitation to in app purchases what other ways can this be done (other than using Apple's IAP)
The answer to the title of the question:
When a purchase is made there is an update received in the app, the next time it is launched which contains a transaction_id (original_transaction_id for renewals), you should associate this transaction id with your app user id.
Case 1: Apple provides an option to "Restore Purchases" in your app. Since, the same account is used, your app servers would already know that a user has already paid and the app shouldn't prompt the user to pay again. However, in order to receive the upcoming renewal updates on phone B, you must "Restore Purchases" which would let Apple link the previous purchase on this device as well. Once the restore is done, the users purchase receipt will be available on the device and all subsequent actions should be taken based on the content validation of the receipt.
Few points here:
Apple will reject your app, if it doesn't provide this option to the user.
Even if your app is buggy, and you failed to restore purchases, user wouldn't be charged again. The purchase would fail saying you already have purchased this.
The above case is completely based on the assumption that the user is using the same Apple Id on both the devices(same application user id doesn't matter).
Case 2: I am not sure if that is anyhow possible. Since it's the same device, the user uses the same AppleId(unless he signs out and changes apple id in App Store) and Apple will restrict the repurchase. At best you may restrict the account B with the subscription content but if your application allows multiple accounts on the same device use case(e.g Instagram), I am not sure if there's a provision for the same.
I tested the same scenario for a music service app I use. Have an active subscription, logged out and signed up with other email (app), but the purchase was denied alerting I have already purchased. However, it was allowing me upgrade and downgrade options. I didn't opt for testing them so not to mess up my account.
P.S: There are a lot of other caveats/gotchas to take care of. Some of them:
In case 2, apple restricts the repurchase but it doesn't restrict if the user chooses an option other than the current active subscription, which will upgrade/ downgrade the subscription. Based on how you have implemented things, it might even change the subscription for user A immediately or next time the user logs back in or on next renewal thereafter.
In both the cases discussed here, user uses the same Apple Id, but consider the cases - same Apple Id different app id AND different Apple Id and same app Id. (See this)
For case 2, you should always refresh receipts or restore purchases(if there's no receipt available) for a fresh user login. The receipt has a original transaction id which you should have linked the first time the purchase was made with user A. Based on the receipt, you can either choose to let user B access the content or restrict. However, you cannot let the user pay for the new account(I suppose so).
Helpful Links:
Restoring Purchases
Receipt Validation
I have a non-renewing subscription in my app, and I'm looking for a way to restore it on other devices. I stored the datas on the user iCloud account, but when there is no account logged in, we can't store it and there is no way to get it on another devices. I don't have login system on my app, so I can't get user reference on database.
Please, is there a way to do it ?
That's what the "Restore purchase" APIs are for. Also, if a user buys the IAP again, they won't be charged, though Apple may object during App Review.
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!
I am stuck with one of the in-app purchase rejection issue in my app and need some help on this.
What this in-app for?
In our app we have options for user to become premium user. A user can become premium user to enjoy some benefits and it is tied to time. There are two in-app products which defines them
One month premium service.
One year premium service.
Since these are time based service, user expects these service should be made available for that user once he/she purchase the product for the specified time, from all his/her other devices. In order to track whether the user is premium service user or not, once the purchase is done, the app writes a entry in server about premium service. So when user uses other device and logs in, he/she can enjoy the premium service without any issues. For this reason I created the above mentioned products as "consumable", thinking that it is controlled by our server there will be no issues. But apple came back with rejection and asked me to change the products to "non-renewing subscription".
Here is what apple says about this
We found that the Purchasability Type for one or more of your In App Purchase products was inappropriately set, which is not in compliance with the App Store Review Guidelines.
"Premium account service for 1 month and 1 year" IAPs are set to Consumable.
However, based on product functionality, it would be more appropriate to use the Non-Renewable Subscription In App Purchase type because the service offered by your application requires the user to make an advance payment to access the content or receive the service.
The Purchasability type cannot be changed once an In App Purchase product has been created. Therefore, you will need to create a new In App Purchase product with the correct Purchasability Type. To create a new In App Purchase in iTunes Connect, go to Manage Your In App Purchases, select your app, and click "Create New". The current product will show in iTunes Connect as "Rejected".
Non-Renewable Subscription content must be made available to all iOS devices owned by a single user, as indicated in Guideline 11.6 of the App Store Review Guidelines:
11.6 Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices
If you choose to use user registration to meet this requirement, please keep in mind that it is not appropriate to require user registration. Such user registration must be made optional. It would be appropriate to make it clear to the user that only by registering will they be able to access the content from all of their iOS devices; and to provide them a way to register later, if they wish to access the content on their other iOS devices at a future time.
For more information about Purchasability Type, please to refer to the iTunes Connect Developer Guide.
Now I have created new in-app products which are non-renewing. But this works the same way as I mentioned earlier, i.e. the server keeps track of whether user is premium user or not, expiry date. When user goes to other device and does login, the app comes to know whether user is premium or not and based on that app works.
But I have couple of questions on this,
Should I need to provide the "Restore" button in the app? If so what is the purpose and how it works?
Since the user can access this service only after doing login to the app (it is different from app store account). Will these two logins make any issue?
Please share your valuable inputs.
It is highly unlikely that the user will end up in a situation where they won't be able to use your app unless they restore their purchases, however it is still possible. Imagine your server goes down for a day and during that day some user purchases a subscription, gets a new iPhone, installs your app on the new device and then wipes their old iPhone. I can think of a couple of other, equally unlikely, but still possible situations (Apple receipt validation server going down, etc) in which the purchase receipt will get lost in transit. It's best to provide the button, and if Apple thinks that you need it in your app, you will have a hard time convincing them otherwise.
If by "two logins" you mean user having to log in to your system and then log in to the App Store to purchase the subscription, that should not be a problem.
I recommend you make the changes Apple requested to the Purchasability Type and then re-submit. If you need to clarify a lack of a restore button put it in the notes for the reviewer
Background:
Apple requires you to implement a restoration mechanism to this type of purchases to let users to get back their purchases after wiping the device or to view purchases from user's other device.
One accepted approach form apple for doing this is to do an optional user registration and handle it on your server to save the transaction receipts. since apple don't do that like other type of purchases as non-consumable. which allow you to get all the receipts of the users to restore them.
Apple say that the registration should be optional. but we must indicate to the user that registration is required to view purchases from other devices.
My Suggested Approach:
I am going to implement the restoration mechanism by saving the purchases receipts in iCloud. I will indicate that logging into iCloud is required to access the subscription content from user's other iOS devices.
On purchasing succeeded app. will check if iCloud is available to save the subscription details(Transaction Receipt) Otherwise, subscriptions will be saved to User Defaults. Every time the app. is launched it will check if iCloud available and iCloud will be synced with User Defaults. subscriptions details available on User Defaults and not on the iCloud will be copied to the iCloud and the subscriptions that are available on iCloud and not on User Defaults will be copied to User Defaults.
Thats provide users the flexibility to login to iCloud in a future time just to move their subscriptions to another devices or just before they decided to delete the app. to save their subscription. (That all will exactly perform as we had the user registration option). Is that accepted?
Another thing. My app. suppose to work on iOS 4.x too. which mean that iCloud is not available. Is that ok too? or I have to give up running app. on iOS 4.x if I want to use iCloud approach? what if I also indicated that restoration will not be available for iOS 4.x?
One way is that , the restoration of payment and other data should be handle by your application or by your side on the server. But i think it will increase your burden of coding. But registration is optional and if user wants that he will be able to use application on his other iOS devices also then u can make registration compulsory, otherwise the restoration of payment or data should be done using keychain.
If u have still doubt then let me know.
So, in this case what if a user makes a purchase without signing into his iCloud account? We won't be providing him the content access on his other device in that case, right?
Is there any way to handle that scenario? Are we allowed to store the user's id and password into the iCloud? This may help us, but won't be a good idea to store the credentials.