There has been a recent flurry of regulatory, legislative, and courtroom activity regarding mobile OSes and their app stores. One emergent theme is Apple's shocking disregard for the spirit of legal findings it views as adverse to its interests.

Take, for instance, Apple's insistence that it would take "months" to support the addition of links to external payment providers from within apps, nevermind it had months of notice. There is a case to be made that formulating policy and constructing a comissions system takes time, but this is ridiculous.

Just sit with Apple's claim a moment. Cupertino is saying that it will take additional months to allow other people to add links within their own apps.

Or consider South Korea's law, passed last August, that elicited months of stonewalling by Google and Apple until, at last, an exasperated KCC started speaking a language Cupertino understands: fines. Having run the clock for half a year, Apple has started making noises that indicate a willingness to potentially allow alternative payment systems at some point in the future.

Never fear, though; there's no chance that grudging "compliance" will abide the plain-language meaning of the law. Apple is fully committed to predatory delay and sneering, legalistic, inch-measuring conformance. Notably, it signaled it feels entitled to skim equivalent revenues to it's monopoly rents for payments paid through third-party processors in both Korea and the Netherlands. If regulators are going to bring this to heel, they will need to start assuming bad-faith.

Dutch regulators have been engaged in a narrowly-focused enquiry into the billing practices of dating apps, and they came to remarkably similar conclusions: Apple's pracctices are flagarantly anti-competitive.

In a malign sort of consistency, Apple responded in the most obtuse, geographically constrained, and difficult-to-use solution possible. Developers would need to submit a separate, country-specific version of their app, only available from the Dutch version of the App Store, and present users with pejorative messaging. Heaven help users attempting to navigate such a mess.

This "solution" was poorly received. Perhaps learning from the KCC's experience, Dutch regulators moved to impose fines more quickly, but perhaps misjudged how little 50 million EUR is to a firm that makes 600× as much in profit per quarter. It certainly hasn't modulated Apple's duplicitous audacity.

Cupertino's latest proposed alternative to its 30% revenue cut will charge developers that use external payment processors a 27% fee which, after the usual 3% credit card processing fee... well, you can do the math.

Regulators in the low countries are rightly incensed, but Apple's disrespect for the rule of law isn't going to be reformed by slowly deployed half-measures, one vertical at a time. Structural change is necessary, and the web could bring that change if it is unshackled from Apple's slipshod browser engine.

A Floor for Functional Browser Choice #

With all of this as context, we should seriously consider how companies this shameless will behave if required to facilitate genuine browser choice. What are the policy and technical requirements regulators should set to ensure fairness? How can the lines be drawn so delay and obfuscation aren't used to scuttle capable competitors? How can regulators anticipate and get ahead of brazenly bad-faith actions, not only by Apple, but Google and Facebook as well?

Geographic Games #

One oligopolist response has been to change anti-competitive behaviour only within small markets, e.g. making changes only to the "dating" category of apps and only within the Netherlands. Apple and Google calculate that they can avoid the Brussels Effect by making a patchwork set of market-specific changes. A goal of this strategy is to confuse users and make life hard for rebellious developers by tightly drawing "fixes" around the letter of the law in each jurisdiction.

While technically meeting legal requirements, these systems will be so hard to use that residents and businesses blame regulators, rather than store proprietors for additional day-to-day inconvenience. Because they're implemented in software, this market well-poisoning is cost-free for Apple. It also buys bad-faith actors months of delay on substantive change while they negotiate with regulators.

Could regulators include language that stipulates how market fairness requirements cannot be met with country-specific versions of apps or capabilities? This quickly hits jurisdictional boundaries, likely triggering years of court appeals. This is undesirable as delay is the ne'er do well's friend.

Regulators generally have scope over commerce within their territorial borders. Multilateral treaty organisations like the the WTO have supranational jurisdiction but no appetite or the treaty scope to tackle firm-level competition issues. They focus instead on tariffs and "dumping" practices that privilege one nation's industries over another, as those are the sorts of disputes national laws cannot address.

A More Durable Approach #

Effective regulation needs market-opening technologies that function without constant oversight. The lines drawn around undermining this technology should be so clear, and the consequences for stepping over them so painful, that even Apple, Google, and Facebook dare not go near them.

When regulators adopt similar (if not identical) regulations they increase the costs to bad actors of country-specific gamesmanship. Regulators that "harmonise" their interventions multiply the chances of compliance, creating a "Brussels of the Willing".

