A Discussion About Apple’s Unsatisfactory In-App Purchase Policies

A couple of weeks ago the issue of Apple’s In-App Purchase (IAP) policy once again came into focus when ComiXology was purchased by Amazon and subsequently removed the ability to purchase comics within their iOS apps using IAPs. I think it is safe to say that there was quite an outcry from ardent ComiXology users and others who follow the news of the technology industry.

The reaction was mostly negative, or at least one of dissapointment. Depending on any one person’s views (or perhaps corporate allegiances), either Amazon was evil, Apple was evil, ComiXology was evil, or they were all evil and “once again” users lose out. I’m being overly dramatic here, but you get the picture: people (generally) weren’t happy with the change. If you want to read more about the specific issues at play in the ComiXology changes, I highly recommend Moises Chiullan’s article at Macworld.

Amazon is not absorbing, nor can it contractually subsume the 30 percent that gets paid to Apple from in-app purchases: By purchasing ComiXology what was previously ComiXology’s “piece of the pie” is now Amazon’s. That piece grows, but the publisher’s portion also grows, and therefore the amount that can be paid out to creators is larger. I asked ComiXology’s Mosher directly: Will the reduced overhead mean that more revenue can and will go to creators, whether they’re big-time publishers or independent creators? “Yes,” he said. (Macworld)

For me, the ComiXology issues once again highlighted the complexity for Apple (and others) of coming up with a policy for IAPs that is appropriate. I’ve always thought that the current policy leaves something to be desired because in a certain set of narrow (but high profile) circumstances, it results in situations that inconvenience or disadvantage the user.

So with all that in mind, I want to explain what the current policy is and the problems that it causes. Then, I will run through some potential alternative rules and highlight their respective benefits and drawbacks.

Apple’s Current IAP Policy

As the rules currently stand (and they have changed significantly from their original format), Apple takes a 30% cut of all IAPs, just as they do for regular apps.1 Apps cannot link directly to an outside store in a way that would encourage customers to circumvent paying via IAPs.2 Nor is it permitted to use a system other than IAPs to allow users to purchase content inside an app.3 But it is permitted to allow customers who have purchased content from outside of the App Store to redeem the content inside the app.4 There is no rule that prohibits IAPs for content/services from being charged at a higher price than what the content/services cost when bought from a website.

To illustrate why this current policy results in unsatisfactory outcomes, let me highlight the biggest problems I perceive, with reference to current examples that exist.

Problem 1: iOS users could be paying more than they need to, and they aren’t informed of this.

One of the ways companies are getting around Apple’s IAP rules is by selling their content or subscriptions at a higher price for IAPs, covering the 30% cut that Apple takes. This is the case for Rdio, which charges users slightly more if they purchase a subscription from inside the app via IAP.5 But many users are no doubt unaware that not only can a subscription be purchased directly from Rdio’s website, but it can be done at a discount. This issue is made worse because of the rule that prohibits apps linking to outside purchase portals, so users are kept uninformed unless they do research or stumble upon the cheaper online price.

Problem 2: To avoid Apple’s 30% cut, many content stores and subscription services don’t offer IAPs and require users to purchase directly from their website.

Because Apple’s rules allow users to redeem outside purchases inside an app, developers have often used this as a way around the 30% cut for Apple. But another rule prohibits using any other purchase system or direct linking to web stores within the app. As a result, many content stores and subscription services have “dumb” apps that can’t do anything until you’ve made a purchase outside the app.

For example, Netflix’s iOS app simply displays a login panel, and until you login to your paid account with a subscription you can’t do anything - and there isn’t a “Buy a month’s subscription” button anywhere. Why? Because they don’t want to (or can’t afford to) let Apple take a 30% cut of their revenues and because Apple says they can’t link to non-IAP purchase mechanisms. Likewise, Amazon’s Kindle app and their new ComiXology apps no longer have a ‘Store’ section: the apps are only viewers for content you have already purchased outside of the App.

Problem 3: It is very hard for a smaller company to avoid IAPs

I think this is the hardest problem to demonstrate but, long term, perhaps the most serious and damning consequence of Apple’s current rules: it stunts the development of innovative new apps and services.

Let’s just discuss for a moment a theoretical new company that delivers a subscription service with some innovative twist at razor thin margins (just like Netflix, Spotify, etc). Consequently, it is simply untenable for them to absorb Apple’s 30% cut. They could go Rdio’s route and charge extra for the convenience of purchasing through IAPs, but that could mean their new, unknown service is now perhaps priced beyond what most people would pay. Or they could go the Netflix route and only allow people to purchase subscriptions outside of the app. But the problem with this approach is that it might work for the behemoths like Netflix and Amazon, but would a small company be able to get away with it? As Beats Music found out recently, it is “very hard” to get people to sign up for a service outside of Apple’s ecosystem.

So What?

