3 ms·

I still don’t understand what you’re trying to say about Safari. After reading the response (outlining draft vs support dates) to your initial comment it seems

I still don’t understand what you’re trying to say about Safari. After reading the response (outlining draft vs support dates) to your initial comment it seems like the reality is that your primary complaints dont make much sense. Maybe there are some other features that they were late to start supporting. Seems more like other browsers jumped on new features before they were standardized, and maybe that is at the heart of your original complaint? Safari taking “too long” to support things that dont have a standard?

spartanatreyu 2y ago
It *is* misleading because Apple saying that Safari supports a feature doesn't actually mean that the feature in question actually works. 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 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.
- dangus 2y ago
  > because you can't reliably use features until the last two major versions of a browser support those feature 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/ 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).
  - doctorpangloss 2y ago
    Apple purposefully does not support immersive WebXR in Mobile Safari. If it did 8th Wall wouldn't exist. 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.

spartanatreyu 2y ago

It *is* misleading because Apple saying that Safari supports a feature doesn't actually mean that the feature in question actually works. 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 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.

dangus 2y ago
> because you can't reliably use features until the last two major versions of a browser support those feature 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/ 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).
- doctorpangloss 2y ago
  Apple purposefully does not support immersive WebXR in Mobile Safari. If it did 8th Wall wouldn't exist. 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.