https://infrequently.org/2021/04/progress-delayed/ Skip to main content Infrequently Noted Alex Russell on browsers, standards, and the process of progress. * Home * About * RSS * Twitter Progress Delayed Is Progress Denied Do App Store policies harm developers? Is the web a credible alternative? A look at the data. April 30, 2021 Updated: May 2, 2021 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 These points can be simultaneously valid and immaterial to the web's fitness as a competent alternative to native app development on iOS. Whatever point gaps in capabilities Apple has created and maintains between the web and native, we must understand the trends rather than the perceptions generated by individual releases. To know if we're in a drought, we have to look at reservoir water levels and seasonal rainfall patterns. Even if it's raining features right this instant, the weather isn't climate. 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]. They are, pound for pound, some of the best engine developers globally 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, browser 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 for web competitiveness as genuine browser choice provides users and developers with meaningful alternatives. MacOS Safari is compelling enough to have held a 40-50% share for many years running. It maintains that share in the face of stiff competition. Safari has many good features, and in an open marketplace, choosing it (or not) is entirely reasonable. That is not the topic of this post. The Performance Argument As an engineer on a browser team, I'm privy to the blow-by-blow of various performance projects, benchmark fire drills, and the ways performance marketing (deeply) impacts engineering priorities. All modern browsers are fast, Chromium and Safari/WebKit included. No browser is always fastest in every area today. As reliably as the Sun rises in the East, benchmarks lost launch projects to re-architect internals, intending to pull ahead. This is as it should be. Healthy competitions feature competitors trading the lead with regularity. Spurious reports of "10x worse" performance merit intense scepticism. 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. Put another way; it's possible to deny web developers access to features simply by failing to deliver them at the margin. For web developers, compatibility across engines is key to productivity. To the extent that an engine has more than 10% share (or thereabouts), developers tend to view features it lacks as "not ready". 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. 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. 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. 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 web platform 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: [rates] 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 critical individual features and sets of capabilities unlock new types of apps on the web. 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. 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 for improving user privacy. 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 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 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. 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. First proposed by Microsoft, it dramatically simplifies input handling. Critical in adapting web content to mobile, particularly regarding multi-touch gestures. Delayed three years^[10]. Service Workers Key API enabling modern, reliable offline web experiences and PWAs. Delayed 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). They are supported only for use in WebRTC but not the usual mechanisms for media playback (