Apple’s Browser Engine Ban Is Holding Back Web App Innovation – InApps 2022

Prominent Apple blogger John Gruber kicked off a firestorm on Twitter when he suggested recently that web developers “should not be trying to create a ‘native like app’ in a web browser.” Gruber said this in relation to increasing criticism of Apple for not allowing competing browser engines on its iOS platform. By forcing browser vendors like Google, Microsoft and Mozilla to use the WebKit browser engine, Apple is deliberately restricting the functionality of web apps on iOS. It’s why many of the features of progressive web apps (PWAs) do not work on an iPhone or iPad.

Despite the clear bias that Gruber has towards Apple’s proprietary iOS platform, he does raise an interesting philosophical question: how far should web apps go in trying to emulate the advanced functionality of native apps? To answer that question, we first need to understand how far web apps have come already.

A Brief History of Web Apps

For the majority of its history, the web has been a platform for applications as well as web pages. Although it started out in 1991 as a document-centric platform, as early as 1993 — with CGI scripts — the web began evolving into an application platform. Both Netscape and Microsoft turned their web browsers into web app platforms in the mid-to-late 90s, and by the early 2000s we had Ajax applications — a key driver of the so-called Web 2.0 era.

Where Gruber’s argument against the web as an application platform comes into play is with the arrival of Apple’s iOS and Google’s Android in the late 2000s. This flipped the internet into a largely smartphone-driven application platform. Famously, Instagram launched in 2010 as an iOS-only app and completely ignored the web (it added an Android app in 2012). Even to this day, Instagram has limited web browser functionality. So the web got left behind somewhat in the early 2010s, as iOS and Android began to dominate the internet landscape.

However, over the past several years we’ve seen the re-emergence of the web as an application development platform. This has been thanks not only to JavaScript-fueled frontend frameworks like React, but also to the recent advancement of web standards. The latter is in no small part due to WHATWG (Web Hypertext Application Technology Working Group), a group run by Apple, Google, Mozilla and Microsoft. WHATWG operates what it calls the “living standard” for HTML, which is then adopted by the World Wide Web Consortium (W3C) as an official web standard.

The problem is, whereas Google, Microsoft and Mozilla have all fully committed to advancing the web as a platform, Apple doesn’t want to erode the popularity of its iOS platform. It wants the next Instagram to be built on iOS, not be launched as a PWA! This brings us to Apple’s controversial position to restrict the web browser engine on iOS to its own WebKit engine.

Instagram was only available as an iOS app over 2010-11. Its website in 2011 was brochureware.

The Differences between WebKit and Blink

Apple’s decision is largely aimed at keeping Google’s technology at bay on iOS. The Blink browser engine that Google took the lead in developing, as a part of the open source Chromium project, is an absolutely vital part of Chrome on desktop, Android, and all other operating systems apart from iOS. The version of Chrome that iOS users can download, which uses WebKit rather than Blink, pales in comparison.

The stated mission of the Blink project could not be clearer about its goals for application functionality. Its mission is to “make the web the premier platform for experiencing the world’s information and deliver the world’s best implementation of the web platform.” The implication is that Blink wants its engine to compete directly against native apps to be the “premier platform” for the consumer internet.

While WebKit is also open source, its stated goals are much less application-centric. WebKit is positioned as a “content engine” — a subtle way of telling us that web browsers should stay in their lane and stick to content, rather than full-on applications. By contrast, Blink calls itself a “rendering engine,” which is a more open-ended definition (apps are rendered, as well as web pages). Further, the WebKit project states that if WebKit is to be used in applications, then it should be in a supporting role rather than a starring role: “…we also want to make it possible to embed WebKit in other applications, and to use it as a general-purpose display and interaction engine.”

The “other applications” obviously refers to iOS applications, which is the primary development platform for Apple.

So Why Should Web Apps Compete with Native Apps?

The answer to the above question is simple: web apps should be allowed to compete with native apps because the web is an open platform that allows developers to “write once, run anywhere.” The arguments against web apps tend to be more complicated and tenuous.

Apple fans like John Gruber argue that on an iOS device, it is better to create sophisticated applications using the native iOS development platform. In his Twitter battle with web app fans, he cited “battery life, security, privacy, and a stance against Chrome dominating the entire web” as some of the reasons he backs Apple banning third-party browser engines. He added later in the thread that “native apps provide a better user experience.”

Well of course they do. What Gruber conveniently failed to mention is that Apple’s banning of third-party browser engines on iOS is repressing innovation in web apps. Modern PWAs running on Android are increasingly providing a user experience just as good as a native app on Android. Whereas on iPhone, there’s no debate that native apps are better than PWAs — but only because Apple doesn’t let third-party browsers use the full spectrum of web app technology.

via @feross

It’s not just the lack of choice in browser engines on iOS, it’s that WebKit itself is deficient as a browser engine. Alex Russell, who is now a Partner Program Manager on Microsoft Edge but before that spent many years as a senior engineer on Google Chrome, has written extensively about Apple’s approach to the web. While he was still with Google, he published a long critique of WebKit, concluding that “Apple’s web engine consistently trails others in both compatibility and features, resulting in a large and persistent gap with Apple’s native platform.”

Build a Better App

Summing up here, native apps are only better than web apps on iOS because a) Apple prevents other browser vendors from using their preferred browser engines, and b) Apple’s WebKit has not kept pace with the likes of Chromium in terms of application functionality. So the fact that web apps aren’t able to fully compete with iOS apps is an Apple problem, not a web problem.

Should web apps aspire to be equivalent to native apps? Absolutely they should, because there is a long and rich history of applications running on the web — going right back to 1993. Web apps got derailed in the early 2010s due to smartphone apps. But now, thanks to web standards and the innovation happening around open source web engines, the web is once again an exciting development platform. Heck, maybe the next Instagram will be built on the web after all!

Lead image via @feross.