I've got auto-renewing subscriptions working in my app, and I have three terms users can pick from:
1 month
3 months
1 year
After they're purchased one subscription, which is set to auto-renew, is there a way to set a different tier for their auto-renew choice the next time their sub expires? For example, they're on a 1 year subscription right now, but they want to go monthly after it expires.
I know this can be done in Settings -> Store -> Apple ID -> Subscriptions, but that's kind of a pain to get to. And we can't even send them directly to the settings since Apple removed those preference URLs in 5.1.
So is there an API to do this?
Thanks.
If I understand your question the answer is yes. You can offer a new duration to a user before the auto-renewal of their next term. If they buy that new term, it will go into affect and be charged at the end of the current term. If they don't then they'll remain on their existing plan (or the subscription will end if they've turned off Auto in Settings).
ARS = Auto Renewing Subscriptions
NRS = Non Renewing Subscriptions
Side Note: If you haven't already submitted and you're not a magazine or newspaper your app may be rejected for using ARS. They may insist you use NRS. This isn't well-documented by Apple but it happened to me and to Marco Arment of Instapaper among others.
As a developer you can't control whether a user's ARS will auto renew or stop at the end of a term. Only the user can do that through the Settings app. The developer also can't see whether the user has turned off auto or not (you just have to wait and see if it renews). And as a developer you can't manually switch a user to a different plan. But you can offer them different durations for purchase that will go into affect at the end of their current term.
Yes, directing a user to the Settings app is frustrating and it's the only way for them to manage their ARS. The only thing you can do in the app is offer new time-intervals for purchase.
Manually-renewing subscriptions give you more power, as a developer.
Related
I want to offer a free trial and the option to BUY (Non-Consumable In-App Purchase) on my ios app. I can see that I can offer a trial and then SUBSCRIBE (Auto-Renewable Subscription), but I personally don't like having to pay over and over for a simple app, but I do want to try it first. Is there a way to achieve the same thing when setting the option to buy? I realize I could track the first usage after download, but this presents a couple of issues:
Will Apple now approve apps for a trial period - previously they have been rejected, but that was before IAP and subscribe was available at all!
How do I prevent the user deleting the app (and any data I might store to know they have activated a trial) and then downloading again?
Or do I have to succumb to the pernicious "subscribe" model or release a "light" version with an upgrade? The last time I went "light", Apple insisted I make so much functionality available, I may well have not bothered with the full version - but that was a while ago.
Apple now allows you to add a free trial for Non-Subscription apps. It's a 0 price plan for fixed days. After this trial expires, you can show the non-subscription plan for purchase. The downside is user need to do a purchase again after trials end. But offering a free trial is a good user experience.
Non-subscription apps may offer a free time-based trial period before
presenting a full unlock option by setting up a Non-Consumable IAP
item at Price Tier 0 that follows the naming convention: "14-day
Trial." Prior to the start of the trial, your app must clearly
identify its duration, the content or services that will no longer be
accessible when the trial ends, and any downstream charges the user
would need to pay for full functionality.
Dont prevent the user from deleting the app. Just store the data online when user hits the trial button, you can store a flag in the web services which can be zero or one based on the user.
One way you could do this if you only care about iOS 11 is using the new DeviceCheck API. It's pretty limited in functionality (it lets you track 2 bits, or 4 cases, total) but should persist between install.
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.
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.
I am planing to publish an iOS app. App should be Free for first 1 month from installation in the Device. Once the 1 month period is over , user has to subscribe to use the application every month by paying some X amount.
1) Will apple allows such applications ?
2) If allows, how to achieve this kind of Payments ?
3) How to prevent user to access the app after 1 month. (Calculation of the Days)?
4) Should i reinstall the app after subscription ?
IAP is supposed to be used to provide additional content and features to an already functional app.
If you render your app useless or without functionality after a month, it will probably be rejected, or banned after approved. I believe you can't have an app that will simply say "Your trial expired.".
In my opinion, you would need to think of a functionality that you can provide to all users, regardless of they paying for it or not, and have the premium or the extra functionality purchased as a In-App Purchase.
Apple does not allow free trials in the app store. If you try to do this, your app will get rejected. Still, there is one category of app where Apple does allow a free trial: apps with auto-renewing subscriptions. These were originally intended for (and only allowed with) Newsstand apps where the subscription is for getting new content such as magazine editions etc.
Apple recently allowed the use of auto-renewing subscriptions in non-Newsstand apps but it's still a very grey area as to what exactly Apple will allow with these. Usually the subscription will have to provide some kind of periodic new content in your app. I agree with those who recommend against using them.
I was using "Auto-Renewable subscription" and it was working perfect and i can verify its recipt and can check status that its active or not, but apple has rejected it and suggested to use "Non-Renewable subscription", main problem using it is that, i can not test its status when after subscription, it expire or user remove it from his apple account, "Auto-Renewable subscription" use to expire after few minute so it was easy to test.
Can any one suggest how to test this scenario
With Non-Renewable Subscriptions you need to manage it yourself, on your server. Once you verify a receipt with Apple, the ball is in your court to calculate and maintain the expiration date. As an example, there's nothing stopping you from selling 1-month subscriptions but giving every one an extra week since you're calculating your own expiration date. Also beware that now you have to sync the subscription across all their device. With ARS you could use restoreCompletedTransactions to extend a subscription to a person's new device. But with NRS, Apple requires you to implement a user account system with username and password to allow a user to log in (to your server) and extend their subscription to a new device.
With NRS you have more power but you also have a lot more responsibility.