I wish to implement IAP within my iOS app, offering a push notification service for a period of time. This seems to fit under the category of non-renewing subscriptions. One requirement from Apple is
You are required to deliver non-renewing subscriptions to all devices
owned by the user. Non-renewing subscriptions are not automatically
synchronized to all devices by Store Kit; you must implement this
infrastructure yourself. For example, most subscriptions are provided
by an external server; your server would need to implement a mechanism
to identify users and associate subscription purchases with the user
who purchased them.
However, I don't want this subscription to be shared across all user's devices (as there is extra cost for pushing notification on additional devices). Does my app's requirement violate the Apple's requirement above? Has anyone experienced any issues similar to what I will do?
Any subscription MUST be restorable to any device that is associated with the user's Apple ID. The subscription is to the Apple ID, not the device. You will be rejected unless you comply completely to this rule.
There's nothing you can do; Apple is very strict on this provision.
Related
here's my straightforward question:
is it allowed for my iOS application to force users to log into my custom account management system, so I can link them to my backend when they want to purchase a non-renewing subscription?
Here's the backstory:
I have a non-renewing subscription. For a good amount of users I can see that the Apple receipt does not contain information about this subscription; the in_app array is empty. This is correct according to the API:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html
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
For some users, I can still see the purchase in the receipt, but let's consider that a bug from Apple and follow their API documentation to the letter.
(More on why this is a bug here https://forums.developer.apple.com/thread/22345)
In order to restore the user's purchase, I'd need something to identify him with. I could create a unique token, store that on the iCloud keychain and use that across the devices to detect the purchase belongs to that Apple account, but since my application supports account creation, I'd rather just use that mechanism. Else I'm using two different methods of purchase detection side by side: iCloud keychain token or a user account.
Thing is, I'm not sure I am allowed to force users to make an account before making a purchase. Is this something Apple would reject the app submission for with a message like "Your users must be able to buy stuff without going through your lengthy account registration process" ?
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.
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html
So its your app's responsibility to check that user has valid subscription or its over and let them purchase it again !
For this you will ask user to first make account or login into app so by this way you can track their subscriptions.
I am developing he application which delivers audio clips as channel basis media over http streaming.
I am planing to use Auto-Renewable Subscriptions in the app and they are renewing on monhly basis as we are updating the contents(Audio clips) of the channel frequently.
I was going through the Apple policy for auto renwing subscription which is,
Definition
Auto-renewable subscriptions allow users to purchase dynamic content, such as magazine subscriptions, for a set duration of time. Subscriptions renew automatically unless the user opts out of the renewal. If the content you want offer doesn’t fit what’s outlined in the App Review Guidelines, consider offering the content through a non-renewing subscription.
Auto-renewable subscriptions can include an incentive to customers who share their contact information with you.
Review Guideline
11.15. Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected
Its very confusing which method to use in my app (Auto-Renewing or Non-Renewing)
hense there are different types of thoughts/information shared on the internet.
So, my question is which method is appropriate to my app?
Can my product will get approval or not if I stick to use Auto-Renewable Subscriptions?
Further, if theres any complete tutorial/sample app for auto-renewable subscriptions please share with me.
Thanks
You can use the Auto-Renewable Subscriptions if you are going to change the content on certain time period basis.
But if this thing is going to be stopped in future then this way will not work for you. Any time Apple reject your application if he get complaints from any user.
To avoid this I will suggest to go with the Non-Renewing Subscription in that you are the one who is going to manage everything by your own. Apple will only provide facility to do transaction only. Rest of the things like management of time period will be on your hands only. In this case your application will not be rejected by Apple anytime in future as well.
Refer this link for sample code which manages everything..
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?).
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.
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?