Marco.org

Apple’s In-App Purchase system permits two types of subscription purchases. The documentation suggests that Auto-Renewable subscriptions are the right choice in almost every case:

Auto-Renewable subscriptions are delivered to all of a user’s devices in the same way as non-consumable products. However, auto-renewable subscriptions differ in other ways. When you create an auto-renewable subscription in iTunes Connect, you choose the duration of the subscription. The App Store automatically renews the subscription each time its term expires. If the user chooses to not allow the subscription to be renewed, the user’s access to the subscription is revoked after the subscription expires. …

Non-Renewing Subscriptions are an older mechanism for creating products with a limited duration; consider using auto-renewable subscriptions instead.

When developing Instapaper 4.0, I initially offered the optional subscription purchase as Auto-Renewable, since it sounded like a perfect fit: a server-side service with ongoing monthly operational costs should be billed until the customer cancels it and the server-side resources can be reclaimed.

When I implemented the auto-renewing subscription in development, which requires quite a bit of tricky server-side subscription validation and tracking, I quickly ran into this mandatory dialog in the purchase flow:

A few things about this dialog bothered me, as a developer:

• The forced use of the word “publisher”. Are all app developers “publishers”? Couldn’t it just say “Instapaper” instead of “The publisher of Instapaper”?
• The use of “their” to refer to the singular “publisher”, and the lowercase “zip”. These are technically permitted, but it looks sloppy. I don’t want my app displaying a sloppy dialog.

But most importantly, this directly says that I “would like your name, email, and zip code”, when that’s not true. I really don’t want any of that information. (Your email address is your Instapaper username, but I already have it.)

The last thing I want to do is take someone’s money for a premium purchase and then immediately give them the impression that I want to sell them out.

There’s no way for a developer to opt out of this data collection and disable this dialog. If you sell an auto-renewable subscription, your customers will be told that you want their personal information, and you will be given that information (and the liabilities that come with it) whether you wanted it or not.

This is pretty bad, but I ultimately decided that it was worth the convenience benefits of auto-renewing. A non-renewing subscription would be a pain in the ass for my customers, generate more support email, and degrade the experience: it sucks if they go to use the premium features and they can’t because their subscription expired yesterday. To provide uninterrupted service with manual renewals, I’d need to send annoying push notifications to subscribers — my best customers, who I’d rather not annoy — whenever their subscription was about to expire.

So I sucked it up and submitted 4.0 with the auto-renewing subscription and the complex server-side code to support it.

It was rejected. I was told via phone about an apparently unwritten rule that I was violating: auto-renewing subscriptions can only be used for apps that deliver “new content” during each renewal period, like magazines. Charging a monthly price for an ongoing service is not allowed.

This Stack Overflow member got it in writing:

Based on product functionality, it would be more appropriate to use the non-renewing subscription In-App Purchase type. The Auto-Renewable Subscription product is best suited for apps that require or feature dynamically or frequently changing content, such as digital periodicals or radio subscriptions.

Reading between the lines on my rejection call, and seeing it codified more clearly here, it’s obvious that only traditional-style media publishing apps can use auto-renewable subscriptions. They were created solely for the existing newspaper and magazine industry, not web services.

This certainly explains a lot about that terrible solicitation dialog. When Apple was developing the auto-renewing subscription system and negotiating with the major magazines and newspapers, they were all “publishers”, and I bet none of them ever asked for an option not to collect their product’s personal information.

Ultimately, I had to ship Instapaper 4.0 with non-renewing subscriptions, I was able to delete all of the clunky auto-renewing server code, nobody sees that terrible dialog in my app, and I need to ship an update soon that will annoy my best customers with manual-renewal notifications.

But this is a great example, like Newsstand Kit’s background downloads, of Apple adding a capability to iOS that’s potentially useful to thousands of developers, and then restricting it so that only a handful of players (usually big companies) can actually use it.

I hope that, in time, they unbundle some of these myopically targeted enhancements and make them potentially useful to all developers. But Apple’s record on this isn’t great so far.