Progress Delayed Is Progress Denied

Do App Store policies harm developers? Is the web a credible alternative? A look at the data.

Updated:

This is part one of the six-part series "Browser Choice Must Matter"

Update (June 16th, 2021): Folks attempting to build mobile web games have informed me that the Fullscreen API remains broken on iOS for non-video elements. This hobbles gaming and immersive media experiences in a way that is hard to overstate. Speaking of being hobbled, the original post gave Apple credit for eventually shipping a useable implementation of IndexedDB. It seems this was premature.

Three facts...

1. Apple bars web apps from the only App Store allowed on iOS.[1]

2. Apple forces developers of competing browsers to use their engine for all browsers on iOS, restricting their ability to deliver a better version of the web platform.

3. Apple claims that browsers on iOS are platforms sufficient to support developers who object to the App Store's terms .

...and a proposition:

Apple's iOS browser (Safari) and engine (WebKit) are uniquely under-powered. Consistent delays in the delivery of important features ensure the web can never be a credible alternative to its proprietary tools and App Store.

This is a bold assertion, and proving it requires overwhelming evidence. This post mines publicly available data on the pace of compatibility fixes and feature additions to assess the claim.

Steve & Tim's Close-up Magic #

Misdirections often derail the debate around browsers, the role of the web, and App Store policies on iOS. Classics of the genre include:

Apple's just focused on performance!

...that feature is in Tech Preview

Apple's trying, they just added <long-awaited feature>

These points can be simultaneously valid and immaterial to the web's fitness as a competent alternative to native app development on iOS.

We have to check reservoir levels and seasonal rainfall to know if we're in a drought. It might be raining features right this instant, but weather isn't climate. We should look at trends rather than individual releases to understand the gap Apple created and maintains between the web and native.

Before we get to measuring water levels, I want to make some things excruciatingly clear.

First, what follows is not a critique of individuals on the Safari team or the WebKit project; it is a plea for Apple to fund their work adequately[2] and allow competition. They are, pound for pound, some of the best engine developers and genuinely want good things for the web. Apple Corporate is at fault, not Open Source engineers or the line managers who support them.

Second, projects having different priorities at the leading edge is natural and healthy. So is speedy resolution and agreement. What's unhealthy is an engine trailing far behind for many years. Even worse are situations that cannot be addressed through browser choice. It's good for teams to be leading in different areas, assuming that the "compatible core" of features continues to expand at a steady pace. We should not expect uniformity in the short run — it would leave no room for leadership[3].

Lastly, while this post does measure the distance Safari lags, let nobody mistake that for the core concern: iOS App Store policies that prevent meaningful browser competition are at issue here.

Safari trails competing macOS browsers by roughly the same amount, but it's not a crisis because genuine browser choice enables meaningful alternatives.

macOS Safari is compelling enough to have maintained 40-50% share for many years amidst stiff competition. Safari has many good features, and in an open marketplace, choosing it is entirely reasonable.

The Performance Argument #

As an engineer on a browser team, I've been privy to the blow-by-blow of various performance projects, benchmark fire drills, and the ways performance marketing impacts engineering priorities.

All modern browsers are fast, Chromium and Safari/WebKit included. No browser is always fastest. As reliably as the Sun rises in the East, new benchmarks launch projects to re-architect internals to pull ahead. This is as it should be.

Healthy competitions feature competitors trading the lead with regularity. Performance Measurement is easy to get wrong. Spurious reports of "10x worse" performance merit intense scepticism, as they tend instead to be mismeasurement. This makes sense given the intense focus of all browser teams on performance.

After 20 years of neck-in-neck competition, often starting from common code lineages, there just isn't that much left to wring out of the system. Consistent improvement is the name of the game, and it can still have positive impacts, particularly as users lean on the system more heavily over time.

All browsers are deep into the optimisation journey, forcing complex tradeoffs. Improving things for one type of device or application can regress them for others. Significant gains today tend to come from (subtly) breaking contracts with developers in the hopes users won't notice. There isn't a massive gap in focus on performance engineering between engines.

Small gaps and a frequent hand-off of the lead imply differences in capability and correctness aren't the result of one team focusing on performance while others chase different goals[4].

Finally, the choice to fund feature and correctness work is not mutually exclusive to improving performance. Many delayed features on the list below would allow web apps to run faster on iOS. Internal re-architectures to improve correctness often yield performance benefits too.

The Compatibility Tax #

Web developers are a hearty bunch; we don't give up at the first whiff of bugs or incompatibility between engines. Deep wells of knowledge and practice centre on the question: "how can we deliver a good experience to everyone despite differences in what their browsers support?"

Adaptation is a way of life for skilled front enders.

The cultural value of adaptation has enormous implications. First, web developers don't view a single browser as their development target. Education, tools, and training all support the premise that supporting more browsers is better (ceteris paribus), creating a substantial incentive to grease squeaky wheels. Therefore, bridging the gap between leading and trailing-edge browsers is an intense focus of the web development community. Huge amounts of time and effort are spent developing workarounds (preferably with low runtime cost) for lagging engines[5]. Where workarounds fail, cutting features and UI fidelity is understood to be the right thing to do.

Compatibility across engines is key to developer productivity. To the extent that an engine has more than 10% share (or thereabouts), developers tend to view features it lacks as "not ready". It's therefore possible to deny web developers access to features globally by failing to deliver them at the margin.

A single important, lagging engine can make the whole web less competitive this way.

To judge the impact of iOS along this dimension, we can try to answer a few questions:

1. How far behind both competing engines is Safari regarding correctness?

2. When Safari has implemented essential features, how often is it far ahead? Behind?

Thanks to the Web Platform Tests project and wpt.fyi, we have the makings of an answer for the first:

Tests that fail only in a given browser. Lower is better.

The yellow Safari line is a rough measure of how often other browsers are compatible, but Safari's implementation is wrong. Conversely, the much lower Chrome and Firefox lines indicate Blink and Gecko are considerably more likely to agree and be correct regarding core web standards[6].

wpt.fyi's new Compat 2021 dashboard narrows this full range of tests to a subset chosen to represent the most painful compatibility bugs:

Stable-channel Compat 2021 results over time. Higher is better.

Tip-of-tree improvements are visible in WebKit. Sadly, these take quarters to reach devices because Apple ties WebKit features to the slow cadence of OS releases.

In almost every area, Apple's low-quality implementation of features WebKit already supports requires workarounds. Developers would not need to find and fix these issues in Firefox (Gecko) or Chrome/Edge/Brave/Samsung Internet (Blink). This adds to the expense of developing for iOS.

Converging Views #

The Web Confluence Metrics project provides another window into this question.

This dataset is derived by walking the tree of web platform features exposed to JavaScript, an important subset of features. The available data goes back further, providing a fuller picture of the trend lines of engine completeness.

Engines add features at different rates, and the Confluence graphs illuminate both the absolute scale of differences and the pace at which releases add new features. The data is challenging to compare across those graphs, so I extracted it to produce a single chart:

Chrome

Firefox

Safari

Count of APIs available from JavaScript by Web Confluence.

Higher is better.

In line with Web Platform Tests data, Chromium and Firefox implement more features and deliver them to market more steadily. From this data, we see that iOS is the least complete and competitive implementation of the web platform, and the gap is growing. At the time of the last Confluence run, the gap had stretched to nearly 1000 APIs, doubling since 2016.

Perhaps counting APIs gives a distorted view?