A competitive landscape for web browsers should be part of any compliance framework because:

• A world with safe, capable web apps provides businesses alternatives to app store gatekeepers.
• Browser competition (enabled by meaningful choice) has consistently delivered safety and control to users far ahead of operating systems. Compare, for instance, the late addition of mobile OS controls for location tracking, ad blocking, and bluetooth compared with the web's more consent-oriented track record.
• Web apps put pricing pressure on platform owners, forcing them to innovate rather than extract rents. Many classes of apps trapped in app stores only use standardised APIs that happen to be spelled differently on proprietary OSes. They could be delivered just as well through the web's open, interoperable, and liberally licensed standards, but for gatekeepers denying those features to browser and scuppering app discoverability on the web.
• Web applications create portability for developers and businesses, lowering costs and improving access to services. This enhances the bargaining power of small firms relative to platform owners.

For the web to perform these essential market functions on mobile, regulation must disrupt the status quo and facilitate competition from within. This also provides a solution to user safety and security concerns that pervasive sideloading may raise, as browsers are aggressively sandboxed. Meanginful choice, coupled with powerful browsers, can deliver better outcomes:

Table Stakes #

Discussion of sideloading and alternative app stores often elides requirements that regulators should put in place to create competition amongst capable browsers. I have previously proposed a set of minimal interventions to ensure meaningful user choice. To restate the broadest points:

• Platform vendors' own products must respect users' browser choices within applications which are not themselves browsers.
• Mobile OSs should provide a simple, global way to opt-out of "in-app browsers" across all applications.
• Developers must be provided with a simple way for their content to opt-out of being loaded via "in-app browsers".
• System-level "in-app browser" protocols and APIs should allow a user's default browser to render sites by default.

iOS Specifics #

Because Apple's iOS is egregiously closed to genuine browser competition, regulators should pay specific attention to the capabilities that vendors that port engines will need. They should also ensure other capabilities are made available by default; the presumption for browser developers must be open access. Apple has shown itself to be a serial bad-faith actor regarding competition and browser choice, so while an enumeration of these features may seem pedantic, it sadly also seems necessary.

Today, Apple's Safari browser enjoys privileged access to certain APIs necessary for any competing browser vendor that wants to match Safari's features. Only Safari can:

• Construct new sub-processes for sandboxing web content. Competing browsers will need to do the same, and be allowed to define a tighter sandbox policy than Apple's default (as they already do on Windows, macOS, and Android).
• JIT JavaScript code. For reasons covered extensively last year, there's no legitimate reason to disallow competing browsers from running at full speed.
• Install Web Apps to the iOS homescreen. Competing browsers must be allowed to match Safari's capability that allows it to install PWAs to the device's homescreen and serve as the runtime for those apps.
• Integrate with SFSafariViewController. Competing browsers set as the user's default must be allowed to also handle "in-app browsing" via the SFSafariViewController protocol without requiring the user to opt-in.
• Provide its own networking layer and integrate with Private Relay's closed APIs. Competing browsers must be allowed access to OS-integrated capabilities without being forced to use Apple's slower, less reliable networking stack.

As a general rule, competing browsers must also be allowed access to all private and undocumented APIs that are used by Safari, as well as iOS entitlements granted to other applications.

Regulators must also ensure capabilities are not prohibited or removed from browsers by secret agreements that Cupertino forces developers to sign. Further (and it's a shame this has to be said), Apple must not be allowed to comply with these terms by further neutering Safari's already industry-trailing feature set.

Apple must also be required to allow browsers with alternative engines to be procured directly through its App Store. It is easy to predict a world of country-specific sideloading regulations, with Apple attempting to blunt the impact of competitive browsers by continuing to banish them from their "legit" discovery surface.

Web browsers must also be allowed to implement the Web Payments API without being forced to use Apple Pay as the only back end. Apple must further be enjoined from requiring specific UI treatments that subvert these flows and prejudice users away from open payment systems.

Lastly, Apple must not be allowed to publish new versions of browsers through an arbitrary and capricious "review" process. Regulators must demand that Apple be forced to publish new browser versions and, if it objects to features within them, file a request for regulatory arbitration of the dispute post publication. Apple has long demonstrated it cannot be trusted with the benefit of the doubt in this area, and allowing updates to flow quickly is critical to ensuring users of the web remain safe.

Only within the contours of this sort of regime can ongoing enforcement of negotiated policy proceed in good faith.