Lately, web developers have begun to question Apple’s monopoly over browser rendering engines on iOS. The App Store rules force browsers on iOS to use the same rendering engine as Safari instead of using their own, as they do on every other platform, including macOS. I’ve written about this before and why this is a problem.
Even some market regulators have picked up on this sentiment. And last year, the British CMA published a preliminary report which may result in rules being imposed on Apple to force them to allow other rendering engines.
But I’ve also seen some responses that argue that having less choice is good for users. Apparently, iOS is the last bastion of WebKit that can prevent a Chromium monoculture. And if we allow Chromium on iOS, WebKit will be doomed, and we will end up with Chromium everywhere.
Web developers don’t mind there being an engine monoculture, they just want it to be a Blink monoculture instead of a Webkit monoculture.
Nick Lockwood
Even Jen Simmons, an evangelist for the web developer experience team at Apple, mirrored that response by saying:
Do we really want to live in a 95% Chromium browser world? That would be a horrible future for the web. We need more voices, not fewer.
Jen Simmons
But that argument seems weird to me. And also a little insulting for the Safari team because why do you think Chromium-based browsers will suddenly overrun Safari? Are you saying Safari is not good enough?
I do agree with Jen about the second part. I do want more voices; that is precisely what this is about. I just don’t think iOS is an exception to this. We want more voices everywhere, also on iOS.
But is there some truth to this, maybe? Are we fighting for more choice and inadvertently ending up having to choose between Chromium or Chromium?
Developers will develop for Chrome and tell users to install Chrome.
I can tell this is a genuine worry, but I hardly think this is as black and white as they make it out to be.
First of all, we need to consider why developers would do this. And I think it would be a mistake to generalize here and say that every instance is completely and totally bad. There may be some good reasons why developers and websites tell users to use another browser.
The issue could be that the browser you are using does not support the web platform features that the website is using. During the last couple of years, I’ve built many demos that require WebBluetooth. In this case, it is clear cut. If your browser does not support WebBluetooth, the website will not work in your browser. There is no alternative. And it is the choice of your browser to support it or not.
But what if that dependency on that web platform feature is not a hard requirement. What if the website could have worked around that requirement. Perhaps it would just take some more time from the developers. Or maybe the workaround would be less performant or less ideal in some other way. That also happens. It happens today and will likely continue to happen when Chromium-based browsers are allowed in the App Store.
We’ve seen this happen with the Google Earth site a couple of years ago when Google replaced their Chrome-only NaCl implementation with a WebAssembly based one. It initially only worked in Chromium browsers. So while they went with a standards-based approach, it was at first very much a side-step and not an improvement. And I’ve very publicly called them out on this, but the reality was that Google Earth used some WebGL features that Safari did not support. The Google Earth team worked around that, or the Safari engineers improved their WebGL implementation. Or both. Probably both. Anyways, it now also runs on Safari.
But it also happens the other way around. For years the Apple keynotes were only available in Safari. And later only in Safari and Edge. Simply because Apple used a method of streaming that Chrome did not support. Could Apple also provide a stream that worked in Chrome? Of course they could. But they chose not to. Could Chrome support the methods of streaming that Apple used? Also yes.
Sometimes these limitations are temporary and caused by constraints in budget. You can only do so much in so much time. Launch now, fix later. Sometimes the resources needed to support multiple platforms are not worth the benefit. Sometimes it is politics, and companies try to push the other side into a different direction. Sometimes, it is the browser that must adapt to changes to the web platform.
But what if developers will become lazy, and instead of making sure their website works in Safari, they will tell users to use Chrome instead? Frankly, If you use this argument, I think that says more about how you feel about web developers than anything else. Web developers are professionals.
If people use Safari, web developers will test websites in Safari. If Safari contains bugs, web developers will work around those bugs to ensure the website works well in Safari.
Web developers will develop for where the users are. We have to because we don’t do our work in a void. We make websites to sell something to users or offer services to users. Companies pay us to create websites so they can make money. And the more potential customers they can reach, the more money they can make. To ignore or even anger Safari user is bad business. Developers will not ignore Safari if users choose to use Safari.
That is what web developers do now, and that will not change. That is what we have been doing as an industry for years. We struggled for years to keep supporting Internet Explorer, but we had to. We had to because there were still people using Internet Explorer.
But there is also some responsibility here for the Safari team. Many of the issues that web developers have been running into are bugs in Safari. Bugs that make Safari act differently, not just from Chromium, but from the standards. Ideally, developers would not even have to test in Safari and developers could follow the standards and have a properly functioning website in every browser. And for the most part, this is true today. Developers are not developing two websites: one for Safari and one for the rest. No, the differences are subtle and, with some exceptions, often only annoying for the developer.
If the differences are only some annoying bugs, why do developers want other browser engines at all? Why not keep the status quo?
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.
But users will choose to use another browser. And if users leave Safari, so will developers.
Yes, some users will choose another browser. That is an inevitable result of offering more choice. But I doubt this will have much of an impact on what browsers developers must support.
People love using Safari. So many people prefer Safari over Chrome today. Even on macOS, where you have a proper choice between browser rendering engines, a large portion of the users use Safari because they feel it best suits them.
The reality is that many iOS users don’t know the difference between a browser and a browser rendering engine. And they shouldn’t have to. And right now, there are already browsers like Chrome, Edge and Firefox in the App Store. Those browsers use the same rendering engine as Safari and not Gecko or Chromium like they do on other platforms. But most people don’t know that. People already believe they have a choice, and they are choosing Safari.
After everything I’ve written, you may be surprised that even I use Safari as my default browser. I don’t hate Safari. I love Safari.
But again, it does highlight some of the responsibilities of the Safari team. They can’t sit back and relax. They’d have to invest in improving their browser and keeping it relevant for users. That is nothing new; they’ve been doing that for years. The Safari team does know how to build a browser that users want to use.
The Safari team is capable enough not to let their browser become irrelevant. And Apple has enough money to support the Safari team to take on other browsers. It does not need some artificial App Store rule to protect it from the competition.
I can’t imagine a future where Safari won’t be a massive player on macOS and iOS.
But what if you are wrong? What if we do end up with a Chromium-monoculture.
I firmly believe that multiple browsers are essential for the future of the web. We need a web where no single browser determines what the web looks like and what is and what isn’t allowed.
But I don’t think we should have to worry about this, because this almost has happened before. Ten years ago, we had a defacto standard rendering engine on mobile. And that engine was quickly taking over desktop too. But it wasn’t Chromium; it was WebKit instead.
Everybody used WebKit. It didn’t matter if you had an iPhone or Android phone; it used WebKit. Did you use Bada, Nokia S40, S60 or BlackBerry? You had a browser based on WebKit. Tizen or webOS? WebKit! Meego or TouchWiz? WebKit too! But it wasn’t just mobile; it was desktop too. Safari and Chrome both used WebKit.
So what happened? The major players involved in WebKit disagreed on the direction to take WebKit. So they split. Chrome forked WebKit and turned it into Blink, the rendering engine that powers all Chromium-based browsers.
We can only imagine what would have happened if Chrome kept using WebKit. We probably ended up with a WebKit-monoculture. Trident is dead, and so is EdgeHTML. Presto is long gone. Only Gecko is left, and frankly speaking, I will be surprised to see it regain its former glory.
But Chrome did fork, and today, we can also see similar things happen in Chromium. I don’t expect somebody to fork Chromium, but it could happen.
We’ve seen Edge adding some privacy enhancements to Chromium pioneered by Safari. Edge shipped those, but Chrome did not. And as more browsers start using Chromium and large companies will work on improving Chromium, more of these disagreements will happen. It will be interesting to see what happens.
Just because a browser is based on Chromium, that does not mean it is identical to Chrome and that Google is in control. Even if the unthinkable happens and Apple is forced to adopt Chromium, that will only ensure that Google is not the only one having a say about Chromium and the future of the web.
And that is what is crucial here. The choice between rendering engines isn’t about code. It isn’t about the rendering engine itself and the features it supports or its bugs. Everything is about who controls the web.
WebKit-only proponents are worried about losing control and Google becoming too powerful. And they feel preventing Google from controlling the web is more important than giving more power to users. They believe they are protecting users against themselves. But that is misguided.
Users need to be in control because if you take power away from users, you are creating the future you want to prevent, where one company sets the rules for everybody else. It is just somebody else who is pulling the strings.
The best way forward is to give users a choice, and developers will follow the users. A lot of users will choose Safari. The Safari team has been doing a fantastic job steering the web into a more privacy-friendly place, and many users love Safari for that approach. Apple does not need anti-competitive App Store rules to protect its influence over the future of the web.