Updating Safari
Tags: apple, safari, webkit, browsers
Published: 2021-08-10 16:57:23

---
title: Updating Safari
published: true
date: 2021-08-05 07:42:10 UTC
tags: apple,safari,webkit,browsers
canonical_url: https://adactio.com/journal/18335
---

Safari has been subjected to a lot of ire recently. Most of that ire has been aimed at the proposed changes to the navigation bar in Safari on iOS—moving it from a fixed top position to a floaty bottom position right over the content you’re trying to interact with.

Courage.

It remains to be seen whether this change will actually ship. That’s why it’s in beta—to gather all the web’s [hot takes](https://daringfireball.net/2021/07/safari_15_public_betas_for_mac_and_ios) first.

But while this very visible change is dominating the discussion, invisible changes can be even more important. Or in the case of Safari, the _lack_ of changes.

Compared to other browsers, Safari lags far behind when it comes to shipping features. I’m not necessarily talking about cutting-edge features either. These are often standards that have been out for years. This creates a gap—albeit an invisible one—between Safari and other browsers.

[Jorge Arango has noticed this gap](https://jarango.com/2021/07/02/back-to-the-bad-old-days-of-the-web/):

> I use Safari as my primary browser on all my devices. I like how Safari integrates with the rest of the OS, its speed, and privacy features. But, alas, I increasingly have issues rendering websites and applications on Safari.

That’s the perspective of an end-user. Developers who have to deal with the gap in features are more, um, strident in their opinions. Perry Sun wrote [For developers, Apple’s Safari is crap and outdated](https://blog.perrysun.com/2021/07/15/for-developers-safari-is-crap-and-outdated/):

> Don’t get me wrong, Safari is very good web browser, delivering fast performance and solid privacy features.
> 
> But at the same time, the lack of support for key web technologies and APIs has been both perplexing and annoying at the same time.

Alas, that post also indulges in speculation about Apple’s motives which always feels a bit too much like a conspiracy theory to me. Baldur Bjarnason has more to say on that topic in his post [Kremlinology and the motivational fallacy when blogging about Apple](https://notes.baldurbjarnason.com/2021/07/28/kremlinology-and-the.html). He also points to a good example of critiquing Safari without speculating about motives: Dave’s post [One-offs and low-expectations with Safari](https://daverupert.com/2021/07/safari-one-offs/), which documents all the annoying paper cuts inflicted by Safari’s “quirks.”

Another deep dive that avoids speculating about motives comes from Tim Perry: [Safari isn’t protecting the web, it’s killing it](https://httptoolkit.tech/blog/safari-is-killing-the-web/). I don’t agree with everything in it. I think that Apple—and Mozilla’s—objections to some device APIs are informed by a real concern about privacy and security. But I agree with his point that it’s not enough to just object; you’ve got to offer an alternative vision too.

That same post has a litany of uncontroversial features that shipped in Safari _looong_ after they shipped in other browsers:

> Again: these are not contentious features shipping by only Chrome, they’re features with wide support and no clear objections, but Safari is still not shipping them until years later. They’re also not shiny irrelevant features that “bloat the web” in any sense: each example I’ve included above primarily improving core webpage UX and performance. Safari is slowing that down progress here.

But perhaps most damning of all is how Safari deals with bugs.

A recent release of Safari shipped with [a really bad Local Storage bug](https://bugs.webkit.org/show_bug.cgi?id=225344). The bug was fixed within a day. Yay! But the fix won’t ship until …[who knows](https://twitter.com/chris_dumez/status/1389695856027209728)?

This is because browser updates are tied to operating system updates. Yes, this is just like the 90s when Microsoft claimed that Internet Explorer was intrinsically linked to Windows (a tactic that didn’t work out too well for them in the subsequent court case).

I don’t get it. I’m pretty sure that other Apple products ship updates and fixes independentally of OS releases. I’m sure I’ve received software updates for Keynote, Garage Band, and other pieces of software made by Apple.

And yet, of all the applications that _need_ a speedy update cycle—a user agent for the World Wide Web—Apple’s version is needlessly delayed by the release cycle of the entire operating system.

I don’t want to speculate on why this might be. I don’t know the technical details. But I suspect that the root cause might not be technical in nature. Apple have always tied their browser updates to OS releases. If Google’s cardinal sin is avoiding anything “Not Invented Here”, Apple’s downfall is “[We’ve always done it this way](https://quoteinvestigator.com/2014/11/27/always-done/).”

Evergreen browsers update in the background, usually at regular intervals. Firefox is an evergreen browser. Chrome is an evergreen browser. Edge is an evergreen browser.

Safari is not an evergreen browser.

That’s frustrating when it comes to new features. It’s unforgivable when it comes to bugs.

At least on Apple’s desktop computers, users have the choice to switch to a different browser. But on Apple’s mobile devices, [users have no choice but to use Safari’s rendering engine](https://adactio.com/journal/17428), bugs and all.

As I wrote [when I had to deal with one of Safari’s bugs](https://adactio.com/journal/17605):

> I wish that Apple would allow other rendering engines to be installed on iOS devices. But if that’s a hell-freezing-over prospect, I wish that Safari updates weren’t tied to operating system updates.