An auto-renewable subscription is an In-App Purchase for iOS that allows an app to provide content or features over a set amount of time. This In-App Purchase product type broadens and extends an app's potential revenue by moving beyond the one-time or infrequent purchasing model of consumable and non-consumable In-App Purchases. Having implemented them for a number of Voila Hub customers, we've noticed that they fall short of providing a complete and efficient solution for subscription-based app models that you would expect from Apple.
Criteria for Using Auto-renewable Subscriptions
Apps that use auto-renewable subscriptions have the ability to charge a recurring fee over a set time period (e.g. monthly, yearly, etc.). Auto-renewable subscriptions are different from other In-App Purchases in that they provide a product that cannot be used up over time. They provide the added benefit of charging a user for a subscription without further intervention.
Apple refers to their different types of In-App Purchases as “products.” For a basic view of the difference between their In-App Purchase products: consumable, non-consumable, and auto-renewable subscription, consider these examples. A consumable could be an hour-long experience point boost in a game app. On the other hand, a non-consumable could take the form of an unlocking a theme, since it could be restored again later.
Historically, Apple has limited the use of auto-renewable subscriptions to Newsstand apps or publications that deliver content on a recurring basis rather than offering access to extra features. This is still evident in the setup process for auto-renewable subscriptions in iTunes Connect, where a "publication" name is asked for. Over the years, Apple has loosened this restriction and has allowed non-Newsstand apps to jump on the auto-renewable subscriptions bandwagon. Auto-renewable subscriptions can now be used in productivity and business apps in particular. Task management app Omnifocus, for example, charges users two-tiered subscription fees beyond a 14-day free trial. Even an app like Lumosity, a brain-training app, offers a free basic membership and uses auto-renewable subscriptions to unlock premium features for subscribers. The app offers individual as well as friends and family subscription plans
Creating an Auto-renewable Subscription
The initial steps of creating an auto-renewable subscription is not too different than creating any other IAP. The main differences you will come across are the ability to set a recurrence time (monthly, yearly, etc) and the ability to provide a free trial. At this time, the free-trial option is limited to a few duration options and is not dynamic. So, if you require a duration outside of the provided options or want to provide different free trial tiers, then ignoring this option and handling that manually is recommended. Developers can also provide free time if the user agrees to provide their details (name, email, address). Regardless of whether you choose to provide free time based on getting this information, the user will still be asked if they want to provide this or not and, as a developer, there is no way to currently disable that request.
Another difference to be aware of is that varying subscription durations must be set within the same auto-renewable subscription and not created as a separate product. Not doing this will most likely get your app rejected. Each subscription length within your auto-renewable subscription product gets its own product ID, so differentiating durations during purchase is a non-issue.
Actual implementation of the purchasing of an auto-renewable subscription is similar to the same process for other In-App Purchase types. There are many tutorials that cover this process for the other IAP types. This one by Neil North focuses on non-renewing In-App Purchases (you can jump to the middle at "Adding Your Subscriptions to the Product List"). The difference in setting up an auto-renewable subscription versus a non-renewing IAP is, as mentioned above, each subscription duration gets set within a single auto-renewable subscription entry, rather than as separate products. Each duration then has its own product ID
How Apple Could Make Auto-renewing Subscriptions Better
Apple doesn't offer a lot of options for developers as far as actually managing the auto-renewable subscription through its lifespan (notification of renewal, cancellation, etc.).
There's no API to get the expiration date back in order to tell if the subscription has been renewed or if the subscription has been cancelled. Instead, developers have to rely on parsing a JSON response to find the relevant information and hope the structure of the JSON doesn't change in the future. Auto-renewable subscriptions also don't provide a callback mechanism, where you can provide a webhook to be called when an event, such as renewal or cancellation, occurs. Such a thing would then allow developers to update that user's subscription accordingly.
Auto-renewable subscriptions also lack an option to provide subscribers with a way to manage their subscriptions through the app. So, for example, if a user really likes the app and wants to change their subscription from monthly to annually, no dice. The same applies for those who hate the app, hate the subscription, and want to cancel in the app. On second thought... that might not be such a bad thing!
Apple provides a URL that allows users to see all of their subscriptions in a subscription management area. While they can't upgrade or change their subscription there, they can cancel it. However, that doesn't help developers since the cancellation is happening outside the app, and there are no callbacks to let developers know that a user is canceling the subscription.
In short, Apple gives developers a way to provide auto-renewing subscriptions in apps, but doesn't provide the set of tools that many would deem necessary to effectively manage those subscriptions
Alternatives to Auto-renewable Subscriptions
Apple requires any digital content and service-related In-App Purchases to go through them rather than a third-party payment processor. Exceptions are rare. If Apple doesn't allow you to use auto-renewable subscriptions, non-renewables are most likely your only option. (Then again, according to Marco Arment, non-renewing subscriptions should be your only option.)
Non-renewing subscriptions, Apple's other solution to subscription-based In-App Purchases do not auto-renew, requiring developers to prompt users to go through the In-App Purchase process again to renew their subscription. That's a pain, not just to implement, but for the app user. I cringe when I think how many customers are lost to the “uh, I don't want to do this again...” when a time-to-renew alert pops up.
What about third-party processors? As mentioned above, the chance of Apple allowing you to use an outside processor like Stripe or Braintree is next to nil, but there is a case where they might make an exception (let might: Double = 96.78% //chance of them rejecting your app). If you include a physical product as part of your subscription, they might let you go outside the StoreKit garden, but again, it's a very slim chance.
If you want to try, then you really can't get any simpler than using Stripe and their iOS SDK with Parse as your backend. This setup makes subscription management more of a passive affair by providing webhooks to listen for purchase success, renewal, and cancellation events. Developers also can offer users the ability to change their subscription, upgrade their subscription, and cancel, all without leaving the app
Concluding Note
The state of subscriptions products for In-App-Purchases in iOS is not ideal. Our frustration comes from having a limited and unpolished toolset for something as necessary as providing subscription-based services in an app. Though it seems like Apple is broadening the types of apps allowed to use auto-renewable subscriptions for In-App Purchases, implementing them can be clunky or unfinished. We only hope iOS 9.1 radically updates them, because, you know, dreams.