Marco.org

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,¹ 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:

• Evernote’s app offers its premium accounts with IAP, but third party clients can’t. Are third-party Evernote clients now prohibited?
• Dropbox’s app doesn’t offer Dropbox’s Pro accounts at all, but the app is indirectly affected by the user’s storage space. Is additional storage space enough to qualify as “content, functionality, or services”? If so, does that put all Dropbox-syncing apps under the (impossible for them) IAP-requiring policy?
• There are a lot of first- and third-party apps that access Salesforce, LinkedIn, and 37signals’ services, all of which have paid service tiers. Will all of these be removed from the App Store if they don’t build in IAP?
• All Pinboard.in accounts are paid. Does that mean that nobody can make a Pinboard client except Pinboard itself, because nobody else can accept payments on its behalf?

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?²

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:

• “The 30% rate is too high.” It doesn’t really matter what this rate is. It could be 80% or 5% and be similarly defensible. Apple can charge whatever they want for the commission — the issue is that they’re forcing everyone to use their payment system.
• “I, or my industry, can’t afford to lose 30%.” That’s not really Apple’s problem, honestly.
• “Apple has no right to do this.” I don’t think this is legally true (antitrust concerns aside, for now). Apple can permit and prohibit whatever it wants within its platform. Just look at all of the restrictions that game-console manufacturers — or even dumbphone platforms, like Verizon’s BREW — place on their respective software publishers.

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.