But here’s the kicker: think of all the other amazing ideas that haven’t gotten a chance to be invented because they aren’t allowed on mobile devices. Mosaic happened less than 10 years after the Macintosh. We very well might have already had a browser-caliber invention by now.

— Francisco Tolmasky (@tolmasky) August 22, 2020

</div>

This is the chief reason why, if I had to choose a victor in this case, I would choose Epic; Apple is a brilliant company, but they hardly have a monopoly on invention and innovation. My overriding concern is that their monopoly on iOS (and duopoly with Google, which copies many of their App Store practices) will prevent the invention and innovation of others.

The problem for Epic — and, I suppose, for me — is that to this observer it seems exceedingly likely that Apple is going to win this case, last night’s decision notwithstanding. Current Supreme Court jurisprudence is very clear that businesses — including monopolies — have no duty to deal with third parties,2 and if they do choose to deal with them (or are even compelled to), that they can choose the terms on which to do so.3 The only exceptions are if the monopoly in question changes the rules in an unprofitable way with the express purpose of driving out a competitor4, or if any company — not even a monopoly — changes access to after-market parts and services5

In short, what is needed are new laws built for the Internet, which is why it was encouraging that Congress is holding hearings about these issues, and also frustrating that Apple received relatively little attention.

WordPress and Hey

The nature of the limited exceptions above are one reason Apple is at pains to emphasize that the App Store rules have been the same from the beginning; this is mostly correct, although the company has certainly tightened the limits around in-app purchasing over the years, to the extent that companies with cross-platform offerings can’t even tell users that they can subscribe on the web. It also seems that the App Store is going further than that; consider last weekend’s kerfuffle with the WordPress app:

• Automattic CEO Matt Mullenweg tweeted that Apple was refusing to allow updates to the WordPress app until it implemented in-app purchase for WordPress.com.
• The problem for Automattic is that the WordPress app is designed for not only WordPress.com, but also all open source WordPress sites (the app itself is distributed with the non-App-Store-compatible General Public License; Automattic has a special license from the WordPress Foundation, which owns the WordPress copyrights, to submit a version compatible with the App Store). This meant that Apple was demanding that an app meant to service all WordPress sites, including those on WordPress.com, add in-app purchases for just one of those sites.
• After 24 hours of confusion and outcry (including from me), Apple reversed its decision and “apologized for any confusion that [they] caused”.

It seems likely that the dual nature of the WordPress app — both adjunct to the for-profit WordPress.com and tool for the open-source WordPress.org project — was the reason Apple reversed its decision (that or bad press); said reasoning, though, means that Apple very much intended to make Automattic add in-app purchase functionality because it felt entitled to the company’s revenue.

This certainly appeared to be the case for Hey.com; while Apple’s official position in its written communication to Basecamp was that the app had to add in-app purchase if it did not have free functionality, the final paragraph suggested the company felt it deserved a cut:

Thank you for being an iOS app developer. We understand that Basecamp has developed a number of apps and many subsequent versions for the App Store for many years, and that the App Store has distributed millions of these apps to iOS users. These apps do not offer in-app purchase — and, consequently, have not contributed any revenue to the App Store over the last eight years. We are happy to continue to support you in your app business and offer you the solutions to provide your services for free — so long as you follow and respect the same App Store Review Guidelines and terms that all developers must follow.

Ultimately Basecamp added free functionality (an email address that is only good for two weeks) and didn’t add in-app purchase, and Apple approved the app; like the WordPress case, though, the question remained: how much did the massive amount of publicity around the case, particularly given the fact this blew up right before Apple’s annual developer conference, matter?

App Store Anecdotes

From what I have seen, quite a bit. When the Hey.com rejection happened, I wondered on Twitter if Apple was blocking other developers from updating their apps unless they added in-app purchase, and was surprised at the response: twenty-one app developers who contacted me had added in-app purchase in the last twelve months, and all of the developers in that list with regular update schedules had significant gaps in their history of updates (for example, one app updated every two weeks, with a four-month interruption in the middle of 2019). Nine more had either committed to adding in-app purchase, still had their app in limbo, or had simply given up on the App Store.

What was striking about all of these apps is that only three of them functioned primarily on an iPhone; in the vast majority of cases Apple was demanding in-app purchase offerings for functionality that was largely not dependent on an iPhone:

• 14 of the apps were “Companion Apps”, many of them in the business-to-business category. Imagine, for example, there was a service that allowed you to track inventory, and that service had a mobile app that let you look up your inventory numbers from your phone; Apple held up updates until the iPhone app had an in-app purchase option for the entire service (this is a fake example, but is representative). There were also some apps that looked a lot like the WordPress app: easier access to a web service (like a blog) that could just as easily have used a web page.
• 6 of the apps were “Cross-platform Web Services”; in this case iPhone access was certainly essential, but only because said service had to work everywhere. Think Hey’s email service, but, well, other email services, none of whom appear to have achieved Hey’s favorable outcome.
• 4 of the apps offered marketplace-type of functionality for things like classes, coaching, therapists, etc. Two examples are Airbnb and ClassPass, which the New York Times wrote about last month.
• 3 of the apps were purely digital goods, 1 was a niche streaming video app (that for whatever reason did not fall under the “reader” exemption), and 1 was a hardware app.