At this point, you could make a decent argument claiming that all of this is just one massive #firstworldproblem and that companies who want to benefit from Apple’s customer base should play by their rules and suck it up. On a certain level, you are right, but I’d argue it’s also a short-sighted view of things. At the moment, in this admittedly narrow category of apps and services, the ones who are losing the most are the customers. Apple constantly jumps up and down about “getting it right” and clearly care about their customers more than most.6 So why not try and come up with a better solution?

Option 1: Don’t take a percentage from IAPs

Let’s start off with the most absurd position that Apple could take: just stop taking a percentage of revenues from IAPs. Sure, it may resolve the bizarre IAP situations that have arisen out of the current policy, but there is a far bigger cost of such a policy. Quite frankly, if this was implemented it would decimate the Paid App section of the App Store. Why would any developer make their app paid (and thus lose 30% of revenues to Apple), when they could instead sell their app through a system of IAPs which wouldn’t be “taxed” by Apple?

Option 2: Reduce the 30% cut

So what about if Apple’s cut wasn’t eliminated, but reduced to a more “tolerable” level? Without even considering what a “tolerable” level is, the result would be the same as above. Whether it be a 5% cut or a 25% cut, that’s still less than 30% and developers would be incentivised, strongly, to shift to an IAP model.

Option 3: Move to a graduated system

We’re slowly moving to less radical ideas, but increasingly complex ones. This idea keeps the status quo initially, whilst then gradually reducing Apple’s cut as the app becomes more popular and earns more revenues. The idea is that it rewards developers that create successful apps by giving them a bigger share of the revenue pie as they become more successful.

But again, we run into the problem that it would disincentivize paid apps, unless the graduated reduction in Apple’s cut was also applied to paid apps - which isn’t completely crazy.

The real question with this idea is whether Apple would still make enough money from their ‘revenue cut’ to cover the expenses of the App Store (such as bandwith, storage, development, app reviewer and support costs).

Option 4: Allow different purchase mechanisms

I don’t know a great deal about how Google’s policy works, but I believe that they allow a developer to implement their own purchase mechanism instead of Google’s and by doing so, they can avoid paying a 30% cut to Google. This is what Amazon has switched to for ComiXology at the same time that it changed the iOS app.

This approach has two fundamental problems that just don’t make it appropriate for iOS or Apple. The first is that it brings significant complexity and, potentially, confusion to users. The beauty of IAPs as they stand now is that it is a unified experience; the benefits of that cannot (and should not) be understated. Whilst it might seem OK to allow Amazon to use their own purchase mechanism, the situation becomes increasingly precarious as more and more developers use different systems that operate in different ways and with varying degrees of security. This would be a nightmare for Apple and completely against their current approach to iOS.

The second problem is that once again it would encourage the destruction of Paid Apps in favour of IAPs in a way that would allow every developer to avoid Apple’s 30%.

Option 5: Exempt certain IAPs from Apple’s 30% cut

Taking a different angle to this dilemma, Apple could create an exemption for certain classes of IAPs, where they don’t take a 30% cut. Such an approach is risky because of the potential (or perception) of unfairness, so it would need to be carefully and narrowly defined. And although it may not seem intuitive, Apple does already have a number of Guidelines that are only applicable to certain categories of Apps. For example, auto-renewing IAP subscriptions are only available to certain classes of apps that are Periodicals, Business Apps, or Media Apps.

One potential approach to this option would be only allowing an exemption from Apple’s 30% cut for IAPs used to purchase individual pieces of content (perhaps defined exclusively as including Music, Movies, TV, Books, Comics) and IAP subscriptions for all-you-can-eat content services for the same categories of content (to cover services such as rdio, Netflix, etc). Apple could still charge a small percentage for these IAPs just to cover credit card and processing fees that these companies would otherwise have to deal with themselves.

This is not a perfect solution, but in my opinion it is the best of the alternatives to the status quo. But whether it is better than the status quo is another, much more difficult question to answer.

One thing to keep in mind is that whilst users win with this approach (they pay the lowest price, can easily purchase inside apps, etc), Apple is the one that loses (financially). They would be removing an impediment that they have long placed on their competitors. Apple cares about their users, but do they care so much about them that they might consider such a proposal that would see the playing field leveled for their competitors, over what is really a somewhat marginal issue that isn’t a huge problem at the moment? I doubt it, but I would be glad to be proven wrong.

Although this is my favourite approach, I really need to stress that in many respects it is the most complicated one of them all and has the potential of causing confusion amongst developers, encouraging the exploration of any potential loopholes of such a rule and laying down an environment in which Apple’s reviewers could accidently and unintentionally come to contradictory interpretations of such a rule.

To highlight why this rule is my favourite alternative approach, let’s go back to those problems that I highlighted at the start and see how this solution might change the outcomes.

Problem 1: iOS users could be paying more than they need to, and they aren’t informed of this.

