The original link: nielsleenheer.com/articles/20…
In the iPhone app Store, there are many browsers to choose from. On the latest iOS, you can even set these browsers as the default. So why do some people complain about browser choice on iOS?
You may not realize that all browsers on iOS need to use the same rendering engine as Safari. On other platforms, this is not the case.
They’re using Chromium on Android, Windows and even macOS. But on iOS, it uses WebKit. Or look at Firefox, which uses the Gecko rendering engine on all platforms. In addition to iOS, it uses WebKit.
### Why is everyone using WebKit?
It’s not because these rendering engines don’t run on iOS. Porting the rendering engine to iOS may take some work, but as far as I know, some browsers want to do it, but unfortunately they’re not allowed to.
In fact, apps in the App Store need to be reviewed and approved by Apple to meet the App Store review guidelines:
2.5.6 Web browsing applications must use the appropriate WebKit framework and WebKit Javascript engine.
This is final. Apple requires browsers to use WebKit. In fact, the application must use the WebKit framework provided by the system. Even if WebKit is open source, you cannot use either modified or improved versions in your applications. Never allow
Caption image created by @mtomWeb
Great equalizer: System WebView
But how do you use licensed versions of WebKit? There is a framework to solve this problem. Apple provides a WebView that allows you to embed WebKit with a little work in your application. You need to provide a configuration object for the framework and handle some of the events it sends. WebKit handles all the actual loading, parsing, and rendering. Your application doesn’t need any details at all. All you need to do is provide a user-friendly interface and perhaps integrate with your ecosystem. For example: Sharing bookmarks with the desktop version of the browser.
That’s why other browser vendors fret about this mess in the first place. They care less about making a great browser on iOS and more about getting their existing users into their current ecosystem on iOS.
Do you use Edge on Windows? No problem, you can download Edge on iOS, where all your passwords, bookmarks and tabs are. Ecosystem integration, perfect!
While this sounds great, it also simplifies the browser to a different user interface.
Why is this important?
The most important thing for a browser is the rendering engine. The user interface needs to be displayed in the browser, but the browser can’t get in the way.
Even Apple believes that user interface rendering should be as fast as possible. Apple’s early experiments with Safari in iOS 15 beta didn’t fit this philosophy, leading to some very vocal criticism from Apple experts like Marco Arment, Frederico Viticci, and John Gruber. Apple is right, though, because users who want to browse the web can only use a browser.
This is where other browsers on iOS can’t innovate, they have to use the same rendering engine as other browsers on the platform.
So if you want to use the new WEB standards? Wait until Apple implements it in WebKit. What if there’s a bug causing a problem? Wait until Apple fixes it and releases a new version of iOS.
That’s the problem.
Standards support and drive the WEB platform
Even if I had created an HTML5test site, I wouldn’t have put up a score to show that Safari scored worse than other browsers. I hope so, because it’s not. The site hasn’t been updated in five years, and Safari supports almost all of the WEB standards from five years ago.
The problem is much more complicated. Apple’s view of the WEB is fundamentally different from other browsers.
It’s easy to recall a similar time when Google didn’t take privacy seriously because they were also an advertising company. Apple only sells hardware. No, it’s not.
The same applies to Apple’s desire to make the roughly 30 to 15 per cent of revenues from the App Store worse for the WEB, forcing users to switch to apps, and profiting from it. I don’t believe it for a second.
The Safari and Chrome teams both want to make the WEB more secure and work to improve it but they have different ideas about what the WEB should look like.
Google is focused on improving the WEB’s ability to extend the WEB by enhancing the WEB’s ability to go beyond what is possible today. It also means allowing it to compete with native apps, something the Android team certainly doesn’t always agree with.
Safari seems focused on improving the WEB to make it safer, faster and prettier. If you want more, you can use an app.
I’m not saying what Apple did was wrong. What Apple is doing is also important, and I commend apple for its work to improve privacy on the WEB.
But this cannot be the only priority. Imagine what the WEB would have looked like 20 years ago if every browser had taken this approach.
In fact, don’t imagine it. Think back to Internet Explorer 6; That was the WEB 20 years ago. I’m not saying Internet Explorer 6 is a bad browser. It was a great browser in 2001. But as with Internet Explorer 6, if you stop innovating, you fall behind. This led to the decline of Internet Explorer. Other browsers did get better through innovation, and Internet Explorer became irrelevant. Although Microsoft tried to catch up for years and even later tried to catch up with Edge, which now uses Chromium as its rendering engine, they failed
It took a lot of effort and innovation over the last 20 years to get to where we are today: new application programming interfaces, new standards, new capabilities. Ironically, the push for a more powerful WEB originally came from Safari and the WebKit rendering engine. WebKit is the upstart that has changed everything and added many useful new features to the WEB.
But times have changed. Safari has fallen behind and struggled to keep up with the WEB platform. I’m not talking about some weird feature that only Chromium does. Even the proper standards and widely supported features found in other browsers can take years to show up in Safari.
The mantra among Web developers is “Safari is the new IE.” Sadly, it has been for some time.
Unfortunately, unlike Internet Explorer, users can’t simply choose to use another browser on iOS. Well, they can, but as we just saw, they’re Safari in disguise.
So it’s not just one browser that’s falling behind. All browsers on iOS are lagging behind. The entire WEB on iOS is lagging behind. IOS has become so important that the entire WEB platform is blocked.
Just as developers are frustrated by the long-term support for Internet Explorer 6, they are also frustrated by having to support Safari.
Even more depressing are some of Apple’s recent announcements. Under pressure from lawsuits and regulators, Apple has defended the closed nature of the App Store, arguing that the WEB is a suitable alternative to building native apps. You don’t have to follow app Store rules; You can also create WEB applications.
At the same time, it hurts to read that they are not interested in implementing features that allow Web applications to compete with native applications.
A long wait
Unfortunately for developers, it’s not just the lack of functionality that complicates things. A major cause of frustration is sudden bugs and errors.
Now, I’m not saying Safari has more bugs than other browsers. Every browser has errors. However, when errors do occur, what matters most is how quickly the problem can be fixed. I will say that it takes longer to roll out bug fixes to users than with other browsers.
Take, for example, a serious error about indexedDB. The technical details of the error are not important, but the timeline is. The error was introduced in iOS 14.6, which was released on May 24. It was reported on June 2 and quickly repaired. So far, so good. It wasn’t rolled out to users until the July 19 release of iOS 14.7. In the meantime, indexedDB is actually not available in Safari, your client is complaining that your WEB application is broken and you should fix it.
Any other browser would have published the bug fix immediately. They can start rolling out fixes in days rather than weeks because their browsers are operating system independent.
But not Safari or any other browser on iOS; Instead, you have to wait until the fix is included in the iOS version, and depending on when that version is released, it may not even be released in an upcoming release. You don’t even know if it will be included because “Apple doesn’t comment on future versions.”
Most of these problems don’t come from the Safari team. I’m pretty sure they’d like to release fixes faster. This is an iOS issue. That being said, it’s still a problem for Safari and other browsers on iOS.
All browsers are equal, but some are more equal
At the beginning of this article, I mentioned that Safari also uses WebKit. It’s true. But the biggest difference between Safari and other browsers is that Safari is free to compete on user interfaces and rendering engines. If they want to implement a new standard or feature, they are free to do so. Other browsers have to wait to see if and when Apple implements a particular feature, and Apple can always add whatever they want. This is not fair competition.
To make matters worse, WebView and Safari systems differ in standard support, and sometimes features are implemented first in Safari but not in WebView until a version or two later.
Recently, there has been a problem with web-based video communication. A WEB standard that allows browsers to access the phone’s front-facing camera was supported for a while in Safari, but not in WEB View. So if you want to use any form of Web-based video chat, you have to use Safari. As of iOS14.5, this issue has been fixed.
In a more famous example from a few years ago, Apple refused to allow third-party browsers to run JavaScript using their faster Nitro engine. This involved some real security issues, because at the time the WebView was running in the same process as the application, and allowing Nitro meant allowing the application to run arbitrary code. A big no-no on iOS. But Safari, of course, doesn’t have those limitations. Finally, they replaced the old WebView with a brand new WebView that ran the rendering engine in its own process, avoiding this problem entirely.
Fortunately, they solved both problems. Great for them and for browsers that rely on these features. Furthermore, the Safari team seems to have good reason not to push these specific features into WebView until they can do so correctly.
Some features may be highly integrated with Safari applications or the Apple ecosystem. Therefore, it doesn’t make sense to extend this functionality to WebViews as well.
But in any case, Apple is not bound by its own rules and is free to innovate while others are not.
All browsers on iOS are equal, but Safari is more equal.
So what can other browsers do?
Browsers can do two things to solve this problem. Unfortunately, both were 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. If the feature is accepted and fits Apple’s vision of the web, it will most likely be included in the next version of Safari — whenever that happens.
The problem is that this increases the burden of improving Safari with other browsers. That’s not how the real world works.
Even if a large browser vendor with a lot of money chooses to provide one for the team, there’s no guarantee Apple will offer it in Safari. Even today, WebKit is still being used and developed by many parties, and as a result, WebKit supports many features not included in Safari.
I’m not saying they ignore these contributions out of malice or due to the “not invented here” syndrome. But because of their different visions, they have different views of the web platform.
Fake it until you break it
One thing that could work is to stop looking for a solution with WebKit, but with the WebView itself. The browser can insert JavaScript into the WebView, and the JavaScript can send messages to the browser application. This is a bit of a cliche, but you could create a Polyfill that inserts automatically when the page loads and pretend to support it. The Polyfill can even talk to the browser application and tell it to execute native code if the function requires it.
This is how Cordova and Capacitor applications work. They run webViews and provide apis to communicate with the native side of the application to support functionality that browsers would never normally support. Browsers can also use this technique.
This is not just a theory. Before Apple supported it in Safari, Chrome used it to provide PaymentRequest support on iOS and there were even some feature-specific browsers in the App Store that provided WebBluetooth or WebMidi support.
But like I said. It’s unwieldy, and it may not work at any time. And some features cannot be polyfilled.
Of course, as a user, I’d be happy if browsers made more use of this technology to bring new web platform capabilities to iOS. But I understand why browsers are hesitant to do this.
outlook
So what’s the real solution to these problems? How do we get browsers to compete not only on looks but also on web platform functionality?
There’s only 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 to really compete. Although Apple has been forced to compromise on some of its App Store rules, I don’t have much hope that will happen.
That’s why I think market regulators need to look into this. Apple claims that the Web is a suitable alternative to the App Store, so regulators should take their word for it and make sure it happens.