This is the second part of our three-part blog series on the state of browsers and browser engines on Apple iOS. In part one, we described what a browser engine does. We also provided background information on the four major players involved in browser development: Apple, Google, Microsoft and Mozilla. Now it’s time to explain more about the current situation regarding browser (engines) on iOS.
WebKit on iOS
As described in the previous blog, only one browser engine is available on iOS: the WebKit engine. Every app on iOS – including browsers from Apple’s competitors – must use this engine if they want to display web content:
Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.
App Store Review Guidelines, Software Requirements, paragraph 2.5.6
It’s not uncommon for browser developers to use an engine that they do not develop (entirely) themselves. For example, the Microsoft Edge browser today is based on Chromium, the engine developed by Google. But usually, browser teams can control which features of an engine they use in their browser and – if needed – add custom features.
This option is impossible on iOS because Apple insists developers must use the WebKit engine and version they specify. By policing these requirements, Apple effectively ensures that WebKit’s engine governs all aspects of browsing on iOS. In practice, third-party browsers can only differentiate themselves based on their appearance. As a result, Chrome, Edge, Firefox and other browsers on iOS are more or less copies of Safari, Apple’s browser, just with a different lick of paint.
Apple’s monopoly
The capabilities of the browser engine are entirely in Apple’s hands. And for Apple, these capabilities are much less critical than for their competitors. After all, Apple is not as dependent on the web when compared with Google, Microsoft, and Mozilla. So while Apple needs to offer a good user experience to users of their iPhones, they are unlikely to suffer significantly if Safari on iOS is better or worse than browsers on other platforms.
You could even argue that Apple would earn less if browsers performed better on iOS. After all, on iOS, users are free to choose between native apps or web apps. Native apps are built on and integrated with the mobile platform. Users select and install these apps through the App Store, with Apple receiving a commission on each purchase. Web apps designed to run on the local browser effectively bypass the App Store, leaving Apple with empty hands!
Apple has complete control over the browser engine on iOS and little commercial incentive to develop a feature-rich WebKit engine. Its monopoly position discourages innovation. Not surprisingly, WebKit (and thus every browser on iOS) has fallen far behind compared to browsers on other platforms, as illustrated by the following graphic (source: wpt.fy):
By logging browser-specific failures (BSF) that fail in exactly one browser, it is evident that Safari (based on WebKit) demonstrates many unique points of failure when compared with other popular browsers.
Some might conclude that Apple’s absolute control is not just hindering innovation of the web on iOS but that they are abusing it to give Safari an edge over competing browsers, for example, by providing the Safari development team with exclusive access to newer and better-performing versions of their WebKit engine. And until recently, it was only possible for Safari to add websites or web apps to the home screen.
Apple’s monopoly under fire
Recently, regulators and legislative authorities have been paying more attention to this type of monopoly. As a result, not only Apple but also Amazon, Facebook, and Google are under investigation for abusing their dominant positions. This scrutiny has already led to several lawsuits.
Apple was particularly under fire for its monopoly position on the iOS App Store. Apple then argued that developers need not use the App Store to reach iPhone users, but can build Web apps instead. However, perhaps due to their WebKit monopoly, we would argue that web apps are not a fully-fledged alternative to native iOS apps. And it seems regulators now realise this as well.
Indeed, EU legislation in the pipeline may require Apple to allow other browser engines on iOS. Australia, Japan and the UK are also investigating the situation and considering similar measures if they believe Apple is abusing its position, leaving consumers to suffer as a consequence.
Google and Mozilla already seem convinced that new regulations may succeed, and are working on iOS-specific versions of their browser engines. We, as web developers, see this as a positive development. In the final part of this blog series, we will discuss the possible benefits of opening up iOS to other browser engines.
Thanks for reading our blog. Do you have questions for BSL about app developments or new web applications? Contact us, and we’ll do our best to help!