Comforting Myths Awash in revisionist histories about Apple's web efforts, a look at the evidence.
In several recent posts, I've attempted to address how the structure of standards bodies, and their adjacent incubation venues, accelerates or suppresses the potential of the web as a platform. The pace of progress matters because platforms are competitions, and actors that prevent expansions of basic capabilities risk consigning the web to the dustbin.
Inside that framework, there is much to argue over regarding the relative merits of specific features and evolutionary directions. This is healthy and natural. We should openly discuss features and their risks, try to prevent bad consequences, and work to mend what breaks. This competitive process has made browsers incredibly safe and powerful for 30 years.
Until iOS, that is.
Imagine my surprise hearing that Apple isn't attempting to freeze the web in amber to make space for its own proprietary platform because it engages to redesign proposals it disagrees with.
As I have occasionally documented, this was not my experience. I had relatively broad exposure to the patterns of Apple's collaboration, having designed, advised on, or led teams that built dozens of features across disparate areas of the platform since the Blink fork.
But perhaps this was the wrong slice from which to judge? I've been hearing of Apple's openness to collaboration on challenging APIs so often that either my priors are invalid, or something else is at work. To find out, I needed data.
A specific parry deployed whenever Apple's sluggish pace is raised: “controversial” features “lack consensus” or “are not standards” or “have privacy and security problems” (unspecified). The corollary being that Apple engages in good-faith to address these developer needs in other ways, even in areas where they have overtly objected.
Apple's engine has indisputably trailed Blink and Gecko in all manner of features over the past decade. This would not be a major problem, except that Apple prevents other browsers from delivering better and more competitive web engines on iOS.
Normally, consequences for not adopting certain features arrive in the market. Browsers that fail to meet important needs, or drop the ball on quality lose share. This does not hold on iOS because no browser can ship a less-buggy or more capable engine than Apple's WebKit.
Because competitors are reduced to rebadging WebKit, Apple has created new responsibilities and expectations for itself. Everyone knows iOS is the only way to reach wealthy users, and no browser can afford to be shut out of that slice of the mobile market. Therefore, the quality and features of Apple's implementation matter intensely to the health and competitiveness of the web, as web developers cannot even encourage users to switch to less buggy or feature-impoverished browsers.
This put's Apple's actions squarely in the spotlight.
The moment iPhone users around the world can install high-quality browsers, the conversational temperature about features and reliability will drop considerably. Apple know this, but it's unclear if those asserting WebKit engages constructively in tricky design areas do.
It's possible to size up Apple's appetite for problem-solving in several ways. We can look to understand how frequently Apple ships features ahead of, or concurrently with, other engines because near-simultaneous delivery is an indicator of co-design. We can also look for visible indications of willingness to engage on thorny designs, searching for counter-proposals and shipped alternatives along the way.
This chart tracks single-engine omissions over the past decade; a count of designs which two engines have implement but which a single holdout prevents from web-wide availability:
Features missing in one engine, '15-25. Lower is better.
APIs missing from Safari impact every iOS browser.
Thanks to the same Web Features data set, many views are possible. This data shows that there are currently 185 features in Chromium that are not available in Safari, and 32 features in Safari that are not yet in Chromium. (or 187 and 35 for mobile, respectively). But as I've noted previously, point-in-time evaluations may not tell us very much.
I was curious about delays in addition to omissions. How often do we see evidence of simultaneous shipping, indicating strong collaboration? Is that more or less likely than leading vendors feeling the need to go it alone, either because of a lack of collaborative outreach, or because other vendors do not engage when asked?
To get a sense, I downloaded all the available data (JSON file), removed features with no implementations, removed features that were not introduced before 2015, filtered to Chrome, Safari, and Firefox, then aggregated by year. The resulting data set is here (JSON file).
The data can't determine causality, but can provide directional hints:
Safari rarely leads, but that does not mean other vendor's designs will stand the test of time. But if Apple engages in solving the same problems, we would expect to see Safari leading on alternatives or driving up the rates of simultaneously shipping features once consensus emerges. But these aren't markedly increased. Apple can, of course, afford to fund work into alternatives for “problematic” APIs, but it doesn't seem to.
Narratives about collaboration in tricky areas take more hits from Safari's higher incidence of catch-up launches. These indicate Apple shipping the same design that other vendors led with, but on a delay of two years or more from their first introduction. This is not redesign. If there were true objections to these APIs, we wouldn't expect to see them arrive at all, yet Apple has done more catching up over the past several years than it has shipped APIs with other vendors.
This fails to rebut intuitions developed from recent drops of Safari features (1, 2) composed primarily of features that Apple's engineers were not primary designers of.
But perhaps this data is misleading, or maybe I analysed it incorrectly. I have heard allusions to engagement regarding APIs that Apple has publicly rejected. Perhaps those are where Cupertino's standards engineers have invested their time?
Most of the hard cases concern APIs that Apple (and others) have rightly described as having potentially concerning privacy and security implications. Chromium engineers agreed those concerns have merit and worked to address them; we called it “Project Fugu” for a reason. In addition to meticulous design to mitigate risks, part of the care taken included continually requesting engagement from other vendors.
Consider the tricky cases of Web MIDI, Web USB, and Web Bluetooth.
Apple has supported MIDI in macOS for at least 20 years — likely much longer — and added support for MIDI on iOS with 2010's introduction of Core MIDI in iOS 4.2. By the time the first Web MIDI proposals broke cover, MIDI hardware and software were the backbone of digital music and a billion dollar business and Apple's physical stores stocked racks of MIDI devices for sale. Today, an overwhelming fraction of MIDI devices explicit list their compatibility with iOS and macOS.
It was therefore a clear statement of Apple's intent to cap web capabilities when it objected to Web MIDI's development just before the Blink fork. The objections by Apple were by turns harsh, condescendingly ignorant and imbued with self-fulfilling stop-energy; patterns that would repeat post-fork.
After the fork and several years of open development (which Apple declined to participate in), Web MIDI shipped in Chromium in early 2015. Despite a decade to engage, Safari has not shipped Web MIDI, Apple has not provided a “standards position” for it , and has not proposed an alternative. To the best of my knowledge, Apple have also not engaged in conversations about alternatives, despite being a member of the W3C 's Audio Working Group which has published many Working Drafts of the API. That group has consistently included publication of Web MIDI as a goal since 2012.
Across 11 charters or re-charters since then, I can find no public objection within the group's mailing list from anyone with an @apple.com email address. Indeed, I can find no mentions of MIDI from anyone at Apple on the public list. Obviously, that is not the same thing as agreeing to publication as a Recommendation, but it also not indicative of any attempts at providing an alternative.
But perhaps alternatives emerged elsewhere, e.g., in an Incubation venue? There's no counter-proposal listed in the WebKit explainers repository, but maybe it was developed elsewhere? We can check for features available behind flags in Safari Technology Preview and read the Tech Preview release notes. To check them, I used curl to fetch each of the 127 JSON files that are, apparently, the format for Safari's release notes, pretty-printed them with jq , then grepped case-insensitively for mention of “audio” and “midi”. Every mention of “audio” was in relation to the Web Audio API, the Web Speech API, WebRTC,, the