The Register recently reported that Google is working on an iOS version of Chromium. A few days later, a second article claimed that Mozilla is working on an iOS version of Gecko, Firefox’s browser engine. Both reports suggest that the Apple browser engine on iOS, WebKit, is in danger of losing its monopoly.
In a series of blog posts, we’ll explain why this is important news for web developers, starting with some relevant background information. The second post will explain more about the state of browsers on Apple iOS, and our final post will describe how this news may impact web developers and customers.
What is a browser engine?
Many browsers are available, but they use a limited set of browser engines. The most popular are WebKit, Blink and Gecko.
- WebKit is Apple’s engine, used by their browser, Safari, on iOS and MacOS. It’s also used in many other Apple apps, such as mail and the App Store.
- Google created Blink as a fork from the WebKit engine. Google has an open-source browser, Chromium, and their proprietary Chrome browser. Both use the Blink engine. Today, many browsers are based on Chromium, including Brave, Opera and Vivaldi. Most recently, Microsoft switched to Chromium, having previously used proprietary Internet Explorer and Edge engines.
- The Gecko engine is from Mozilla, which they use in the Firefox browser.
The browser engine determines the capabilities of the Web experience. For example, displaying animations, games, or audio/video in a browser was initially impossible because the engines offered no support. Many of you will remember using plugins such as Flash, Shockwave or Silverlight before developers included multimedia support in their browser engines.
Browser (engine) features
But who determines which features your browser engine supports? Today, browser teams from the four major players, Apple, Google, Microsoft and Mozilla, work together in a consortium to create a living standard for the Web. And this standard is constantly changing to meet new demands.
One of the teams will usually produce specifications for a new feature to fulfil a specific need of their users or developers. The specifications are shared with the other teams, fine-tuned as necessary, and finally approved or disapproved.
Because of the inherent need for consultation, implementing a new feature can be time-consuming. Ideally, everyone within the consortium will quickly agree on the implementation. But the individual teams will have their own perspective of what the Web should support – and how it should be delivered. For example, the Chromium teams prefer to see the Web become a platform that can compete with native apps. However, the Firefox team remains less convinced, despite their earlier attempt to launch a mobile OS supporting only web applications (no native apps). The Safari team apparently shares this view.
These differing views sometimes cause friction within the consortium. For example, a browser team sometimes includes a browser feature without first agreeing on a standard specification with the other consortium members. With luck, the subsequent popularity of such a feature may cause the standard to follow later. After all, if the other teams fail to adopt a popular website feature, they run the risk that their users are unable to use specific websites. Thus, a consortium member can resolve an impasse in discussing a new standard by using the public to leverage a decision.
However, browser teams should be able to customise the engine to successfully include new features. Due to the exclusive use of the Apple WebKit on iOS, only Apple can make these changes, creating a technical monopoly that other consortium members would like to break. Read our next blog to find out more!
Why not get in touch with us if you have questions about Web and App development?