I am planning to use subscription (auto renew) type of in-app purchase. My idea is to allow one subscription per device. (i.e.) if someone purchase the subscription on iPhone, he shouldn't be able to use same subscription on iPad. Instead I want to force user to new subscription for other device. But from in-app purchase what i understood is that, if user subscribe for a particular item, if he tries to purchase the same thing again, app store allows to user to restore already purchased item.
As per my current setup, all the downloads will happen from a separate server and I am going to keep all the receipts and content in that server. In order to implement this particular thing, what should I do in my application? Could someone help me on this?
Also if I want to limit download of data from server using in-app purchase for only 3 device? Beyond 3 I want user to make payment via in-app purchase again? How will I do this?
Thanks
Apple's In-App Purchase Guidelines state that you must support restoring subscriptions to all of a user's devices (see page 7).
Also consider if your content is episodic (such as a TV show or magazine) because that's a requirement for using auto-renewing subscriptions. For things like time-limited access to a certain feature, like voice guidance in a navigation app, you'd need to use non-renewing subscriptions.
Related
I'm creating a Mac app that has a non-renewing subscription as an in-app purchase. I want to sync this data to the cloud for the following reasons:
I want the user to be able to use the app on all their Macs
The in-app purchase enables a widget, so that widget needs to access this data.
By Apple's documentation the restoration of non-renewing subscriptions has to be handled by the app by some kind of registration / cloud sync.
So I decided to implement a CloudKit sync to store the following data:
Which IAP product did the user purchase (currently only one value, but might change in the future)
When did the purchase occur.
Here's what I'm doing now when a user makes an in-app purchase:
I validate the receipt
If I find any IAP data, I sync that to CloudKit
I use a function to fetch the purchase data from CloudKit for the said widget
Question 1: As far as I can tell all the in-app purchases are contained in the receipt file, even after removing and restoring it. I could be using this, however the documentation clearly says I shouldn't. Even the forums are not certain about it... What do you think?
Question 2: While testing the app with multiple sandbox users I noticed that no matter which sandbox user I use to make the purchase, the currently logged in iCloud account (my personal account) gets the receipt data synced to CloudKit. Why isn't the purchaser (App Store) user getting the data to their private cloud database? How can I test that everything works fine? Do I have to log out of my iCloud account to make this work?
Thank you for your time :)
Question 1: Using the App Receipt to restore non-renewable subscriptions
From Apple's Documentation:
Apple's documentation on whether an in-app purchase of a non-renewing subscription remains in the receipt has contradictory answers:
Yes (retrieved 2016-05-11):
Table 1-2 Comparison of subscription types
Subscription type Auto-renewable Non-renewing Free
Users can buy Multiple times Multiple times Once
Appears in the receipt Always Always Always
Synced across devices By the system By your app By the system
Restored By the system By your app By the system
No (retrieved 2016-05-11):
The in-app purchase receipt for a consumable product or non-renewing subscription is added to the receipt when the purchase is made. It is kept in the receipt until your app finishes that transaction. After that point, it is removed from the receipt the next time the receipt is updated—for example, when the user makes another purchase or if your app explicitly refreshes the receipt.
From Apple's Developer Forums:
In a thread reporting the temporary (now fixed) loss of non-renewable subscriptions from the app receipt, an Apple Developer Technical Support engineer said:
I've queried the iTunes Production Support engineer who made the change - The "fix" to provide the history of non-renewing subscriptions in the application receipt is permanent. My interpretation is that permament means that if we make a change, we'll announce the change at a Developer Conference and announce the function to be deprecated for a period of time.
With regards to using iCloud as a means to restore non-renewing subscriptions, I've heard from my App Review contact - an application "can use iCloud to track the non-renewing subscriptions (NRS) but it can’t force the user to login prior to making the purchase. It has to be optional - that can can alert the user that iCloud is required to access the NRS content from their other iOS devices - and providing a way to register later, if users wish to have access to this content at a later time."
Source: https://forums.developer.apple.com/thread/22345#79067
You could attempt refreshing the app receipt to restore the non-renewable subscriptions, but it has broken before, the documentation isn't clear, and there have been past reports of App Review rejecting applications that try this method.
Question 2:
CloudKit always uses the current iCloud account under Settings > iCloud.
App Store purchases use the Apple ID configured in Settings > iTunes & App Store.
The user may be signed into the same Apple ID for both iCloud & iTunes, but there is no guarantee. These are two entirely separate settings.
We are three guys, who have made a free game for iPhone, which has been available on the App Store for almost a year.
The app is a board game, where you create a user or login using your Facebook credentials. You are able to log out of the game and log back in with another account.
Now we have updated the app with the ability to upgrade the user to a premium user. Allowing personal and global game statistics.
But Apple is giving us a headache in the approval process, and refuses to accept our In-App Purchase. First they would not approve it, as it had no restore button. Then when we told them, a restore button was not required, as it was a consumable purchase, they now demand we change it to a non-consumable and add the restore button.
Consider this scenario if purchase was non-consumable.
User logs in.
User upgrades account to premium
User logs out.
User logs in with a different account.
User restores the previous purchase.
This would allow you to upgrade two accounts to premium, but with just one purchase.
Apple's argument is, that our users need to be able to restore purchases, if a new device is setup, or a device is restored.
But that is not the way it works. Users upgrade their accounts to premium accounts. Now when they buy a new device or restores an existing device, they just log in with their existing game account, and the upgrade will be available, because we on the server-side has marked the account as a premium account.
So my question is basically. Were we totally wrong, when we choose to use a consumable instead of a non-consumable. And if so, how should a non-consumable be implemented in order to be (potentially) purchased more than once with different game accounts on the same device?
And secondly, if we are correct about the usage of a consumable in-app purchase, what should we say to convince Apple, that we are on the right path?
If your premium account is something that your users have to buy only once then Apple is definitely right to ask you to switch to non-consumable in-app.
The scenario you described is quite possible (i had to face it too) but if you add server-side verification of in-app receipts before unlocking the premium feature (saving all transactions associated to a user) you have the chance to verify that the purchase is new or restored checking the fields original_transaction_id and original_purchase_date in the receipt data. This way you can see if the user restoring the purchase is the same that originally bought it (maybe checking its facebook user id).
Anyway, experience showed me that the chance of this happening is not really high and i wouldn't recommend implementing this check (although server side validation is almost always a must ;-) )
According to the 'Restoring Transactions' section of the In-App Purchase Programming Guide:
If your application supports product types that must be restorable, you must include an interface that allows users to restore these purchases.
If your app contains non-consumable purchase, and if you don't include a restore button apple will not approve your app.
This has been made necessary by apple after June 2012.
So to answer your question: No, it seems that you must use restoreCompletedTransactions.
Hope it helps you.
I am new to In-App purchase feature in iOS.
I am working on an iOS app in which I'll be showcasing my products along with its price, and when the user wants to purchase a products he can do so by tapping on shopping cart, which will launch a web-view and displays my mobile webpage from where they can buy the selected product. My products are tangible and will be delivered outside the App.
My question is:
Do I need to implement In-App purchase, even if the user transaction is done in my mobile web-page?
If I have to implement Apple In-App purchase, how will I know if the user has purchased the product, so as to inform the Apple that a product has been purchased?
It really depends on the type of product you are selling. If it's a tangible good. i.e. a Plane ticket, or some other physical item. You can use your own payment mechanism. If it's something that can be consumed in the app, or could otherwise be conceivably delivered via Apple's IAP mechanism then you must use IAP. If you don't you will most likely be rejected.
To answer your questions. 1) If the transaction is done via the web, and is for a none-IAP type item as described above, then you cannot use IAP. 2) If you did have something that could be purchased via IAP, Apple is responsible for the transaction, and they take the typical 30% off the top.
Check out section 11 (specifically, 11.2 and 11.3) of the review guidelines
Apple will not allow you to direct the consumer to purchase something Within the app. Unless it is with an in app purchase.
The way we have gotten around this. is to let the user request information about it. or sign up an invoice. which will be delivered to their email address. and they can continue the purchase outside the app.
Apple has graciously accepted our app with this feature.
If you want them to provide a credit card number within the app, then you will need to use In app purchases instead.
Another way around this may be to have them sign up on your site and add a credit card for them to purchase with. And use that purchase method when the user buys something.
Not requiring them to put in their credit card on the app is I believe the main concern.
i have a news reader app. i want to add IAP to my app.
i added Consumable Purchase. when the user purchases i write expire date to nsuserdefaults.
when it expires i show purchase screen again.
but apple rejected it,
it says:
However, based on product functionality, it would be more appropriate to use the 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.
...
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:
....
first i tried to use Auto-Renewable Subscription, but my app doesn't have any content to be downloaded.
then i tried to implement Non-Renewing subscription. but people say that it is deprecated.
i want to allow users who buyed app to use it on other devices too.
but i can't get AppleId (Apple doesn't allow it either).
I'm really stucked.
how can i add monthly subscription to my app?
can anyone give me some advice...
I've been through almost the exact same thing. Here's what you do:
First off, although Apple's documentation seems to suggest that Non-Renewing Subscriptions are deprecated, they are not. In fact, that's what Apple steered me towards when they rejected my app for using Auto-Renewing subscriptions.
In terms of syncing across multiple devices: I tried using a unique identifier that I stored on the user's iCloud account to identify a user (like what #Yorxxx suggested), but Apple rejected the app again, saying that the guidelines state that I need to provide an optional username/password system to allow a user to restore their subscription onto all their devices.
A few notes about Non-Renewing Subscriptions:
You set and track your own durations and expiration dates.
You essentially have to administer the service from your own server, since you'll need to sync a user's subscription across all their devices.
There is no prompt asking the user if they want to send the developer their contact information.
restoreCompletedTransactions is useless with Non-Renewing Subscriptions.
If I were you I would store the persons username on iCloud if they give you one. That way, when they install your app on a new device, you can prompt them that they already have an account and if they log in, their existing subscription will by synced to that device.
I have a question regarding in-app payments for iPhone apps. I thought the only difference between auto-renewing subscriptions and non-renewing subscriptions was obviously the self-renewing thing.
But as I read through the documentation it seems that there are other important differences. This is how I understood it:
Auto-renewing:
user can disable auto-renewing (so it might behave like a non-renewing subscription)
is restored after a device reset
is automatically transfered between different devices on the same iTunes account
can only be bought once (as long as the subscription is still valid)
Non-renewing:
the developer must handle license restoring after device resets
user can buy the subscription more than once at a time
Is this correct?
I seems like auto-renewing subscriptions are way better for my app, even though I don't need the subscription to necessarily renew automatically.
But, as an additional question, when I added a new product in iTunes Connect, I had only the choice between "Consumable", "Non-consumable" and "non-renewing subscription" - but no auto-renewing subscription?!
Best regards
I think you get the differences globally.
Some corrections however:
is restored after a device reset
is automatically transfered between different devices on the same iTunes account
Not really, it's up to you, in your application, (usually in the dedicated "store" part of your application) to propose a restore subscription so that the user will be able to get back his subscription on this iOS device (this may be needed if he resets the device as you said, but also if he deletes the application and reinstall it).
The restore action (triggered in your code via StoreKit) will automatically prompt the user for his iTunes password, so this cannot be done automatically without user acknowledge.
user can disable auto-renewing (so it might behave like a non-renewing subscription)
yes this can be achieved from the settings in the iPhone, in the "store" part, and then display for apple ID properties: the user will get a view with all his on going subscription + a switch to disable the auto renewing.
when I added a new product in iTunes Connect, I had only the choice between "Consumable", "Non-consumable" and "non-renewing subscription" - but no auto-renewing subscription?!
I also had this at the beginning, the reason for that is that you didn't acknowledge a part of the contract (Amendments) that is specifically related to autorenewable subscription. As far as I can remember, go to the Contracts, Tax, Banking part of itunesConnect and you should have something to agree on, then you'll be able to create auto-renewable in app purchase.
a subscription is not synced with iTunes instead it is saved on a apple server somewhere. It is stored in your account (indeed thats not correct, it can be synced but I mean it's not only stored on the device). "Consumable" are such things like ammo in a shooter game. You can buy them more than one time and but this would mean that "Non-consumable" and "non-renewing subscription" are nearly the same.
Did you read the customer help also additionally to the developer documentation?
http://support.apple.com/kb/ht4009