Marco.org • About ▾

I’m : a programmer, writer, podcaster, geek, and coffee enthusiast.

Subscriptions and the new In-App Purchase requirement

Apple’s new subscription-billing requirement has generated a lot of bad press and debate. The new rule, from the App Store Review Guidelines (developer account required):

11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected

In practice, this means that any app that requires content or subscription purchases, or uses a service that does, now must either implement IAP under Apple’s terms and take a 30% cut,1 or get kicked out of the App Store.

It’s easy to accept App Store policies that are defensible for practical reasons or quality concerns — and most are. But this one’s not clearly defensible as currently implemented.

Apple’s press release quotes Steve Jobs:

“Our philosophy is simple—when Apple brings a new subscriber to the app, Apple earns a 30 percent share; when the publisher brings an existing or new subscriber to the app, the publisher keeps 100 percent and Apple earns nothing.”

This is partially defensible: Apple’s promotions in the App Store certainly bring a lot of people to apps, and it’s all happening on their hardware and platform. But if someone wants the Wall Street Journal app and finds it by searching for “WSJ” in the App Store and selecting it directly, who really brought that customer to the app?

“All we require is that, if a publisher is making a subscription offer outside of the app, the same (or better) offer be made inside the app, so that customers can easily subscribe with one-click right in the app.”

This would be a great guideline — developers should offer IAP to buy content, since it’s so easy for users that they’re likely to make more money overall with it. But forcing all app publishers with purchase systems outside of IAP to suddenly and completely adopt it in parallel has no apparent practical or pragmatic justification. Instead, it just looks like greed.

Implementation problems

Since there are so many gray areas and it’s very far-reaching, this is going to be a difficult policy to enforce consistently.

One issue is that this policy assumes that all apps are made by someone with the ability and authority to collect IAP payments on the service’s behalf, which isn’t the case for third-party clients using a service’s API.

If Twitter charged a subscription fee, or even sold any content whatsoever, no third-party Twitter clients would be permitted on the App Store, effectively preventing that entire market.

But we don’t need to look only at Twitter. There are plenty of paid services, or free services with paid upgrades, that have first- and third-party iOS apps. Some of the many examples:

What’s going to be the rule for third-party apps accessing paid services?

And if it’s acceptable for third parties to use the same types of paid APIs that would get first-party apps without IAP rejected, doesn’t that put the first-party apps at a competitive disadvantage and force an often-vague distinction between what is and isn’t “first-party”?

What happens if an app, that was previously permitted on the App Store, sells content, functionality, or services that aren’t allowed to be sold via IAP? Currently, prohibited IAP content includes subscriptions that last less than a week and any virtual currencies or credits that expire. What if your app requires something that IAP prohibits, but that you’ve been externally charging for?2

Some of the gray areas above rely on a distinction of what, exactly, is included in “content, functionality, or services in an app”. The paid features of Dropbox and Evernote, for instance, might be judged too insignificant in the context of apps to require IAP. If so, how much of a service needs to be free to get this exemption?

And what about a situation like Amazon’s Kindle app that will presumably be targeted for not selling Kindle books via IAP, even though Amazon’s catalog is so large that it surpasses Apple’s own limits on how many IAP items an app can register?

Reframing the discussion

I’ve seen three common arguments so far about this policy that I think aren’t strong and only serve to weaken the other points made around them:

But one argument that Apple should care about: this policy will prevent many potentially great apps, from many large and small publishers, from being created on iOS at all.

A broad, vague, inconsistently applied, greedy, and unjustifiable rule doesn’t make developers want to embrace the platform.

Android’s installed base is now large enough that a huge, compelling new service could launch exclusively on it. (It wouldn’t be easy, but it’s possible.) What if the developer of the next mobile killer app decides, for political or economic reasons like this, to release it only on Android?

What if major publishers, such as the New York Times or The Wall Street Journal (whose current app violates this new policy, along with Hulu, Netflix, Kindle, The Economist, and countless others), decide that they don’t want to offer their services through IAP (at 30% less revenue per customer) and just cancel their current or future iOS apps?

Don’t we all lose?

The discussion shouldn’t be whether Apple can enforce this policy, but whether they should. And if you look at what this does to developer relations, big and small, it’s easier to argue that this is likely to result in more harm than good to the iOS platform.

Update: Email from Jobs to further clarify (or confuse) the issue.


  1. The rules also prohibit apps from simply charging more in the IAP version. So, effectively, to keep anywhere near the same margin per subscriber, publishers need to either abandon iOS apps completely or raise their prices everywhere by 43%. 

  2. Instapaper’s Subscriptions currently offer nothing within the iOS apps, so I don’t expect Apple to reject Instapaper for not having IAP for its Subscriptions. But what if they do? Can I use IAP to charge for something that does nothing? 

Ads via The Deck