An Abridged History of Safari Showstoppers
Roderick E.J.H. Gadellaa (Hacker News):
As noted elsewhere, a developer-lamented but regulator-overlooked aspect of Apple’s monopoly on iOS browser engines has been the prevalence of show-stopping bugs.
We define “showstoppers” here as bugs that cause working apps to become entirely broken or inadvisable to use on the web.
All browsers have issues, but iOS is unique in depriving users of choices that developers can recommend when the system-provided engine breaks. Users and developers have literally no choice; they can’t choose a different browser to work around Apple’s frequent bouts of platform breakage. How bad is it? To get a sense for the impact, we’ve laid out the worst issues of the past decade. We’ve also included a rough estimate of the fraction of time when web apps would have worked as advertised on iOS but for Apple’s implementation… hiccups.
Via Alex Guyot:
These bugs heavily impact websites and web apps that are trying to build more sophisticated experiences on the web. They affect a wide variety of platform features which Apple itself claims to be stable and fully-supported. Safari is the only major browser that consistently ships bugs this nasty, and especially the only one that leaves them there for years.
[…]
The web isn’t an app store where you can list your site for only certain operating systems. People aren’t going to build ambitious PWAs when anyone who actually manages to install them on iOS is met with a broken experience.
I agree (and love it!) that Safari’s been improving on web standards recently, but this is also the year in which Apple almost killed PWAs with no notice, and has a bug in iOS 18 where keyboards don’t show up in PWAs in the EU.
People often think native apps are better due to “performance of compiled code” but it’s actually due to “not a hostile, buggy, artificially API-poor environment”.
In the fullness of time, the web will win due to its superior deployment model and developer freedom. The days are long but the decades are short.
I was all-in on mobile web apps, but apple’s policy around iOS and browsers pretty much forced my hand. I had to watch how a native app team rewrote the web app I had already built, with the same feature set, except with notifications and more offline storage, crucial requirements at the time. This was over a decade ago, and while things have gotten a little better, the gap between what a web developer can do on iOS and what a native developer can do has never been wider.
Too many don’t understand Apple’s privacy stance, which has some reasonable elements, is being used to massively foot drag on everyone else trying to build an open web ecosystem.
Previously:
- Does Google Chrome Still Devastate Mac Battery Life?
- EU iOS Envy
- Safari 18 Announced
- iOS 17.4 Changes PWAs to Shortcuts in EU
- DMA Compliance: Alternative Browser Engines
- Web Push for Web Apps on iOS and iPadOS
- The Time to Fix Web Security Bugs
- The Danger of Sideloading Chromium
- Catching Native Apps
- Safari Frustrations
- Sketch on Native Mac Apps
- Is WebKit Sabotaging the Future of the Open Web?
- The Hotel Cupertino Clause
- Safari Is the New IE
Update (2024-10-01): Jeff Johnson:
Hanlon’s razor applies here. Apple is not deliberately trying to wreck web apps, any more than Apple is deliberately trying to wreck Safari extensions, or Safari itself, its user interface.
I think it’s probably neither malice nor stupidity. Apple just cares about different things so they have different priorities. That’s why it’s good for there to be a diversity of browser engines and for platform features like SMS auto-fill to not be restricted to Safari.
Update (2024-10-03): Uli Kusterer:
Safari is completely broken. No matter which page I visit, even just local HTML files, it goes “This web page was reloaded because a problem occurred”. Repeatedly.
It’s absurd that in the year 2024, Safari web extensions still don’t support match_about_blank.
This should have been a showstopping bug in 2020.
Update (2024-10-10): MurphysLaw:
So, I am currently in a Grad Program to get my teaching license and it is all online. I realized that Blackboard - the web software schools use to manage online classes - is not optimized for Safari only after the assignment was past due. It was running into errors that I did not even realize. My Grad School and the District that I work in both have this Frankenhybrid system of Google on top of Microsoft and as much as I hate to say it, the iPad without real Chrome is frustrating to use.
[…]
So either (A) Apple has to unleash Safari to make it worth web developers time or they (B) need to let real chrome on the iPad before anyone can consider it a “real” computer.
6 Comments RSS · Twitter · Mastodon
I don‘t like PWAs because I can’t have control about the version I‘m using. They can change completely every second or get be hacked. One thing I only like is the control I have with adblockers and that I can fix bad design decisions by injecting CSS. But that’s also a security problem and only a cure for deeper problems.
I'd also like to know the reverse: what Safari does /better/ than Chrome or Firefox. The consensus is that Safari is no longer better for battery life and its benchmark gains are generally not felt. But what features has Safari pushed into existence that other browsers lagged on? Maybe some color and effects at CSS Level 5? Maybe JpegXL recently?
For as many showstoppers as Safari has, what does the reverse look like? What does web dev look like without Safari? Does Firefox become the new IE?
Safari feels like there is so much tech debt and they're slow to ship fixes. But that seems like a function of Apple as an organization -- just trying to get them to fix any bug in any of their stuff takes forever. Their approach to software dev is rotten.
Do you think there is value to users if Safari re-based off of something like Ungoogled Chromium or Firefox? It'd be a hell froze over moment, but even Microsoft threw in the towel.
@Captain Hammer - Being Default and KeyChain / iCloud Password. Support Online Password reuse in Apps.
10 years later Safari still dont have Tabs suspension. Bookmark, History and address bar is the slowest ( or has been the slowest ) compared to Chrome and Firefox. Webkit on the other hand picked up a lot of bug fix and features in the past 3-4 years. But it is still lagging behind somewhat.
@Nils Or... it's a perfect way for devs to ensure that bugs and security holes are solved for all users. A nice way of ensuring that everyone is on the same feature set so that you can free up time for developers and focus on what's important.
@Captain Hammer - It's tab groups for me. Totally changed my browser workflow, much lower friction than trying to use bookmarks.
I accept that PWAs *can* be useful, especially if they're self-hostable.
But the problem really is that native apps are designed using a sensible abstraction for software, where the OS provides a UI toolkit that a developer uses to build efficiently rendered apps, with functionality built in, especially accessibility and keyboard interaction, where web apps are usually nothing like as refined or dependable. Web app devs just don't want to hear that, but it should go without saying that layering boatloads of shite written in JavaScript in order to implement a complete UI layer is simply not going to provide the same experience for people who rely on that kind of consistency and usability which your platform gives you for free. And it is rare that webapps break this trend; in fact the only example I can think of, ironically, is 1Password, which of course was once a native Mac app, where it's clear that a great deal of attention has been given to restoring that functionality, and even then rather imperfectly.
