This content originally appeared on Bram.us and was authored by Bramus!
Things have been heating up lately, regarding the #AppleBrowserBan. The summary is that people, including me, want to see Apple open up browser engine diversity on iOS, as all browsers on iOS today are Safari WebKit under the hood.
Because of this limitation, certain features will never make it into any browser on iOS. Even if the Firefox or Chrome teams want to add a web platform feature to their browser on iOS, they can’t, because Apple says so. This lock-in reeks of monopolistic behavior.
As a result, people are getting frustrated: not being able to use features at all and/or having to wait an unknown amount of time before seeing features land into WebKit due to Apple/Safari having other priorities (or — from a bug reporter’s POV — them seemingly ignoring things).
Thankfully there are companies like Igalia that can make a difference with their Open Prioritization effort. However, in the end, it’s still Apple that decides whether a feature lands into Safari or not. Yes, a feature can make it into WebKit, but that doesn’t mean it’ll end up in Safari.
~
Adding to these frustrations is that MobileSafari updates are linked to iOS updates. Because of this, it can take quite some time before bug and security fixes get shipped to users.
This is contradictory for a company that holds security up high. Security fixes in an application should be shipped as soon as possible, instead of being part of a bigger OS update.
Note that on macOS, this tight coupling between Safari and OS releases thankfully no longer is the case. It’s a fact that some like the underline during discussions, but be aware that it’s only valid for macOS, not iOS.
If Apple can’t or won’t unlink both update mechanisms from each other, well, then I’m getting serious flashbacks to the early 2000s where Microsoft was penalized for doing exactly that.
~
Safari was once driving innovation on the web (CSS Animations, for example), but over the years they have lost their pole position. This leads to people, including myself in the past, naming Safari the new IE6, as it has many resemblances. It even escalated when Chromium and Safari (DevRel) Engineers publicly threw stuff at each other on Twitter.
In response, Dave wrote “Before I go: When it comes to complaining about web browsers” in which he indicates that it’s no good to talk sh*t, as it doesn’t move things forward.
Complaining on Twitter sure does feel good but it doesn’t do much other than burning bridges and burning through people’s patience.
While I agree with the general sentiment to keep things civil, I, however, don’t think we can ignore the fact that Apple has been tone-deaf about many things for a very long time, ultimately leading to these kinds of sh*tposts in the first place. Cause and Effect.
Above that, I must say that, as web developer, my patience with Safari has also been burned (100vh not being 100vh, anyone?). As a front-end engineer, I only see the things I need in my day-to-day job. I can imagine that engineers who sit close near the specs/core of browsers have a more detailed view on the number of things that go wrong.
On the other hand, we definitely must acknowledge that Apple seems to be ramping up things nowadays when it comes to Safari — they’re actively hiring people for new positions and are pushing out many exciting new Technology Preview releases. I’ve hinted at this a few times already: I think the Safari team is crushing it nowadays!
~
So yes, many of the new things are wonderful and Apple/Safari/WebKit is leading in some areas again today (:has()! Color Spaces! Cascade Layers! …), but that doesn’t mean they can get away with the whole browser ban.
With “they”, I mean Apple, not the Safari team. The engineers are doing great work, and they should be applauded for that. But policy-wise, I, along with many others that are against the ban, can see room for improvement.
Yes …, but …
— it seems to be a recurring theme when I talk about Apple.
~
In response to the whole situation, Niels also wrote a piece: Why Safari does not need any protection from Chromium. It’s a well-nuanced piece that goes into the idea that allowing Chrome on iOS would somehow lead to Chrome entirely taking over the browser landscape.
I want more choice because competition will make Safari stronger. I want a strong Safari that is powerful enough to take on other browsers. The privacy features in Safari are fantastic, and other browsers should pay more attention to what Apple is doing here. But competition will push Apple to invest more in Safari and build an even better product. And if they do that, they don’t have to worry about developers abandoning Safari.
But at the same time, Safari is very opinionated about which features they will support and which they won’t. And that is fine for their browser. But I don’t want the Safari team to choose for all browsers on the iOS platform.
So in a way, it will cause websites to tell users to use a different browser. But because those users want to use their browser for things that are not possible in Safari. Not because Safari can’t support those features, but because Safari has chosen not to support those features. Not because lazy developers will abandon Safari. That is ridiculous.
It’s a good quoted part I like to close this post with.
~
I guess my message to Apple is to bury the hatches and push the web forward, together. No need for silly restrictions and limitations. If you truly are the best self you can be, you shouldn’t fear competition. Embrace competition. It leads to better results.
Don’t believe me? Here’s a flyer from the FTC, an agency you’re most likely familiar with:
Competition in the marketplace is good for consumers and good for business. Competition from many different companies and individuals through free enterprise and open markets is the basis of the U.S. economy. When firms compete with each other, consumers get the best possible prices, quantity, and quality of goods and services. Antitrust laws encourage companies to compete so that both consumers and businesses benefit.
FIN.
~
🔥 Like what you see? Want to stay in the loop? Here's how:
This content originally appeared on Bram.us and was authored by Bramus!
Bramus! | Sciencx (2022-02-11T11:25:11+00:00) Not all Browsers are Created Equal (on iOS). Retrieved from https://www.scien.cx/2022/02/11/not-all-browsers-are-created-equal-on-ios/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.