Should Apple Continue to Ban Rival Browser Engines on iOS?

Apple requires all apps that browse the web in iOS and iPadOS to use its own browser engine, WebKit, but amid accusations of anti-competitive conduct, should it continue to effectively ban rival browser engines?

Big tech has been gripped by accusations of anti-competitive conduct in recent times, with Chief Executive of the UK's Competition and Markets Authority (CMA) Andrea Coscelli declaring in a press release:

Apple and Google have developed a vice-like grip over how we use mobile phones and we're concerned that it's causing millions of people across the UK to lose out.

Among these accusations of anti-competitive conduct, Apple has been criticized for demanding apps that browse the web to use the WebKit framework and WebKit Javascript on iOS and iPadOS, in a policy that effectively bans non-WebKit based browsers. Apple's App Store Review Guidelines state:

2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

There is heated debate around this requirement, with some developers and regulatory agencies contending that it actively stifles innovation on iOS and iPadOS, while Apple argues that it is necessary to protect user security and privacy, as well as prevent the dominance of Chromium.

Why Apple Could Be Right to Ban Rival Browsers

Google's Chromium is the technology behind many popular browsers including Chrome, Microsoft Edge, Brave, and Opera. Some have argued that Chromium's dominance is leading to a "browser monoculture," stifling the development of rival web technologies. A tweet from Jen Simmons, an Apple Evangelist and developer advocate for Safari, appears to suggest the importance of maintaining the WebKit restriction for this reason:

According to data from web analytics service StatCounter, Safari holds a 9.84 percent market share of desktop browsers compared to Google Chrome's overwhelming 65.38 percent. Safari currently has a more secure position on mobile platforms than it does on desktops, but it still comes second to Google Chrome. Despite Safari being the default browser on the iPhone and iPad, Safari has a 26.71 percent market share on mobile, while Chrome dominates both iOS and Android with a market share of 62.06 percent. Beyond Chrome, Chromium-based browsers, such as Microsoft Edge, dominate the other most popular browsers.

If Apple stops mandating the use of WebKit on iOS and iPadOS, the developers behind the mobile versions of browsers like Chrome and Edge could switch to Chromium like their desktop counterparts, enabling Chromium to obtain even larger overall market share and potentially limit the chances of rival technologies competing with it.

In its mobile ecosystems market study interim report, the CMA said that Apple defended its WebKit policy on iOS using the following rationale:

Apple told us that only allowing WebKit on iOS is motivated primarily by security and privacy considerations. In particular, many modern websites run code from unknown developers. Apple told us that because of the WebKit restriction, it is able to address security issues across all browsers on the iPhone, for all iPhone users, quickly and effectively (given there is only one browser engine). It further told us that, in Apple's opinion, WebKit offers a better level of security protection than Blink and Gecko.

Apple argues that, since it controls WebKit and it is the only browser engine on these devices, the restriction allows the company to make sweeping security and privacy improvements across all browsers on the iPhone and ‌iPad‌, providing a better user experience and preventing fragmentation. It also claims that WebKit is more secure than rival browser engines.

Why Apple Could Be Wrong to Ban Rival Browsers

Others have argued that the WebKit restriction actively harms browser competition on iOS. The CEO of Epic Games, Tim Sweeney, was at the center of a tumultuous dispute with Apple about App Store fees and now says that the WebKit restriction is anti-competitive and uninclusive:

Apple's policies around WebKit have caught the attention of regulatory agencies, such as the CMA, which has heavily criticized the restriction:

We have found that by requiring all browsers on iOS devices to use its WebKit browser engine, Apple controls and sets the boundaries of the quality and functionality of all browsers on iOS. It also limits the potential for rival browsers to differentiate themselves from Safari. For example, browsers are less able to accelerate the speed of page loading and cannot display videos in formats not supported by WebKit. Further, Apple does not provide rival browsers with the access to the same functionality and APIs that are available to Safari. Overall, this means that Safari does not face effective competition from other browsers on iOS devices.

The evidence also suggests that browsers on iOS offer less feature support than browsers built on other browser engines, in particular with respect to web apps. As a result, web apps are a less viable alternative to native apps from the App Store for delivering content on iOS devices.

The CMA highlighted that app developers cannot differentiate their browsers from Safari, while web developers are bound by the features that WebKit supports.

Importantly, due to the WebKit restriction, Apple makes decisions on whether to support features not only for its own browser, but for all browsers on iOS. This not only restricts competition (as it materially limits the potential for rival browsers to differentiate themselves from Safari on factors such as speed and functionality) but also limits the capability of all browsers on iOS devices, depriving iOS users of useful innovations they might otherwise benefit from.

The debate also links to Apple's long-running reticence to allow app sideloading on iOS and iPadOS. The only practical obstruction to developers shipping web apps on iOS and iPadOS that are indistinguishable from native apps, outside of top level games, is Apple's WebKit restriction and control over Safari. If developers could use a different browser to open web apps, sideloading from the web effectively becomes possible.

It is also of note that CMA does not accept Apple's argument that limiting web browsing on iOS and iPadOS to WebKit is better for performance and tackling security vulnerabilities:

Overall, the evidence we have received to date does not suggest that Apple's WebKit restriction allows for quicker and more effective response to security threats for dedicated browser apps on iOS...

[...]

... the evidence that we have seen to date does not suggest that there are material differences in the security performance of WebKit and alternative browser engines.

Amid the ongoing debate, some developers have rallied behind the Twitter hashtag #AppleBrowserBan and launched an advocacy group to express their frustration with Apple's WebKit restriction.

Final Thoughts

The discussion around Apple's WebKit restriction is growing to be at the forefront of many issues with browsing on iOS and iPadOS. It remains open to debate whether allowing non-WebKit based browsers onto iOS like Firefox, Chrome, and Edge would be good for users or diminish the experience and security of browsing on the iPhone and ‌iPad‌. Would allowing Chromium onto iOS, for example, lead to a browser monoculture where Safari has less than a five percent market share? Would lifting the WebKit restriction be good for browser engine competition or cement the dominance of Chromium?

Apple is seemingly concerned about its worsening relationship with some developers with regards to Safari, and the company recently sought to tackle the accusation that "Safari is the worst, it's the new IE" by asking for feedback. Apple reneged on its controversial Safari redesign from WWDC last year, but Microsoft Edge is now on the verge of overtaking Safari as the world's second most popular desktop browser.

As a result, Apple is facing pressure to improve relations with developers, as well as make Safari and WebKit more compelling, but it is unclear whether any of this is enough to prompt the company to change its position on the WebKit restriction. There is also the question of whether Apple can realistically continue to maintain its policy in the face of increasing regulatory pressure.