Apple gets 30% of Rdio’s IAP subscription purchases today. To cover that 30% cut to Apple, Rdio charges more for subscriptions paid through IAPs, and doesn’t alert users because that would be against Apple’s guidelines. By implementing this rule, Rdio could charge the same amount for subscriptions purchased through IAPs and those purchased on their website. Users would win because they can easily purchase a subscription via IAPs and not be charged more for that convenience. Surely that sounds like a good outcome for an Apple dedicated to giving users the best experience?

Problem 2: To avoid Apple’s 30% cut, many content stores and subscription services don’t offer IAPs and require users to purchase directly from their website.

Apple gets nothing from Netflix today, because their app is free and only allows existing customers (who sign up on their website) to login and use their service. By adopting this rule, Apple would continue to get no revenue from Netflix, but Netflix could allow users to purchase subscriptions from within the Netflix app. The clear winner from such an approach are the users, who no longer have to jump to the web browser, fill in their credit card details and so on - just tap the buy now button, enter an Apple ID password and it’s done. Users win, and because users win, Netflix and Apple are better off in customer satisfaction terms.

Problem 3: It is very hard for a smaller company to avoid IAPs

Imagine a new startup that is an online storefront that sells content from other authors (let’s imagine it is focused on illustrated short stories) wants to create an iPad app because it is the perfect device for the content they sell.

Currently, they face the following dilemma:

  • (A) Use IAPs to allow users to purchase content, but inflate prices to recoup the money lost to Apple (and risk losing customers); or
  • (B) Use IAPs to allow users to purchase content, charge the same price as on the website store, but because of Apple’s cut they have to reduce their and/or the author’s share of revenues, potentially risking the viability of the business and/or discouraging authors to sell through your store; or
  • (C) Don’t use IAPs becase of the prohibitive 30% cut to Apple and only allow users to buy content from the website store, severely harming the user experience and perhaps damaging any potential for success.

Now imagine that this rule has been adopted. The startup can now use IAPs (a good user experience) and charge the same amount without reducing their, or their author’s share of revenues.

Conclusion

It is important to recognise that this was mostly just a thought experiment. I am skeptical that Apple views this a problem, let alone a big enough problem the merits a fundamental shift in their IAP policy. But at the same time, Apple has in the past adapted and improved the App Review Guidelines and IAPs rules in particular have already undergone a number of fundamental shifts over the years - so I remain hopeful.

I also ask anyone to question whether the current situation in which iPad Kindle users have to go to a web browser to purchase a new eBook is in any way a logical or appropriate user experience outcome. The same applies to those iPhone users that discovered Rdio on the App Store and are now paying more than they really need to, all because of the way the current policy is structured - and what it incentivises.

I’ve specifically tried to avoid the issue of anti-competitive practices, mostly because I do not think this falls under such a discussion. But I think I should briefly mention it because I am sure some would say that it is anti-competitive or comes close to it. And sure, there is an argument that there is an anti-competitive streak to the policy because in practice the people most harmed by these policies are those customers of services that compete with Apple’s various digital content stores: Kindle and Comixology (iBooks), Rdio and Spotify (iTunes Radio/iTunes Music), Netflix (iTunes Movies and TV), etc.

So, what do you think? I’d love to hear your comments, feedback or alternative suggestions.


  1. Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these purchases, as set forth in the Program License Agreement. (Review Guidelines 11.12) ↩︎
  2. Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a “buy” button that goes to a web site to purchase a digital book, will be rejected. (Review Guidelines 11.13) ↩︎
  3. Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected. (Review Guidelines 11.2) ↩︎
  4. Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, video and cloud storage) that is subscribed to or purchased outside of the App, as long as there is no button or external link in the App to purchase the approved content. Apple will only receive a portion of revenues for content purchased inside the App. (Review Guidelines 11.14) ↩︎
  5. If you buy a month’s subscription to Rdio on their website in the US you’ll pay $9.99. If you buy it through the Rdio app with IAPs, you’ll pay $14.99. ↩︎
  6. Some may disagree completely with that, and Apple isn’t always successful at making life easier for users, but their intention is usually in the right place. ↩︎

Access Extra Content and Perks

Founded in 2015, Club MacStories has delivered exclusive content every week for nearly a decade.

What started with weekly and monthly email newsletters has blossomed into a family of memberships designed every MacStories fan.

Learn more here and from our Club FAQs.

Club MacStories: Weekly and monthly newsletters via email and the web that are brimming with apps, tips, automation workflows, longform writing, early access to the MacStories Unwind podcast, periodic giveaways, and more;

Club MacStories+: Everything that Club MacStories offers, plus an active Discord community, advanced search and custom RSS features for exploring the Club’s entire back catalog, bonus columns, and dozens of app discounts;

Club Premier: All of the above and AppStories+, an extended version of our flagship podcast that’s delivered early, ad-free, and in high-bitrate audio.