We are looking at using consumable (non-renewable) IAP for subscriptions for our app after being rejected for auto-renewable subscriptions. I've read through many posts pertaining to this, but haven't seen any discussion on limiting the number of iOS devices a user can use the consumable on or "restore" to.
The main concept seems to be, let user create an account (optionally) on your server, and allow them to enter account info to restore/share across multiple devices.
My primary question is, how can we limit the number of devices a user is allowed to use the subscription on, and the number of devices a user is allowed to "restore" to, and still meet Apple's requirements for restoring purchases?
If we setup a server, and allow the user to optionally create an account to store the receipt information, how can we keep that user from sharing their login information with anyone if we have no way to uniquely track the number of unique devices that are using the account? (perhaps I'm wrong here, but with the deprecation of UUID and the possibility of identifierForAdvertising changing if the app is deleted and re-installed, there is no way to cache a unique device to determine how many devices have used the subscription, correct?)
I've contemplated storing an auth token in the user's iCloud, but from my understanding, there is no upper limit on how many devices can share an iCloud account.
I'm sure I'm not the first to run into this problem, how is everyone solving this?
Thanks -
Matt
Consumable items are intended to be device-sepcific. And once consumed, the user must purchase it again, even if it were purchased previously on the given device.
Apple doesn't officially want you to limit the number of devices for subscriptions or non-consumables - they want your IAP subscriptions and non-consumables to be available on ALL of a user's devices. See: https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/StoreKitGuide/APIOverview/OverviewoftheStoreKitAPI.html
Why not use iCloud to transfer an IAP non-renewable-subscription between devices? That limits it to just the user's device set. Why do you care if they have 2 devices or 10? I bet that users don't typically share their apple-id's outside of their immediate family.
Related
I intend my app to gain access to my server after the in-app purchase is complete. This access requires real work, and data & traffic ($$).
A typical client might own anywhere up to a couple of hundred devices (and I assume on one account, for their simplicity).
Thus I only get the one payment across many, many devices interacting with the server.
I'm not trying to be stingy - but can I prevent multiple devices sharing the same purchase (in my case server access)?
Or do I implement another method for selling access?
You'll have to implement another method. Apple's guide explicitly states that:
Users can restore products that they previously purchased—for example, to bring content they’ve already paid for onto their new phone.
If the same iTunes account is associated with more than one device then Apple requires any purchases to be available on all those devices.
#Tommy is correct - regarding non-consumable IAPs. However, you could implement a non-recurring subscription in-app purchase instead and give each device a unique identifier. When the user attempts to access the server, you could see if that identifier is in your database (if the user has purchased the IAP), and determine whether or not they need to purchase a subscription. Even though you may not want a subscription-based service, you could probably make a membership for a very long period of time like 10 years (it's not required to be selected in iTunes Connect) and handle it that way. Only issue is that you need to figure out a way to give each device a unique ID that won't change.
Further to the #Tommy answer, in the February 3, 2014 version of Apple's Getting Started with In-App Purchase on iOS and OS X it says:
There are a handful of important guidelines to keep in mind as you design your application:
- You must make your In-App Purchase items available to all of the devices registered to a user
and
Users view the items they purchase as theirs to keep and permanent. Therefore be sure
purchased items are available in all instances of your app running on all the devices the user
owns, even after your app is deleted from a device, reinstalled, or downloaded to a new device.
and
For Non-Renewing Subscriptions, [blah, blah, blah]..
Additionally, your application must include a mechanism to deliver the purchased Non-
Renewing Subscription In App Purchase to all iOS devices owned by a single user.
Looks like there is no way to restrict items to a single device :(
The IAP never expires. It is linked to a UUID in a KeyChain. The UUID is used in a database and other places as an identifer, and is critical to functionality.
If they upgrade to a newer iPhone and reuse the Apple ID, then the IAP follows them. The UUID shouldn't be changing in this case. Everything is cool so far.
But I don't want the IAP to be shared across multiple devices sharing the same Apple ID. I want them to pay for the IAP because every new device with the IAP represents a cost to me.
So I'm at a dilemma on how to classify it:
It isn't a consumable because you never need more than one and you don't use it up.
It could be a non-consumable, however, those need to be restored based on Apple ID. Here I get screwed with the Restore Purchases requirement. Basically, any Joe Schmoe can give out his Apple ID to his friends, and everybody gets the IAP for free. I don't want the IAP transferred to multiple devices.
It could be a non-renewing subscription, but it never expires, so they never need to add additional subscriptions. Can I specify the subscription lasts for a very long time (like 20 years) and limit them to purchasing one? The Apple guidelines aren't very specific on this.
It's not an auto-renewable subscription for multiple reasons detailed above.
It is a non-consumable. If you expect the Apple ID will be used across multiple devices, just price your IAP accordingly to account for this.
To be honest, I'm not sure this question is a great fit here because it's not a programming question and nobody but Apple's app review team will be able to give you a definite answer. I do know that subscriptions need to be restorable across multiple devices, so I don't know if that helps you out. The only non-restorable purchase type you can have is a consumable.
I am also not sure that your logic quite works - let's say you store the UUID in the keychain. How are you deriving it so that it's locked to the SIM? You don't have access to the IMEI or anything that uniquely identifies the SIM card on iOS.
You want to restrict the use to one device. That means it must be a "consumable IAP" according to Apple guidelines (note - non-renewing subscriptions won't work - they need to be copied to all devices owned by the user). So make it consumable but make it easy - sell the product as "5000 uses". Each time the user uses the function or the App, charge them one 'use'. This also has the advantage that a heavy user may willingly pay you twice.
And…you can use bluetooth (MKSession) or iCloud to transfer all remaining uses from one device to another device to solve the problem of a user purchasing a new device.
I am implementing an App with in app purchase of type:non-renewing subscriptions.
according to apple documents:
If your app uses non-renewing subscriptions, your app is responsible for the restoration process.
FROM HERE
My question is, if the restoring is mandatory by apple, how to prevent thousands of users sharing one apple account with only one description?
For example, if in my app, you pay $0.99 that can use this app for 10 days, from apple's requirements, the user must be able to use app within 10 days on any his/her devices, with simply enter the credentials. However, if the user set a simple account credentials and share it with 100 people, then, the 100 people don't have to buy the subscription anymore and can use the app free during the 10 days.
Some people keep assert that people won't share their account... how do you know that? i saw people register some apple id exclusive for sharing apps and games, and only need to pay once.
Besides, i don't implement my own server and my App don't need one. Is there a way to prevent this?
Thanks in advance
Since non-renewing subscriptions seem to require the app (developer) to use a separate (non-Apple) server to deal with the restore process (for example, see How to support multiple devices with non-renewing In-App Purchase?), why not have that server keep track of the number of restores per "user"? Then you could impose a maximum number of restores per "user". Each installed app that has made a purchase could have its own unique_token (for example, see app rejected.how to track user non-renewing subscription). The user would then have to have a username/password, which would be associated with the unique_token, in order to do a restore (for example, see Restore transactions for Non-renewing subscriptions without registration; and see Registration should be always optional on non-renewing subscription?).
My client has an app in the App Store that uses the auto-renew subscription type. Upon resubmitting the app it was rejected because they claimed they don't have periodic content (even though they do... but this problem seems to be ubiquitous currently). I was wondering what the best approach is to deal with non-renewing subscriptions. Specifically issues dealing with:
Losing your device and restoring your subscription
Restoring your subscription to multiple devices (as mandated by Apple)
Preventing users from abusing the system.
What I came up with so far is the following:
When a user purchases a 1 month subscription this information is stored locally (say in NSUserDefaults). Also, a unique ID is generated and sent to my clients server. When the subscription ends users are asked whether they want to be directed to the purchase screen. If users wishes to save the subscription in case they need to restore they device, or in case they lose their device, they can opt to have the unique identifier sent to their email address (which they are prompted to enter, indicating that this information will not be used). The app has an place to enter this ID. It will retrieve the subscription information from the server and again store this in the NSUserDefaults. Each time a restore is done, a counter is increased. When it has reached say 5, the user can no longer restore. The same principle described above works in the case of sharing subscriptions over multiple devices. Does this seem like a reasonable solution (and one that Apple will accept)?
Thanks for your time!
Why don't you want to use Apple's restoreCompletedTransactions? It just provides you with information about ALL the previous purchases, on any device, at any time.
http://developer.apple.com/library/mac/#documentation/StoreKit/Reference/SKPaymentQueue_Class/Reference/Reference.html#//apple_ref/occ/instm/SKPaymentQueue/restoreCompletedTransactions
The app I'm working on was recently rejected by Apple for containing an auto-renewable subscription. They recommended that we switch to non-renewing subscriptions for our content.
The one thing I can't quite wrap my brain round is how to restore a purchased subscription to a shared device. Apple recommends we don't use user login - something we would like to avoid ourselves. I did come across one solution where unique codes were used between the two devices - to validate a purchased subscription, through a server. But I believe that could be easily pirated, as in theory friends or employees within a company could share these unique codes with one another and avoid paying the subscription charge.
I can't really find much on Google about this, and was curious to know if anyone has been able to successfully implement a non-renewing subscription?
To paraphrase the advice we received from Apple when dealing with these issues:
Per the iTunes Connect Developer Guide:
...subscriptions must be provided on all devices associated with a
user. In App Purchase expects subscriptions to be delivered through an
external server that you will provide. You must provide infrastructure
to deliver subscriptions to multiple devices.
Apple consider user registration to be appropriate but won't allow you to make it obligatory. So registration must be optional and the user must be able to register at any time — including to allow them to share a subscription they've already bought between devices.
So it sounds like we may have received slightly different advice. Is it possible that Apple only told you not to require user login in general, separately from the requirement for distributing the subscription to all devices?