Apple's Safari browser runs the risk of becoming the new Internet Explorer – holding the web back for everyone

WebKit engine is well behind the competition

The legacy of Internet Explorer 6 haunts web developer nightmares to this day. Microsoft's browser of yore made their lives miserable and it's only slightly hyperbolic to say it very nearly destroyed the entire internet. It really was that bad, kids. It made us walk to school in the snow. Uphill. Both ways. You wouldn't understand.

Or maybe you would. Today developers who want to use "cutting-edge" web APIs find themselves resorting to the same kind of browser-specific workarounds, but this time the browser dragging things down comes from Apple.

Apple's Safari lags considerably behind its peers in supporting web features. Whether it's far enough behind to be considered "the new IE" is debatable and may say more about the shadow IE still casts across the web than it does about Safari. But Safari – or more specifically the WebKit engine that powers it – is well behind the competition. According to the Web Platform Tests dashboard, Chrome-based browsers support 94 per cent of the test suite, and Firefox pulls off 91 per cent, but Safari only manages 71 per cent.

On the desktop this doesn't matter all that much because users can always switch to Google Chrome (or even better, Vivaldi). On iOS devices, however, that's not possible. According to Apple's App Store rules: "apps that browse the web must use the appropriate WebKit framework and WebKit Javascript." Every iPhone user is a Safari/WebKit user whether they use Safari or Chrome.

Apple has a browser monopoly on iOS, which is something Microsoft was never able to achieve with IE. In Windows you could at least install Firefox. If you do that on iOS it might say Firefox, but you're still using WebKit. The reality is if you have an iOS device, you use Safari and are bound by its limitations.

Another thing web developers find distressing is Apple's slow development cycle. Apple updates Safari roughly every six months at best. Blink-based browsers update every six weeks (soon every four), Firefox releases every four weeks, and Brave releases every three. This means that not only is Apple slow to add new features, but its development cycle means that even simple bug fixes have to wait a long time before they actually land on users' devices. Safari workarounds are not quick fixes. If your website is affected by a Safari bug, you can expect to wait up to a year before the problem is solved.

One theme that emerges when you dig into the Web Platform Tests data on Safari's shortcomings is that even where WebKit has implemented a feature, it's often not complete. Take the case of progressive web apps (PWAs). Progressive web apps is an umbrella term of websites that want to behave like native mobile applications. Some of the APIs used to build PWAs include the ability to run full screen (no browser UI), send notifications and alerts, offline capabilities, and launch from an icon on your home screen. Probably the two best-known examples of PWAs are Twitter and Uber.

Apple has implemented much of what developers need to build PWAs, but there are limitations. Apple hasn't added support for sending notifications and home screen icons. In essence Apple hasn't implemented some of the core features that make websites able to behave in an app-like way.

This has long been the core of the argument that Apple is deliberately crippling WebKit to protect its App Store business. In other words, if Apple implements these things, developers will start building better web apps, no one will buy native apps, and Apple will lose its 30 per cent cut of the iOS App Store.

That might make sense to web developers, who are deeply passionate about building web apps, but it doesn't make much sense outside that context. Apple is one of the wealthiest companies on Earth, and it probably isn't too worried about what web developers are going to do with all those fantastic new APIs it isn't supporting. Apple is certainly protecting its interests, but at least right now that seems to be more related to Apple's move to position itself as the protector of user privacy than worry about web apps.

Is Safari saving the web?

Safari's defenders, and Apple itself, argue that the company isn't implementing all these new APIs because letting developers have access to your USB ports, Bluetooth, battery status, and proximity sensor will allow advertisers to build device "fingerprints" which further erode privacy, to say nothing of the impact on battery life.

I don't own any iOS devices but, in all honesty, Apple's stance here almost makes me want one.

I should probably admit now that I hate the modern web. I don't really worry all that much because having a mobile device and having privacy are mutually exclusive. I punt on privacy, but I find the experience of modern websites so unreliable, slow, and overall user-hostile that I prefer to do literally anything else.

I dislike the experiences enabled by JavaScript-driven web APIs so much I've taken to browsing with JavaScript disabled. This returns the web to a beautiful, clean simplicity that would probably make Apple happy. Sites that load without JavaScript I read – sites that don't I can't be bothered. Yes, I am serious. If Invidious can load YouTube content without JavaScript, why can't YouTube? I don't know and I don't care. I wrote a script to make sure I am always redirected to Invidious (PeerTube is a better alternative) but I digress.

My point is, I want to support Apple here, but unfortunately I think the argument that Apple is holding Safari back to protect user privacy is weak. While I don't think Apple is all that worried about web developers hurting its App Store profits, I also don't think the company is big enough to ignore the web completely and not suffer the consequences. That is, Apple may believe that it's acting to protect user privacy, but it won't work.

Failing to implement these APIs hasn't stopped them from being adopted in every other browser. It will take a while, but we already know how this story ends. It ends like it ended for Internet Explorer: Microsoft lost. Everyone else moved on and eventually Microsoft was the company with the product no one wanted. If Apple goes down that road, not only will Apple lose, but the web will as well. Because the Apple defenders are right about one thing: if Apple doesn't stand up to Google's Blink juggernaut, it doesn't look like anyone else will either.

Just what does that juggernaut look like? Web developer Tim Perry recently pointed out that once upon a time every browser was offering their own add-on APIs. But, as Perry writes, "Chrome effectively dominated developer mindshare, provided more powerful and easier to use extension APIs that became far more popular, and both Firefox and Safari … killed their own APIs and accepted Chrome's, unintentionally allowing Google to unilaterally set the web extension standard." This is what happens when no-one is around to push back against the market leader.

Now the same thing is happening with dev tools and APIs. "Chrome is following the same path today," writes Perry, "offering web developers more powerful tools and a better development experience (better devtools, fewer bugs) than Safari. If nothing changes, the outcome is likely to be similar. This is bad."

How Apple really could help the web

What the web needs is someone to put the brakes on Google and Blink and make sure that the APIs being created are good for web users. Not just good for Google users. Not just good for Apple users. Not just good for web developers. Good for everyone.

Too much of modern web feature development happens in silence with very little debate. Blink developers propose features by shipping them in Chrome behind a developer flag. At that point there's already a working implementation and debate is difficult – if not impossible.

I'm not suggesting that Apple would have impure motives, but it seems like perhaps its vision for Safari might, temporarily at least, be helpful to the web standards process … if Apple could change how it approaches Safari.

It's probably a pipe dream. But as long-time web advocate (and former Opera evangelist) Bruce Lawson recently wrote: "If Apple allowed Safari to actually compete, it would be better for web developers, businesses, consumers, and for the health of the web."

If Apple were less opaque and faster in its development process it could participate more in the debate over new APIs. If the company truly has concerns about the privacy implications of APIs, then it should voice them. Push back against Google, and provide a real alternative to Chrome. It wouldn't be easy, but it might be the only hope we have. ®

Source