Is Chrome the New IE? (2023)

SSE's

W3C draft standard in 2012. Supported in Safari in 2010.

web sockets

This one is true. IETF standard 2011. Supported fully in Safari 2013.

IndexedDB API

W3C recommended standard in 2015. Supported in Safari in 2014.

animations

If we're talking the Web Animations API, it hasn't been standardized yet (W3C working draft) and level 2 isn't even that far.

relative color syntax

Not standardized yet. It's currently a W3C working draft.

container queries

Not standardized yet. It's currently a W3C working draft.

a bunch of <video> stuff

Need specifics.

flexbox

W3C candidate recommendation 2018. Supported in Safari 2013.

Rather than go through every single point (because I don't have all day), I'll just pick one:

> IndexedDB API

> W3C recommended standard in 2015. Supported in Safari in 2014.

No.

It didn't work in 2014, it wasn't working until 2016. (see: https://gist.github.com/nolanlawson/08eb857c6b17a30c1b26)

So what? It was recommended in 2015 and was working in 2016, what's the big deal?

The big deal is that if you tried to see if you could use it at all, you would get false information:

```js

function indexedDBOk() {

    return "indexedDB" in window;

```

This returned true on Safari, all of the functions did, and a bunch of them looked like they worked too, until they completely bugged out.

So we couldn't use them until it was fixed, *and* because you can't reliably use features until the last two major versions of a browser support those feature and because Safari releases updates locked to OS updates, that means that it wasn't what most would consider "supported" until nearly 2018.

That feature that every other browser had working since 2012 wasn't "working" until almost 2018, for Safari, and worse than that 6 year difference, they lied about it working.

So you could spend 6 months working on a project, release your product, then get inundated with bad reviews because it didn't work for half the population with iPhones.

And instead of improving your project, you have to either try to retrofit the base storage layer of your app, or build a new product based on a different tech. That's assuming you were lucky enough to have the runway to continue and not just have your project fail.

They weren't just late, they lied and those lies harmed developers.

Maybe a bit of a nitpick but this particular comparison is exactly the same with any other browser.

Sure, Safari is locked to iOS version, but iOS adoption rates are insanely fast, about as fast as browser updates. We are talking 90% current major version adoption within 5 months. Here's a source with some historical info: https://worldmetrics.org/ios-version-statistics/

So really, at worse you're looking at being one year behind to cover 95%+ marketshare in iOS.

The latest version of Safari runs on the two previous versions of macOS, so it's even less of a problem on macOS.

> So you could spend 6 months working on a project, release your product, then get inundated with bad reviews because it didn't work for half the population with iPhones.

That could happen to you if you don't test your software on popular platforms.

Let's not forget, Safari and Chrome have the exact same open source core with proprietary commercial applciation development model. Safari has about 1/4 of the user base as Chrome. But here we are expecting the open source community around Webkit to fix bugs just as fast as Chrome?

You could have fixed the indexDB bug yourself if you wanted to. I would say that what you are framing as "Apple lying" about capabilities can be more generously interpreted as "Apple has 1/4 of the community developer resources to find and squash bugs in Webkit compared to Chromium." Really, it's far less less considering that essentially every other browser besides Mozilla uses the Chromium engine. Microsoft is of course another huge company also contributing to Chromium, and once you put Google and Microsoft together Apple doesn't look like such a behemoth anymore. The only thing that makes Apple "bigger" is the fact that they sell a lot of high margin hardware. In reality, the software businesses at Google and Microsoft are far larger and more complex than Apple (e.g., Apple has no enterprise cloud computing business, and essentially no enterprise software business at all).

Mobile Safari would regularly break WASM. Like iOS 10.1 and 10.2 just broke it for no good reason. It had a broken WebGL 2 implementation for a long time. This hobbled Unity games.

The compressed textures support for WebGL was also broken for a long time.

The lowest latency WebRTC codecs that Stadia and Xbox Cloud Gaming used were also purposefully not enabled by default. Google had to smuggle in an obscure WebRTC feature for low latency via libwebrtc that Apple just didn't know about.

I have no idea why you guys are going out and defending this stuff. Android Chrome has much better support for web standards that Mobile Safari does, even in situations where the codebase was shared like libwebrtc, because of strategic Apple decisions.

For all we know WebXR immersive just isn't ready yet, just like WebXR wasn't ready for VisionOS 1 and shipped in VisionOS 2, which also makes sense considering that Apple's VR/AR business is years behind its competitors.

Broken stuff can just be bugs and regressions.

And I think it's also contextual to point out that Google really badly needs you to prefer Chrome and have the browser with the most features a lot more than Apple needs Safari to be anything more than a functional basic web browser. Examples like Stadia or even Unity in the web browser are essentially features that nobody asked for and that have worked better as native applications for decades. In other words, Google depends on the web browser being "the only application" as much as Apple depends on their users turning to the App Store first.

I totally get where Apple has a vested interest in boxing out competitors in the way you describe, but at the same time some of the complaints end up sounding a lot like bugs or just being generally behind in development velocity.

Chrome, Firefox and IE had buggy implementations in 2012. Firefox didn't support IndexedDB from worker threads and would corrupt data. Chrome couldn't write blobs and would corrupt data.

Safari certainly required more workarounds due to more bugs than anyone, but the truth is that the IndexedDB standard sucks. For goodness sake, there's still no standard for locking to prevent corruption between two tabs (while everyone supports the Web Locking API now, it's not actually a standard).

We would have all been better off if we tossed it and replaced it with WebSQL.

You spent 6 months developing against an unstandardised technology on a platform with well documented compatibility complexities, and you didn’t test it on one of your larger target devices?

I think that’s on you, friend.

Google implementing a draft they themselves authored with minimal review doesn't make it standard just because w3c publishes the draft.

And so you'd purchase a new iOS device for ~$1000 and test against it.

Then you realise that you're getting bugs from some customers that you literally cannot replicate on your device.

Then you realise that the bugs are type of device independent, so you need to purchase one of every kind of device apple offers for ~$10,000 and test against those.

Then you realise that the bugs aren't just type of device independent, they're actually dependent on a combination of OS version AND type of device.

So you spend another ~$10,000 for a second copy of each device, and set them up to never auto update.

But now you need to wait 12 months for the next iOS update so you can test the current and the previous version, but waiting 12 months won't do.

So you want to rollback iOS versions, but Apple doesn't let you do that.

But they do let you simulate combinations of iOS devices and versions through xcode. So you buy a macOS device and you're out another $5,000 and spend time simulating, but then you realise that the simulations don't actually replicate the device bugs, they're just running sandboxed versions of desktop Safari on the host machine that are scaled down and streamed into the simulated device. And so we've learnt a $5000 lesson on the difference between simulation and emulation.

So here you are, out ~$25,000 and dealing with customer complaints and troubleshooting, the you find something unexpected... You find a customer with a combination of type of device and OS version that you have, and you can't replicate the issue.

So it's not just type of device plus OS version dependent bugs. The bugs are independent to the devices themselves. Yes, really!

So what do you do at that point?

You have no way to reliably test if a feature works, the only thing you can do is take Apple at their word and recommend to customers that they can still access your product through other platforms (Android, macOS, Windows) and just put up with the angry complaints and reviews from iPhone customers that you can't help.

--------

The above comes from personal hands-on experience.

We have purchased multiple of the same device on the same day from the same shop with the same OS on factory settings and have witnessed different behaviours.

Reporting issues to Apple is useless, their responses are absent at best, and hostile at worst.