Some minor additions (e.g. CSS's new Typed Object Model) may feature large expansions in API surface. Likewise, some transformative APIs (e.g. webcam access via getUserMedia() or Media Sessions) may only add a few methods and properties.

To understand if intuitions formed by the Web Confluence data are directionally correct, we need to look more deeply at the history of feature development and connect APIs to the types of applications they enable.

Material Impacts #

Browser release notes and caniuse tables since Blink forked from WebKit in 2013[7] capture the arrival of features in each engine over an even longer period than either WPT or the Confluence dataset. This record can inform a richer understanding of how individual features and sets of capabilities unlock new types of apps.

Browsers sometimes launch new features simultaneously (e.g., CSS Grid and ES6). More often, there is a lag between the first and the rest. To provide a sizeable "grace period", and account for short-run differences in engine priorities, we look primarily at features with a gap of three years or more[8].

What follows is an attempt at a full accounting of features launched in this era. A summary of each API and the impact of its absence accompanies every item.

Where Chrome Has Lagged #

It's healthy for engines to have different priorities, leading every browser to avoid certain features. Still, mistakes have been made, and Chrome has missed several APIs for 3+ years:

Storage Access API

Introduced in Safari three years ago, this anti-tracking API was under-specified, leading to significant divergence in API behaviour across implementations. The low quality of Apple's initial versions of "Intelligent Tracking Prevention" created a worse tracking vector(pdf) (subsequently repaired)[9].

On the positive side, this has spurred a broader conversation around privacy on the web, leading to many new, better-specified proposals and proposed models.

CSS Snap Points

Image carousels and other touch-based UIs are smoother and easier to build using this feature. Differences within the Blink team about the correct order to deliver this vs. Animation Worklets led to regrettable delays.

Initial Letter

An advanced typography feature, planned in Blink once the LayoutNG project finishes.

position: sticky

Makes "fixed" elements in scroll-based UIs easier to build. The initial implementation was removed from Blink post-fork and re-implemented on new infrastructure several years later.

CSS color()

Wide gamut colour is important in creative applications. Chrome does not yet support this for CSS, but is under development for <canvas> and WebGL.

JPEG 2000

Licensing concerns caused Chrome to ship WebP instead.

HEVC/H.265

Next-generation video codecs, supported in many modern chips, but also a licensing minefield. The open, royalty-free codec AV1 has been delivered instead.

Where iOS Has Lagged #

Some features in this list were launched in Safari but were not enabled for other browsers forced to use WebKit on iOS (e.g. Service Workers, getUserMedia). In these cases, only the delay to shipping in Safari is considered.

getUserMedia()

Provides access to webcams. Necessary for building competitive video experiences, including messaging and videoconferencing.

These categories of apps were delayed on the web for iOS by five years.

WebRTC

Real-time network protocols for enabling videoconferencing, desktop sharing, and game streaming applications.

Delayed five years.

Gamepad API

Fundamental for enabling the game streaming PWAs (Stadia, GeForce NOW, Luna, xCloud) now arriving on iOS.

Delayed five years.

Audio Worklets

Audio Worklets are a fundamental enabler for rich media and games on the web. Combined with WebGL2/WebGPU and WASM threading (see below), Audio Worklets unlock more of a device's available computing power, resulting in consistently good sound without fear of glitching.

After years of standards discussion and the first delivered to other platforms in 2018, iOS 14.5 finally shipped Audio Worklets this week.

IndexedDB

A veritable poster-child for the lateness and low quality of Safari amongst web developers, IndexedDB is a modern replacement for the legacy WebSQL API. It provides developers with a way to store complex data locally.

Initially delayed by two years, first versions of the feature were so badly broken on iOS that independent developers began to maintain lists of show-stopping bugs.

Had Apple shipped a usable version in either of the first two attempts, IndexedDB would not have made the three-year cut. The release of iOS 10 finally delivered a workable version, bringing the lag with Chrome and Firefox to four and five years, respectively.

Pointer Lock

Critical for gaming with a mouse. Still not available for iOS or iPadOS.

Update: some commenters seem to sneer the the idea of using a mouse for gaming on iOS, but it has been reported to browser teams as a key feature by the teams building game streaming PWAs. It appears a sizeable set of users use external mice and keyboards with their iPads, and the entire categories of games are functionally unusable on these platforms without Pointer Lock.

Media Recorder

Fundamentally enabling for video creation apps. Without it, video recordings must fit in memory, leading to crashes.

This was Chrome's most anticipated developer feature ever (measured by stars). It was delayed by iOS for five years.

Pointer Events

A uniform API for handling user input like mouse movements and screen taps that is important in adapting content to mobile, particularly regarding multi-touch gestures.

First proposed by Microsoft, delayed three years by Apple[10].

Service Workers

Key API enabling modern, reliable offline web experiences and PWAs.

Delayed more than three years (Chrome 40, November 2014 vs. Safari 11.1, April 2018, but not usable until several releases later).

WebM and VP8/VP9

Royalty-free codecs and containers; free alternatives to H.264/H.265 with competitive compression and features. Lack of support forces developers to spend time and money transcoding and serving to multiple formats (in addition to multiple bitrates).

Supported only for use in WebRTC but not the usual mechanisms for media playback (<audio> and <video>). Either delayed 9 years or still not available, depending on use.

CSS Typed Object Model

A high-performance interface to styling elements. A fundamental building block that enables other "Houdini" features like CSS Custom Paint.

Not available for iOS.

CSS Containment

Features that enable consistently high performance in rendering UI, and a building block for new features that can dramatically improve performance on large pages and apps.

Not available for iOS.

CSS Motion Paths

Enables complex animations without JavaScript.

Not available for iOS.

Media Source API (a.k.a. "MSE")

MSE enables the MPEG-DASH video streaming protocol. Apple provides an implementation of HLS, but prevents use of alternatives.

Only available on iPadOS.

element.animate()

Browser support for the full Web Animations API has been rocky, with Chromium, Firefox, and Safari all completing support for the full spec the past year.

element.animate(), a subset of the full API, has enabled developers to more easily create high-performance visual effects with a lower risk of visual stuttering in Chrome and Firefox since 2014.

EventTarget Constructor

Seemingly trivial but deceptively foundational. Lets developers integrate with the browser's internal mechanism for message passing.

Delayed by nearly three years on iOS.

Web Performance APIs

iOS consistently fails to provide modern APIs for measuring web performance by three or more years. Delayed or missing features are not limited to:

- navigator.sendBeacon()

- Paint Timing (delayed two-to-four years)

- User Timing

- Resource Timing

- Performance Observers

The impact of missing Web Performance APIs is largely a question of scale: the larger the site or service one attempts to provide on the web, the more important measurement becomes.

fetch() and Streams

Modern, asynchronous network APIs that dramatically improve performance in some situations.

Delayed two to four years, depending on how one counts.

Not every feature blocked or delayed on iOS is transformative, and this list omits cases that were on the bubble (e.g., the 2.5 year lag for BigInt). Taken together, the delays Apple generates, even for low-controversy APIs, makes it challenging for businesses to treat the web as a serious development platform.

The Price #

Suppose Apple had implemented WebRTC and the Gamepad API in a timely way. Who can say if the game streaming revolution now taking place might have happened sooner? It's possible that Amazon Luna, NVIDIA GeForce NOW, Google Stadia, and Microsoft xCloud could have been built years earlier.

It's also possible that APIs delivered on every other platform, but not yet available on any iOS browser (because Apple), may unlock whole categories of experiences on the web.

While dozens of features are either currently, or predicted to be, delayed multiple years by Apple, a few high-impact capabilities deserve particular mention:

WebGL2

The first of two modern 3D graphics APIs currently held up by Apple, WebGL2 dramatically improves the visual fidelity of 3D applications on the web, including games. The underlying graphics capabilities from OpenGL ES 3.0 have been available in iOS since 2013 with iOS 7.0. WebGL 2 launched for other platforms on Chrome and Firefox in 2017. While WebGL2 is in development in WebKit, the anticipated end-to-end lag for these features is approaching half a decade.

WebGPU

WebGPU is a successor to WebGL and WebGL2 that improves graphics performance by better aligning with next-gen low-level graphics APIs (Vulkan, Direct3D 12, and Metal).

WebGPU will also unlock richer GPU compute for the web, accelerating machine learning and media applications. WebGPU is likely to ship in Chrome in late 2021. Despite years of delay in standards bodies at the behest of Apple engineers, the timeline for WebGPU on iOS is unclear. Keen observers anticipate a minimum of several years of additional delay.

WASM Threads and Shared Array Buffers

Web Assembly ("WASM") is supported by all browsers today, but extensions for "threading" (the ability to use multiple processor cores together) are missing from iOS.

Threading support enables richer and smoother 3D experiences, games, AR/VR apps, creative tools, simulations, and scientific computing. The history of this feature is complicated, but TL;DR, they are now available to sites that opt in on every platform save iOS. Worse, there's no timeline and little hope of them becoming available soon.

Combined with delays for Audio Worklets, modern graphics APIs, and Offscreen Canvas, many compelling reasons to own a device have been impossible to deliver on the web.[11]

WebXR

Now in development in WebKit after years of radio silence, WebXR APIs provide Augmented Reality and Virtual Reality input and scene information to web applications. Combined with (delayed) advanced graphics APIs and threading support, WebXR enables immersive, low-friction commerce and entertainment on the web.

Support for a growing list of these features has been available in leading browsers across other platforms for several years. There is no timeline from Apple for when web developers can deliver equivalent experiences to their iOS users (in any browser).

These omissions mean web developers cannot compete with their native app counterparts on iOS in categories like gaming, shopping, and creative tools.

Developers expect some lag between the introduction of native features and corresponding browser APIs. Apple's policy against browser engine choice adds years of delays beyond the (expected) delay of design iteration, specification authoring, and browser feature development.

These delays prevent developers from reaching wealthy users with great experiences on the web. This gap, created exclusively and uniquely by Apple policy, all but forces businesses off the web and into the App Store where Apple prevents developers from reaching users with web experiences.

Just Out Of Reach #

One might imagine five-year delays for 3D, media, and games might be the worst impact of Apple's policies preventing browser engine progress. That would be mistaken.

The next tier of missing features contains relatively uncontroversial proposals from standards groups that Apple participates in or which have enough support from web developers to be "no-brainers". Each enables better quality web apps. None are expected on iOS any time soon:

Scroll Timeline for CSS & Web Animations

Likely to ship in Chromium later this year, enables smooth animation based on scrolling and swiping, a key interaction pattern on modern mobile devices.

No word from Apple on if or when this will be available to web developers on iOS.

content-visibility

CSS extensions that dramatically improve rendering performance for large pages and complex apps.

WASM SIMD

Coming to Chrome next month, WASM SIMD enables high performance vector math for dramatically improved performance for many media, ML, and 3D applications.

Form-associated Web Components

Reduces data loss in web forms and enables components to be easily reused across projects and sites.

CSS Custom Paint

Efficiently enables new styles of drawing content on the web, removing many hard tradeoffs between visual richness, accessibility, and performance.

Trusted Types

A standard version of an approach demonstrated in Google's web applications to dramatically improve security.

CSS Container Queries

A top request from web developers and expected in Chrome later this year, CSS Container Queries enable content to better adapt to varying device form-factors.

<dialog>

A built-in mechanism for a common UI pattern, improving performance and consistency.

inert Attribute

Improves focus management and accessibility.

Browser assisted lazy-loading

Reduces data use and improves page load performance.

Fewer of these features are foundational (e.g. SIMD). However, even those that can be emulated in other ways still impose costs on developers and iOS users to paper over the gaps in Apple's implementation of the web platform. This tax can, without great care, slow experiences for users on other platforms as well[12].

What Could Be #

Beyond these relatively uncontroversial (MIA) features lies an ocean of foreclosed possibility. Were Apple willing to allow the sort of honest browser competition for iOS that macOS users enjoy, features like these would enable entirely new classes of web applications. Perhaps that's the problem.

Some crucial features (shipped on every other OS) that Apple is preventing any browser from delivering to iOS today, in no particular order:

Push Notifications

In an egregious display of anti-web gate-keeping, Apple has implemented for iOS neither the long-standard Web Push API nor Apple's own, entirely proprietary push notification system for macOS Safari

It's difficult to overstate the challenges posed by a lack of push notifications on a modern mobile platform. Developers across categories report a lack of push notifications as a deal-killer, including:

- Chat, messaging, and social apps (for obvious reasons)

- e-commerce (abandoned cart reminders, shipping updates, etc.)

- News publishers (breaking news alerts)

- Travel (itinerary updates & at-a-glance info)

- Ride sharing & delivery (status updates)

This omission has put sand in the web's tank — to the benefit of Apple's native platform, which has enjoyed push notification support for 12 years.

PWA Install Prompts

Apple led the way with support for installing certain web apps to a device's homescreen as early as iOS 1.0. Since 2007, support for these features has barely improved.

Subsequently, Apple added the ability to promote the installation of native apps, but has not provided equivalent "install prompt" tools for web apps.

Meanwhile, browsers on other platforms have developed both ambient (browser provided) promotion and programmatic mechanisms to guide users in saving frequently-used web content to their devices.

Apple's maintenance of this feature gap between native and web (despite clear underlying support for the mechanism) and unwillingness to allow other iOS browsers to improve the situation[13], combined with policies that prevent the placement of web content in the App Store, puts a heavy thumb on the scale for discovering content built with Apple's proprietary APIs.

PWA App Icon Badging

Provides support for "unread counts", e.g. for email and chat programs. Not available for web apps added to the home screen on iOS.

Media Session API

Enables web apps to play media while in the background. It also allows developers to plug into (and configure) system controls for back/forward/play/pause/etc. and provide track metadata (title, album, cover art).

Lack of this feature prevents entire classes of media applications (podcasting and music apps like Spotify) from being plausible.

In development now, but if it ships this fall (the earliest window), web media apps will have been delayed more than five years.

Navigation Preloads

Dramatically improve page loading performance on sites that provide an offline experience using Service Workers.

Multiple top-10 web properties have reported to Apple that lack of this feature prevents them from deploying more resilient versions of their experiences (including building PWAs) for users on iOS.

Offscreen Canvas

Improves the smoothness of 3D and media applications by moving rendering work to a separate thread. For latency-sensitive use-cases like XR and games, this feature is necessary to consistently deliver a competitive experience.

TextEncoderStream & TextDecoderStream

These TransformStream types help applications efficiently deal with large amounts of binary data. They may have shipped in iOS 14.5 but the release notes are ambiguious.

requestVideoFrameCallback()

Helps media apps on the web save battery when doing video processing.

Compression Streams

Enable developers to compress data efficiently without downloading large amounts of code to the browser.

Keyboard Lock API

An essential part of remote desktop apps and some game streaming scenarios with keyboards attached (not uncommon for iPadOS users).

Declarative Shadow DOM

An addition to the Web Components system that powers applications like YouTube and Apple Music. Declarative Shadow DOM can improve loading performance and help developers provide UI for users when scripts are disabled or fail to load.

Reporting API

Indispensable for improving the quality of sites and avoid breakage due to browser deprecations. Modern versions also let developers know when applications crash, helping them diagnose and repair broken sites.

Permissions API

Helps developers present better, more contextual options and prompts, reducing user annoyance and "prompt spam".

Screen Wakelock

Keeps the screen from going dark or a screen saver taking over. Important for apps that present boarding passes and QR codes for scanning, as well as and presentation apps (e.g. PowerPoint or Google Slides).

Intersection Observer V2

Reduces ad fraud and enables one-tap-sign-up flows, improving commerce conversion rates.

Content Indexing

An extension to Service Workers that enables browsers to present users with cached content when offline.

AV1/AVIF

A modern, royalty-free video codec with near-universal support outside Safari.

PWA App Shortcuts

Allows developers to configure "long press" or "right-click" options for web apps installed to the home screen or dock.

Shared Workers and Broadcast Channels

Coordination APIs allow applications to save memory and processing power (albeit, most often in desktop and tablet form-factors).

getInstalledRelatedApps()

Helps developers avoid prompting users for permissions that might be duplicative with apps already on the system. Particularly important for avoiding duplicated push notifications.

Background Sync

A tool for reliably sending data — for example, chat and email messages — in the face of intermittent network connections.

Background Fetch API

Allows applications to upload and download bulk media efficiently with progress indicators and controls. Important for reliably syncing playlists of music or videos for offline or synchronising photos/media for sharing.

Periodic Background Sync

Helps applications ensure they have fresh content to display offline in a battery and bandwidth-sensitive way.

Web Share Target

Allows installed web apps to receive sharing intents via system UI, enabling chat and social media apps to help users post content more easily.

The list of missing, foundational APIs for media, social, e-commerce, 3d apps, and games is astonishing. Essential apps in the most popular categories in the App Store are impossible to attempt on the web on iOS because of feature gaps Apple has created and perpetuates.

Device APIs: The Final Frontier #

An area where browsers makers disagree fervently, but where Chromium-based browsers have forged ahead (Chrome, Edge, Samsung Internet, Opera, UC, etc.) is access to hardware devices. While not essential to most "traditional" web apps, these features are foundational for vibrant categories like education and creative music applications. iOS Safari supports none of them today, while Chromium browsers on other OSes enable these apps on the web:

Web Bluetooth

Allows Bluetooth Low Energy devices to safely communicate with web apps, eliminating the need to download heavyweight applications to configure individual IoT devices.

Web MIDI

Enables creative music applications on the web, including synthesisers, mixing suites, drum machines, and music recording.

Web USB

Provides safe access to USB devices from the web, enabling new classes of applications in the browser from education to software development and debugging.

Web Serial

Supports connections to legacy devices. Particularly important in industrial, IoT, health care, and education scenarios.

Web Serial, Web Bluetooth, and Web USB enable educational programming tools to help students learn to program physical devices, including LEGO.

Independent developer Henrik Jorteg has written at length about frustration stemming from an inability to access these features on iOS, and has testified to the way they enable lower cost development. The lack of web APIs on iOS isn't just a frustration for developers. It drives up the prices of goods and services, shrinking the number of organisations that can deliver them.

Web HID

Enables safe connection to input devices not traditionally supported as keyboards, mice, or gamepads.

This API provides safe access to specialised features of niche hardware over a standard protocol they already support without proprietary software or unsafe native binary downloads.

Web NFC

Lets web apps safely read and write NFC tags, e.g. for tap-to-pay applications.

Shape Detection

Unlocks platform and OS provided capabilities for high-performance recognition of barcodes, faces, text in images and video.

Important in videoconferencing, commerce, and IoT setup scenarios.

Generic Sensors API

A uniform API for accessing sensors standard in phones, including Gyroscopes, Proximity sensors, Device Orientation, Acceleration sensors, Gravity sensors, and Ambient Light detectors.

Each entry in this inexhaustive list can block entire classes of applications from credibly being possible on the web. The real-world impact is challenging to measure. Weighing up the deadweight losses seems a good angle for economists to investigate. Start-ups not attempted, services not built, and higher prices for businesses forced to develop native apps multiple times could, perhaps, be estimated.

Incongruous #

The data agree: Apple's web engine consistently trails others in both compatibility and features, resulting in a large and persistent gap with Apple's native platform.

Apple wishes us to accept that:

- It is reasonable to force iOS browsers to use its web engine, leaving iOS on the trailing edge.

- The web is a viable alternative on iOS for developers unhappy with App Store policies.

One or the other might be reasonable. Together? Hmm.

Parties interested in the health of the digital ecosystem should look past Apple's claims and focus on the differential pace of progress.

Full disclosure: for the past twelve years I have worked on Chromium at Google, spanning both the pre-fork era where potential features for Chrome and Safari were discussed within the WebKit project, as well as the post-fork epoch. Over this time I have led multiple projects to add features to the web, some of which have been opposed by Safari engineers.

Today, I lead Project Fugu, a collaboration within Chromium that is directly responsible for the majority of the device APIs mentioned above. Microsoft, Intel, Google, Samsung, and others are contributing to this work, and it is being done in the open with the hope of standardisation, but my interest in its success is large. My front-row seat allows me to state unequivocally that independent software developers are clamouring for these APIs and are ignored when they request support for them from Apple. It is personally frustrating to be unable to deliver these improvements for developers who wish to reach iOS users — which is all developers. My interests and biases are plain.

Previously, I helped lead the effort to develop Service Workers, Push Notifications, and PWAs over the frequent and pointed objections of Apple's engineers and managers. Service Worker design was started as a collaboration between Google, Mozilla, Samsung, Facebook, Microsoft, and independent developers looking to make better, more reliable web applications. Apple only joined the group after other web engines had delivered working implementations. The delay in availability of Service Workers (as well as highly-requested follow-on features like Navigation Preload) for iOS users and developers interested in serving them well, likewise, carries an undeniable personal burden of memory.

1. iOS is unique in disallowing the web from participating in its only app store. macOS's built-in App Store has similar anti-web terms, but macOS allows multiple app stores (e.g. Steam and the Epic Store), along with real browser choice.

Android and Windows directly include support for web apps in their default stores, allow multiple stores, and facilitate true browser choice. ↩︎

2. Failing adequate staffing for the Safari and WebKit teams, we must insist that Apple change iOS policy to allow competitors to safely fill the gaps that Apple's own skinflint choices have created. ↩︎

3. Claims that I (or other Chromium contributors) would happily see engine homogeneity could not be more wrong. ↩︎

4. Some commenters appear to confuse unlike hardware for differences in software. For example, an area where Apple is absolutely killing it is CPU design. Resulting differences in Speedometer scores between flagship Android and iOS devices are demonstrations of Apple's domineering lead in mobile CPUs.

A-series chips have run circles around other ARM parts for more than half a decade, largely through gobsmacking amounts of L2/L3 cache per core. Apple's restrictions on iOS browser engine choice have made it difficult to demonstrate software parity. Safari doesn't run on Android, and Apple won't allow Chromium on iOS.

Thankfully, the advent of M1 Macs makes it possible to remove hardware differences from comparisons. For more than a decade, Apple has been making tradeoffs and unique decisions in cache hierarchy, branch prediction, instruction set, and GPU design. Competing browser makers are just now starting to explore these differences and adapt their engines to take full advantage of them.

As that is progressing, the results are coming back into line with the situation on Intel: Chromium is roughly as fast, and in many cases much faster, than WebKit.

The lesson for performance analysis is, as always, that one must always double-and-triple-check to ensure you actually measure what you hope to. ↩︎

5. Ten years ago, trailing-edge browsers were largely the detritus of installations that could not (or would not) upgrade. The relentless march of auto-updates has largely removed this hurdle. The residual set of salient browser differences in 2021 is the result of some combination of:

- Market-specific differences in browser update rates; e.g., emerging markets show several months of additional lag between browser release dates and full replacement

- Increasingly rare enterprise scenarios in where legacy browsers persist (e.g., IE11)

- Differences in feature support between engines

As other effects fade away, the last one comes to the fore. Auto-updates don't do as much good as they could when the replacement for a previous version lacks features developers need. Despite outstanding OS update rates, iOS undermines the web at large by projecting the deficiencies of WebKit's leading-edge into every browser on every iOS device. ↩︎

6. Perhaps it goes without saying, but the propensity for Firefox/Gecko to implement features with higher quality than Safari/WebKit is a major black eye for Apple.

A scrappy Open Source project without ~$200 billion in the bank is doing what the world's most valuable computing company will not: investing in browser quality and delivering a more compatible engine across more OSes and platforms than Apple does.

This should be reason enough for Apple to allow Mozilla to ship Gecko on iOS. That they do not is all the more indefensible for the tax it places on web developers worldwide. ↩︎

7. The data captured by MDN Browser Compatibility Data Respository and the caniuse database is often partial and sometimes incorrect.

Where I was aware they were not accurate — often related to releases in which features first appeared — or where they disagreed, original sources (browser release notes, contemporaneous blogs) have been consulted to build the most accurate picture of delays.

The presence of features in "developer previews", beta branches, or behind a flag that users must manually flip have not been taken into account. This is reasonable based on several concerns beyond the obvious: that developers cannot count on the feature when it is not fully launched, mooting any potential impact on the market:

- Some features linger for many years behind these flags (e.g. WebGL2 in Safari).

- Features not yet available on release branches may still change in their API shape, meaning that developers would be subject to expensive code churn and re-testing to support them in this state.

- Browser vendors universally discourage users from enabling experimental flags manually

↩︎

8. Competing engines led WebKit on dozens of features not included in this list because of the 3+ year lag cut-off.

The data shows that, as a proportion of features landed in a leading vs. trailing way, it doesn't much matter which timeframe one focuses on. The proportion of leading/lagging features in WebKit remains relatively steady. One reason to omit shorter time periods is to reduce the impact of Apple's lethargic feature release schedule.

Even when Apple's Tech Preview builds gain features at roughly the same time as Edge, Chrome, or Firefox's Beta builds, they may be delayed in reaching users (and therefore becoming available to developers) because of the uniquely slow way Apple introduces new features. Unlike leading engines that deliver improvements every six weeks, the pace of new features arriving in Safari is tied to Apple's twice-a-year iOS point release cadence. Prior to 2015, this lag was often as bad as a full year. Citing only features with a longer lag helps to remove the impact of such release cadence mismatch effects to the benefit of WebKit.

It is scrupulously generous to Cupertino's case that features with a gap shorter than three years were omitted. ↩︎

9. One effect of Apple's forced web engine monoculture is that, unlike other platforms, issues that affect WebKit impact every other browser on iOS too.

Not only do developers suffer an unwelcome uniformity of quality issues, users are impacted negatively when security issues in WebKit create OS-wide exposure to problems that can only be repaired at the rate OS updates are applied. ↩︎

10. The three-year delay in Apple implementing Pointer Events for iOS is in addition to delays due to Apple-generated licensing drama within the W3C regarding standardisation of various event models for touch screen input. ↩︎

11. During the drafting of this post, iOS 14.5 was released and with it, Safari 14.1.

In a bit good-natured japery, Apple initially declined to provide release notes for web platform features in the update.

In the days that followed, belated documentation included a shocking revelation: against all expectations, iOS 14.5 had brought WASM Threads! The wait was over! WASM Threads for iOS were entirely unexpected due to the distance WebKit would need to close to add either true Site Isolation or new developer opt-in mechanisms to protect sensitive content from side-channel attacks on modern CPUs. Neither seemed within reach of WebKit this year.

The Web Assembly community was understandably excited and began to test the claim, but could not seem to make the feature work as hoped.

Soon after, Apple updated it's docs and provided details on what was, in fact, added. Infrastructure that will eventually be critical to a WASM Threading solution in WebKit was made available, but it's a bit like an engine on a test mount: without the rest of the car, it's beautiful engineering without the ability to take folks where they want to go.

WASM Threads for iOS had seen their shadow and six more months of waiting (minimum) are predicted. At least we'll have one over-taxed CPU core to keep us warm. ↩︎

12. It's perverse that users and developers everywhere pay a tax for Apple's under-funding of Safari/WebKit development, in effect subsidising the world's wealthiest firm. ↩︎

13. Safari uses a private API not available to other iOS browsers for installing web apps to the home screen.

Users who switch their browser on iOS today are, perversely, less able to make the web a more central part of their computing life, and the inability for other browsers to offer web app installation creates challenges for developers who must account for the gap and recommend users switch to Safari in order to install their web experience. ↩︎

Hobson's Browser

How Apple, Facebook, and Google Broke the Mobile Browser Market by Silently Undermining User Choice

Updated:

This is part two of the six-part series "Browser Choice Must Matter"

Update: This post was turned into a talk for State of The Browser in October 2021; you can watch the recording here.

At first glance, the market for mobile browsers looks roughly functional. The 85% global-share OS (Android) has historically facilitated browser choice and diversity in browser engines. Engine diversity is essential, as it is the mechanism that causes competition to deliver better performance, capability, privacy, security, and user controls. More on that when we get to iOS.

Tech pundits and policymakers form expectations of browsers on the desktop and think about mobile browser competition the same way. To recap:

- Users can freely choose desktop browsers with differing features, search engines, privacy features, security properties, and underlying engines.

- Browsers update quickly, either through integrated auto-update mechanisms or via fast OS updates (e.g., ChromeOS).

- Browsers bundled with desktop OSes represent the minority of browser usage, indicating a healthy market for replacements.

- Popular native apps usually open links in users' chosen browsers and don't undermine the default behaviour of link clicks.[1]

Each point highlights a different aspect of ecosystem health. Together, these properties show how functioning markets work: clear and meaningful user choice creates competitive pressure that improves products over time. Users select higher quality products in the dimensions they care about most, driving quality and progress.

The mobile ecosystem appears to retain these properties, but the resemblance is only skin deep. Understanding how mobile OSes undermine browser choice requires a nuanced understanding of OS and browser technology. It's no wonder that few commenters are connecting the dots.[2]

How bad is the situation? It may surprise you to learn that until late last year only Safari could be default browser on iOS. It may further disorient you to know that competing vendors are still prevented from delivering their own engines on iOS. Meanwhile, on Android, the #2 and #3 sources of web traffic do not respect browser choice. Users can have any browser with any engine they like, but it's unlikely to be used. The Play Store is little more than a Potemkin Village of browser choice; a vibrant facade to hide the rot.

Registering to handle link taps is only half the battle. For a browser to serve as the user's agent, it must also receive navigations. Google's Search App and Facebook's various apps for Android undermine these choices in slightly different ways.[3] This reduces the effectiveness of privacy and security choices users entrust in their browsers. Developers also suffer higher costs and reduced opportunities to escape Google, Facebook, and Apple's walled gardens.

Web engineers frequently refer to browsers as "User Agents", a nod to their unique role as interpreters of developer intent that give users the final say over how the web is experienced. A silent erosion in the effectiveness of browser choice has transferred this power away from users, re-depositing it with dominant platforms and app publishers. To understand how this sell-out happened (quite literally) under our noses, we must look closely at how mobile and desktop differ.

The Baseline Scenario #

The predominant desktop situation is relatively straightforward:

Browsers handle links, and non-browsers defer loading http and https URLs to the system, which in turn invokes the default browser. This flow is the central transaction that gives links power and utility. If any of the players involved (OSes, browsers, or referring apps) violate aspects of the contract, user choice in browsers becomes less effective.

"What, then, is a 'browser'?" you might ask? I've got a long blog post brewing on this, but jumping to the end, an operable definition is:

A browser is an application that can register with an OS to handle http and https navigations by default.

On Android this is expressed via specific intent filters in the manifest and listing in the BROWSABLE category. iOS gained browser support in late 2020 (a dozen years late) via an Entitlement.[4] Windows and other Desktop OSes have similar (if less tidy) mechanisms.

No matter how an OS technically facilitates user choice, it's this ability to choose that defines browsers as a class. How often links lead users to their preferred browser controls the meaningfulness of this choice.

Thomas Steiner's excellent 🕵️ PWA Feature Detector

Android's "In-App Browser" Problem(s) #

The history of mobile computing starts from an incredibly resource-constrained point. First-generation iOS and Android smartphones were slow single-core, memory-impoverished affairs, leading mobile OSes to learn new tricks to facilitate responsive computing. Android and iOS adopted heuristics to kill and reclaim RAM used by non-foreground apps when resource pressure intensified.

This background task killing behaviour created unique problems for link-heavy apps. Launching the user's browser placed linking apps in the background, increasing friction in returning to the sending app, as browser UI did not provide affordances for returning to referring applications. Being put in the background also increases the likelihood of being killed.[5] Returning to the source app while in this state can feel excruciating. It can take seconds to re-start the original app and restore the UI state, an experience that gets worse on low-end devices that are most likely to evict apps in the first place.

Engagement-thirsty apps began including "In-App Browsers" ("IABs") to address these challenges. Contrary to any plain-language understanding of "a browser", these IABs cannot generally be installed as the default handler for links, even when OSes support browser choice. Instead, they load content referred by their hosting native app in system-provided WebViews.

The benefits to apps that adopt WebView-based IABs are numerous:

- WebViews are system components designed for use within other apps. They do not place embedders in the background where the system may kill them to reclaim resources. This reduces friction and commensurately increases "engagement" metrics.[6]

- As they are now "the browser", they can provide UI that makes returning to the host application easier than continuing on the web.

- Because they lean on the system-provided WebView component, they do not need to pay the expense of a heavier app download to support rendering HTML, running JavaScript, decoding images, or loading network resources.

- Apps can customise UI to add deeper integrations, e.g., "pinning" images from a hosted page to Pinterest.

- On Android today and early iOS versions, WebViews allow embedders to observe and modify all network traffic (regardless of encryption). Apps can also monitor user input, resulting DOM, and system auto-filled credentials.

To the extent that users are comfortable with apps not remembering their previously-stored passwords, login state, privacy preferences, extensions, or accessibility configurations, this can be a win-win.

Conversely, the web feels broken when any one of those conditions is not met.

Thanks to the light (bordering on non-existent) attribution back to the hosting app, along with disjoint and buried user controls to disable this misfeature, users may think the web isn't worth visiting, or that their browser broke.[7]

1...2...3...Party Time! #

WebViews are the source of much confusion in debates around apps and browser choice. Thankfully, the situation is only complicated rather than complex.

There are two dimensions in play:

- Can the app register with an OS to handle http/https navigations by default?

- If so, it's a browser regardless of the underlying engine.

- If not, it's something else; a "content renderer" or an IAB.

- Does the app include its own web engine?

- If so, it's integrated — e.g., an "Integrated Browser".

- If not, it's WebView-powered, e.g. a "WebView Browser" or "WebView IAB".

So, a browser can be WebView-based, and so can an IAB. But neither has to be.

What is a WebView? To quote the Android documentation, a WebView is...:

A View that displays web pages. ... In most cases, we recommend using a standard web browser, like Chrome, to deliver content to the user.

WebViews have a long history in mobile OSes, filling several roles:

- Rendering HTML on behalf of the first-party application developer.

- Displaying cooperating, second-party content like ads.

- Providing the core of browsers, whose job is to display third-party content. The original Android Browser used early-Android's system WebView, for instance.

The power dynamics of these situations are starkly different, even though "web technology" is used to render content in each case.

The use of a "raw" WebView is entirely appropriate for first and second-party content. Here, native apps are doing work related to their core function; storage and tracking of user data are squarely within the four corners of the app's natural responsibilities. Furthermore, the content developer is unlikely to find limits presented by the WebView to be unwelcome or unreasonably immutable (via collaboration with the app developer). Instead of breaking content, WebViews are likely to facilitate it in these scenarios faithfully.

All bets are off regarding WebViews and third-party content, however. To understand why it helps to know that WebViews are not browsers.

WebViews contain core browser features, along with hooks that allow embedders to "light up" many more. However, producing a complete and competitive WebView-based browser requires additional UI and glue code. In particular, features that require permission-gated access to privileged services need explicit support from embedders to work as specified.

Features in this category include:

- Privacy and site quality support, including "acceptable ads" enforcement and browser history clearing.

- Security indicators (TLS padlock, interstitial warnings, etc.)

- Basic navigation and window management features to (e.g. window.open() and <a target="_blank"> which are critical to some site monetization features).

- Friction reducing OS integrations such as:

- Web Payments (streamlined e-commerce checkout)

- Web OTP (for easier/faster sign-in)

- Web Share

- Hardware access APIs, notably:

- Geolocation

- Camera/mic (getUserMedia())

- Web Bluetooth

- WebUSB

- Web Serial

- WebHID

- WebMIDI

- Web NFC

- Filesystem Access

- Re-engagement features including:

- PWA installation and home screen shortcuts for sites

- Push Notifications

Few (if any) WebView browsers implement all of these features, even when their underlying WebViews support bindings for them.

The situation is even more acute in WebView IABs, which tend not to fully support features from these categories even when they appear available to developers via script. Worse, debugging from these IABs is challenging, compounded by a lack of awareness about how much traffic may come from these sources.

How can that be? Web developers are accustomed to real browsers in the desktop mould. Standard tools, analytics packages, and feature availability dashboards do not make mention of IABs, and the largest WebView IAB promulgators (Facebook, Pinterest, Snap, etc.) have invested almost nothing in clarifying the situation.

It's vital to understand that neither users nor developers chose Facebook, Pinterest, or Google Go as a browser. The flow that WebView IABs present denies users agency over their choices, and technical limits imposed by them often prevent developers from opening content in real browsers.

No documentation is available for third-party web developers from any of the largest WebView IAB (ab)users. This absence mirrors the scandalous free-riding of these app publishers regarding browser feature support, which is perhaps not surprising. It is, however, all the more egregious for the subtlety and scale of breakage.

If Facebook, the third largest "browser"-maker for Android, employs a single developer relations engineer or doc writer to cover these issues, I'm unaware of it. Meanwhile, forums are full of melancholy posts recounting myriad ways these submarine renderers break features that work in other browsers.

Having been given "the first 80%" of a browser, with development and distribution of critical components subsidised by OS vendors, WebView IABs near-universally fail to keep up their end of the bargain with either users or developers. First-party webdevs can collaborate with their app-development colleagues to build custom access for any exotic feature supported by the OS. Second-party developers expect less (ads are generally not given broad feature access). But third-party developers? They are as helpless as users are to understand why an otherwise browser-presenting environment appears subtly, yet profoundly, broken.

Avatar for firt

Maximiliano Firtman@firt

There are still users browsing with a Chrome 37 engine (7 years ago), not because they don't update their browsers but because it's Facebook Mobile Browser on Android 5 using a webview. Facebook does NOT honor user browser choice leaving that user with an old engine. +

Image from Tweet

5212:12 PM · Jul 15, 2021

These same app publishers request (and heavily use) features within real browsers they do not enable for others, even when spotted the bulk of the work. Perhaps browser and platform vendors should consider denying these apps access to capabilities they undermine for others.

WebView IAB User Harms #

The consequences of WebView IABs on developers are noteworthy, but it's the impacts on users that inspire confusion and rage.

Consider again the desktop reference scenario:

Clicking links from apps transfers control to an external browser which dutifully applies the user's stored preferences and accumulated state. Login credentials for example.com are not forgotten when a link is followed from an email. The same unified experience ensures that saved addresses and payment information are readily available. Most importantly, accessibility settings and privacy preferences are consistently applied.

Facebook's IAB features predictably dismal privacy, security, and accessibility settings. Disabling the IAB is <a href='https://twitter.com/slightlylate/status/1167548118876901376' target='_new'>Kafkaesque journey one must embark anew for each Facebook-made app on each device.</a> Kafkaesque journey one must embark anew for each Facebook-made app on each device.

By contrast, WebView IABs fracture user state, storing it in silos within each hosting application, creating a continuous partial amnesia.

The confusion that reliably results is the consequence of an inversion of the power relationship between apps and websites.

Does any user expect that everything one does on any website loaded from a link in the Facebook app, Instagram, or Google Go can be fully monitored by those apps? That all passwords shared and the full scope of sites visited from the first page can potentially be recorded and tracked?[8] To be clear, there's no record of these apps using this extraordinary access in overtly hostile ways, but even the unintended side-effects reduce user control over data and security.

Retaining onward links is not objectionable in programs that also offer themselves as browsers, but the WebView IAB sleight of hand is to act as a browser when users least expect it, but never to cop to the power and privacy implications of the responsibilities browsers accept.

CCT: A New Hope? #

Libraries emerged to facilitate the construction of WebView IABs, leading to a recognition by OS and browser vendors that users were becoming confused and developers irate.

To address this challenge, Apple introduced SFSafariViewController and Google followed suit with the inartfully-named Chrome Custom Tabs protocol and helper library. Both systems allow native app developers to skip the drudge work of building a WebView IAB system and instead work with the OS to invoke the user's default browser to load web pages within the context of the host app. Similarly to WebView IABs, CCT and SFSVC address background eviction and lost app state. However, because they invoke the user's actual browser, they also prevent user confusion whilst delivering the complete set of features supported by proper browsers.

These solutions come at the cost of some flexibility for app developers who lose access to read network traffic between users and third-party sites. They also cannot inspect and change page content trivially, removing the ability to add new, non-standard features to their IABs. Counterbalancing these concerns, CCT and SFSVC restore user choice[9] and ensure developers access to the complete set of browser features.

Et Tu, Google? #

CCT sounds pretty great, huh?

Well, it is. At least in the default configuration. Despite the clunky inclusion of "Chrome" in the name, the CCT library and protocol are browser-agnostic. A well-behaved CCT-invoking-app (e.g., Twitter for Android) will open URLs in the CCT-provided IAB-alike UI via Firefox, Brave, Samsung Internet, Edge, or Chrome if they are the system default browser.

That is unless the native app overrides the default behaviour and invokes a specific browser.

Avatar for AdaRoseCannon

Ada Rose Cannon@AdaRoseCannon

@slightlylate I recently was talking to my Dad about the Web and asked what browser he uses and he showed me what he does:

He searches for the Web site in the Google search widget and then just uses the results page Chrome tab as his entire browser.

His default browser is not set to Chrome.

506:21 PM · Jul 15, 2021

Who would do this, you might ask? None other than Google's own Search App; you know the one that comes on every reputable Android device via the ubiquitous home screen search widget.

AGSA's homescreen widget; the text box that launched two billion phones. Links followed from search results always load in Chrome via CCT, regardless which browser users have set as default.

Known as the "Android Google Search App" ("AGSA", or "AGA"), this humble text input is the source of a truly shocking amount of web traffic; traffic that all goes to Chrome, no matter the user's choice of browser.

There were justifiable reasons to add code like this. Early in the life of the CCT protocol, before support was widespread, many browsers exhibited showstopper bugs. 2021 is far advanced from those early days, however, and so the primary effect of calling to Chrome is to distort the market for browsers and undermine user choice. This behaviour subverts user privacy, undermines the ecosystem benefits of engine diversity, and makes it hard for alternative browsers to compete on a level playing field.

This situation is admittedly better than the wholesale neutering of important developer-facing features by WebView IABs, but a Hobson's Choice none the less.

<b>'Powered By Chrome'</b>: Google's Search App disregarding browser choice on a system with Samsung Internet set as the default browser.'Powered By Chrome': Google's Search App disregarding browser choice on a system with Samsung Internet set as the default browser.

WebLayer: New Frontiers In User Confusion #

Google can (and should) revert to the system default of affirmatively respecting user choice in browsers by deleting the offending choice override. Given that AGSA uses CCT to load web pages rather than a WebView, this is nearly trivial today. CCT's core design is sound and has enormous potential if made mandatory in place of WebView IABs by the Android and Play teams.

There's reason to worry that this is unlikely.

Instead of addressing frequent developer requests for features in the CCT library, the Chrome for Android team has invested heavily in the "WebLayer" project. You can think of WebLayer like a WebView-with-batteries-included, repairing issues related to missing features but continuing to fracture state and user choice.

There is a positive case for WebLayer: as a replacement for WebViews in the context of browsers, it's a major step forward. In the context of IABs, however, WebLayer looks set to entrench user-hostile patterns further.

This subversion of choice extends a dispiriting trend in search apps that fancy themselves browsers without even attempting to earn a user's business as a browser.

In addition to Google Go, the Google app for iOS as well as Microsoft's Bing app for Android both capture outbound links in WebView IABs, subverting both browser choice and feature availability for developers. If there's any mercy, it's that their relatively lower use somewhat limits their impact on the overall ecosystem. Adopting WebLayer will not meaningfully improve the user experience or privacy of these amnesiac browsing experiences.

Google and Apple have the chance to lead, to show they aren't hostile to users, and remove the permission structure for lousy behaviour that less scrupulous players exploit. More on that in a moment.

iOS's Outsized, Malign Influence #

Imagine if automakers could only use one government-mandated engine model across all cars and trucks. Different tires and upholstery only go so far. If the engine is underpowered, many tasks might not be possible, rendering whole vehicle classes pointless. If the engine is particularly polluting, choosing a different model of car can't help to reduce harmful emissions. That's the situation iOS creates for browser makers and the browser-downloading public, and the only recourse it to buy a phone running a different OS.

iOS matters because wealthy users carry iPhones. It's really as simple as that. Even when Apple's products fail to gain a numerical majority of users in a market, the margin contribution of iOS users can dominate all other business considerations.

From at least 2012, Apple has deigned to allow "competing browsers" in its App Store. Those applications could not be browsers in any meaningful sense as they could not supplant Safari as the default handler of http/https links. The long charade of choice without effect finally ended with the release of iOS 14.2 in late 2020, bringing iOS into line with every other significant OS in supporting alternative browsers.[10]

But Apple has taken explicit and extensive care to ensure that this choice is only ever skin deep on iOS. Browsers on Windows, Linux, ChromeOS, Android, and MacOS can be Integrated Browsers. iOS, meanwhile, restricts browsers to shells over the system-provided WebView.

Unlike WebView browsers on other OSes, Apple locks down these components in ways that prevent competition in additional areas, including restrictions on network stacks that block improved performance, new protocols, or increased privacy. These restrictions make some sense in the context of WebView IABs, but extending them to browsers only serves to deflect pressure from Apple to improve their browser.

Perhaps it would be reasonable for iOS to foreclose competition from integrated browsers and insist on uniquely constrained WebViews. Such policies would represent a different view of what computing should be if native apps were required to live within similar limits. However, Apple is happy to provide a much wider variety of features to unsafe native applications so long as they comply with the coercive terms of its App Store.

Integrated browsers present a model that, if allowed to flourish, pose a threat to the fundamentals of Apple and Google's whale-based, dopamine fueled, "casual" gaming monetisation rackets.

Unlike other native apps, integrated browsers are principally concerned with user safety. A safe-by-default, capable platform with low-friction discovery could obviate the core justification for app stores: that they're necessary to keep in check the over-powered-by-default apps built to an OS's proprietary platform.

Apple forestalls this bottom-line threat by keeping the web on iOS from gaining reasonable feature parity. Outlawing integrated browser choice leaves only Apple's own, farcially under-powered, Safari/WebKit browser/engine...and there's precious little that other WebView browsers can do to improve the situation at a deep level.[11]

Web developers are understandably livid:

Avatar for AdaRoseCannon

Ada Rose Cannon@AdaRoseCannon

Seeing a Web App I worked on used by *Apple* to justify that the Web is a viable platform on iOS is bullshit

The Web can be an ideal place to build apps but Apple is consistently dragging their heals on implementing the Web APIs that would allow them to compete with native apps twitter.com/stopsatgreen/status/1389593307219701760

70706:05 PM · May 4, 2021

Avatar for AdaRoseCannon

Ada Rose Cannon@AdaRoseCannon

In addition, by refusing to let any other Web browser engines run on iOS. They are preventing any other browser filling in the feature gap. Truly holding back Web Apps on iOS.

15806:05 PM · May 4, 2021

Avatar for AdaRoseCannon

Ada Rose Cannon@AdaRoseCannon

I have defended Apple's choice to restrict web browsers on their platform before and I still do but they can't have their cake and eat it to.

They should not hold back Web Apps with one hand and then turn around and say that Web Apps can compete with native apps.

15806:10 PM · May 4, 2021

Pointing to a site of serial developer mistreatment to justify other developer-hostile App Store policies takes next-level chutzpah.

Developer anger only hints at the underlying structural rot. 25+ years of integrated browser competition has driven waves of security, capability, and performance improvements. Competition has been so effective in delivering these benefits that browsers now represent most computing time on OSes with meaningful and integrated browser choice.

Hollowing out browser choice while simultaneously starving Safari and WebKit of resources, somewhat miraculously, put the genie back in the bottle. Privacy, security, performance, and feature evolution all suffer when the competition is less vibrant — and that's how Apple likes it.

Mark(et)d Impacts #

A vexing issue for commentators regarding Apple's behaviour in this area is that of "market definition". What observers should understand is that, in the market for browsers, the costs that a browser vendor can inflict on web developers extend far beyond the market penetration for their specific product.

A typical (but misleading) shorthand for this is "standards compliance". While Apple's engine falls woefully short on support for ratified standards, that isn't even the beginning of the negative impacts.[12] Because the web is an open, interoperable platform, web developers build sites to reach the vast majority of browsers from a single codebase.

When browsers with more than ~10% share fail to add a feature or exhibit nasty bugs, web developers must pay attention and work around these limitations. In the case of outright missing APIs, entire classes of content may simply be viewed as unworkable. The cost of these capability gaps is steep. When the web cannot deliver experiences that iOS native apps can (a very long list), businesses must build entirely different apps using Apple's proprietary tools. These apps, not coincidentally, can only be distributed via Apple's high-tax App Store.

A lack of meaningful user choice in browsers leads directly to higher costs for users and developers across the entire digital ecosystem even if they don't use Apple's products. The permission structure Apple's norm-eroding policies have constructed has served to justify some of the worst privacy and choice-undermining behaviour of tech giants. Apple's leadership in the race to the bottom has inspired a burgeoning field of fast-followers.

Beyond direct harms, interested parties should not consider browser choice as somehow orthogonal to other objectionable App Store policies; they are part and parcel of an architecture of control that tilts commerce into coercive, centralising App Stores. No matter how Apple wants to define the market, its actions distort and undermine competition.

Small Changes to Restore Choice #

Here's a quick summary of the systems and variations we've seen thus far, as well as their impacts on user choice:

System

Respects Choice

Notes

Integrated Browsers

Yes

Maximizes impact of choice

WebView Browsers

Yes

Reduces diversity in engines; problematic when the only option (iOS).

WebView IABs

No

Undermines user choice, reduces engine diversity, and directly harms developers through lower monetisation and feature availability (e.g., Facebook, Google Go).

Chrome Custom Tabs (CCT)

Partial

WebView IABs replacement, preserves choice by default (e.g. Twitter). Problematic when configured to ignore user preferences (e.g. AGA).

WebLayer

No

Like WebView with better feature support. Beneficial when used in place of WebViews for browsers. Problematic when used as a replacement for WebView IABs.

SFSafariViewController

Partial

Similar to CCT in spirit, but fails to support multiple browsers.

Proposals to repair this profoundly broken situation must centre first on the effectiveness of browser choice. Some policymakers have suggested returning to browser choice ballots, however these will not be effective in a world where user choice is undermined no matter which browser they choose. Interventions to encourage informed browser choice cannot have a positive effect until the impact of choices can be assured.

Thankfully, repairing the integrity of browser choice in the mobile ecosystem can be accomplished with relatively small interventions. We only need to ensure that integrated browsers are universally available and that when third-party content is displayed, user choice of browser is respected.

Android #

Repairing the IAB situation will likely require multiple steps, given the extreme delay in new Android OS revisions gaining a foothold in the market. Thankfully, many fixes don't need OS updates:

- Google should update the CCT system to respect browser choice when loading third-party content and require updates to CCT-using apps to this new behaviour within six months.

- Verification of first-party content for use with specific engines is possible thanks to the Digital Asset Links infrastructure that underpins Trusted Web Activities, the official mechanism for putting web apps in the Play Store.

- AGSA and Google Go should respect user choice via CCT.

- Android's WebView and WebLayer should be updated with code to detect a new HTTP header value sent with top-level documents that cause the URL to be opened in the user's default browser (or a CCT for that browser) instead.

- These systems update out-of-band every six weeks on 90+% of devices, delivering quick relief.

- As a straw-person design, the existing Content Security Policy system's frame-ancestors mechanism can be extended with a new 'system-default' value.

- Such an opt-out mechanism preserves WebViews for first-party and second-party use-cases (those sites will simply not set the new header) while giving third-parties a fighting chance at being rendered in the user's default browser.

- Apps that are themselves browsers (can be registered as default http/https handlers) would be exempt, preserving the ability to build WebView browsers. "Browserness" can be cheaply verified via an app's manifest.

- Google should provide access to all private APIs currently reserved to Chrome, including but not limited to the ability to install web applications to the system (a.k.a. "WebAPKs").

Future releases of Android should bolster these improvements by creating system-wide opt-out of WebView and WebLayer IABs.

Play policy enforcement of rules regarding CCT, WebView, and WebLayer respect for user and developer choice will also be necessary. Such enforcement is not challenging for Google, given its existing binary analysis infrastructure.

Together, these small changes can redress the worst anti-web, anti-user, anti-developer, and anti-choice behaviour of Google and Facebook regarding Android browsers, putting users back in control of their data and privacy along the way.

iOS #

iOS begins from a more troubling baseline but with somewhat better IAB policies. What's undermining user choice there require deeper, OS-level fixes, including:

- Integrated browser choice, including access to APIs that iOS restricts to Safari today, such as:

- The ability to create sandboxed subprocesses for renderers.

- Push Notifications APIs.

- Adding web apps to the home screen, including PWA installation.

- Support in Web.app for alternative engine runtimes to ensure that home screen shortcuts and PWAs run in the correct context.

- SFSafariViewController support for browsers other than Safari.

- All apps that load non-consenting third-party websites (outside of edge cases like authentication flows) in IABs should be required to update to SFSafariViewController,

- Apple's WebViews should support Content-Security-Policy: frame-ancestors 'system-default'

Allowing integrated browsers will require updates to Apple's App Store policies to clarify that alternative engines are permitted in the context of com.apple.developer.web-browser entitled applications.

For Markets To Work, Choice Must Matter #

The mobile web is a pale shadow of its potential because the vehicle of progress that has delivered consistent gains for two decades has silently been eroded to benefit native app platforms and developers. These attacks on the commons have at their core a shared disrespect for the sanctity of user choice, substituting the agenda of app and OS developers for mediation by a user's champion.

This power inversion has been as corrosive as it has been silent, but it is not too late. OSes and app developers that wish to take responsibility can start today to repair their own rotten, choice-undermining behaviour and put users back in control of their browsing, their data, and their digital lives.

The ball's in your court, platforms.

Deepest thanks to Eric Lawrence and Kevin Marks for their thoughtful feedback on drafts of this post.

1. Windows 10, for example includes several features (taskbar search box, lock screen links) that disrespect a user's choice of default browser. This sort of shortcut-taking in the competition for user attention has a long and discouraging history, but until relatively recently was viewed as "out of bounds". Mobile has shifted the Overton Window.

A decade of degraded norms around browser choice by mobile OSes has made these sorts of unreasonable tie-ins less exceptional. The work-a-day confusion of following links on mobile helps to create a permission structure that enables ever-more bad behaviour. The Hobbesian logic of power-begets-success is fundamentally escalatory, forcing those without a priori privilege into a paranoid mode, undercutting attempts to differentiate products in a market on their merits.

Fixing mobile won't be sufficient to unwind desktop's increasingly negative dark patterns, of course. But that's no reason to delay. Centering user's choices on their most personal devices can do much to reset the expectations of PMs and managers across the industry as to which tactics are, in fact, above-board. ↩︎

2. It's less clear why Mozilla is MIA in at least making noise about the situation. Their organisation has a front-row seat to the downsides of undermined user choice. The inability to project the benefits of their engine into the lives of their mobile users materially harms their future business and differentiation prospects.

It seems unlikely (if plausible) that the Firefox OS experience has so thoroughly burned management that there is no scope for mobile risk-taking, even if constrained to jawboning or blog posts.

If any organisation can credibly, independently connect the dots, it should be the Mozilla Foundation. One hopes they do. ↩︎

3. The history, competitive pressures, and norms of Android app developers caused many smaller apps to capture clicks (and user data), failing to send navigations onward.

A shortlist of notable apps that undermine user choice via IABs would include:

- Facebook Messenger

- Instagram

- Pinterest

- Snapchat

- Microsoft Bing Search

Some apps that previously (ab)used WebViews for IABs in the pre-CCT era switched over to that choice-respecting mechanism, notably Twitter. ↩︎

4. This definition of "a browser" may sit uncomfortably with folks accustomed to the impoverished set of choices Apple made possible on iOS until late last year. In particular, folks will undoubtedly note that "alternative browsers" were available in the App Store much earlier, including a Chrome-branded app since at least 2012.

Even ignoring Apple's ongoing anti-competitive and anti-web behaviour regarding engine choice, the presence of these apps in stores or on a device wasn't meaningful for users in the ways we understand browsers on every other successful OS.

Not all applications that can load web pages are browsers. Only apps that can become the user's agent in browsing the web are. Until nine months ago, iOS only supported Safari as a proper browser. "Alternative browsers" could only traverse link space when users began browsing within them. They were impotent to support users more broadly, unable to consistently assist users, modulate harmful aspects of content, or project user preferences into sites. Without the ability to catch all navigations sent to the OS, users who downloaded these programs suffered frequent computing amnesia. User preferences were only respected if users started browsing from within a specific app. Incidental navigations, however, were subject to Apple's monopoly on link handling and whatever choices Safari projected.

In this way, iOS undermined choice and competition. OSes that prevent users from freely picking their agent in navigating the web most of the time cannot, therefore, be said to support browser choice — no matter how many directed-browsing apps they allow to list in their stores. ↩︎

5. Problems related to background task killing can, of course, be avoided by building a web app instead of a native app one. When users remain in a browser across sites, there's no heavy process switch between pages. Developers tried this path for a while but quickly found themselves at an impossible feature disadvantage. Lack of Push Notifications alone proved business-defining, and Apple's App Store policies explicitly forbid web apps in their store.

To be discovered where users are looking for apps and access business-critical features, mobile platforms effectively forced all developers into app stores. A strong insinuation that things would not go well for them in app stores if they used web technologies (via private channels, naturally) reliably accompanied this Sophie's choice.

Platforms played these user-and-developer hostile games in mobile's early days to dig a moat of OS-exclusive apps. Exclusives create friction for users considering a switch to a different OS. Platform owners know the cost of re-developing apps for each OS means when independent software vendors invest heavily in their proprietary systems, it becomes less likely that those developers can deliver quality experiences on their competitor's system.

App developers only have so many hours in the day, and it costs enormous amounts, both initially and in an ongoing way, to re-build features for each additional platform. The web is a portable applications platform, and portability is a bug to proprietary platform owners. The combination of engine neglect, feature gap expansion, and app store policies against web participation — explicit and implied — proved a shockingly effective "fix".

This motivation eventually gave way to a second, more lucrative raison d'etre: rent extraction from a very narrow class of social games and the users addicted to them.

The story of feature-gap coercion and "app store lottery" games illuminate the backdrop of a new normal that none of us should accept. ↩︎

6. Many have adroitly covered the perspective and ethical distortions within social media firms caused by the relentless pursuit of "north star" metrics. There's little new I can add.

I can, however, confirm some uncharitable takes of their detractors are directionally correct. One cannot engage with engineers and PMs from these organisations for a decade without learning something about their team's values.

The blinkered pursuit of growth via "make number go up"-OKRs creates blind spots that are managed as exogenous crises. The health of the ecosystems around them is unfailingly subordinate to questions of competitive positioning. The hermetically circular logic of "we're changing the world for the better" does create incentives to undermine user autonomy, safety, and choice.

The jury is no longer out. Change is possible, but it will not come from within. But "unintended consequences!" special pleading weighs heavily. To improve this situation, folks must understand it sufficient depth to mandate maximally effective, competition-and-choice-enhancing interventions that carry the lightest footprint.

In the long list of dangerous, anti-competitive, opacity-increasing ills of modern tech products, the hollowing out of browser choice may seem small-time. Issues of content recommendation radicalisation, "persuasive design" dark patterns, source-of-funds ads opacity, and buried data collection controls surely deserve more attention. However, it would be a missed opportunity not to put users back in control of this aspect of their digital lives whilst the opportunity presents itself. ↩︎

7. Social apps strip-mining ecosystems they didn't build for their benefit while deflecting responsibility for downside consequences?

Heaven forfend! ↩︎

8. Facebook engineers have noted that the FB IAB is important in fighting bad behaviour on their social network. We should take these claims at face value.

Having done so, several further questions present themselves:

- Why, then, is this system not opt-in? Presumably Facebook can convince a representative subset of users to enable it while preserving browser choice for the vast majority.

- Why is CCT not invoked for low risk origins?

- Why is Facebook not publicly attempting to improve CCT and SFSVC in ways that can meets its needs, given they may be required to move to SFSafariViewController for iOS

- Why is this not a game-over problem for Facebook's desktop website?

- If it's necessary to keep users within a browser that Facebook owns end-to-end, why not simply allow Facebook's native apps to be browsers. It's a simple Android manifest change that would put them back into line with the norms and expectations of the broader web community and allow them to compete for user's browsing time on the up-and-up. Not doing so suggests they have something to hide and may be ashamed of this browser that, by their calculations, keeps users safer.

The need for more information to protect users may be real, but undermining choice for all is a remedy that, at least with the information that's public thus far, seems very tough to justify. ↩︎

9. iOS didn't support browser choice at the time of SFSafariViewController's introduction and appeared only to have acquiesced to minimal (and initially broken) browser choice under regulatory duress. It is hardly surprising, then, that Apple hasn't updated SFSafariViewController to work with other default browsers the way CCT does.

Will they? Doubtful, at least not until someone makes serious, sustained noise. Goodness knows there's a lot on the backlog, and they're chronically short-staffed (by choice). ↩︎

10. Yes, even ChromeOS supports changing the default browser, complete with engine choice! ↩︎

11. The supine position of browser makers to Apple's unjust, anti-competitive prohibition on integrated iOS browsers is vexing.

For reasons that seem to boil down to Great Power calculations and myopic leadership focus on desktop, none of the major browser vendors has publicly challenged these rules or the specious, easily-debunked arguments offered to support them.

To recap, Apple has at various points argued that the blatantly anti-competitive policies against integrated browsers are necessary because Apple cannot allow programs to run Just-In-Time (JIT) compilers for languages like JavaScript due to safety concerns. Apple's WebKit framework is the only program on the system allowed to contain such a JIT.

JITs are central to modern JavaScript engines but are not strictly necessary in integrated browsers. Disallowing non-JITing alternative engines on this basis is nonsensical.

Commenters forwarding these claims, as a rule, do not understand browser architecture. Any modern browser can suffer attacks against the privileged "parent" process, JIT or not. These "sandbox escapes" are not less likely for the mandated use of WebKit; indeed, by failing to expose APIs for sandboxed process creation, Apple prevents others from bringing stronger protections to users. iOS's security track record, patch velocity, and update latency for its required-use engine is not best-in-class.

Apple's right to worry about engine security. Any vendor as frequently exploited by their browser engine would be. It is, however, backwards to under-invest here while simultaneously preventing more secure, more capable browsers from protecting users in the (long-running) breech. Apple's multi-year delay in shipping an allegory for Site Isolation should indicate to observers how unserious these arguments are.

User security would be meaningfully improved were Apple to allow integrated browsers that demonstrated an Apple-esqe-or-better patch velocity. Such a policy is not hard to formulate, and the ability for apps running on top of the OS to update without slow, painful-for-users update processes would meaningfully improve patch rates versus today's OS-update-locked cadence for WebKit.

Some commenters claim that browsers might begin to provide features that some users deem (without evidence) unnecessary or unsafe if alternative engines were allowed. These claims are doubly misinformed.

Alternative WebView browsers can already add features through JavaScript monkey-patching. There's no substantive security or privacy benefit in forcing browser vendors to re-build them in a contorted (but still allowable) way on top of WebViews. Indeed, bringing an integrated engine to iOS would do much to prevent one-off security issues that have been a frequent occurrence in such WebView browser feature extensions. Securing a single codebase is more straightforward than having to analyse multiple platform-specific workarounds. Engine choice will improve security, in part, by focusing limited security reviewer time on fewer attack vectors. Of course, a functioning market for browsers will still allow users to pick from under-powered, less secure, slower-updating, feature-light browsers as they can today; Safari, for example.

Misdirection about JITs and per-feature security posture are technically wanting but serve ably distract from iOS's deeper restrictions. Capable integrated browsers need access to a suite of undocumented APIs and capabilities Apple currently reserves to Safari, including the inability to create processes, set tighter sandboxing boundaries, or efficiently decode alternative media formats. Opening these APIs to competing integrated browsers would pave the way to safer, faster, more capable computing for iPhone owners.

Others have argued on Apple's behalf that if engine competition were allowed, Chromium's (Open Source) Blink engine would become ubiquitous on iOS, depriving the ecosystem of diversity in engines. This argument is seemingly offered with a straight face to defend the very policies that have prevented effective engine diversity to date. Mozilla ported Gecko twice, but was never allowed to bring its benefits to iOS users. In addition to being self-defeating regarding engine choice, this fear also seems to ignore the best available comparison points. Safari is the default browser for MacOS and has maintained a healthy 40-50% share for many years, despite healthy competition from other integrated browsers (Chrome, Firefox, Opera, Edge, etc.). Such an outcome is at least as likely on iOS.

Sitting under all of these arguments are, I suspect, more salient concerns to Apple's executives to resist increasing RAM in the iPhone's Bill of Materials. In the coerced status quo, Apple can drive device margins by provisioning relatively little in the way of (expensive) RAM components while still supporting multitasking. A vital aspect of this penny-pinching is to maximise sharing of "code pages" between programs. If alternative browsers suddenly began bringing their engines, code page sharing would not be as effective, requiring more RAM in Apple's devices to provide good multitasking experiences. More RAM could help deliver increased safety and choice to users, but would negatively impact Apple's bottom line.

Undermining user choice in browsers has, in this way, returned significant benefits — to AAPL shareholders, anyway. ↩︎

12. Engine developers possess outsized ability within standards bodies to deny new features and designs the ability to become standards in the first place. The Catch-22 is easy to spot once you know to look for it, but casual observers are often unacquainted with the way feature development on the web works.

In a nutshell, its often the case features are shipped by browsers ahead of final, formal inclusion in web standards. Specifications are documents that describe the working of a system. Some specifications are ratified by Standards Development Organisations (SDOs) like the World Wide Web Consortium (W3C) or Internet Engineering Task Force (IETF) as "web standards". Thanks to wide implementation and unambiguous IP licensing, standards increase market confidence and adoption of designs. But no new feature's specification begins life as a standard.

Market testing of proposed standards ("running code" in IETF-speak) are essential for the progress of any platform, and pejorative claims that a feature in this state is "proprietary" is misleading. This bleeds into active deception when invoked by other vendors who neither propose alternatives to solve developer challenges nor participate in shaping proposals in open collaboration.

Withholding engagement, then claiming that someone else is proceeding unilaterally — when your input would remove the stain — is a rhetorical Möbius strip. ↩︎

Next: "The Core Web Platform Loop"

Previously: "Git Worktrees Step-By-Step"

iOS Engine Choice In Depth

Updated:

This is part three of the six-part series "Browser Choice Must Matter"

Update (September 25th, 2021): Commenters appear confused about Apple's many options to ensure safety in a world of true browser competition, s and all. This post has been expanded to more clearly enunciate a few of these alternatives.

Update (April 29th, 2022): Since this post was first published, Google's Project Zero released an overview of their findings regarding the trend of browser security. This post has been updated to capture their finding that iOS and Safari continues to lag the industry in delivering fixes to issues that Project Zero finds.

Recent posts here covering the slow pace of WebKit development and ways the mobile browser market has evolved to disrespect user choice have sparked conversations with friends and colleagues. Many discussions have focused on Apple's rationales, explicit and implied, in keeping the iOS versions of Edge, Firefox, Opera, and Chrome less capable and compatible than they are on every other platform.

How does Apple justify such a policy? Particularly since last winter, when it finally (ham-fistedly, eventually) became possible to set a browser other than Safari as the default?

Two categories of argument are worth highlighting: those offered by Apple and claims made by others in Apple's defence.[1]

- Apple's Arguments

- Apple's Security Argument

- Just-In-Time Pretexts

- Diversity Perversity

- End Notes

Apple's Arguments #

The decision to ban competing browser engines is as old as iOS, but Apple has only attempted to explain itself recently and only when compelled:

- Apple's 2019 response to the U.S. House Judiciary Committee's Subcommittee on Antitrust, Commercial and Administrative Law (PDF)

- Apple's February 2021 response to the Australian Competition & Consumer Commission (PDF)

- 2021 court arguments in the case of EPIC Games vs. Apple (slide image)

Apple's lawyers <a href='https://twitter.com/slightlylate/status/1389647183457124353?s=20'>mangled a screen capture of the Financial Times (<abbr>FT</abbr>) web app to cover for a deficit of features in Safari and WebKit</a>, inadvertently setting the tone. mangled a screen capture of the Financial Times () web app to cover for a deficit of features in Safari and WebKit, inadvertently setting the tone.

Experts tend to treat Apple's arguments with disdain, but this skepticism is expressed in technical terms that can obscure deeper issues. Apple's response to the U.S. House Antitrust Subcommittee includes its fullest response and it provides a helpful, less-technical framing to discuss how browser engine choice relates to power over software distribution:

4. Does Apple restrict, in any way, the ability of competing web browsers to deploy their own web browsing engines when running on Apple's operating system? If yes, please describe any restrictions that Apple imposes and all the reasons for doing so. If no, please explain why not.

All iOS apps that browse the web are required to use "the appropriate WebKit framework and WebKit Javascript" pursuant to Section 2.5.6 of the App Store Review Guidelines <https://developer.apple.com/app-store/review/guidelines/#software-requirements>.

The purpose of this rule is to protect user privacy and security. Nefarious websites have analysed other web browser engines and found flaws that have not been disclosed, and exploit those flaws when a user goes to a particular website to silently violate user privacy or security. This presents an acute danger to users, considering the vast amount of private and sensitive data that is typically accessed on a mobile device.

By requiring apps to use WebKit, Apple can rapidly and accurately address exploits across our entire user base and most effectively secure their privacy and security. Also, allowing other web browser engines could put users at risk if developers abandon their apps or fail to address a security flaw quickly. By requiring use of WebKit, Apple can provide security updates to all our users quickly and accurately, no matter which browser they decide to download from the App Store.

WebKit is an open-source web engine that allows Apple to enable improvements contributed by third parties. Instead of having to supply an entirely separate browser engine (with the significant privacy and security issues this creates), third parties can contribute relevant changes to the WebKit project for incorporation into the WebKit engine.

Let's address these claims from most easily falsified to most contested.

Apple's Open Source Claim #

The open source nature of WebKit is indisputable as a legal technicality. Anyone who cares to download and fork the code can do so. To the extent they are both skilled in browser construction and have the freedom to distribute modified binaries, WebKit's source code can serve as the basis for new engines. Anyone can fork WebKit and improve it, but they cannot ship enhancements to iOS users of their products.

Apple asserts this is fine becase WebKit's openness extends to open governance regarding feature additions. It must know this is misleading.

Presumably, Apple's counsel included this specious filigree to distract from the reality that Apple rarely accepts outside changes that push the state of the art forward. Here I speak from experience.

From 2008 to 2013, the Chromium project was based on WebKit, and a growing team of Chrome engineers began to contribute heavily "upstream." I helped lead the team that developed Web Components. Our difficulty in trying to develop these features in WebKit cannot be overstated. The eventual Blink fork was precipitated by an insurmountable difficulty in doing precisely what Apple suggested to Congress: contributing new features to WebKit.

The differing near-term objectives of browser teams often make potential additions contentious, and only competition has been shown to reliably drive consensus. Every team has more than enough to do, and time spent even considering new features can be seen as a distraction. Project owners fiercely guard the integrity of their codebases. Until and unless they become convinced of the utility of a feature, "no" is the usual response. If there is no competition to force the issue, it can also be the final answer.

Browser engines are large projects, necessitating governance through senior engineer code review. There tend to be very few experts empowered to do reviews in each area relative to number of engineers contributing code.

It's inevitable that managers will communicate disinterest in continuing collaboration if they find their most senior engineers spending a great deal of time reviewing code for features they have no interest in and will disable ("flag off") in their own products[2]. The pace of code reviews needed to finish a feature in this state can taper off or dry up completely, frustrating collaborators on both sides.

When browsers provide their own engines (an "integrated browser"), then it's possible to disagree in standards venues, return to one's corner, and deliver their best design to developers (responsibly, hopefully). Developers can then provide feedback and lobby other vendors to adopt (or re-design) them. This process can be messy and slow, but it never creates a political blockage for developing new capabilities for the web.

WebKit, by contrast, has in recent years gone so far as to publicly, pre-emptively "decline to implement" a veritable truckload features that some vendors feel are essential and would be willing to ship in their products.

The signal to parties who might contribute code for these features could scarcely be clearer: your patch is unlikely to be accepted into WebKit.

Suppose by some miracle a "controversial" feature is merged into WebKit. This is no gaurantee that iOS browsers will gain access to it. Features in this state have lingered behind flags for years, ensuring they are not available in either Safari or competing iOS browsers.

When priority disagreements inevitably arise, competing iOS browsers cannot reliably demonstrate a feature is safe or well received by web developers by contributing to WebKit. Potential sponsors of this work won't dare the expense of an attempt. Apple's opacity and history of challenging collaboration have done more than enough to discourage ambitious participants.

Other mechanisms for extending features of third party browsers may be possible (in some areas, with low fidelity; more on that below), but contributions to WebKit are not a viable path for a majority of potential additions.

It is shocking, but unsurprising, that Apple felt compelled to mislead Congress on these points. The facts are not in their favour, but few legislative staffers have enough context to see through debates about browser internals.

Apple's Security Argument #

The most convincing argument in Apple's 2019 response to the U.S. House Judiciary Committee is rooted in security. Apple argues it bans other engines from iOS because:

Nefarious websites have analysed other web browser engines and found flaws that have not been disclosed, and exploit those flaws when a user goes to a particular website to silently violate user privacy or security.

Like all browsers, WebKit and Safari are under constant attack, including the construction of "zero day" attacks that Apple insinuates WebKit is immune to.

As a result of this threat landscape, responsible browser vendors work to put untrusted code (everything downloaded from the web) in "sandboxes"; restricted execution environments that are given fewer privileges than regular programs. Modern browsers layer protections on top of -level sandboxes, bolstering the default configuration with further limits on "renderer" processes.

Some engines go further, adopting safer systems languages and aggressive mitigations in their first lines of defence, in addition to more strictly isolating individual websites from each other. None of these protections were in place for iOS users in the most recent Solar Winds incident thanks to Apple's policy against engine choice, even for folks using browsers other than Safari.

The incredibly powerful devices Apple sells provide more than enough resources to raise such software defences, yet iOS users are years behind in recieving them and can't access them by switching browser. Apple's under-investment in security combine with its uniquely anti-competitive polices to ensure these gaps cannot be filled, no matter how contientious iOS users are about their digital hygiene.

Leading browsers are also adopting more robust processes for closing the "patch gap". Since all engines contain latent security bugs, precautions to insulate users from partial failure (e.g., sandboxing), and the velocity with which fixes reach end-user devices are paramount in determining the security posture of modern browsers. Apple's rather larger patch gap serves as an argument in favour of engine choice, all things equal. Cupertino's industry-lagging pace in adding additional layers of defence do not inspire confidence, either.

This brings us to the final link in the chain of structural security mitigations: the speed of delivering updates to end-users. Issues being fixed in the source code of an engine's project has no impact on its own; only when those fixes are rolled into new binaries and those binaries are delivered to user's devices do patches become fixes.

Apple's reply hints at the way its model for delivering fixes differs from all of its competitors:

[...] By requiring apps to use WebKit, Apple can rapidly and accurately address exploits across our entire user base and most effectively secure their privacy and security.

[...]

By requiring use of WebKit, Apple can provide security updates to all our users quickly and accurately, no matter which browser they decide to download from the App Store.

Aside from Chrome OS (and not for much longer), I'm aware of no modern browser that continues the medieval practice of requiring users download and install updates to their Operating System to apply browser patches. Lest Chrome OS's status quo seem a defence of iOS, know that the cost to end-users of these updates in terms of time and effort is night-and-day, thanks to near-instant, transparent updates on restart. If only my (significantly faster) iOS devices updated this transparently and quickly!

Unlike browsers on every other major OS, updates to Safari are a painful affair, often requiring system reboots that take tens of minutes, providing multiple chances to re-take this photo.

Lower-friction updates lead to faster patch application, keeping users safer, and Chrome OS is miles ahead of iOS in this regard.

All other browsers update "out of band" from the , including the WebView system component on Android. The result is, that for users with equivalent connectivity and disk space, out-of-band patches are installed on the devices significantly faster.

This makes intuitive sense: iOS update downloads are large and installing them can disrupt using a device for as much as a half hour. Users are understandably hesitant to incur these interruptions. Browser updates delivered out-of-band can be smaller and faster to apply, often without explicit user intervention. In many cases, simply restarting the browser delivers improved security updates.

Differences in uptake rates matter because it's only by updating a program on the user's devices that fixes can begin to protect users. iOS's high friction engine updates are a double strike against its security posture; albeit ones Cupertino has attempted to spin as a positive.

The philosophical differences underlying software update mechanisms run deep. All other projects have learned through long experience to treat operating systems as soft targets that must be defended by the browser, rather than as the ultimate source of user defence. To the extent that the  is trustworthy, that's a "nice to have" property that can add additional protection, but it is not treated as a fundamental protection in and of itself. Browser engineers outside the WebKit and Safari projects are habituated to thinking of  components as systems not designed for handling unsafe third-party input. Mediating layers are therefore built to insulate the  from malicious sites.

Apple, by contrast, tends to rely on  components directly, leaning on fixes within the  to repair issues which other projects can patch at a higher level. Apple's insistence on treating the  as a single, hermetic unit slows the pace of fixes reaching users, and results in reduced flexibility in delivering features to web developers. While iOS has decent baseline protections, being unable to layer on extra levels of security is a poor trade.

This arrangement is, however, maximally efficient for Apple in terms of staffing. But is  cost efficiency for Apple the most important feature of a web engine? And shouldn't users be able to choose engines that are willing to spend more on engineering to prevent latent  issues from becoming security problems? By maintaining a thin artifice of perfect security, Apple's iOS monoculture renders itself brittle in the face of new threats, leaving users without the benefits of the layered paranoia that the most secure browsers running on the best es can provide.[3] As we'll see in a moment, Apple's claim to keep users safe when using alternative browsers by fusing engine updates to the  is, at best, contested.

Instead of raising the security floor, Apple has set a cap while breeding a monoculture that ensures all iOS browsers are vulnerable to identical attacks, no matter whose icon is on the home screen.

Preventable insecurity, iOS be thy name.

Update: In February 2022, Google's Project Zero posted a report on the metrics they track regarding product bug and patch rates. This included a section on browsers, which included the following — incredibly damning — chart:

To quote the post: 'WebKit is the outlier in this analysis, with the longest number of days to release a patch at 73 days.'

Introducing Apple to developer.apple.com #

Given Apple's response to Congress, it seems Cupertino is unfamiliar with the way iOS browsers other than Safari are constructed. Because it forbids integrated browsers, developers have no choice but to use Apple's own APIs to construct message-passing mechanisms between the privileged Browser Process and Renderer Processes sandboxed by Apple's WebKit framework.

A <a href='https://blogs.windows.com/msedgedev/2020/09/30/microsoft-edge-multi-process-architecture/'>diagram from the Edge Team's explanation of modern browser process relationships</a>. diagram from the Edge Team's explanation of modern browser process relationships.

These message-passing systems make it possible for WebKit-based browsers to add a limited subset of new features, even within the confines of Apple's WebKit binary. With this freedom comes the exact sort of liabilities that Apple insists it protects users from by fixing the full set of features firmly at the trailing edge.

To drive the point home: alternative browsers can include security issues every bit as severe as those Apple nominally guards against because of the side-channels provided by Apple's own WebKit framework. Any capability or data entrusted to the browser process can, in theory, be put at risk by these additional features.

More troublingly, these features are built in a way that is different to the mechanisms used by browser teams on every other platform. Any browser that delivers a feature to other platforms, then tries to bring it to iOS through script extensions, has doubled the security analysis and attack surface area.

None of this is theoretical; needing to re-develop features through a straw, using less-secure, more poorly tested and analyzed mechanisms, has led to serious security issues in alternative iOS browsers. Apple's policy, far from insulating responsible WebKit browsers from security issues, is a veritable bug farm for the projects wrenched between the impoverished feature set of Apple's WebKit and the features they can securely deliver with high fidelity on every other platform.

This is, of course, a serious problem for Apple's argument as to why it should be exclusively responsible for delivering updates to browser engines on iOS.

The Abandonware Problem #

Apple cautions against poor browser vendor behaviour in its response, and it deserves special mention:

[...] Also, allowing other web browser engines could put users at risk if developers abandon their apps or fail to address a security flaw quickly.

Ignoring the extent to which WebKit represents precisely this scenario to vendors who would give favoured appendages to deliver stronger protections to their users on iOS, the justification for Apple's security ceiling has a (very weak) point: browsers are a serious business, and doing a poor job has bad consequences. One must wonder, of course, how Apple treats applications with persistent security issues that aren't browsers. Are they un-published from the App Store? And if so, isn't that a reasonable precedent here?

Whatever the precedent, Apple is absolutely correct that browsers shouldn't be distributed without commitments to maintenance, and that vendors who fail to keep the pace with security patches shouldn't be allowed to degrade the security posture of end-users. Fortunately, these are terms that nearly every reputable browser developer can easily agree to.

Indeed, reputable browser vendors would very likely be willing to sign up to terms that only allow use of the (currently proprietary and private) APIs that Apple uses to create sandboxed renderer processes for WebKit if their patch and -fix rates matched some reasonable baseline. Apple's recently-added Browser Entitlement provides a perfect way to further contain the risk: only browsers that can be set as the system default could be allowed to bring alternative engines. Such a solution preserves Apple's floor on abandonware and embedded WebViews without capping the potential for improved experiences.

There are many options for managing the clearly-identifiable case of abandonware browsers, assuming Apple managers are genuinely interested solutions rather than sandbagging the pace of browser progress. Setting high standards has broad support.

Just-In-Time Pretexts #

An argument that Apple hasn't made, but that others have derived from Apple's App Store Review Guidelines and instances of rejected app submissions, including Just-In-Time Compilers (s), has been that alternative browser engines are forbidden on iOS because they include JITs.

The history of this unstated policy is long, winding, and less enlightening than a description of the status quo:

- All major browser engines support both a  "fast path" for running JavaScript, as well as an "interpreted mode" that trades a s large gains in execution speed for faster start-up and lower memory use.

- compilers are frequent sources of bugs, and a key reason why all responsible browser vendors put code downloaded from the web in sandboxes.

- Other iOS applications can embed non-ing interpreters for JavaScript, if they like.

- Safari on iOS had  for many years, whereas competing browsers were prevented from approaching similar levels of performance. More recently, WebView browsers on iOS have been able to take advantage of WebKit's -ing JavaScript engine, but are prevented from bringing their own.

An <a href='https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO45JZNB1QZF9wuijK3OxBwr0/edit#gid=865365202'>analysis from Mozilla</a> shows that <abbr>JIT</abbr>s are a frequent source of browser bugs, and how some browsers are <a href='https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/'>actively looking for ways to reduce the scope of their use</a>. analysis from Mozilla shows that s are a frequent source of browser bugs, and how some browsers are actively looking for ways to reduce the scope of their use.

In addition to WebKit's lack of important JavaScript engine features (e.g. WASM Threads) and protections (Site Isolation), Apple's policy makes little sense on its visible merits.

Obviously, the speed delivered by s is important in browser competition, but it's also a fallacy to assume competitors wouldn't prefer the freedom to improve the performance, compatibility, and capabilities of the rest of their engines because they might not be able to  JavaScript. Every modern browser can run without a , and many would prefer that to being confined to Apple's trailing-edge, low-quality engine.

So what does the prohibition on s actually accomplish?

As far as I can tell, disallowing other engines and their -ing JavaScript runtimes mints Apple (but not users) two key benefits:

- Allowing other engines would mean providing access to the currently-private APIs that allow the creation of sandboxed subprocesses.[4]

- Re-using the WebKit binary maximizes the sharing of "code pages" across processes. Practically speaking, this allows more programs to run simultaneously without the need for Apple to add more RAM to their devices. This, in turn, pads Apple's (considerable) margins in the construction of phones.

Blessing Safari as the only app allowed to mint sandboxed subprocesses, while preventing other from doing so, is clearly unfair. This one-sided situation has persisted because the details of sandboxing and process creation have been obscured by a blanket prohibition on alternative engines. Should Apple choose (or be required) to allow higher-quality engines, this private API should surely be made public, even if it's restricted to browsers.

Similarly, skimping on RAM in thousand-dollar phones seems a weak reason to deny users access to faster, safer browsers. The Chromium project has a history of strengthening the default sandboxes provided by es (including Apple's), and would no doubt love the try its hand at improving Apple's security floor qua ceiling.

The relative problems with  for opening the field to vendors who will to put in the work Apple has not to protect users. If the net result is that Cupertino sells safer devices while accepting a slightly lower margin (or an even more eye-watering price) on its super-premium devices, what's the harm? And isn't that something the market should sort out?

High-modernism may mean never having to admit you're wrong, but it doesn't keep one from errors that functional markets would discipline. You do learn about them, but at the greatest of delays.

Policy Options #

Apple may genuinely believe it is improving security by preventing other engines, not just padding its bottom line. For instance, beyond the abandonware problem, what of threats from "legitimate" browsers that abuse JIT priviledges? Or vendors that drag their heels in responding to security issues?

No OS vendor wants third parties exposing users to risks it feels helpless to mitigate. Removing browsers from user's devices is an existing option, but would be a drastic step that raises serious governance questions about the power Apple wields (and on whose behalf).

As middle-ground policy options go, Apple is far from helpless.

It has already created a bright line between browsers and other apps that embed WebViews, thanks to the Browser Entitlement, and could continue to require the latter use Apple's system-provided WebKit.

For browsers slow to fix security bugs, there also options short of dissalowing other engines and their . Every engine on the market today also contains a non-ing mode. Apple could require that vendors submit both ful and less builds for each version they wish to publish and could, as a matter of policy and with warning, update user devices with non-ing versions of these browsers should users be opened to widespread attack through vendor negligence.

In the process of opening up the necessary private APIs to build truly competitive browsers, Apple can set design quality standards. For example, if Apple's engine uses a now-private mechanism to ensure that code pages are not both writeable and executable, it could require other engines adopt the same techniques. Apple could further compel vendors to aggressively adopt protections from new hardware capabilities (e.g. Control Flow Integrity (pdf)) as it releases them.

Lastly, Apple can mandate all code loaded into sandboxed renderer processes be published as open source, along with build configurations, so that Apple can verify the supply chain integrity of browsers granted these capabilities.

Apple can maintain protections for users in the face of competition. Hiding behind security concerns to deny its users access to better, safer, faster browsers is indefensible.

Diversity Perversity #

A final argument made by others, (but not by Apple who surely knows better), is that:

- Diversity in browser engines is desirable because, without competition, there is little reason for engines to keep improving.

- Apple's restrictions on iOS ensure that a heavily-used engine has a different codebase to the growing use of Blink/Chromium in other browsers.

- Therefore, Apple's policies are — despite their clear restrictions on engine choice — promoting the cause of engine diversity.

This is a slap-dash line of reasoning along several axes.

First, it fails to account for the different sorts of diversity that are possible within the browser ecosystem. Over the years, developers have suffered mightily under the thumb of entirely unwanted engine diversity in the form of trailing-edge browsers; most notably Internet Explorer 6.

The point of diversity and competition is to propel the leading edge forward by allowing multiple teams to explore alternative approaches to common problems. Competition at the frontier enables the market and competitive spirits to push innovation forward. What isn't beneficial is unused diversity potential. That is, browsers occupying market share but failing to meaningfully advance the state of the art.

The solution to this sort of deadweight diversity has been market pressure. Should a browser fall far enough behind, and for long enough, developers will begin to suggest (and eventually require) users to adopt more modern options to access their services at the highest fidelity.

This is a beneficial market mechanism (despite its unseemly aspects) because it creates pressure on browsers to keep pace with user and developer needs. The threat of developers encouraging users to "vote with their feet" also helps ensure that no party can set a hard cap on the web's capabilities over time. This is essential to ensure that oligopolists cannot weaponise a feature gap to tax all software.

Taxation of software occurs through re-privatisation of low-level, standards-based features and APIs. By restricting use of previously-free features (e.g. Bluetooth, USB, Serial, MIDI, and HID) to proprietary frameworks and distribution channels, a successful would-be monopolist can extract outsized rents on any application that requires even one of these features. Impoverishing the commons through delay and obstruction is, over time, indistinguishable from active demolition.

Apple's playbook is in line with this diagnosis, preserving the commons as a historical curiosity at best. Having blockaded every road to upgrading the web, Apple have made it impossible for an open platform to keep pace with Apple's own modern-but-proprietary options. The game's simple once pointed out, but hard to see at first because it depends on consistent inaction. This sort deadweight loss is hard to spot on short time horizons. Disallowing competitive engines that might upgrade the carrying capacity of freely-available alternatives may have been accidental at introduction of iOS, but it's value to Apple now can scarcely be overstated. After all, it's hard to extract ruinous taxes on a restive population with straightforward emigration options. No wonder Cupertino continues to perform new showings of the "web apps are a credible alternative on iOS!" pantomime.

In this understanding, the web helps maintain a fair market for software services. Web standards and open source web engines combine to create an interoperable commons across closed operating systems upon which services can be built without taxation; but only to the extent it's capable enough to meet user needs over time. Continuing to bring previouly proprietary features into the commons is the core mechanism by which this progress is delivered. Push notifications may have been new and shiny in 2011 but, a decade later, there's no reason to think that a developer should pay an ongoing tax for a feature that is offered by every major  and device. The same goes for access to a phone's menagerie of sensors, as well as more efficient codecs.

The sorts of diversity we have come to value in the web ecosystem exist exclusively at the leading edge.

Intense disputes about the best ways to standardise a use-case or feature are a strong sign of a healthy dynamic. It's rancid, however, when a single vendor can prevent progress across a wide swathe of domains that are critical to delivering better experiences, and suffer no market consequence.

Apple has cut the fuel lines of progress by requiring use of WebKit in every iOS browser; choice without competition, distinction without difference. Users can have any sort of web they like, so long as it's as trailing-edge as Apple's.

Yet this sort of participation-prize diversity is exactly what purported defenders of Apple's policies would have us believe is healthy for the web.

It's a curious argument, admitting Apple's engine is deeply sub-par to defend an ongoing failure to compete. Apple is not wanting for the funds and talent to build a competitive product, it simply chooses not to. Apple's 2+ trillion dollar market cap is paired with nearly $200 billion in cash on hand. One could produce a competitive browser for the spare change in Cupertino's Eames lounges.

Claims that foot-dragging must be protected because otherwise capable engines might win share is not much of a defence. Excusing poor performance is to suggest that Apple does not possess the talent, skill, and resources to ever construct a competitive engine. I, at least, think better of Apple's engineering acumen than these nominal defenders.

Would WebKit really dissapear if Apple were to allow other engines onto iOS? We have a natural experiment in Safari for macOS. It continues to enjoy a high share of that browser market despite stiff and competition from browsers that include higher-quality engines. Why are Apple's defenders so certain that this won't be the iOS result?

And what is the worst-case scenario, exactly? That Safari loses share such that Apple must respond by funding the WebKit team adequately? That the Safari team feels compelled to switch to another open source rendering engine (e.g. Gecko or Blink), preserving their ability to fork down the road, just as they did with KHTML, and as the Blink project did with WebKit?

None of these are close ended scenarios, nor must they result in a reduction in constructive, leading edge diversity. Edge, Brave, Opera, and Samsung Internet consistently innovate on privacy and other features without creating undue drag on core developer interests. Should the Chromium project become an unwelcome host for this sort of work, all of these organisations can credibly consider a fork, adding another new branch to the lineage of browser engines.

It's not a foregone conclusion the world's most valuable tech firm should produce the lowest-quality browser engine. Developer's would likely take Apple's side if coercion about engine choice weren't paired with failure to keep pace on even basic features.

The point of diversity at the leading edge is progress through competition. The point of diversity amid laggards is the freedom to replace them — that's the market at work.

End Notes #

Nobody wishes it had come to this.

Apple's polices against browser choice were, at some point, relatively well grounded in the low resource limits of early smartphones. But those days are long gone. Sadly, the legacy of a closed choice, back when WebKit was still a leader in many areas, is an industry-wide hangover. We accepted a bad deal because the situation seemed convivial, and ignored those who warned it was a portent of a more closed, more extractive future for software.

Only if we had listened.

Thanks to Chris Palmer and Eric Lawrence for their thoughtful comments on drafts of this post. Thanks also to Frances for putting up with me writing this post on holiday.

1. As we shall see, it would be better for Apple if their "supporters" would stop inventing straw man arguments as they tend to undermine, rather than bolster, Cupertino's side. ↩︎

2. Browser engines all have a form of selective exclusion of code that is technically available within the codebase but, for one reason or another, is disabled in a particular environment. These switches are known variously as "flags," "command line switches," or "runtime-enabled features."

New features that are not ready for prime time may be developed for months "behind a flag" and only selectively enabled for small populations of developers or users before being made available to all by default. Many mechanisms have existed for controlling the availability of features guarded by flags. Still, the key thing to know is that not all code in a browser engine's source repository represents features that web developers can use. Only the set that is flagged on by default can affect the programmable surface that web developers experience.

The ability of the eventual producer of a binary to enable some flags but not others means that even if an open source project does agree to include code for a feature, restrictions on engine binaries can preclude an alternative browser's ability to provide even some features which are part of the code the system binary could include.

Flags, and Apple's policies towards them over the years, are enough of a reason to reject Apple's feint towards open source as an outlet for unmet web developer needs on iOS. ↩︎

3. It's perverse that the wealthy users Apple sells its powerful devices to — the very folks who can most easily dedicate the extra CPU and RAM necessary to enable multiple layers of protection — are prevented from doing so by Apple's policies that are, ostensibly, designed to improve security. ↩︎

4. and sandbox creation are technically separate concerns (and could be managed by policy independently), but insofar as folks impute a reason to Apple for allowing its engine to use this technique, sandboxing is often offered as a reason. ↩︎

A Week to Define the Web for Decades

Updated:

This is part four of the six-part series "Browser Choice Must Matter"

If you live or do business in the  or the , what you do in the next seven days could define the web for decades to come. By filing public comments with  regulators and  legislators this week, you can change the course of mobile computing more than at any other time in the past decade. Read on for why this moment matters and how to seize the day.

By way of background, regulators in much of the anglophone world (and beyond) spent much of 2021 investigating the state of the mobile ecosystem.

This is important because Apple has succeeded in neutering the web's potential through brazenly anti-competitive practices and obfuscation. Facebook and Google, meanwhile, have undermined user agency in browser choice for fun and profit.

I kid.

It was all for profit:

Play: Hobson's Browser: How Browser Choice Died In Our Hands

Public statements from leading authorities who have looked into this behaviour leave a distinct impression of being unimpressed. Here's the unflappably measured  Competition and Markets Authority () weighing in last month:

Apple and Google have developed a vice-like grip over how we use mobile phones and we're concerned that it's causing millions of people across the  to lose out.

The 's 400+ page interim report (plus an additional ~200 pages of detailed appendices) didn't make the waves it deserved when it was released near the winter holidays.[1] That's a shame as the report is by turns scathing and detailed, particularly in its proposed remedies, all of which would have a profoundly positive impact on you, me, and anyone else who uses the mobile web:

The report sets out a range of actions that could be taken to address these issues, including:

- Making it easier for users to switch between iOS and Android phones when they want to replace their device without losing functionality or data.

- Making it easier to install apps through methods other than the App Store or Play Store, including so-called "web apps".

- Enabling all apps to give users a choice of how they pay in-app for things like game credits or subscriptions, rather than being tied to Apple's and Google's payment systems.

- Making it easier for users to choose alternatives to Apple and Google for services like browsers, in particular by making sure they can easily set which browser they have as default.

This is shockingly blunt language from a regulatory body:

Avatar for CMAgovUK

Competition & Markets Authority@CMAgovUK

Our market study has provisionally found that:

❌ People aren’t seeing the full benefit of innovative new products and services such as cloud #gaming and web #apps.

[2/5]

1010:19 AM · Dec 14, 2021

Avatar for CMAgovUK

Competition & Markets Authority@CMAgovUK

Our provisional findings also suggest:

💷 customers could be facing higher prices than they would in a more competitive market.

[3/5]

910:20 AM · Dec 14, 2021

The report demonstrates that the  understands the anti-competitive browser and browser-engine landscape too. Its findings are no less direct than the summary:

Impact of the WebKit restriction

As a result of the WebKit restriction, there is no competition in browser engines on iOS and Apple effectively dictates the features that browsers on iOS can offer[.]

The  has outlined its next steps and is requesting comment until February 7th, 2022.

Apple, in particular, has demonstrated that it is a bad actor with regards to competition law. This post could easily contain nothing but a rundown of fruity skulduggery; that's how brazen Cupertino's anti-competitive practices have become. Suffice to say, Apple sees being fined 5M EUR per week over entirely reasonable requests a "cost of doing business." Big respect-for-the-rule-of-law vibes.

But this sort of thing isn't going to last. Regulators don't like being taken for a ride.

...Meanwhile in Washington #

On this side of the pond, things are getting serious. In just the past two weeks:

- The Senate Judiciary Committee — last seen here being dissembled-to by Apple in sworn testimony — voted to move serious legislation out of committee after lobbying by firms that somehow failed to notice that Apple's extortionate terms are an "economic miracle."

- 35 states' attorneys general filed amicus curiae briefs in support of Epic's appeal against Apple.

We're even getting gauzy coverage of pro-regulatory senators. It's quite the moment, and indicates dawning awareness of these blatantly anti-competitive practices.

This Is About More Than Browsers #

It's tempting to think of browser choice and app store regulation as wholly separate concerns, but neither the web nor apps exist in a vacuum. As the desktop web becomes ever-more powerful on every OS, even the most sophisticated app developers gain more choice in how they reach users.

Unleashing true choice and competition in mobile browsers won't only help web developers and users, it will level the playing field more broadly. Native app developers that feel trapped in abusive policy regimes will suddenly have real alternatives. This, in turn, will put pricing pressure on app store owners that extract egregious rents today.

Web apps and PWAs compete with app stores for distribution, lowering the price to develop and deliver competitive experiences. This allows a larger pool of developers and businesses to "play".

App store "review" and its capricious policy interpretations have always been tragicomic, but true competition is needed to drive the point home. Businesses are forced into the app store, requiring they spend huge amounts to re-build features multiple times. Users risk unsafe native app platforms when the much-safer web could easily handle many day-to-day tasks. We're only stuck in this morass because it helps Google and Apple build proprietary moats that raise switching costs and allow them to extort rents from indie developers and hapless users.

A better future for mobile computing is possible when the web is unshackled, and that will only happen when competition has teeth.

What You Can Do #

This is the last week to lodge comment by email with the UK's  regarding the findings of its interim report. Anyone who does business in the UK and cares about mobile browser choice should send comments, both as an individual and through corporate counsel.

For  residents, the speed at which legislation on this front is moving through Congress suggests that this is the moment for a well-timed email or, more preferably, call to your elected senator.

If you live or do business in the  or the , this week matters.

Whichever geography you submit comment to, please note that regulators and legislators have specific remits and will care more or less depending on the salience of your input to their particular goals. To maximize your impact, consider including the following points in your comments:

- Your residence and business location within the district they serve (if appropriate)

- How a lack of choice, including missing features and an endless parade of showstopping bugs, have hurt your business or forced you to accept unfair app store terms

- Support of specific provisions in their proposals, particularly regarding true browser choice

- The number of employees in your firm or the amount of business done annually in their geography

- The extent to which you service export markets with your technology

- The specific ways in which unfair App Store, Play Store, or browser choice policies have negatively impacted your business (think lost revenue, increased costs, bugs, etc.)

- Your particular preferences regarding competition both on the web (e.g., the availability of alternative browser engines on iOS) and between the web and native (e.g., the inability to offer a lower-cost, higher service web experience vs. being forced into app stores)

- Specific missing features and issues that cause you ongoing business harm

- If you are contacting a politician or their office, your willingness to vote on the issue

Leaving your contact information for follow-up and verification never hurts either.

It's been 761 weeks since Apple began the destruction of mobile browser choice, knowingly coating its preference for a "native" device experience (in web-friendly garb) at the expense of the mobile web. This is the week you can do something about it.

Carpe diem.

Minimum Standards for iOS Browser Competition

Updated:

This is part five of the six-part series "Browser Choice Must Matter"

There has been a recent flurry of regulatory, legislative, and courtroom activity regarding mobile  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  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  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  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 s that happen to be spelled differently on proprietary es. 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:

Play: Hobson's Browser: How Browser Choice Died In Our Hands

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

- 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 s 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 s 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).

- 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 s 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 s. Competing browsers must be allowed access to -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 s 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  without being forced to use Apple Pay as the only back end. Apple must further be enjoined from requiring specific  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.

Next: "Towards a Unified Theory of Web Performance"

Previously: "A Week to Define the Web for Decades"

Apple Is Not Defending Browser Engine Choice

Updated:

This is part six of the six-part series "Browser Choice Must Matter"

Gentle reader, I made a terrible mistake. Yes, that's right: I read the comments on a MacRumors article. At my age, one knows better. And yet.

As penance for this error, and for being short with Miguel, I must deconstruct the ways Apple has undermined browser engine diversity. Contrary to claims of Apple partisans, iOS engine restrictions are not preventing a "takeover" by Chromium — at least that's not the primary effect. Apple uses its power over browsers to strip-mine and sabotage the web, hurting all engine projects and draining the web of future potential.

As we will see, both the present and future of browser engine choice are squarely within Cupertino's control.

- Apple's Long-Standing Policies Are Anti-Diversity

- "WebKit couldn't compete if it had to."

- Browsers Are Big Business

- WebKit Is No Charity

- Choices, Choices

- Recent Developments

- How Apple Gutted Mozilla's Chances

- Back Of The Napkin

- The Best Kind Of Correct

- What Now?

Apple's Long-Standing Policies Are Anti-Diversity #

A refresher on Apple's iOS browser policies:

- From iOS 2.0 in '08 to iOS 14 in late '20, Apple would not allow any browser but Safari to be the default.

- For 14 years and counting, Apple has prevented competing browsers from bringing their own engines, forcing vendors to build skins over Apple's WebKit binary, which has historically lacked feature parity, been slower, and less secure.

- Apple will not even allow competing browsers to provide different runtime flags to WebKit. Instead, Fruit Co. publishes a paltry set of options that carry an unmistakable odour of first-party app requirements.

- Apple continues to self-preference through exclusive  access for Safari; e.g., the ability to install s to the home screen, implement media codecs, and much else.

Defenders of Apple's monopoly offer hard-to-test claims, but many boil down to the idea that Apple's product is inferior by necessity. This line is frankly insulting to the good people that work on WebKit. They're excellent engineers; some of the best, pound for pound, but there aren't enough of them. And that's a choice.

"WebKit couldn't compete if it had to." #

Nobody frames it precisely this way; instead they'll say, if WebKit weren't mandated, Chromium would take over, or Google would dominate the web if not for the WebKit restriction. That potential future requires mechanisms of action to cause Safari users to switch. What are those mechanisms? And why are those who comment on them so sure the end is nigh for WebKit?

Past swings away from  default browsers have hinged on the new features, better performance, improved security, and superior site compatibility. Marketing and distribution play a prominent role but have been indecisive in recent browser battles. The leads of  incumbents are not insurmountable because browsers are commodities with relatively low switching costs. Better products tend to win.

Destkop <abbr>OS</abbr>es have long created a vibrant market for browser choice, enabling many competitors to flourish over the years. es have long created a vibrant market for browser choice, enabling many competitors to flourish over the years.

Apple's prohibition on iOS browser engine competition has drained the potential of browser choice to deliver improvements. Without the ability to differentiate on features, security, performance, privacy, and compatibility, what's to sell? A slightly different ? That's meaningful, but identically feeble web features cap the potential of every iOS browser. Nobody can pull ahead, and no product can offer future-looking capabilities that might make the web a more attractive platform.

This is working as intended:

<a href='https://developer.apple.com/app-store/review/guidelines/#2.5.6'>Apple's policies</a> explicitly prevent meaningful competition between browsers on iOS. In 2022, you can have any default you like, as long as it's as buggy as Safari.Apple's policies explicitly prevent meaningful competition between browsers on iOS. In 2022, you can have any default you like, as long as it's as buggy as Safari.

Of all the reasons to switch browsers, compatibility is often the most compelling. Major sites asking users to switch is incredibly effective in aggregate.

"Compatibility" describes both a browser's ability to display existing content and developers' ability to rely on a set of features across browsers. Standards support is a sub-point of this latter issue but acts as a trailing indicator of engine quality.[1]

On es with browser competition, sites can recommend browsers with engines that cost less to support or unlock crucial capabilities. However, developers are loathe to do this; turning away users isn't a winning growth strategy, and prompting visitors to switch is passé.

Still, in extremis, missing features and the parade of showstopping bugs render some services impossible to deliver. In these cases, suggesting an alternative beats losing users entirely.

But what if there's no better alternative? This is the situation that Apple has engineered on iOS. Cui bono? — who benefits?

All iOS browsers present as Safari to developers. There's no point in recommending a better browser because none is available. The combined mass of all iOS browsing pegged to the trailing edge means that folks must support WebKit or decamp for Apple's App Store, where it hands out capabilities like candy but at a shocking price.

iOS's mandated inadequacy has convinced some that when proper engine choice is possible, an overwhelming majority of users will switch to browsers with better engines. This will, in turn, cause developers to skimp on testing for Safari, making it inevitable that browsers based on WebKit and other minority engines cannot compete. Or so the theory goes.

But is it predestined?

Perhaps some users will switch, but browser market changes take a great deal of time, and Apple enjoys numerous defences.

To the extent that Apple wants to win developers and avoid losing users, it has plenty of time.

It took over five years for Chrome to earn majority share on Windows with a superior product, and there's no reason to think iOS browser share will move faster. Regulatory mandates about engine choice will also take more than a year to come into force, giving Apple plenty of time to respond. And that's the lower bound. Apple's pattern of malaicious compliance will likely postpone the opportunity for true choice somewhat futher. As Apple fights tooth-and-nail to prevent browser choice, it will try to create ambiguity for vendors, delaying investment in ports. One way it may do this is by forcing vendors to challenge each missing API through an arduous and intentionally lengthy process, one geography at a time. Even in the best case, lots of time will be lost to this sort of brinksmanship.

Why would developers recommend alternatives if Safari adds features, improves security, prioritises performance, and fumigates for showstopping bugs? Remember: developers don't want to prompt users to switch; they only do it under duress. The features and quality of Safari are squarely in Apple's control.

So, given that Apple has plenty of time to catch up, is it a rational business decision to invest enough to compete?

Browsers Are Big Business #

Browsers are both big business and industrial-scale engineering projects. Hundreds of folks are needed to implement and maintain a competitive browser with specialisations in nearly every area of computing. World-class experts in graphics, networking, cryptography, databases, language design,  implementation, security, usability (particularly usable security), power management, compilers, fonts, high-performance layout, codecs, real-time media, audio and video pipelines, and per- specialisation are required. And then you need infrastructure; lots of it.

How much does all of this cost? A reasonable floor comes from Mozilla's annual reports. The latest consolidated financials (PDF) are from 2020 and show that, without marketing expenses, Mozilla spends between $380 and $430 million  per year on software development. Salaries are the largest category of these costs (~$180-210 million), and Mozilla economises by hiring remote employees without offering large bonuses and stock-based compensation.

From this data, we can assume a baseline cost to build and maintain a competitive, cross-platform browser at $450 million per year.

Browser vendors fund their industrial-scale software engineering projects through integrations. Search engines pay browser makers for default placement within their products. They, in turn, make a lot of money because browsers send them transactional and commercial intent searches as part of the query stream.

Advertisers bid highest to place ads against search keywords in commercial intent categories. This market in turn funds all of the  and operational costs of search engines, including "traffic acquisition costs" like browser search default deals.[2]

How much money are we talking about? Mozilla's $450 million in annual revenue comes from approximately 8% of the desktop market and negligible mobile share. Browsers are big, big business.

WebKit Is No Charity #

Despite being largely open source, browsers and their engines are not loss leaders.

Safari, in particular, is wildly profitable. The New York Times reported in late 2020 that Google now pays Apple between $8-12 billion per year, up from $1 billion in 2014. Other estimates put the current payments in the $15 billion range. What does this almighty torrent of cash buy Google? Searches, preferably of the commercial intent sort.

Mobile accounts for two-thirds of web traffic (or thereabouts), making outsized iOS adoption among wealthy users particularly salient to publishers and advertisers. Google's payments to Apple are largely driven by the iPhone rather than its niche desktop products where effective browser competition has reduced the influence of Apple's defaults.

Against considerable competition, Safari was used by 52% of visitors to <abbr>US</abbr> Government websites from macOS devices from <time datetime='2022-03-06'>March 6<sup>th</sup></time> to <time datetime='2022-04-04'>April 4<sup>th</sup>, 2022</time>  Government websites from macOS devices from th to th, 2022

The influence of a dozen years of suppressed browser choice is evident on iOS, where Safari is used 90% of the time. Apple's policies caused Mozilla to delay producing an iOS browser for seven years, and its de minimus iOS share (versus 3.6% on macOS) is a predictable result.

iOS represents 75% of all visits to <abbr>US</abbr> Government websites from Apple <abbr>OS</abbr>es  Government websites from Apple es

Even with Apple's somewhat higher salaries per engineer, the skeleton staffing of WebKit, combined with the easier task of supporting fewer platforms, suggests that Apple is unlikely to spend considerably more than Mozilla does on browser development. In 2014, Apple would have enjoyed a profit margin of 50% if it had spent half a billion on browser engineering. Today, that margin would be 94-97%, depending on which figure you believe for Google's payments.

In absolute terms, that's more profit than Apple makes selling Macs.

Compare Cupertino's 3-6% search revenue reinvestment in the web with Mozilla's near 100% commitment, then recall that Mozilla has consistently delivered a superior engine to more platforms. I don't know what's more embarrassing: that some folks argue with a straight face that Apple is trying hard to build a good browser, or that it is consistently overmatched in performance, security, and compatibility by a plucky non-profit foundation that makes just ~5% of Apple's web revenue.

Choices, Choices #

Steve Jobs launched Safari for Windows in the same  keynote that unveiled the iPhone.

Play: WWDC 2007 - One More Thing: Safari for Windows

Commenters often fixate on the iPhone's original web-based pitch, but don't give Apple stick for reducing engine diversity by abandoning Windows three versions later.

Today, Apple doesn't compete outside its home turf, and when it has agency, it prevents others from doing so. These are not the actions of a firm that is consciously attempting to promote engine diversity. If Apple is an ally in that cause, it is only by accident.

Theories that postulate a takeover by Chromium dismiss Apple's power over a situation it created and recommits to annually through its budgeting process.

This is not a question of resources. Recall that Apple spends $85 billion per year on stock buybacks[3], $15 billion on dividends, enjoys free cash flow larger than the annual budgets of 47 nations, and retain tens of billions of dollars of cash on hand.[4] And that's to say nothing of Apple's $100+ billion in non-business-related long-term investments.

Even if Safari were a loss leader, Apple would be able to avoid producing a slower, stifled, less secure, famously buggy engine without breaking the bank.

Apple needs fewer staff to deliver equivalent features because Safari supports fewer es. The necessary investments are also  expenses that receive heavy tax advantages. Apple enjoys enviable discounts to produce a credible browser, but refuses to do so.

Unlike Microsoft's late and underpowered efforts with  7-11, Safari enjoys tolerable web compatibility, more than 90% share on a popular

Recent Developments #

One way to understand the voluntary nature of Safari's poor competitiveness is to put Cupertino's recent burst of effort in context.

When regulators and legislators began asking questions in 2019, a response was required. Following Congress' questions about default browser choice, Apple quietly allowed it through iOS 14 (however ham-fistedly) the following year.

In the past six months, the Safari team has gone on a veritable hiring spree. This month's  announcements show the investment is making a difference. By spending more in response to regulatory pressure, Apple has eviscerated notions that it could not have delivered a safer, more capable, and competitive browser many years earlier. The added investment is relatively large compared to the previous size of the Safari team, but in terms of Apple's , it's loose change. Predictably, hiring talent to catch up has come at no appreciable loss to profitability.

The competitive potential of any browser hinges on headcount, and Apple is not limited in its ability to hire engineering talent. Recent efforts demonstrate that Apple has been able to build a better browser all along and, year after year, decides not to.

How Apple Gutted Mozilla's Chances #

For over a dozen years, setting any browser other than Safari as the iOS default was impossible. This, of course, has spotted Safari a massive market share head-start. Meanwhile, restrictions on engine choice hinder competitors' arguments for why users should switch. But don't take my word for it; here's the recent "UK CMA Final Report on Mobile Ecosystems" summarising submissions by Mozilla and others (pages 154-155):

5.48 The WebKit restriction also means that browser vendors that want to use Blink or Gecko on other operating systems have to build their browser on two different browser engines. Several browser vendors submitted that needing to code their browser for both WebKit and the browser engine they use on Android results in higher costs and features being deployed more slowly.

5.49 Two browser vendors submitted that they do not offer a mobile browser for iOS due to the lack of differentiation and the extra costs, while Mozilla told us that the WebKit restriction delayed its entrance into iOS by around seven years

That's seven years of marketing, feature iteration, and brand loyalty that Mozilla sacrificed on the principle that if they could not bring their core differentiation, there was no point in trying. It would have been better if Mozilla had made a ruckus, rather than hoping the world would notice its stoic virtue, but thankfully the T-rex has roused from its slumber.

Given the hard times the Mozilla Foundation has found itself in, it seems worth trying to quantify the costs.

Mozilla must fund a separate team to re-develop features atop a less-capable runtime. Every feature that interacts with web content must be re-developed in an ad-hoc way using inferior tools. Everything from form autofill to password management to content blocking requires extra resources to build for iOS. Not only does this tax development of the iOS product, it makes coordinated feature launches more costly across all ports.

Most substantially, iOS policies against default browser choice — combined with "in-app-browser" and search entry point shenanigans — have delayed and devalued browser choice.

Until late 2020, users needed to explicitly tap the Firefox icon on the home screen to get back to their browser. Naïvely tapping links would, instead, load content in Safari. This split experience causes a sort of pervasive forgetfulness, making the web less useful.

This hurts browser makers too. On OSes with competition, convincing a user to download a new browser has a chance of converting nearly all of their browsing to that product. iOS (along with Android and Facebook's mobile apps) undermine this by constantly splitting browsing, ignoring the user's default. When users don't consistently end up in their browser, searches occur through it less often, affecting revenue. Web developers also experience this as a reduction in visible share of browsing from competing products, reducing incentives to support alternative engines.

A foregetful web hurts publishers too. Users struggle to access pay-walled content when browsing is split. Ad bid rates are likewise suppressed. A lack of re-engagement features like Push Notifications are the rotten cherry on top, forcing sites to push users to the App Store where Apple doesn't randomly log users out, or deprive publishers of key features.

Users, browser makers, web developers, and web businesses all lose. The hat-trick of value destruction.

Back Of The Napkin #

The pantomime of browser choice on iOS has created an anaemic, amnesiac web. Tapping links is more slogging than surfing when autofill fails, passwords are lost, and login state is forgotten. Browsers become less valuable as the web stops being a reliable way to complete tasks.

Can we quantify these losses?

Estimating lost business from user frustration and ad rate depression is challenging. But we can extrapolate what a dozen years of choice might have meant for Mozilla from what we know about how Apple monetises the web.

For the purposes of argument, let's assume Mozilla would be paid for web traffic at the same rate as Apple ($8-15 billion per year for ~75% share of traffic from Apple es). If the traffic numbers to  government websites are reasonable proxies for the iOS/macOS traffic mix (big "if"s), then equal share for Firefox on iOS to macOS would be worth $215-400 million per year.[5]

Put differently; there's reason to think that Mozilla would not have suffered layoffs if Apple were an ally of engine choice. Apple's policies have made the web a less compelling ecosystem, and its anti-competitive behaviour has driven up costs for browser makers while starving them of revenue.

The Best Kind Of Correct #

There is a narrow, fetid sense in which Apple's influence is nominally pro-diversity. Having anchored a significant fraction of web traffic at the trailing edge, businesses that do not decamp for the App Store may feel obliged to support WebKit.

This is a malignant form of diversity, not unlike the sort presented by every other lagging engine through the years. At least in the case of  6, folks could recommend alternatives, or plugins to transparently upgrade the platform. Lagging engines taxed developers and businesses, too, and in the era before open-source engines, the loss of one lineage may have been a deep loss. But the fact of an engine being different does not make that difference valuable, and WebKit's differences are incremental. Sure, Blink now has a faster layout engine, better security, more features, and fewer bugs, but like WebKit, it is also derived from KHTML. Both engines are forks and owe many present-day traits to their ancestors.

The history of browsers includes many forks and remixes. It's naïve to think that will end if iOS becomes hospitable to browser competition. After all, it has been competition that spurred engine improvements and forks.

Today's KHTML descendants are not the end of the story. Future forks are possible. New codebases can be built from parts. Indeed, there's already valuable cross-pollination today between Gecko, WebKit, and Chromium. Unlike the '90s and early 2000s, diversity can arrive in valuable increments through forking and recombination.

What's necessary for leading edge diversity, however, is funding.

By simultaneously taking a massive pot of cash for browser-building off the table, returning the least it can to engine development, and preventing others from filling the gap, Apple has foundationally imperilled the web ecosystem by destroying the utility of a diverse population of browsers and engines.

Apple has agency. It is not a victim, and it is not defending engine diversity.

What Now? #

A better, brighter for the web is possible, and thanks to belated movement by regulators, increasingly likely. The good folks over at Open Web Advocacy are leading the way, clearly explaining to anyone who will listen both what's at stake and what it will take to improve the situation.

Investigations are now underway worldwide, so if you think Apple shouldn't be afraid of a bit of competition if it will help the web thrive, consider getting involved. And if you're in the UK or do business there, consider helping the CMA help the web before July 22nd, 2022.. The future isn't written yet, and we can change it for the better.

1. Many commenters come to debates about compatibility and standards compliance with a mistaken view of how standards are made. As a result, they perceive vendors with better standards conformance (rather than content compatibility) to occupy a sort of moral high ground. They do not. Instead, it usually represents a broken standards-setting process.

This can happen for several reasons. Sometimes standards bodies shutter, and the state of the art moves forward without them. This presents some risk for vendors that forge ahead without the cover of an 's protective  umbrella, but that risk is often temporary and measured. s aren't hard to come by; if new features are valuable, they can be standardised in a new venue. Alternatively, vendors can renovate the old one if others are interested in the work.

More often, working groups move at the speed of their most obstinate participants, uncomfortably prolonging technical debates already settled in the market and preventing definitive documentation of the winning design. In other cases, a vendor may play games with intellectual property claims to delay standardisation or lure competitors into a patent minefield (as Apple did with Touch Events).

At the leading edge, vendors need space to try new ideas without the need for the a priori consensus represented by a standard. However, compatibility concerns expressed by developers take on a different tinge over time.

When the specific  details and capabilities of ageing features do not converge, a continual tax is placed on folks trying to build using features from that set. When developers stress the need for compatibility, it is often in this respect. Disingenuous actors sometimes try to misrepresent this interest and claim that all features must become standards before they are introduced in any engine. This interpretation runs against the long practice of internet standards development and almost always hides an ulterior motive.

The role of standards is to consolidate gains introduced at the leading edge through responsible competition. Vendors that fail to participate constructively in this process earn scorn. They bring ignominy upon their houses by failing to bring implementations in line with the rough (documented and tested) consensus or by playing the heel in s to forestall progress they find inconvenient.

Vendors like Apple. ↩︎

2. In the financial reports of internet businesses, you will see the costs to acquire business through channels reported as "Traffic Acquisition Costs" or "". Many startups report their revenue "excluding " or "ex-". These are all ways of saying, "we paid for lead generation", and search engines are no different. ↩︎

3. This is money Apple believes it cannot figure out a way to invest in its products. That's literally what share buybacks indicate. They're an admission that a company is not smart enough to invest the money in something productive. Buybacks are attractive to managers because they create artificial scarcity for shares to drive up realised employee compensation — their own included. Employees who are cheesed to realise that their projects are perennially short-staffed are encouraged not to make a stink through  appreciation. Everyone gets a cut, -rich managers most of all. ↩︎

4. Different analysts use different ways of describing Apple's "cash on hand". Some analysts lump in all marketable securities, current and non-current, which consistently pushes the number north of $150 billion. Others report only the literal cash value on the books ($34 billion as of  Apple's consolidated financial statements (PDF) with public reporting on them.

The picture is also clouded by changes in the way Apple manages its cash horde. Over the past two years, Apple has begun to draw from this almighty pile of dollars and spend more to inflate its stock price through share buybacks and dividends. This may cast Apple as more cash-poor than it is. A better understanding of the actual situation is derived from free cash flow. Perhaps Apple will continue to draw down from its tall cash mountain to inflate its stock price via buybacks, but that's not a material change in the amount Apple can potentially spend on improving its products. ↩︎

5. Since this post first ran, several commenters have noted a point I considered while writing, but omitted in order to avoid heaping scorn on a victim; namely that Mozilla's management has been asleep at the switch regarding the business of its business.

Historically, when public records were available for both Opera and Mozilla, it was easy to understand how poorly Mozilla negotiated with search partners. Under successive leaders, Mozilla has been paid less than as half as much per point of share and there's no reason to think MoCo's negotiating skills have improved dramatically. Apple, therefore, is likely to caputre much more revenue per search or seat than an install of Firefox.

But even if Mozilla only made 1/3 of Apple's haul for an equivalent fraction of use, the combined taxes of feature re-development for iOS and lost of revenue would be material to the Mozilla Foundation's bottom line.

Obviously, to get that share, Mozilla would need to prioritise mobile, which it has not done. This is a deep own-goal and a point of continued sadness for me.

A noble house reduced to rubble is a tragedy no matter who turns the final knife. Management incompetence is in evidence, and Mozilla's Directors are clearly not fit for purpose.

But none of that detracts from what others have done to the Foundation and the web, and it would be just as wrong to claim Mozilla should have been perfect in ways its enemies and competitors were not. ↩︎