logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·02.11.26
← Back to news

Abject Praise

Original article
infrequently.org|5 points|1 comments|by genericlemon24|Jul 7, 2026

Abject Praise

By Alex Russell

It is a risky venture to disagree with someone as insightful and considerate as Jeremy. However, for the last two weeks, his reaction to Apple's marketing for iOS 27 has been like a persistent cricket in my attic—impossible to ignore.

I find myself wondering: why would someone with a deep understanding of the current landscape give Apple credit for doing the bare minimum, while simultaneously dismissing those who have consistently gone above and beyond?

The Cycle of Redundancy

Similar to the way Apple marketed Safari 16.4 and 26, the simultaneous launch of Safari and iOS 27 in September highlights an impressive agonizingly sluggish release cadence.

If the new features or the level of specification adherence were industry-leading, it would be a different story. But a close inspection of the release notes reveals that Safari 27 is primarily delivering patches for problems that other competing engines simply didn't have.

Note: To be clear, Apple's focus on quality is a positive step, as stability has historically been a weak point for Safari.

However, for the web developers who have suffered for years, how much actual relief is coming?

Measuring Progress via WPT

The most reliable benchmarks are found in the community-driven Web Platform Tests (WPT) project. By comparing experimental builds against stable releases, we can project the impact of the next major browser updates.

Comparison of Engine Performance

Engine/BrowserRelease Cadence (Annual)WPT Pass Rate Trend
Safari (WebKit)~7 releases (8-week cycle)Closing in on Firefox (seemingly)
Firefox (Gecko)12 releases (Monthly)Steady improvement
Chrome (Blink)12 releases (Monthly)High-velocity improvement

Crucial Detail: In the EU and Japan, where Apple is theoretically forced to allow alternative engines, Apple requires a minimum pass rate of 90%90\%90% across all WPT tests for competitors.

WPT Pass Rates Chart

While it looks like Safari is catching up to Firefox, this is a mathematical illusion. Apple's jump in passing tests between nightly and stable (1558 vs. 990 for Firefox) seems large, but it ignores the time factor.

Using a time-weighted calculation: Improvement Rate=ΔTests PassedWeeks since last stable release\text{Improvement Rate} = \frac{\Delta \text{Tests Passed}}{\text{Weeks since last stable release}}Improvement Rate=Weeks since last stable releaseΔTests Passed​

The results are telling:

  • Blink: 460 tests/week
  • Gecko: 230 tests/week
  • WebKit: 207 tests/week

The Gap in Evolution

If we look at the change in tests passed from July 2025 to July 2026, WebKit remains the least improved. Because the total number of tests (the denominator) grows as new features are added, we must look at the fraction of tests passing.

Progress Ratio=New Tests PassedTotal Test Suite Size\text{Progress Ratio} = \frac{\text{New Tests Passed}}{\text{Total Test Suite Size}}Progress Ratio=Total Test Suite SizeNew Tests Passed​

This reveals that while other engines are keeping pace with the web's potential, WebKit is actually falling further behind.

The "Unique Failure" Problem

Total pass rates can be misleading. If every browser failed the same way, the web would be consistently broken, but compatible. The real issue is unique failures—bugs that exist in only one engine.

Over the last eight years, WebKit nightlies have averaged double the unique failures of Gecko and 3-4 times those of Blink. This suggests a systemic lack of investment in WebKit compared to its peers.

The Case of the Temporal API

The introduction of the Test262 JavaScript suite makes WebKit's deficiency even more glaring. There is a massive spike in WebKit-exclusive failures due to the Temporal API.

// Example of the Temporal API that Blink and Gecko support
const now = Temporal.Now.zonedDateTimeISO();
console.log(`Current time: ${now.toString()}`);

The Temporal API has been in the works for nearly a decade. It wasn't a surprise. Yet, based on the Safari 27 blog and nightly runs, it will be missing from the September release.

The Regulatory Contradiction

Apple has told regulators that "real choice" in iOS browsers is unnecessary because Safari is "more than capable" and "well-funded."

The Reality Check:

  • Blink ships Temporal API
  • Gecko ships Temporal API
  • WebKit ships Temporal API →\rightarrow→ FAILED

How can Apple square their claims of capability with such an embarrassing failure on a long-anticipated feature they didn't even object to?

Features vs. Tests

One might argue that tests ≠\neq= features. For instance, the Temporal API has an exhaustive suite of sub-tests that inflates the failure count. Other foundational features might have fewer tests but more impact. However, the trend remains clear...