The injunction states that Apple is “permanently restrained and enjoined from prohibiting developers from (i) including in their apps and their metadata buttons, external links, or other calls to action that direct customers to purchasing mechanisms, in addition to In-App Purchasing and (ii) communicating with customers through points of contact obtained voluntarily from customers through account registration within the app.”
Particularly, the first point about in-app purchases has seen a lot of discussion. In this post, I will unpack what we know and don’t know, and what developers should do about it.
Disclaimer: I am not a lawyer, and this article should not be understood as legal advice. If you want an analysis of the judgment by a lawyer, check out this extensive analysis as a podcast. In any case, a lot of questions remain because it’s not yet clear how Apple will change their rules as a result of the injunction.
Update: A few hours after this post was published, Apple filed an appeal against the judgment (as expected), asking for a stay on the injunction. If Apple wins the stay, which will be decided in November, the injunction would be delayed until appeals in the case have finished, or might be overturned altogether. The appeals process could take years.
Will developers be able to charge credit cards directly inside an app instead of using Apple’s in-app purchases?
This very narrow limitation makes it clear that Apple will still be able to require in-app purchases (IAPs) for anything that happens inside the app. Our interpretation, and that of most industry analysts, is that Apple will now have to allow apps to send customers out of the app for payment.
Promises of drop-in replacements for Apple’s in-app purchases are therefore misleading. Reader apps (e.g., Kindle and Netflix) currently don’t have to offer in-app purchases and may now be allowed to link out to purchase on their website without supporting Apple’s in-app purchases. But all other app developers will still have to support in-app purchases even if they also want to try converting some customers via credit card purchases on their websites.
Will linking out mean an actual web browser, or will an in-app webview be allowed?
This question is up to Apple’s interpretation since the injunction doesn’t specify. My prediction is that Apple won’t allow external purchases in in-app webviews (and they will enforce that through App Review). The reason is pretty simple: Apple will want to make the distinction between in-app purchases and external purchases as clear as possible to consumers, and in-app webviews can be made to look like they are part of the app.
If you’re thinking about supporting external payments, you should be working under the assumption that you will have to link out of the app to Safari to complete the purchase, and then back into the app (e.g., via deep link) once the purchase is complete.
What restrictions will Apple place on the number and appearance of links to external payments?
There is a good chance Apple will create rules around links to external payments. In the extreme case, Apple may just allow a single, plain text link. It is, of course, questionable whether the judge would allow that (especially given that the language of the injunction talks about links, buttons, and calls-to-action in the plural). A good example to illustrate the effect of this question might be the Kindle app: would the Kindle app only be allowed one link to amazon.com, or could it have a complete discovery section in which each book has a link to purchase it on amazon.com?
If I were to make a guess here, I would expect Apple to at least require any call-to-action for outside payments to be less prominent than a call-to-action for in-app purchases on a given page. But that may not apply to reader apps if they are allowed to link out without supporting in-app purchases.
Will Apple mandate price parity for external purchases?
Apple originally required that in-app subscriptions be offered at the same price or less as the same subscription offered via other channels. That requirement was dropped in 2011, but Apple could of course bring back such a rule, and nothing in the injunction itself would prevent Apple from doing so.
However, in the full judgment, Judge Yvonne Gonzalez Rogers explicitly finds that Apple “unreasonably restrains competition and harm consumers, namely the lack of information and transparency about policies which effect consumers’ ability to find cheaper prices, increased customer service, and options regarding their purchases.” In other words, Apple preventing developers from telling consumers about cheaper prices on the web is anti-competitive. Therefore Apple mandating that the prices be the same everywhere would potentially violate the spirit of the judgment and seems unlikely to happen.
Can and will Apple levy commissions on external purchases?
This is a topic that doesn’t seem to be on many people’s radar. The full judgment explicitly states that Apple would be entitled to charging commissions on external purchases: “IAP is the method by which Apple collects its licensing fee from developers for the use of Apple’s intellectual property. Even in the absence of IAP, Apple could still charge a commission on developers. It would simply be more difficult for Apple to collect that commission.”
So Apple could potentially charge a commission on these external purchases. Will they? My guess is that they won’t. It would be an administrative nightmare, particularly for the long tail of small developers. In addition, Apple already allows developers to give customers access to paid content purchased on other platforms, and doesn’t charge any commission for that.
Moreover, Apple’s right to monetize intellectual property via commissions also applies to all the purchases that are already excluded from Apple’s commission. Uber, for example, certainly wouldn’t exist without the iPhone’s GPS features, which are part of Apple’s intellectual property, but Uber is not currently forced to pay Apple a commission.
Will these new rules apply globally?
The permanent injunction itself only applies in the United States, but it remains to be seen whether Apple will choose to make changes to their rules globally or have different rules per country. We have a very recent precedent here: On September 1st, Apple settled with the Japan Fair Trade Commission to allow “Reader” apps to provide a single link to create and manage their account, and while the settlement was Japan-specific, Apple chose to apply these new rules globally. Therefore, my prediction would be that any new rules Apple creates in response to this injunction will apply globally.
When will these changes come into effect?
The injunction comes into effect 90 days after it was issued, which is December 9th. However, there is the chance that the appeals process might delay this date, or even overturn the injunction. There is one particularly strong argument Apple could make that might lead to an appeals court overturning the decision: Judge Yvonne Gonzalez Rogers based the injunction on California’s Unfair Competition Law (i.e., state law), but applied it nationwide.
Will the new rules be beneficial for consumers and/or developers?
This is honestly a very tough question to answer. Consumers certainly benefit from Apple’s tight control and consumer friendly approach to purchases, refunds, subscription management, and more. Developers benefit from the low-friction nature of in-app purchases and the fact that customers are much more likely to update their payment information on their Apple account than with any individual app.
On the other hand, the current model does impose limitations. Some business models with marginal costs, like ebooks or music, simply aren’t viable with a 30% commission, and that makes for a worse user experience today. It is hard to argue that having to pull up amazon.com in a browser to buy Kindle books instead of being able to do so inside the Kindle app (or even the Amazon app) is in any way a better user experience. Apple owning the customer relationship for in-app purchases is also a challenge for developers, who can’t even directly refund customers who request one.
In the end, I believe there is value in choice and hope to see a new paradigm emerge where consumers have the choice between the convenience of App Store payments, and other, potentially cheaper, payment methods. Developers should also have the choice to try and squeeze out a few percentage points of margin, even if it’s unlikely that the whole difference between Apple’s 30%/15% commission and the ~3% credit card fees can be captured as upside.
Will this be the end of the story?
Not at all. There are several pending regulatory processes on this front which might force Apple (and Google) to further change their rules. Here are a few examples:
For these pending processes, the outcomes are even less clear than for the Epic vs. Apple injunction—and regulators will likely watch Apple’s reaction in the Epic case closely to determine whether or not Apple has ceded enough ground.
How should subscription app developers react?
As a developer, you might be tempted to pursue this new opportunity. If the rules come into effect in December, the holiday and New-Year period is a big time of the year for many subscription-based apps. If you are already selling web subscriptions today, it is probably easy to conceive some experiments to send customers to the web from the app—pending what exactly will and won’t be allowed. Of course, since you will not be able to move all of your subscriptions to external purchases, you will have to continue to support in-app purchases.
Developers who currently don’t sell any subscriptions on the web will have to first set up the infrastructure to make web purchases and manage them (including account management, cancellation, and updating billing information).
For RevenueCat customers, we have plans to make it easy to start selling web subscriptions and test whether they will be beneficial for you and your customers. By December, we are planning to launch a hosted web paywall that can be linked to from the RevenueCat SDK. Your customers will be able to purchase a subscription with their credit card, and be linked back into the app once the purchase is complete.
The solution will be 100% compatible with our in-app purchase system allowing you to manage customers from iOS, Android, and the web with one platform. Web purchases will be backed by our battle-tested Stripe integration, but developers won’t have to host their own web frontend.
This is an early illustration of how the hosted web paywall could look. We will finalize these when it becomes clear what will and won’t be allowed—our goal is to provide a solution that is compliant with Apple’s rules, not to break them.
Since RevenueCat already provides a one-stop-shop for web and in-app subscriptions, our hosted web payment solution will be a very low friction way to test the waters on this new monetization opportunity.