My application currently allows the user to subscribe to our service using in-app purchase auto-renewable subscription. The app provides images, 12 images per month, and every month the user needs to renew his/her subscription to see the new content.
I haven't work on the auto-renewable model before, so I have built a model to validate the receipt and it works, but should I check if the user subscription expired or not, and, if so, how?
Also, does the app store only allow magazines and newspaper items to be auto-renewable?
I haven't worked on the auto-renewable model before, so any help on this matter would be highly appreciated.
When a user signs up for an auto-renewable subscription, they continue to be charged until they manually cancel it. This is obviously great from a developer’s point of view, because it takes a lot more effort to cancel something than to just let it continue.
You might already be familiar with a class of apps that use auto-renewable subscriptions already: Newsstand.
Newsstand was first introduced in iOS 5, and allows content providers to easily distribute their newspapers and magazines. With it, Apple introduced the auto-renewable subscription model, which allows you to set a subscription duration and manage renewals automatically through the StoreKit framework.
However, Apple has placed some very strict rules around auto-renewable subscriptions, meaning their usage is (usually) exclusive to Newsstand apps.
So sadly, if you want to provide content or features for a limited duration, outside of Newsstand, then your only option is to use non-renewing subscriptions.
found that here: http://www.raywenderlich.com/36270/in-app-purchases-non-renewing-subscription-tutorial
An auto-renewable subscription is an iOS In-App Purchase category that allows an app to provide and charge for content or features over a set amount of time.
Hear is a very useful link!. It provides almost every details about auto renewable subscription
Auto-Renewable In-App purchases continues charging the user (weekly/monthly/yearly etc.) until they cancel it.
You can check if the subscription has expired using the a validated receipt. It contains subscription expiration date and time.
If you want to lock content if subscription has not renewed, you may want to check receipt info against current date/time, on applicationDidBecomeActive delegate. There are open source libraries that lets you verify receipts locally as well.
And any kind of app can have Auto-Renewable In-App purchases, not just newsstand apps.
Related
I am having a programmer code my iOS app, which he has done great. However, due to a new competitor we have decided to change from our current revenue model with In-App Purchases as subscription based to just having users pay a one-time fee. He tells me it'll take a lot of hours to make that change. Is it really true that there is no easy way around changing the code from having renewable purchases to simply have one-time purchases?
Well, this is a very objective question. It's impossible to tell you with any certainty without reviewing the actual code, but here are a few of the obstacles your developer may face:
The methods to buy a subscription is slightly different to buying a non-consumable product, however the app will need to continue to provide content users who are currently paying for a subscription. There is no way to change a subscription to a non-consumable product in iTunes Connect, and you may need to, or should ask and remind the user to cancel their subscription to prevent further renewals (you can't do this yourself or in the app, you can only link to the subscriptions page in their iTunes settings).
The app will need to check for either the subscription product (active or expired) or the non-consumable product has been purchased in order to provide the content. Support for this will need to be on the start of the app, purchase of a product and on the restore in-app purchases function.
There may be further complexities too, particularly if your app uses a backend API that syncs purchase information with a user account.
In conclusion, it's non-trivial, if your developer says it will take a lot of hours, I would be inclined to believe him.
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..
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."
My application is a web-service client. Service has a paid one month subscription. I want to implement subscription payment with IAP. At first I think to implement it as Auto-Renewable Subscription but after reading several posts about it drawbacks (rejecting from the App Store because the content is not a digital content or something like this) I decided to make Non-renewable subscription - but it also has some drawbacks (hard to sync it, optional registration). In on SO post - developer wrote that his app was rejected from the App Store when he made iCloud synchronization.
So can someone with good production experience wrote all pros and cons of both Auto-Renewable Subscriptions and Non-renewable? What should I choose for the one-month subscription to the medical web-service? Thanks
I do not have experience with auto-renewable subscriptions, but I do have extensive experience with IAP and non-renewable subscriptions. I use non-renewable subscriptions for a service that isn't a digital download.
Renewable Subscription Cons
User has to manually renew each month.
You will probably want to consider longer subscription periods. My app has 2 month and 1 year.
Renewable Subscription Pros
Users only pay for what they use. You can turn this to your advantage.
My own app saw a good increase in conversation rates when I explained that subscriptions do not auto renew and so they did not need to worry about canceling the subscription.
You can change the price!
Much more flexibility about how you can use it.
It has the standard popups during purchase. You will have a better conversation rate from the user hitting the buy button to them following through with the purchase.
Auto-Renewable Cons
LOTS of regulations about what you can do with it.
It is very possible that you won't be able to use auto-renewable in your situation.
Only the user can cancel their subscription. You can't add an easy way to do this into your app and keep your users happy.
The purchase process has extra steps that ask the user if they want to share their information with the publisher.
There is no API to know when the subscription will end.
You will have more negative reviews.
Auto-Renewable Pros
Users don't have to manually renew.
You have a more guaranteed income per month.
You will need to sync the subscriptions between devices. I use Parse.com as my backend. Basically, before making an IAP transaction as complete I push the data to parse. Users can then pull that data down onto their device to sync the subscriptions. Parse lets you save the transaction for users with and without accounts. So it has the benefit of giving you real time sales information.
EDIT: Auto Renewable Subscriptions will Change This Fall
Auto renewable subscriptions are drastically changing this Fall (2016). Pretty much every reason not to use auto renewable is going away. https://developer.apple.com/app-store/subscriptions/whats-new/
I had exactly the same experience with a auto-renewable subscription (an app that gives access to a specific information while subscription is active). The app was rejected because "app is not suited for auto-renewable subscriptions, and their recommendation was to switch to non-renewable subscription, and that is what I did.
After that, the app was rejected because there was no way to transfer the subscription between user's devices or after device reset. What I did, was to set up an user/password authentication system and allow up to 5 devices to connect at the same time with one user/password combination and to allow to extend the subscription from any of that user's devices. This solution was approved (back when iOS 5 was the latest version) and is still working.
In my app, I would like users to buy a subscription for Backup, Sync, and more.
so I found out that Apple offer two kinds of subscription IAP:
Non Renewable Subscription
Auto Renewable Subscription
which should I use, given that I don't have a server, and I rely on iCloud for the sync?
Auto-renewable in-app purchase are allowed only if your app provide new content each time (or often) the user pays. (like provide new magazine, video...)
If your purpose is to do a premium subscription which give access to so premium functions (so no logic of periodical new content), Apple will reject your app.
You will find much more explanations on the subject here: The limited world of auto-renewable subscriptions
I don't know much about this, but I think it is quite difficult to get Apple to accept an auto-renewable subscription for anything but Newsstand apps. For other use cases, I think they prefer you to adopt the non-renewable subscription.
You could also consider a one time payment to 'unlock' the feature, rather than a subscription, since you aren't actually paying any ongoing costs (e.g. storing data).