If you go to the App Store on your iPhone, there are many browsers to choose from. And with the latest version of iOS, you can even set these browsers as the default browser. So why are some people complaining about browser choice on iOS?
You may not realise that all browsers on iOS are required to use the same rendering engine as Safari. On other platforms, this is not the case.
Take, for example, Chrome. On Android, Windows and even macOS, they are using the Chromium rendering engine. But on iOS, it is using WebKit. Or look at Firefox, which uses the Gecko rendering engine on all platforms. Except on iOS, where it uses WebKit.
Why does everybody use WebKit?
It’s not that these rendering engines can’t run on iOS. It might require some effort porting the rendering engine to iOS, but I know that some browsers would like to put in that work, but sadly they are not allowed to.
The reality is that apps in the App Store need to be reviewed and approved by Apple, and according to the App Store Review Guidelines:
2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.
And that is final. Apple requires browsers to use WebKit. In fact, it must use the system-provided WebKit framework. Even though WebKit is open-source, you can’t modify or improve that version and use that in your app. No.
The great equaliser: the system WebView
But how can you use that one authorised version of WebKit? There is a framework for that. Apple provides an WebView that allows apps to embed WebKit in your app with relatively little effort. You provide the framework with a configuration object and need to handle some events it sends your way. WebKit handles all the actual loading, parsing and rendering. Your app does not need to worry about that at all. All you need to do is provide a friendly user interface and maybe integrate with your ecosystem. For example, bookmark sharing with the desktop version of your browser.
And that is precisely why other browser manufacturers are willing to bother with this mess in the first place. They care less about making a great browser on iOS but more about letting their existing users tap into their current ecosystem on iOS.
Are you using Edge on Windows? No problem, you can download Edge on iOS, and all your passwords, bookmarks, and tabs are there. Ecosystem integration, baby!
While this sounds great, it also reduces browsers to little more than different user interfaces on top of the same thing.
Why does this matter?
The most important thing about a browser is the rendering engine. The user interface is just something that needs to be there to be able to use the browser, but it must not get in the way.
Even Apple thinks that the user interface should get out of your way as quickly as possible whenever possible. Apple’s early experiments with Safari in the iOS 15 betas took this philosophy a bit too far, resulting in some pretty vocal criticism from some Apple pundits like Marco Arment, Frederico Viticci and John Gruber . But despite that, Apple is right in that the main reason a user uses a browser is that they want to browse the web.
And that is precisely where other browsers on iOS can’t innovate. They have to use the same rendering engine as every other browser on the platform.
So that new web standard you would like to use? Not until Apple implements it in WebKit. Is there a bug that causes problems? Wait until Apple fixes it and releases a new version of iOS.
And there lies the problem.
Standards support and moving the web platform forwards
Even though I created the site, I am not going to whip out some HTML5test scores and show you that Safari scores fewer points than other browsers. If only, because that is no longer true. The site hasn’t been updated in 5 years and Safari supports pretty much all of the web standards that were in demand 5 years ago.
The problem is way more complex than that. There is a fundamental difference between how Apple sees the web and how other browsers see the web.
And it is easy to go back to the old tropes about Google not taking privacy seriously because they are also an ad company. And Apple just sells hardware. No, that is not it.
The same applies to the argument that Apple wants its 30% 15% take of the revenue from the App Store. And Apple has a vested interest in making the web worse and forcing users to use apps instead. I don’t believe that at all.
The Safari and Chrome team both want to make the web safer and work hard to improve the web. But they do have different views on what the web should be.
Google is focussing on improving the web by making it more capable. To expand the relevance of the web, to go beyond what is possible today. And that also means allowing it to compete with native apps, with which the Android team surely does not always agree.
Safari seems to focus on improving the web as it currently is. To let it be a safer place, much faster and more beautiful. And if you want something more, you can use an app for that.
And I am not saying Apple’s approach is wrong. What Apple is doing is important too, and I applaud the work Apple has been doing in improving privacy on the web.
But it can’t be the only priority. Just imagine what the web would look like if every browser would have taken that approach 20 years ago.
Actually, no, don’t imagine it all. Just think back at Internet Explorer 6; that is what the web looked like 20 years ago. And I am not saying Internet Explorer 6 was a bad browser. It was a great browser in 2001. But just like Internet Explorer 6, if you stop innovating, you fall behind. And that started the downfall of Internet Explorer. Other browsers did innovate and became better, and Internet Explorer became irrelevant. And despite many years of trying to catch up and even replacing the browser with Edge, Microsoft ultimately failed, and Edge now uses Chromium as the rendering engine.
Over the last 20 years, it took a lot of hard work and innovation to make it what it is today: new API’s, new standards, new capabilities. Ironically, a lot of the push for a more capable web initially came from Safari and the WebKit rendering engine. WebKit was the upstart, shaking things up and adding many useful new features to the platform.
But times have changed. Safari has fallen behind and struggles to keep up with where the web platform is heading. And I am not talking about some exotic features that only Chromium has implemented. Even proper standards and widely supported features in other browsers can take years to appear in Safari.
The running gag under web developers is “Safari is the new IE”. And sadly, it has been for quite a while.
Unfortunately, unlike what happened with Internet Explorer, users cannot simply choose to use another browser. Not on iOS. Well, they can, but as we’ve just seen, they are just Safari in disguise.
So it’s not just one browser that falls behind. It’s all browsers on iOS. The whole web on iOS falls behind. And iOS has become so important that the entire web platform is being held back as a result.
Just as developers were becoming frustrated with Internet Explorer 6 because they still had to support it for a long time, they are becoming frustrated because they have to support Safari.
Even more frustrating are some of the statements Apple made recently. Under pressure from lawsuits and regulators, Apple defends the closed nature of the App Store by saying that the web is a proper alternative to building native apps. You don’t have to follow the rules of the App Store; you can also create web apps instead.
It just hurts a bit to read that when, at the same time, they are not interested in implementing features that would allow web apps to compete with native apps.
The long wait
Unfortunately, it is not just missing features that are complicating things for developers. One major source of frustration is all the little quirks and bugs that seem to pop up.
Now, I am not saying that Safari has more bugs than other browsers. Every browser has bugs. However, when a bug appears, the most important thing is how quickly that problem is fixed. And what I am saying is that it takes a lot longer for bug fixes to roll out to users compared to other browsers.
Take, for example, a severe bug concerning indexedDB. The technical details of the bugs are not important, but the timeline is. The bug was introduced in iOS 14.6, released on May 24th. It was reported on June 2nd and fixed quickly. So far, so good. Then it took until the release of iOS 14.7 on July 19th to get this rolling out to users. All the while, indexedDB was effectively not usable in Safari, and your customers are complaining that your web app is broken and that you should fix it.
Any other browser would have issued an immediate bug fix. They could have started rolling out the fix in days instead of weeks because their browsers are rolled out independently from the operating system.
But not Safari or any other browser on iOS for that matter; instead, you have to wait until that fix is included in an iOS release, and depending on how far along that release is, it might not even make the upcoming release. And you don’t even know if it will be included because “Apple does not comment on future releases”.
Most of these issues are not rooted in the Safari team. I am pretty sure they would love to ship fixes sooner. It is an issue with the iOS platform. But having that said, it is still an issue for Safari and other browsers on iOS.
All browsers are equal, but some are more equal
At the start of this article, I mentioned that Safari also uses WebKit. And that is true. But the big difference between Safari and other browsers is that Safari is free to compete on both user interface and rendering engine. If they want to implement a new standard or feature, they are free to do so. While other browsers must wait to see if and when Apple implements a particular feature, Apple can add whatever they want, whenever they want. That is not fair competition.
And it gets worse. There are differences in standards support between the system WebView and Safari. Sometimes features are first implemented in Safari, only to end up in the WebView a release or two later.
Recently, there was an issue with web-based video communication. A web standard that allows the browser to access your phone’s front camera was for some time supported in Safari, but not in the WebView. So if you wanted to use any form of web-based video chat, you had to use Safari. As of iOS 14.5, this issue has been resolved.
A more famous example from quite a few years ago is that Apple refused to allow third-party browsers to run JavaScript using their much faster Nitro engine. There were some real security issues involved because at that time, the WebView ran in the same process as the app and allowing Nitro would mean allowing the app to run arbitrary code. A big no-no on iOS. But of course, Safari did not have these limitations. In the end, they replaced the old WebView with a completely new one that runs the rendering engine in its own process, avoiding this problem altogether.
They luckily solved both of these issues. So good for them and for the browsers that depend on those features. Moreover, the Safari team had seemingly valid reasons not to roll out these specific features to the WebView until they could properly do so.
Some features may be heavily integrated with the Safari app or the Apple ecosystem. So it does not make sense to roll that feature out to the WebView too.
But in any case, Apple is not bound by its own rules and can innovate freely, while others cannot.
All browsers on iOS are equal, but Safari is more equal.
So what can other browsers do?
There are two things browsers can do to work around this issue. Unfortunately, both are doomed from the start.
As I mentioned, WebKit is open-source, and other browser makers can invest time and money to implement the features they want themselves. And if that feature is accepted and in line with Apple’s vision for the web, there is a good chance that it will be included in the next release of Safari – whenever that will be.
The problem is that this puts the burden of improving Safari with the other browsers. That is not how the real world works.
And even if one big browser vendor with lots of money did choose to take one for the team, there is no guarantee that Apple will ship that feature in Safari. Even today, WebKit is used and developed by multiple parties, and as a result, WebKit has support for lots of features that are not included in Safari.
And I don’t mean they will ignore these contributions out of spite or due to the not-invented-here syndrome. But because of the different vision, they have for the web platform.
Fake it until you break it
One thing that could work is stop looking at WebKit for a solution but the WebView itself. The browser can insert JavaScript in the WebView, and that JavaScript could send messages to the browser application. It’s all a bit hacky, but you could create a polyfill that is automatically inserted on page load that pretends that the feature is supported. And that polyfill could even talk to the browser app and tell it to execute native code if that feature requires it.
That is how Cordova and Capacitor apps work. They run a WebView and offer API’s that talk to the native side of the app to support features that browsers would typically never support. Browsers could use this technique too.
And it is not just a theory. Chrome used this to offer PaymentRequest support on iOS before Apple supported it in Safari. There are even some feature-specific browsers in the App Store that offer WebBluetooth or WebMidi support.
But like I said. It is hacky and could break at any time. And some features cannot be polyfilled.
Of course, as a user, I would love if browsers would use this technique more to bring new web platform features to iOS. But I understand why browsers would be hesitant to do this.
A bleak outlook
So what is the real solution to these problems? How do we allow browsers to compete on not just looks but web platform features too?
There can only be one proper solution: Apple needs to open up their App Store to browsers with other rendering engines. Scrap rule 2.5.6 and allow other browsers on iOS and let them genuinely compete. Even though Apple has been forced to compromise on some App Store rules, I have little hope for this to happen.
And this is why I think market regulators need to look into this. Apple claims the web is a proper alternative to the App Store, so regulators should take them up on that claim and ensure it becomes true.