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:
- : Web Push for iOS (but only for installed PWAs)
- : PWA Badging API (for unread counts) and
idsupport (making updates smoother) - : 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, including:
- Myriad small CSS improvements and animation fixes, but also:
- :
<iframe>lazy loading - :
Clear-Site-Datafor Service Worker use at scale - : Web Codecs for video (but not audio)
- : WASM SIMD for better ML and games
- : Compression Streams
- : Reporting API (for learning about crashes and metrics reporting)
- : Screen Orientation & Screen Wake Lock APIs (critical for games)
- : 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 accelerated through 2021 and into 2022.
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.
from Hacker News https://ift.tt/9rMCbIs
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.