Abject Praise

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?" ContentsReduxFeatures Over TestsConsequencesYou Do Not Have To Hand It To ThemEverywhere You TurnQuality Has A Quality All Its Own 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 for 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

It would appear that Safari is closing on Firefox, but this is misleading. 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. On a time-weighted basis, however, 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 perhaps the most recent releases are outliers. Looking across a longer time period can help us level-set.

WPT is flexible, allowing us to construct a query comparing developer channel releases of each engine in July 2025 to current builds:

Change In Tests Passed, July '25 - July '26 Safari's WebKit remains least improved since this time last year. Source: wpt.fyi

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. This highlights the extent to which engines are 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 Safari isn't passing tests for, 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 set, but WebKit has fallen further behind? Source: wpt.fyi

Total passage 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; that is, cases where two browsers implement a feature correctly, and only one is out of conformance. 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. Source: wpt.fyi 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 versus WebKit.

Lower is better. With the recent addition of the Test262 test suite for JavaScript, WebKit's contribution to feature impairment becomes even more pronounced. Source: wpt.fyi Including the test262 JavaScript conformance suite, we see a huge spike in WebKit-exclusive test failures. This is thanks to Blink and Gecko shipping the new Temporal API this spring. Temporal has been in development for nearly a decade; it hardly snuck up on Cupertino. Judging by the Safari 27 blog post, and confirmed by the state of the nightly test runs, it will not be included when new features ship in September. Apple has repeatedly claimed to regulators that there's no need for real choice in iOS browsers because Safari is more than capable and the team is well funded. It's unclear how those claims can be squared with such an embarassing showing on a long-anticipted feature that Apple has no objection to. Features Over Tests One critique raised by this visualisation is that tests are not features. Some areas (like Temporal) include exhaustive test suites with many sub-tests, driving up their relative numbers. Other features may be foundational or internally complicated, but may have proportionally fewer WPT tests. Thankfully, webstatus.dev has collated a feature-oriented view of the same data. Looking across the past decade, it shows that WebKit is the predominant reason features remain unavailable to users and developers, forcing both into the App Store where Apple demands a 30% cut: Lower is better. As of June 30th, 2026 Safari is alone in blocking 59 features, Firefox keeps 43 from becoming widely available, and Chromium is blocking nine.3 Source: webstatus.dev Blink has consistently maintained the lead on features and conformance over the past decade, but iOS users remain stuck with Apple's buggier, less capable engine, no matter which browser they choose. Looking at large, heavily tested, uncontroversial regions of the platform shows that the gap isn't simply down to features that Apple thinks are problematic; even in areas where Cupertino is fully engaged, it consistently trails:

Remember that Mozilla makes something in the range of $500MM/yr from all revenue sources and spends the vast majority of that on browser development.

Apple, meanwhile, rakes in more than $20BN per year from its web search deal with Google, or 40x as much. With that much cash available, WebKit should be trouncing all comers; instead, it's barely middle of the pack when it isn't losing outright. Stable Firefox passes 84.9% of CSS tests, while Safari clears 86%, or a 1.1% difference:

Results from nightlies suggest that Safari 27 will widen Apple's lead versus Firefox to 1.6%, while trailing both Stable and Canary versions of Chromium (93.4% and 95.5%, respectively). Improvement is improvement, but Apple's layout engine remains riddled with O(n^2) behaviours. Both Mozilla and the Chromium community funded multi-year rearchitecture projects improve rendering performace, but Apple has not made similar investments. In other uncontroversial areas, such as networking, Apple's engine loses handily — both today and into the future. The fetch specification underpins browser networking, and WPT scores again highlight the consequences of subsistence-level funding for WebKit:

This continuing embarrassment is not a divergence from historical trends. But for Cupertino to feel any shame, or face any consequences, influential developers like Jeremy will need to look past marketing. Consequences These large, persistent gaps matter to the mobile and web ecosystems because Apple is unique in denying access to more capable, less-buggy engines and actively erecting unlawful barriers to choice when forced by legislation to enable it. This is accomplished through eye-watering budgets for legal shenanigans, direct lobbying, and well-heeled astroturf front groups to maintain a capability gap between web and native.4 That chasm is instrumental in trapping users and developers in the extractive vice of Cupertino's App Store. A persistent, material gap in capabilities creates a perception of the web being less-than; a budget option for the unserious. Should users choose more capable, more private, less buggy browsers for a larger share of their computing needs, Apple might lose the leverage that enables it to extract rents. Cupertino can put up with a lot of things, but it can't abide that. Which is why it spends lavishly to deflect and delay true browser choice, rather than investing those resources in the Safari team.

You Do Not Have To Hand It To Them Having looked at the data, and having manually dug into dozens of the fixes listed for WebKit in the Networking and HTML sub-areas, I can say with some confidence that Jeremy's praise for Apple's comparative rate of bug fixing is simply off-base. Cupertino might be talking up how much it cares, and we might all be desperate for green shoots given Apple's iOS hostage-taking, but our most fervent wishes and FruitCo's carefully presented narrative do not to change the reality that Apple is consistently out-engineered and out-invested by a non-profit with 1/40th the web-derived revenue. Against a near peer, the results of Cupertino's continuing under-investment are squalid. What we see in these differences has a name: greed. Apple is extracting tens of billions of dollars in private profit from browsers while socializing the costs to every digital business forced to work around Safari's buggy engine. Ecosystem-wide deadweight losses are even higher, impacting every user and business forced into the App Store by the incapability of Apple's browser. Not coincidentally, this is where Cupertino extracts a second vig. Higher prices for everyone else are not a bug to the monopolist's mind, but a confirmation of their own rightness and purity of charachter. Sure, that sounds like lunacy, but a lot of things go down more easily when you're absolutely rolling in it. Just ask anyone at Apple. Everywhere You Turn Like test conformance, security and performance are also indicators of quality that comes from consistent investment over time. News recently broke that a Blink for iOS prototype is showing massive performance upside relative to Safari on Apple's own hardware: The Blink for iOS prototype tested on Apple's own benchmarks, on Apple hardware. In the most representative test suite (Speedometer), Chromium leads by more than 25%. That's to say nothing of the heavily requested features no developer can use on iOS thanks to Apple's sandbagged engine. Safari engineers have worked behind the scenes to keep important, oft-requested features out of Interop where a lack of progress might make Cupertino's choices more legible.