Why I Don’t Recommend Auto-Renewable Subscriptions, Even If Apple Lets Your App Use Them
I recently wrote that I wouldn’t use auto-renewable subscriptions again after extensive experience with both non-renewing in Instapaper and auto-renewing in The Magazine. A lot of developers have asked me to elaborate, especially as Apple has gradually allowed some apps to use them outside of Newsstand.1
Support and Perception
Like any other in-app purchase, customers can start an auto-renewing subscription within your app.
But they can’t end it. There’s no way for developers to offer an “Unsubscribe” button, and the actual App Store subscription management page is buried where few customers ever think to look.
Naturally, customers who can’t figure out how to unsubscribe don’t get angry at Apple — they blame the developers, writing angry 1-star reviews and nasty support emails because they think we’re trying to rip them off.
We can’t help them in response, because developers can’t even cancel their subscriptions — only the customers can. Developers can only apologize and refer them to this Apple support document.
Purchase Experience
When a new customer subscribes, the system in-app-purchase dialog pops up to confirm (…eventually — it’s so slow that it’s easy to assume it failed and tap again). Then a second box comes up with the dreaded “share your information with the publisher” dialog, which has its own problems.
The new-subscriber process is mediocre, but it’s much better than when an existing subscriber needs to sign in on another device.
By convention and policy, apps should display a “Restore Purchases” button. If a subscriber invokes it, their subscription is (…eventually) restored properly.
If they instead select “Subscribe” again, the subscribe flow works as usual, but ends early with a dialog telling the user that they’re already subscribed. Fatally, this is reported as a failure to the app, and there’s no way to distinguish between an “already subscribed” failure and any other subscription failure, such as a failed login or hitting Cancel.2
As you can imagine, this causes yet more support email and angry 1-star reviews. And when apps do it wrong — which happens frequently, especially since sandbox testing is difficult and Apple’s reviewers don’t test for this — it causes embarrassing bugs that prevent people from using the subscription they’re paying for.
Inflexibility
There’s no way for developers to know for sure when an auto-renewing subscription will end. When a customer toggles “Renew automatically” to “Off”, that isn’t reflected in the API. The subscription continues through the current period, and there’s no way to tell when it will end until it actually ends.3 And, of course, we can’t end it manually.
Developers also have no way to extend a subscription. And nobody — developers or customers — can buy or redeem subscriptions as gifts.
This complicates support and marketing. Developers can’t, for instance, give free subscriptions to reviewers or extend a subscription to appease an angry customer.
These limitations can be avoided by having a separate website payment and subscription system. (Use Stripe.) Then you can give reviewers web subscriptions, enable gift purchases, extend subscriptions arbitrarily, cancel subscriptions yourself, and provide much more helpful sign-in feedback in the app, all while paying much lower commissions.
But in an iOS app, you must offer subscriptions via In-App Purchase. Web and in-app subscriptions can coexist without too much trouble, but it becomes problematic when an in-app subscriber wants to convert to a web subscription to get one of its benefits (redeeming a gift or extension, etc.). Since you can’t cancel an in-app subscription, detect when it will end, or even verify whether any given email address is a subscriber,4 it’s difficult to coordinate the switchover.
The Benefits
What are all of this complexity and all of these limitations supposed to buy?
In theory, it’s easier for customers since they don’t need to renew manually after each period. But it’s much harder to restore purchases and cancel subscriptions, so I’m not sure it’s a net win for them.
The real appeal is clearly lopsided to benefit the developers:
- “Free” money from accidental renewals: There’s certainly some of this, but it’s ethically questionable. It also has potentially unforeseen costs: how will it affect your business if your customers resent you for taking money from them every period until they remember to go through the clumsy process of canceling?5 How much will it cost you in guilt, 1-star reviews, support emails, and lost loyalty when you try asking the audience to check out something new?
- Reliable income: Again, there’s some of this, but it’s not as reliable as you might think. Like any other subscription, you’re going to lose some subscribers in every period, and you’re going to need to attract at least as many to make up for the loss.
- Subscriber information for direct marketing or selling to third parties: If your business model depends on this, I can’t help you — we’re in two very different worlds. I’d really rather not get people’s names and home addresses — that’s a pretty big liability that I don’t want — and I only want emails so I can send password resets and maybe an occasional opt-in newsletter.
The Alternative
What I built for Instapaper instead was much simpler.
I used the old “non-renewable subscription” in-app purchase type, which is almost a misnomer — it’s simply buying access to something for a fixed duration. I also offered the same subscriptions on the website through PayPal with recurring billing. (That was a mistake. Never use PayPal for recurring subscriptions.6 Use Stripe.)
The non-renewable in-app purchase enables your subscription for an additional 3, 6, or 12 months.7 Two weeks before a subscription expires, the app shows one dialog informing the user of this and offering a renewal. Three days before, it shows one more. And after it expires, it shows one more. That’s it.
It had almost the same loss and renewal rate as the auto-renewing PayPal subscription, but with nearly zero support cost. It was great for the customers, Instapaper, and Apple.
Implementing non-renewing subscriptions is simple, too: every user has a subscription expiration timestamp. When a purchase comes in, validate it and simply extend the user’s expiration date into the future by that interval. It’s night and day compared to implementing and supporting Apple’s auto-renewing subscriptions.
Offering non-renewing options and a good auto-renewing system, like Stripe, is a nice balance. But if your choice is between non-renewing subscriptions or a bad auto-renewing system, such as PayPal’s or Apple’s, you’re better off not using auto-renewing subscriptions at all.
-
Building a non-Newsstand app with the expectation that you’ll be permitted to use auto-renewing subscriptions is still a big risk, though.
The most common case I see is developers who want to fund a web service with them. While Apple has permitted some services to bill with auto-renewing subscriptions, it hasn’t been consistent — I still hear from people who have been rejected for attempting it. Even if you get approved, anytime you’re on the edge of a policy like this, there’s a good chance you’ll be rejected or required to remove it in the future. ↩︎
-
In an early version of The Magazine, I tried evading the “already subscribed” problem by quietly invoking a restore-purchases before every subscribe attempt. It worked well in most conditions, but had a few awkward edge cases. Shortly after releasing it, Apple required that I remove it because it used In-App Purchase in a “non-standard” way. ↩︎
-
Well, you don’t know a subscription has ended until you poll Apple’s API for an update. Apple doesn’t support automatic notification to a callback on your servers, so you just need to poll them to revalidate every subscription on some interval, generally daily or weekly. ↩︎
-
The “share your information with the publisher” report includes names, emails, and addresses, but does not include transaction IDs. There’s no way to tell whether someone with a given email address is a current subscriber or when their subscription ends.
So if you have a website, you also need to build and support a method for people to claim and connect their in-app-purchase subscription to their website account. ↩︎
-
Apple does send an email to subscribers a few days before each renewal. You’d think this would alleviate the “you’re taking my money, I don’t understand what this is for, I demand you stop immediately” emails, but in practice, it doesn’t. Many people apparently either don’t receive them, don’t read them, don’t understand them, or simply don’t remember them. ↩︎
-
This could be its own entire post. The quick version: the website becomes unusably slow with lots of small transactions, issuing refunds is time-consuming and tedious, non-PayPal-account customers can’t cancel their own subscriptions, disputes are handled as if everything’s an eBay item you didn’t ship, the payment notifications to your servers are unreliable, and there’s no way to get a list of all current subscribers in the API or otherwise (really!), which makes it impossible to rectify inconsistencies caused by the unreliable notifications.
Trust me. Use Stripe. The loss of buyers without credit cards is completely worth the massive savings in support email and headaches. ↩︎
-
There were no savings for buying more time — it was simply $1 per month. I thought nobody would buy the biggest option (12 months). But interestingly, while almost nobody bought the middle option (6 months), the 3-month and 12-month options consistently grossed almost the same amount each day. ↩︎