Abject Praise - Infrequently Noted

Skip to main content

Series

Reckoning

Browser Choice Must Matter

The Performance Inequality Gap

Effective Standards Work

Recently

Abject Praise

The Web Is An Antitrust Wedge

Naked Power

The Performance Inequality Gap, 2026

The App Store Was Always Authoritarian<br>'25, '24, '23, '22, '21, '20, Earlier

Popular

Misfire

If Not React, Then What?

The Performance Inequality Gap, 2026

The Performance Inequality Gap, 2024

It's perilous to disagree with someone as wise and thoughtful as Jeremy, but for the past fortnight his post in response to Apple's iOS 27 marketing invades my quiet moments like a cricket in the attic.

"Why", I ruminate, "should someone who understands the state of play give Apple credit for doing less than the minimum while rubbishing those who have consistently done more?"

Redux

Like Apple's previous marketing of Safari 16.4 and Safari 26, the conjoined September release of Safari and iOS 27 documents an achingly slow release cycle. It would be one thing if the features or spec conformance were world-beating, but looking closely at the release notes, Safari 27 is set to deliver fixes to issues that, by and large, competing engines didn't suffer.1

Don't get me wrong: it's great that Apple is focusing on quality; it remains a persistent issue for Safari. But how much relief should long-suffering web developers expect?

The best comparative measures come from the communal Web Platform Tests project. Comparing the current experimental builds with stable channel releases can illuminate the scale of change we can expect when the next major version of each browser launches:2

WPT Test Pass Rates (%)

90% is the minimum Apple requires across all WPT tests for competitors' engines in the EU and Japan where it has been forced to allow them (in theory). Safari barely clears the bar. Source: wpt.fyi.

It would appear that Safari is closing on Firefox, but this is slightly misleading, as Mozilla's monthly release cycle is significantly shorter. Apple managed seven releases over the past year, or a roughly eight week cadence. Mozilla and Chromium, meanwhile, have released 12 versions to stable, or one a month. These serve as denominators (7.4 weeks vs. 4.3) when calculating rates of improvement. Safari's larger increase in passing tests between nightly and stable versions (1558 vs. 990 for Firefox) looks large, and Apple wants us to think that's down to renewed focus. But this is a statistical mirage. On a time-weighted basis, Safari continues to improve more slowly than Firefox, logging 207 improved tests per week since the last stable release versus Firefox's 230 and Chromium's 460.

But is that focus on this most recent release misleading? WPT is very flexible, and anyone can construct a query like this, comparing developer channel releases of each engine at this point last year to the current build:

Change In Tests Passed, July '25 - July '26

Safari's WebKit remains least improved since this time last year. Source: wpt.fyi.

Note that the total number of tests in the corpus is not fixed; because new features are constantly added to browsers, the denominator continues to increase over time. It's helpful, then, to look at the change in tests passing as a fraction of all tests over time. This gives us a sense if an engine is progressing (or regressing) relative to the web's potential:

Change In Tests Passed %, July '25 - July '26

Apple might not care to implement some of the features for tests Safari isn't passing, but is that a reason they should be denied to all iOS users? And what does it say that others can improve relative to the overall test suite, but WebKit has regressed while there remain large conformance gaps in WebKit in core spec areas Apple supports? Source: wpt.fyi.

Total test pass rates imply the role of engines as the blockers of widespread compatibility, but aren't a foolproof indicator. For example, if every engine failed the same way, it would be regrettable, but compatible. Web developers wouldn't have cause to throw shade at one browser more than others, so perhaps overall test failure rates obscure more than they clarify?

Helpfully, wpt.fyi also generates charts for tests that fail in just one engine. But for bugs unique to that codebase, the web would be more capable and less costly to develop for. The higher the count, the more an engine holds back progress:

Lower is better. Over the past eight years, Safari's WebKit nightly builds have uniquely failed double the number of WPT tests as Firefox's Gecko on average. WebKit consistently racks up 3-4x as many single-engine failures as Chromium's Blink engine across the same time period.

At the time of writing, WebKit nightlies are alone in failing ~4,200 tests, Gecko is next at ~2,400, and Blink is the least incompatible with just under 800 unique failures. These relative rates have remained stable across many years, indicating higher sustained investment in Blink and Gecko...