Safari 16.4 Is An Admission - Infrequently Noted

Safari 16.4 Is An Admission

If you're a web developer not living under a rock, you undoubtedly got word of last week's big Safari 16.4 reveal. There's much to cheer, but we also need to talk about why this mega-release is happening now, and what it means for the future.

But first, the list!

WebKit's Roaring Twenties #

Apple's summary combines dozens of minor fixes with several big-ticket items. Here's an overview of the most notable features, and prefixed with the year they shipped in Chromium browsers:

• 2015: Web Push for iOS (but only for installed PWAs)
• 2020: PWA Badging API (for unread counts) and id support (making updates smoother)
• 2015: PWA installation for third-party browsers (but not to parity with "Smart Banners")

• A bevy of Web Components features, many of which Apple had held up in standards bodies for years[1], including:

• Myriad small CSS improvements and animation fixes, but also:
  • 2018: CSS Typed OM for faster styling from JavaScript
  • 2020: CSS Custom Properties can now be animated
• 2019: <iframe> lazy loading
• 2017: Clear-Site-Data for Service Worker use at scale
• 2021: Web Codecs for video (but not audio)
• 2021: WASM SIMD for better ML and games
• 2020: Compression Streams
• 2018: Reporting API (for learning about crashes and metrics reporting)
• 2020: Screen Orientation & Screen Wake Lock APIs (critical for games)
• 2018: Offscreen Canvas (but only 2D, which isn't what folks really need)
• Critical usability and quality fixes for WebRTC

A number of improvements look extremely promising, but remain exclusive to macOS and iPadOS:

• Fullscreen API fixes
• AVIF and AV1 support

The lack of iOS support for the Canvas Fullscreen API continues to harm game makers; likewise, the lack of AVIF and AV1 holds media and streaming businesses back.

Regardless, Safari 16.4 is astonishingly dense with delayed features, inadvertantly emphasising just how far behind WebKit has remained for many years and how effective the Blink Launch Process has been in allowing Chromium to ship responsibly while consensus was witheld in standards by Apple. It simultaneously shows how effective the requirements of that process have been in accelerating catch-up implementations. By mandating proof of developer enthusiasm for features, extensive test suites, and accurate specifications, the catch-up process has been put on rails for Apple. The intentional, responsible leadership of Blink was no accident, but to see it rewarded so definitively is gratifying.

The size of the release was expected in some corners, owing to the torrent of WebKit blog posts over the last few weeks:

This is a lot, particularly considering that Apple has upped the pace of new releases to once every eight weeks (or thereabouts) over the past year and a half.

Good Things Come In Sixes #

The new cadence of releases started in September 2021 and represents a sea change all its own. Before Safari 15, Apple only delivered two substantial releases per year, a pattern that had been stable since 2016:

• New features were teased at WWDC in the early summer
• They landed in a Fall dot-oh release with the new iOS version
• A second set of feature updates would trickle out as part of a Spring point-one update.

In leaner years (2012-2015), a single Fall release was all we'd get. Two releases per year meant that, for a decade, progress on WebKit bugs was a roulette that developers lost by default. Leading browsers had moved to 6-week update cadence by 2011 at the latest, routinely delivering fixes at a quick clip.

Contrast that level of visible progress with Apple's manufactured scarcity around bug fix information. Recall that Cupertino manages the actual work of Safari engineers through Apple-internal systems (previously named "Radar"), making public bug reports a sort of parallel track; once an issue is imported from a public bug to a private tracker, it's more likely to get developer attention. However, aside from the reading of tea leaves, there's no way to know if work is progressing.

This lack of transparency is by design and provides Apple deniability while simultaneously setting low expectations, making them easier to exceed. What choice do developers have, but to sit and stew? Without competitive recourse, what will they do? Recommend a different browser?

Features had lower odds of being cherry-picked into the private stabilisation branch if they don't make the pre-WWDC stabilisation branch cut, dragging timelines for anticipated improvements past nine months in many cases. Given the dire state of WebKit, and the challenges contributors face helping to plug the gaps, serial heartbreak induced a learned helplessness in much of the web community. So little has changed for so long that some doubted it ever could.

But here we are, with eight releases a year and WebKit accelerating the pace at which it's closing the still large gap.

What Changed? #

Many big-ticket items are missing from this release — iOS fullscreen API for <canvas>, Paint Worklets, true PWA installation APIs for competing browsers, Device APIs (if only for installed web apps), etc. — but the pace is now blistering.

This is the power of just the threat of competition.

Apple's representatives have offered browser-based claims in court and in regulatory filings to defend App Store rapaciousness. They argued that if developers don't like its generous offer to take only 30% of their revenue, there's always Cupertino's highly capable browser to fall back on.

The only problem, of course, is that lawyers and regulators ask follow-up questions like "is it?" and "what do developers think?"

Which they did.

TL;DR: It wasn't, and developers had lots to say_.

This was, as they say, a bad look.

And so Apple hedged, slowly at first, but ever faster as 2021 bled into 2022 and the momentum of additional staffing began to pay dividends.

Headcount Is Destiny #

Apple had the resources needed to build a world-beating browser for many moons. The choice to ship a slower, less secure, less capable engine was precisely that: a choice.

Starting in 2021, Apple made a different choice, opening up dozens of Safari team positions. In the 2023 world of tech layoffs, this might just seem like the same sort of enthusiastic hiring all of Apple's competitors were engaged in, but recall that Cupertino had maintained extreme discipline about Safari staffing for nearly two decades. Feast or famine, Safari wouldn't grow, and Apple wouldn't put significant new resourcing into WebKit, no matter how far it fell behind.

The decision to hire, including some "big gets" in standards-land, indicated more was afoot, and the reason wasn't that Tim had suddenly lost his cool and started writing comedy-sized checks. No, this was a change in strategy. New problems needed new (old) solutions, namely:

The more up-to-date (within limits) Safari was the blunter argument for how engine choice might look. Combined with (previously winning) security scaremongering, reduced developer pressure might allow Cupertino to wriggle out of engine choice. Failing that, a more capable Safari provides fewer reasons for web developers to recommend another browser. It takes time to board up the windows before a storm, and if competition is truly coming, this burst of energy looks like a belated attempt to batten the hatches for competition.

It's critical for Apple to maintain narrative discipline with both developers and regulators. The dilatory attempt at catch-up only works if developers tell each other that these changes are an inevitable outcome of Apple's long-standing commitment to web developers and web apps (remember the first iPhone!?!). This was always part of the plan; nobody is making Cupertino do anything it doesn't want to do, nevermind the frantic regulatory filings and legal briefings.

But what if developers see behind the veil? What if they begin to reflect and internalise Apple's abandonment of web apps after iOS 1.0 as an (eventual) exercise of monopolistic power that held the web back for more than a decade?

That might lead developers to demand competition. Apple might not be able to ring-fence browser choice in one or a few geographies. The web might threaten Cupertino's ability to extract rents in precisely the way Apple represented in court that it already was.

Early Innings #

Rumours of engine ports are afoot. The plain language of the EU's DMA is set to allow true browser choice on iOS. But the regulatory landscape is not at all settled. Apple might still prevent progress from spreading. It might yet sue its way to curtailing the potential size and scope of the market that will allow for the web to actually compete, and if it succeeds in that, no amount of fast catch-up in the next few quarters will pose a true threat to native.

Consider the omissions:

• PWA installation prompting
• Fullscreen for <canvas>
• Improved codecs
• Web Transport
• WebGPU
• Device APIs

Depending on the class of app, any of these can be a deal-breaker, and if Apple isn't facing ongoing, effective competition, it can just reassign headcount to other, "more critical" projects when the threat blows over. It wouldn't be the first time.

So, this isn't over. Not by a long shot.

Safari 16.4 is an admission that Apple is spooked, but it isn't an answer. Only genuine browser competition can ensure the taps stay open.

---

1. Apple's standards engineers have a long and inglorious history of stalling tactics in standards bodies to delay progress on important APIs, like Declarative Shadow DOM (DSD).

   The idea behind this API was not new, and the intensity of developer sentiment had only increased since Dimitri's 2015 sketch. A 2017 attempt to revive it was shot down in 2018 by Apple engineers without evidence or data.

   Throughout this period, Apple would engage sparsely in conversations, sometimes only weighing in at biannual face-to-face meetings. It was gobsmacking to watch them argue that features were unnecessary directly to the developers in the room who were personally telling them otherwise. This was disheartening because a key goal of any proposal was to gain support from iOS. In a world where nobody else could ship-and-let-live, and where Mozilla could not muster an opinion (it did not ship Web Components until late 2018), any whiff of disinterest from Apple was sufficient to kill progress.

   The phrase "stop-energy" is often misused, but the dampening effect of Apple on the progress of Web Components after 2015-2016's burst of V1 design energy was palpable. After that, the only Web Components features that launched in leading-edge browsers were those that an engineer and PM were willing to accept could only reach part of the developer base.

   I cannot stress enough how effectively this dampened progress on Web Components. The pantomime of regular face-to-face meetings continued, but Apple just stopped shipping, and what at one point had been a grudging willingness to engage on new features turned into what I can only describe as a stalemate.

   But needs must.

   In early 2020, after months of background conversations and research, Mason Freed posted a new set of design alternatives, which included extensive performance research. The conclusion was overwhelming: not only was Declarative Shadow DOM now in heavy demand by the community, but it would also make websites much faster.

   The proposal looked shockingly like those sketched in years past. In a world where <template> exists and Shadow DOM V1 has shipped, the design space for Declarative Shadow DOM alternatives is not large. Without many competing options, we just needed to pick one. An updated proposal was presented to the Web Components Community Group in March 2020; Apple objected on spurious grounds, offering no constructive counter.[2]

   Residual questions revolved around the security implications of potentially changing parser behaviour, but these are also relatively straightforward. The first draft of Mason's Explainer even calls out why the proposal is less invasive than a whole new element.

   Recall that Web Components and the <template> element themselves were large parser behaviour changes; the semantics for <template> even required changes to the long-settled grammar of XML (long story, don't ask). A drumbeat of (and proposals for) new elements and attributes post-HTML5 also represent identical security risks, and yet we barrel forward with them. These have notably included <picture>, <portal> (proposed), <fencedframe> (proposed), <dialog>, <selectmenu> (proposed), and <img srcset>.

   The addition of <template shadowroot="open"> would, indeed, change parser behaviour, but not in ways that were unknowable or unprecedented in scope. Chromium's usage data, along with the HTTP Archive crawl HAR file corpus, provided ample evidence about the prevalence of patterns that might cause issues. None were detected.

   And yet, at TPAC 2020, Apple's representatives continued to press the line that unworkably large security issues were at issue. This was all considered at length. Google's security teams audited the colossal volume of user-generated content Google hosts for problems and did not find significant concerns. And yet, Apple continued to apply stop-energy.

   The feature eventually shipped with heavy developer backing as part of Chromium 90 in April 2021 but without consensus in the community group. Apple persistently repeated objections that had already been answered with patient explication and evidence.

   Apple is now implementing this same design, and Safari may have DSD as soon as summer or (more likely) Fall 2023.

   I don't mean to imply this has been the worst case of Apple malfeasance and delay — looking at you, Push Notifications — but rather as an exemplar of the high-stakes games that Apple (and, to a lesser extent, Mozilla) have forced problem solvers to play over their dozen years of engine disinvestment.

   Even in Chromium, DSD was delayed by several quarters. Because of the Apple Browser Ban, full ecosystem availability was further postponed by at least two years. The fact that Apple will ship DSD without changes and without develop counterproposals across the long arc of obstruction indicates that they were not being cautious or thoughtful.

   The only folks to bring data to the party were Googlers and web developers. No new thing was learned through spurious objections. No new understanding was derived from the delay. Apple did no research about the supposed risks. It has yet to argue why it's safe now, but wasn't then.

   So let's call it what it was: concern trolling.

   Uncritical acceptance of the high-quality design it had long delayed is an admission, of sorts, by Apple. It shows a fundamental disinterest in meeting developer and user needs (until pressed) and an unseriousness in engineering rigor, all paired with great skill at deflection. The playbook is simple:

   • Use opaque standards processes to make it look like occasional attendance at a F2F meeting is the same thing as good-faith co-engineering.
   • "Just ask questions" when you don't want to do the work.
   • Spread FUD about the security or privacy of a meticulously-vetted design.
   • When all else fails, say you will formally object and then claim that others are "shipping whatever they want" and "not following standards" when they carefully launch a vetted, specced, and tested design you were long consulted about but withheld good faith engagement to improve.

   The last step works because only the most informed insiders can distinguish between legitimate critiques and standards process jockeying. Hanging the first-mover risk around the neck of those working to solve problems you don't want to is nearly cost-free when you can also prevent designs from moving forward through standards processes through.

   Play this same anti-constructive dynamic out over dozens of features across a decade, and you'll better understand why Chromium participants get exercised about responsibility theatre by various Apple engineers. Understood in context, it decodes as delay and deflection from using standards bodies to help actually solve problems.

   Cupertino has paid no price for deploying these smoke screens, thanks to the Apple Browser Ban and a lack of curiosity in the press. Without those shields, Apple engineers would have had to offer convincing arguments from data for why their positions were correct. Instead, they have whatabouted for over three years, only to suddenly implement proposals they recently opposed when the piercing gaze of regulators finally fell on WebKit.[3]↩︎

2. The presence or absence of a counterproposal when objecting to a design is a primary indicator of seriousness within a standards discussion. All parties will have been able to examine proposals before any meeting, and in groups that operate by consensus, blocking objections are understood to be used sparingly by serious parties.

   It's normal for disagreements to surface over proposed designs, but engaged and collaborative counter-parties will offer soft concerns — _"we won't block on this, but we think it could be improved..." — or through the offer to bring a counterproposal. The benefit of a concrete counter is large. It demonstrates good faith in working to solve the problem and signals a willingness to ship the offered design. Threats to veto, or never implement a specific proposal, are just not done in the genteel world of web standards.

   Over the past decade, making veto threats while offering neither data nor a counterproposal have become a hallmark of Apple's web standards footprint. It's a bad look, but it continues because nobody in those rooms wants to risk pissing off Cupertino. Your narrator considered a direct accounting of just the consequences of these tactics a potentially career-ending move; that's how serious the stakes are.

   The true power of a monopoly in standards is silence, the ability to get away with things others blanch at because they fear you'll hold an even larger group of hostages next time. ↩︎

3. Apple has rolled out the same playbook in dozens of areas over the last decade, and we can learn a few things from this experience.

   First, Apple does not care about the web. It grudgingly implements when pressured, not out of its own volition or interest.

   Next, external pressure must be maintained. Cupertino must fear losing their market share for doing a lousy job. That's a feeling that hasn't been felt near the intersection of I-280 and CA Route 85 in a few years. For the web to deliver for users, gatekeepers must sleep poorly.

   Lastly, Apple had the capacity and resources to deliver a richer web for a decade but simply declined. This was a choice — a question of will, not of design correctness or security or privacy.

   Safari 16.4 is evidence, an admission that better was possible, and the delaying tactics were malignant gaslighting. Apple will disrespect the legitimate needs of web developers when allowed, so it must not be.

   Lack of competition was the primary reason Apple feared no consequence for failing to deliver. Apple's protectionism towards Safari's participation-prize under-achievement hasn't withstood even the faintest whiff of future challengers, which should be an enduring lesson: no vendor must ever be allowed to deny true and effective browser competition. ↩︎