Op-ed: Safari is the new Internet Explorer

Last weekend I attended EdgeConf, a conference populated by many of the leading lights in the Web industry. It featured panel talks and breakout sessions with a focus on technologies that are just now starting to emerge in browsers, so there was a lot of lively discussion around Service Worker, Web Components, Shadow DOM, Web Manifests, and more.

EdgeConf’s hundred-odd attendees were truly the heavy hitters of the Web community. The average Twitter follower count in any given room was probably in the thousands, and all the major browser vendors were represented—Google, Mozilla, Microsoft, Opera. We had lots of fun peppering them with questions about when they might release such-and-such API.

There was one company not in attendance, though, and it served as the proverbial elephant in the room that no one wanted to discuss. I heard it referred to cagily as “a company in California” or “a certain fruit company.” Its glowing logo illuminated nearly every laptop in the room, and yet it seemed like nobody dared speak its name. Of course I’m talking about Apple.

I think there is a general feeling among Web developers that Safari is lagging behind the other browsers, but when you go to a conference like EdgeConf, it really strikes you just how wide the gap is. All of the APIs I mentioned above are not implemented in Safari, and Apple has shown no public interest in them. When you start browsing caniuse.com, the list goes on and on.

Even when Apple does implement newer APIs, it often does it halfheartedly. To take an example close to my heart, IndexedDB was proposed more than five years ago and has been available in IE, Firefox, and Chrome since 2012. Apple, on the other hand, didn’t release IndexedDB until mid-2014, and when it did, it unveiled a bafflingly incompetent implementation that was so bad, it’s been universally derided as unusable. (LocalForage, PouchDB, and YDN-DB, the major IndexedDB wrappers, all ignore Safari’s version and fall back to WebSQL.)

Now, after one year, Apple has fixed a whopping two bugs in IndexedDB (out of several), and it has publicly stated that it doesn’t find much value in working on it, because it doesn’t see “a huge use.” Well duh, nobody’s going to use IndexedDB if the browser support is completely broken. (Microsoft, I’m looking at you, too.)

It’s hard to get insight into why Apple is behaving this way. It never sends anyone to Web conferences, its Surfin’ Safari blog is a shadow of its former self, and nobody knows what the next version of Safari will contain until that year’s WWDC. In a sense, Apple is like Santa Claus, descending yearly to give us some much-anticipated presents with no forewarning about which of our wishes he’ll grant this year. And frankly, the presents have been getting smaller and smaller lately.

In recent years, Apple’s strategy toward the Web can most charitably be described as “benevolent neglect.” Although performance has been improving significantly with JSCore and the new WKWebView, the emerging features of the Web platform—offline storage, push notifications, and “installable” webapps—have been notably absent on Safari. It’s tempting to interpret this as a deliberate effort by Apple to sabotage any threats to its App Store business model, but a conspiracy seems unlikely since that part of the business mostly breaks even. Another possibility is that it's just responding to the demands of iOS developers, which largely amount to 1) more native APIs and 2) Swift, Swift, Swift. But since Apple is pretty good at keeping a lid on its internal process, it’s anyone’s guess.

The tragedy here is that Apple hasn’t always been a Web skeptic. As recently as 2010, back when Steve Jobs famously skewered Flash while declaring that HTML5 is the future, Apple was a fierce Web partisan. Lots of the early features that helped webapps catch up to native apps—ApplicationCache, WebSQL, touch events, touch icons—were enthusiastically implemented by WebKit developers, and many even originated at Apple.

Around that same time, when WebSQL was deprecated in favor of IndexedDB, you can even find mailing list arguments where Apple employees vigorously defended WebSQL as a must for performant Web applications. Reading the debates, I sense a lot of bitterness from Apple after IndexedDB won out. The irony here is that Apple nearly gave us the tools to undermine its own proprietary platform, but by rejecting WebSQL, we gave it an opportunity to rethink its strategy and put the brakes on any new progress in Web APIs.

I find Application Cache, which will probably soon be deprecated in favor of Service Worker, to be a similar story. It gained wide browser support at a time when Apple was still interested in the Web, but unfortunately it turned out to be a rushed, half-baked solution to the problem. I worry that Service Worker might suffer the same fate as IndexedDB if Apple continues to lag behind the pack.

At this point, we in the Web community need to come to terms with the fact that Safari has become the new IE. Microsoft is repentant these days, Google is pushing the Web as far as it can go, and Mozilla is still being Mozilla. Apple is really the one singer in that barbershop quartet hitting all the sour notes, and it’s time we start talking about it openly instead of tiptoeing around it like we’re going to hurt somebody’s feelings. Apple is the most valuable company in the world; it can afford to take a few punches.

So what can we do when one of the major browser vendors is stuck in the 2010 model and, furthermore, has a total monopoly on iOS (because no, “Chrome for iOS” is not really Chrome) showing a brazenness even beyond that of '90s-era Microsoft? I see three major coping mechanisms:

1. Stick with what worked in 2010 and use polyfills to support Safari. This is a strategy I highlighted in my opening talk for the frontend data panel, where I showed that you can get nearly the same features as Service Worker by using AppCache and PouchDB (which falls back to WebSQL on Safari). This approach should appeal to the vast majority of Web developers, who tend to hit the snooze button on new technologies until they’re available cross-browser. On the other hand, it’s also a good way to coddle Apple and give it no incentive to step up its game.
2. Use technologies like Service Worker that don’t work on Safari and consider it a progressive enhancement. Alex Russell made a great point about this during the “installable webapps” breakout, arguing that if we create a large body of free webapps that use Service Worker and which work fabulously well on Android but only meh on iOS, then it will be in Apple’s interest to suck it up and support the API. Unfortunately, while this would be the best outcome for the Web community as a whole, it’s going to be hard to convince developers to write code that only reaches half their audience.
3. Contribute to WebKit. The core of Safari is still, after all, an open source project, so there’s no practical reason why anyone with the C++ chops couldn’t roll up their sleeves and implement the new APIs themselves. (The absurdity of giving free labor to the richest company on earth isn’t lost on me, but we’re talking desperate times here.) The major problem I see with this approach is that WebKit is not Safari, and Apple could still decide to not deploy WebKit features to its flagship browser. To circle back to IndexedDB again, it was fully implemented by Google well before the Blink fork, and for several years, Apple could have just flipped a bit in its build script to include Google’s implementation. Instead, it decided to waffle for a few years and then replace it with its own broken version. There’s no guarantee it wouldn’t do the same thing for other outside contributions.

I don’t know what the right solution is. I’ve engaged many of the WebKit developers on Twitter, and I’ve even done the hard work of writing reproducible test cases and trying out its beta software so I can give it early warning. (Yes, I fork over $200 a year to Apple for the privilege of testing its own software for it.) And frankly I’ve grown bitter, because most of the bugs I’ve reported have languished with little response other than a link to its internal Radar tracker.

I appreciate the work that many of the WebKit developers have been doing (Brady Eidson has been particularly patient and helpful), but at this point it seems to me that the best strategy toward Apple may be the stick rather than the carrot. So I’m inclined to take up Alex Russell’s solution outlined in #2 above and start promoting the adoption of new Web technologies—Safari support be damned.

If we can start building a vibrant ecosystem of Web applications where Apple is not invited, then maybe it’ll be forced to pull a Microsoft and make its own penitent walk to Canossa. Otherwise we’ll have to content ourselves with living in the Web of 2010, with Safari replacing IE as the blue-tinged icon that fills Web developers with dread.