I have sat on these anecdotes for several months now, in part because this is all I can say: none of the developers were willing to go on the record for fear of angering Apple. What I think the WordPress and Hey episodes show, though, is that these are the exact sort of apps where Apple is getting things wrong, at least as far as popular opinion is concerned. Epic, what with its costumes and emotes that have zero marginal costs and only ever exist within the virtual world that Fornite created, is in many respects the worst possible agent for App Store change.

Organizing Principles

Here is what I believe the App Store has fundamentally wrong: its current organizing principle is digital versus analog; anything that is digital has to have in-app purchase, while anything that is analog — i.e. connected to the real world — can monetize however it pleases. That is why Amazon or Uber can ask for your credit card, and Airbnb can do the same for rooms but not for digital experiences (according to Apple).

The problem with this organizing principle is found in “Reader” app exception; from the App Store Guidelines:

3.1.3(a) “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions (specifically: magazines, newspapers, books, audio, music, video, access to professional databases, VoIP, cloud storage, and approved services such as classroom management apps), provided that you agree not to directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods are not designed to discourage use of in-app purchase.

This is how you end up with Netflix or Spotify or Kindle having apps that open to a login screen with zero indication about how to sign up for an account; most users probably figure out to go to their websites, but it is hardly a good experience from anyone’s perspective, and lesser known apps are likely to simply lose potential customers. At the same time, though, you can understand why “Reader” apps don’t really have a choice: Kindle has to pay publishers for books, and Spotify music labels; layering on 30% simply isn’t feasible.

The better organizing principle is whether or not the app developer has marginal costs. If every incremental sale costs the developer money, then Apple should not only not charge 30%, but should in fact compete for that purchase. Consider, for example, the ClassPass example in that New York Times article:

ClassPass built its business on helping people book exercise classes at local gyms. So when the pandemic forced gyms across the United States to close, the company shifted to virtual classes. Then ClassPass received a concerning message from Apple. Because the classes it sold on its iPhone app were now virtual, Apple said it was entitled to 30 percent of the sales, up from no fee previously, according to a person close to ClassPass who spoke on the condition of anonymity for fear of upsetting Apple. The iPhone maker said it was merely enforcing a decade-old rule…

With gyms shut down, ClassPass dropped its typical commission on virtual classes, passing along 100 percent of sales to gyms, the person close to the company said. That meant Apple would have taken its cut from hundreds of struggling independent fitness centers, yoga studios and boxing gyms.

In this case, Apple should both allow ClassPass to sell its classes via a webview (i.e. loading a webpage within its app), and also offer in-app purchases for, say, 10%; yes, that’s more expensive than credit card processing fees (which are ~$0.30+2.5%~2.9%, or around 6% of a $10 purchase), but the superiority of the user experience may convert enough customers that ClassPass would consider it worth the expense. This should also apply to all of the apps in the “Reader” category.

Fortnite, on the other hand, like most games, is selling purely virtual goods that have zero marginal cost; a costume or emote are bits in a database. Epic may be right that Apple’s 30% take is higher than it would be if the App Store had competition, but ultimately the cost of Fortnite’s V-Bucks is a completely arbitrary one (that is why, for example, Fortnite was willing to cut the price of V-Bucks on consoles to make their App Store point, even though they were still paying 30% to Sony, Microsoft, and Nintendo). To the extent that the App Store tax must exist — and to be clear, this is all predicated on the assumption that it isn’t going anywhere — purely digital goods, particularly those that are only usable on Apple’s platform, are the least objectionable.

This does, I should note, apply to more categories of apps than games. Many productivity apps are zero marginal cost — they are simply infinitely replicable software — and Apple’s take is reducing profitability, as opposed to making individual sales unviable. Indeed, I have always been less concerned about the 30% take for productivity apps and more focused on the lack of traditional trials and paid updates.

There is also a distinction worth drawing between experiences that primarily happen on an iPhone, and those that are primarily on the web, or cross-platform. The latter should be allowed the current “Reader” exception: simply present a login, because, by definition, the user is already using the application in question elsewhere. It is absolutely bizarre that Apple is going after these apps to demand in-app purchase; the fact these developers bothered to make an iPhone app as an add-on is the real win, and punishing them is counter-productive.

Distinguishing apps according to their iPhone-centricity and marginal costs results in a landscape that looks like this:

iPhone-focused experiences with zero marginal cost goods pay the full in-app purchase tax, while cross-platform experiences are allowed only a login. Apps with marginal costs, meanwhile, can either offer their own payment solution via a webview, or take advantage of the App Store’s superior in-app purchase experience at a competitive rate.

A New App Store Approach

I know this Article has been wide-ranging, but there is a reason:

• First, while I recognize there are good reasons for Apple’s approach to the App Store, in a vacuum I would prefer far more openness and freedom, primarily for the sake of increased innovation.
• Second, under current law, I expect Apple to retain total control of the App Store.
• Third, I believe that Apple’s current approach to the App Store is bad for developers, bad for innovation, and ultimately bad for Apple.

All of these points are important; it is tempting to write a screed about the App Store that ignores point two, for example, which means the screed doesn’t matter; at the same time, I am concerned that Apple itself will ignore point three, and miss an opportunity to rethink its approach.

That, then, is the spirit of my proposals: if we accept the fact that Apple is determined to make a significant amount of money off of the App Store, and that they have the right to do so, what is a better approach? For this I will incorporate all of the above, and also draw on the distinctions I made to discrete App Store functionality last week (and again, let me be very clear: this isn’t my preferred outcome, but rather one that I hope is plausible).

App Installation: Apple should stop using App Installation to stifle new business models like Google Stadia or Xbox Game Pass. This is, admittedly, one of my weaker arguments: I believe Apple should allow these because innovation is important, and cloud gaming is exactly that. At the same time, cloud gaming is a direct challenge to Apple’s App Store control, so I understand why 30% is not enough from Apple’s perspective.

Payment Processing: This is where the marginal cost/cross-platform distinction comes into play:

• If your app experience is contained to the iPhone and has zero marginal costs, you can only use in-app purchase at Apple’s rate (30% currently).
• If your app experience is cross-platform and has zero marginal costs, your app can simply be a login page at launch, with the assumption you are paying elsewhere; if you wish to offer payments, you have to offer in-app purchase at Apple’s rate.
• If your app experience has marginal costs, then you can offer either a webview for purchase or an in-app purchase at a new Apple rate (~10%) (keep in mind that marginal costs means something discrete; simply needing some indeterminate amount of more server capacity doesn’t suffice).

There will still be edge cases here, particularly when it comes to determining what is an iPhone-only experience, as opposed to a cross-platform one; Fortnite, for example, can be played cross-platform, but I would still classify it as an iPhone-only experience (I would be ok with simply assuming that all games are iPhone-only experiences). What makes these edge cases far more tolerable, though, is that they are arguing about who gets what share of zero marginal cost goods, as opposed to driving folks who need to pay for what they provide out of business.

In addition, I will never rest in my call for traditional trials and upgrade pricing (and go ahead Apple, take your 30%); it’s a better model for productivity apps than subscriptions, particularly small-scale apps, and it genuinely bums me out that this doesn’t yet exist. Indeed, this is the strongest possible argument as to why one company having a monopoly over payment processing is such a terrible idea.

Customer Management: Here Apple both gives and takes. The taking is clear: by virtue of controlling payment, Apple controls the customer relationship. That is a reason for a developer to try and consummate the payment on their own.

At the same time, the App Store is itself a marketing channel. I do believe that Apple massively overstates its importance — sure, it is nice to for an app to be featured, but you can’t build a business model around that like you can targeted advertising — but it is a potential value-add. What Apple should do is make discovery in the App Store contingent on using in-app purchase. If you want to be featured or show up in charts use in-app purchase; if you don’t, then customers have to search for your app directly.

The odds are that Apple isn’t going to change anything; the App Store is extremely profitable, and Apple is probably going to win its court case. Why give up a single dime? At the same time, the constant wave of controversies have to be wearing on the company, from a morale perspective if nothing else. Apple can be legitimately accused of profiteering off of COVID-19!

To that end, I hope the company will at least consider the possibility that this isn’t the 1990s, they’re not about to go out of business, and that being perceived as an asset to developers and not a tax opens up the possibility of growing the pie, not simply taking their slice. If that is the outcome of this summer of App Store turmoil, it will be a win for everyone: developers, Apple, and the users that want both security and innovation.

1. Fortnite still works if you have previously downloaded it; the judge’s order does suggest that Apple could render Fortnite (and only Fortnite) completely unplayable if it chose to
2. See Verizon Communications Inc. v. Law Offices of Curtis V. Trinko, LLP.
3. See Pacific Bell Telephone Co. v. linkLine Communications, Inc..
4. See Aspen Skiing v. Aspen Highlands Skiing; this case may apply to Apple’s removal of parental control apps that leveraged mobile device management capabilities.
5. See Eastman Kodak Co. v. Image Technical Services, Inc., of which the dissent is the de facto controlling precedent.