Until its recent demise, Internet Explorer was the browser hated most by web developers.
Internet Explorer is now a thing of the past, replaced by the far-better Microsoft Edge.
Why did developers and software engineers hate IE so much? Because IE was seriously outdated, lacking support for cutting-edge web APIs and technologies enabling the modern websites and web apps we use today.
With IE now out of the way, the distinction of ‘most-hated browser’ goes to Apple’s Safari – which all along had been a close second to IE.
In a similar vein, Safari has consistently lagged behind competing browsers in supporting modern web APIs and features, presenting considerable challenges for developers wanting to create products that work consistently across all the major browsers (Chrome, Edge, Firefox, and Safari).
However, the annoyance with Safari gets deeper and more nuanced, which I’ll explain further below.
Progressive web apps
Did you know that it’s possible today to create something for your browser that works like a native app on your device?
This is enabled through what’s known as progressive web apps (PWAs) – a collection of modern browser technologies that together let you create a site that looks, feels, and performs similar to a native app on your smartphone, tablet, or desktop.
Progressive web apps are really cool, because they can give you the following capabilities that you would normally expect with a native app:
- Run full-screen (no visible browser UI)
- OS-level notifications and alerts
- Ability to use the app when the device is offline
- Local data storage and retrieval
- Install an app icon on your smartphone’s home screen
- Access to hardware functions such as the camera, microphone, USB port, etc.
Apple dragged their feet in adding support for PWAs in Safari, and when they finally did, limited the capabilities of a PWA so that native-like app functionality wouldn’t be possible, like notifications or a home screen icon shortcut – to name just a few of the many restrictions imposed by Apple.
But it goes beyond that. On iOS, the only web rendering engine allowed is Apple’s own WebKit, which runs Safari. Third-party iOS browsers such as Chrome can only use WebKit, not their own engines (as would be permitted in Windows, Android, or macOS). And it’s WebKit that governs PWA capabilities.
The reason for Apple’s self-imposed limitations on PWA-related web APIs? They’ll tell you they’re for user privacy reasons, which may be valid in certain cases.
But most of us know the dominant reason is because fully-capable PWAs would compete against the iOS App Store – robbing Apple of 30% cut in revenue it rakes in when an app is purchased, or an in-app purchase is executed.
Until recently, the controversy over Apple’s halting PWA support was fairly confined to the web developer community. But now, it’s been laid bare to the public, thanks to the Epic vs. Apple case, and the possibility of anti-trust regulatory actions.
Apple may ultimately be compelled to fully expand PWA or third-party iOS browser support as a concession to satisfy government regulators. We’ll see what happens.
Lagging support for WebRTC and other features
Web developers and engineers have long lamented about slow or lack of support of key web APIs and CSS features that are commonly available with other browsers.
… Apple don’t give a f**k about any modern APIs. PWA, streams, who the f**k needs that? Well, dear Apple, a f**king lot of web devs need that nowadays.
Take WebRTC, for example. WebRTC is prominently used in video and audio communications over the web. It’s also used to send files, and share screen content.
Apple took years to finally add WebRTC support to Safari, far enough behind Chrome and Firefox that it practically became a running joke among developers and even industry observers.
Despite the support now available, WebRTC is known to be buggier on Safari desktop compared to other browsers. Developers have found it a mess to support in iOS that it’s practically not even worth the effort.
There’s been past criticism for Safari not supporting the VP9 video codec or the WebP image compression format. Some good news: as of late 2020 they’re now supported – though it’s worth nothing they’ve been around for years with other browsers and have proven very popular.
Now, Apple just needs to get its act together and support the AV1 video codec and related AVIF image format. This may be a tall order, though, since Apple collects royalties for the competing HEVC codec, and is a big proponent of the HEIC image format.
Bug and infrequent updates
I often read about developers frustrated with the many bugs in Safari’s implementation of web APIs and CSS features, and in particular, the slowness of seeing them addressed.
How are we supposed to keep up with this? Isn’t Apple one of the richest company in the world? Invest in your f**king browser.
Further contributing to the frustration is the fact that unlike Chrome or Firefox, Safari updates are not automatic on regular basis. They’re only shipped together with the infrequent updates to the entire OS.
Seriously! Microsoft employs automatic updates to the Edge browser. So surely, Apple can find the *courage* to do so as well.
A matter of priorities
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.
The enormous popularity of iOS makes it all the more annoying that Apple continues to hold back developers from being able to create great experiences over the web that work across all platforms.
But not exactly surprising either, given that Apple has staked its future on service-based revenue that includes sales generated from the App Store.
Apple has been known to stand down in the face of public pressure. Maybe there will be enough of it to lead to some serious changes to Safari.