When Apple launched the iPhone, Steve Jobs stood on stage and talked about how the way to build great apps for it was to build web apps.
We've got an innovative new way to create applications for mobile devices, really innovative, and it's all based on the fact that iPhone has the full Safari inside. The full Safari engine is inside of iPhone and it gives us tremendous capability, more than there's ever been in a mobile device to this date, and so you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone!
And these apps can integrate perfectly with iPhone services: they can make a call, they can send an email, they can look up a location on Google Maps. After you write them, you have instant distribution. You don't have to worry about distribution: just put them on your internet server. And they're really easy to update: just change the code on your own server, rather than having to go through this really complex update process. They're secured with the same kind of security you'd use for transactions with Amazon, or a bank, and they run securely on the iPhone so they don't compromise its reliability or security.
And guess what: there's no SDK! You've got everything you need, if you know how to write apps using the most modern web standards, to write amazing apps for the iPhone today.
— Steve Jobs
Today, on Apple's website, it explicitly reads: Apps that provide core features and functionality dynamically with web technology like HTML5 are best delivered to everyone in Safari, rather than through the curated App Store.
So this push has been around from the beginning of iOS right up to today: the idea that you can and should use web apps to deliver great experiences on Apple's devices. They point you at the browser. They're encouraging you to use the browser.
And Apple themselves are still claiming this! They claim that you can deliver your app perfectly happily on the web. In their opening presentation to the US court trial Epic Games vs. Apple, Apple showed the Financial Times web app on an iPhone, next to the Financial Times native app on an iPhone, with the two looking basically identical, to demonstrate that web apps are as competent as native apps on their devices.
But you have to use their browser to do it. The App Store review guidelines specifically state this:
2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.
And what this means is that any browser on the device is basically Safari. You can add features around the core browser, but you can't change the browser itself: you can't change how web pages are rendered or how they're interacted with, and you can't fix issues or offer features that Safari doesn't.
Apple claim that the reasons for this are privacy and security. As part of the US congressional subcommittee on antitrust (PDF transcript), the chairman David N. Cicilline asked: “Does Apple restrict, in any way, the ability of competing web browsers to deploy their own web browsing engines when running on Apple’s operating system?”
And Kyle Andeer, Vice President of Corporate Law at Apple, replied: “The purpose of this rule is to protect user privacy and security. By requiring apps to use WebKit, Apple can rapidly and accurately address exploits across our entire user base and most effectively secure their privacy and security.”
So, what if we take them at their word? Do Apple rapidly and most effectively secure our privacy and security?
There's an interesting Vice article from earlier in 2021 on this topic. It goes into some detail about Apple's security work — or sometimes absence of it — on their devices. “Out of the seven in the wild vulnerabilities fixed by Apple this year, five of them were in Webkit, the browser engine developed by the company and used in Safari,” the article says, followed by how “researchers who specialize in looking for vulnerabilities and exploits for iOS consider this amount of iPhone vulnerabilities being exploited in the wild to be high.”
But everyone has security problems. Simply pointing a finger at Apple's problems specifically seems like it might be singling them out; the issue is not only how many security bugs and exploits there are, but how they're handled.
But when policy is that there’s only one web browser and Apple the only ones who can fix it, the patch gap becomes a problem: this is how long it takes a fix for a bug to arrive on your iPhone.
Cybersecurity startup Theori identified a crasher bug in Safari's handling of AudioWorklets, a part of the Web Audio API to allow web apps to play and control sound. The bug in question was fixed in the open source WebKit engine for weeks before that fix was actually included in Safari.
Now, Apple have talked a lot about their security stance. There is a list of 16 APIs that Apple have declared they will not implement; most of these are around accessing hardware devices from web apps. They include Web Bluetooth, Web MIDI, Web NFC, battery status, Web USB, serial API, the ambient light sensor. The industry is divided on the wisdom of allowing web apps to control hardware devices in this way: Apple consider these APIs a security or privacy risk, and so do Mozilla in Firefox; Google do not in Chrome, and these APIs have implementations in Chrome and some other browsers using its underlying Blink engine.
It is undeniable that these features form a difference between native app and web app capabilities; any app which intends to use any of these APIs cannot be delivered as a web app and therefore there is not feature parity between web apps and native apps. However, as mentioned, the industry is divided on this. It is worth leaving these issues to one side; instead, we should discuss other details of standards compliance and implementation speed in Safari. It can be confusing when some APIs and some features have been left out for security reasons; in particular, it's quite easy to imply that all of Safari's lag in implementation — all of the patch gap — comes about because of a conservative security stance when this is not the case. Much of the lag behind has nothing to do with security.
This is a graph from the Web Compat 2021 dashboard which shows the "Compat 2021" score for each browser over the course of 2021, a measure of how well and how completely each browser implements each of five of the most common problem points for web developers. None of these five common points are security-related or to do with hardware access APIs; each is related to layout and styling of pages, and improvements to support in these areas affect pretty much every web page that's written. Handling issues and mistakes in browser support in these issues consumes a lot of web developer time; the issues, for techie types, are flexbox, grid, position sticky, aspect ratio, and CSS transforms. Safari's score under these tests lags noticeably behind other browsers, and this is not because support is slower or being declined for security reasons. This is the “patch gap”, but it applies to everything.
The idea that “Safari is the new Internet Explorer” is almost axiomatic in parts of the web developer community; the memories of Microsoft's Internet Explorer having once been the leading browser but then being left to stagnate and hold back web development for years are still painful.
So if Apple aren’t doing a perfect job, can anyone else help? They imply that others can; Apple point out (in their submission to the US committee on antitrust) that WebKit is open source:
“WebKit is an open-source web engine that allows Apple to enable improvements contributed by third parties... third parties can contribute relevant changes to the WebKit project for incorporation into the WebKit engine.”
But they've also declared that they won't include support for the 16 APIs already mentioned, for example. And there is a lot of stop energy around other features, such as web components, which are less obviously disagreements about security rather than direction.
So it's difficult to claim that WebKit truly is open to outside contribution, if that outside contribution disagrees with Apple's corporate direction. And even changes which are entirely uncontroversial are still painful to get to actual users; as above, changes successfully made in the underlying WebKit still take longer to arrive into Safari itself. Part of the reason for this is that Safari changes are released with the OS, meaning that you can't get a browser fix until you get a new OS version.
Google has had to fund some work to fix some of the scrolling and iframe sizing issues in Safari ...but can't fix all of them because Safari isn't actually Open Source, and many of the scrolling bugs are additions to or changes in the private iOS copy of WebKit, not the public open source version, and so are not visible to or contributable to by the public.
So if Apple aren't keeping their promise by making it possible to deliver equivalently featured apps on the web, and it's difficult for other companies or contributors to help them to do so, do they allow anyone else to compete by publishing their own browser as a rival to Safari?
No. On iOS, all browsers are Safari.
The company have tried quite hard to imply that this is not the case. In the submission to the committee on antitrust, they say:
Web Browsing: Apple offers Safari. There are a wide variety of browser apps on the App Store. Examples: Google Chrome, Microsoft Edge, Firefox, Yahoo, Yandex Browser and Duck Duck Go.
But this is wildly disingenuous when there's only one browser engine shared between them all! This is not true on any other OS; even Chrome OS, which is named after a browser, does not restrict other browsers from running.
Alternative browsers on iOS aren't just restricted to WebKit, they're restricted to the version of WebKit which is in the current version of Safari. Not even different or more modern versions of WebKit itself are allowed.
Even motivated users who work hard to get out of the browser choice they're forced into don't actually get a choice; if they choose a different browser, they still get the same one. If there’s a requirement from people for something, the market can’t provide it because competition is not permitted.
This graph from before should be annotated to indicate that “Chrome/Edge” actually means “Chrome/Edge on platforms other than iOS”, and Chrome and Edge (and Firefox and everything else) on iOS are actually Safari, and follow the Safari line.
Apple's claims that web apps are at parity with native apps on their platform is denied by the very developers who built the web apps they hold up as examples! Ada Rose Cannon in her tweet says:
Seeing a Web App I worked on used by *Apple* to justify that the Web is a viable platform on iOS is bullshit
— Ada Rose Cannon (@AdaRoseCannon) May 4, 2021
The Web can be an ideal place to build apps but Apple is consistently dragging their heels on implementing the Web APIs that would allow them to compete with native apps
and links further to Peter Gasston's tweet:
This image from Apple‘s opening presentation in the Epic Games court case is very misleading. “Web Apps and Native Apps can look the same, therefore no-one needs to publish on the App Store”.
— Peter Gasston (@stopsatgreen) May 4, 2021
Let @slightlylate explain why…https://t.co/tqqBMiEDWr pic.twitter.com/rrrOiO7HUe
which in turn links to Alex Russell's piece, “Progress Delayed Is Progress Denied”, part of a series of essays on browser choice and the browser landscape, including the very relevant “iOS Engine Choice In Depth”.
It's pretty well known that software diversity leads to better security. There's no diversity in browsers on iOS and thus decreased security; an exploit in one browser is an exploit in all of them. And because Safari is closely tied to the OS such that new Safari releases effectively require new OS releases, an exploit in any browser is also often an OS-level compromise. This is why jailbreaking software, which breaks the security of an iOS device to allow circumventing Apple's policies, is often delivered by compromising the browser -- see TotallyNotSpyware and JailbreakMe and PwnMy for various iOS versions.
The idea that forbidding choice leads to greater security is extremely dubious.