Web devs rally to challenge Apple App Store browser rules
Open Web Advocacy takes aim at Apple's walled garden
On Monday, a group of software engineers plan to launch a group called "Open Web Advocacy" to help online apps compete with native apps and to encourage or compel Apple to relax its iOS browser restrictions.
The group (OWA), organized by UK-based developers Stuart Langridge, Bruce Lawson, and others, aims to promote a more open web by explaining subtle technical details to lawmakers and to help them understand anti-competitive aspects of web technology. Over the past few months, group members have been communicating with the UK Competitions and Markets Authority (CMA) to convince the agency that Apple's iOS browser policy harms competition.
In conjunction with the debut of the group's website, the OWA plans to release a technical paper titled "Bringing Competition to Walled Gardens," that summarizes the group's position and aims to help regulators in the UK and elsewhere understand the consequences of web technology restrictions. The group is looking for like-minded developers to take up its cause.
"We're mostly software engineers, we're all individuals," explained Langridge in an interview with The Register. "So this isn't just on behalf of browser vendors or employers or anything like that. We came together to make the web better, really, and no major companies have been pushing for changes. And there's a lot we think that can be done to improve the web, specifically on Apple devices and more generally."
"The motive of the group is to try to persuade Apple that they need to allow other browser engines on iOS, so the iOS can be a better platform for developing stuff for the modern web," explained Lawson. "Because at the moment, every browser on iOS, whether it be badged Chrome, Firefox or Edge is actually just a branded skin of Safari, which lags behind [other browsers] because it has no competition on iOS."
The primary concern raised by Langridge and Lawson is that Apple's iOS App Store Guidelines require every browser running on iPhones and iPads to be based on WebKit, the open source project overseen by Apple that serves as the rendering engine for the company's Safari browser.
Apple's browser engine monoculture has long been a sore spot with web developers and web technology advocates like Alex Russell, formerly with Google and currently with Microsoft.
But the issue of browser engine choice has been overshadowed by recent legal and legislative efforts, spearheaded by Epic Games, to open up Apple's iOS App Store to third-party payment systems. While Epic Game's antitrust lawsuit against Apple has sparked debate and seen a legislative fix proposed, the issue of web engines in Apple's ecosystem has been left unaddressed.
However, Apple turned the spotlight back onto its WebKit rules when it defended its App Store hegemony by asserting that web apps present viable competition to the native iOS apps within its App Store. Russell and others pushed back, arguing that one of the slides Apple presented during the Epic vs. Apple trial misrepresented reality by claiming of web and native apps have equal capabilities on iOS devices.
- UK's antitrust watchdog is very angry and has written a letter telling Apple and Google how angry it is with them
- Apple's Safari browser runs the risk of becoming the new Internet Explorer – holding the web back for everyone
- Apple emits emergency fix for exploited-in-the-wild WebKit vulnerability
- What if Chrome broke features of the web and Google forgot to tell anyone? Oh wait, that's exactly what happened
"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," the regulator wrote.
The CMA in December last year extended the information-gathering phase of its investigation until today - the end of February 2022. It's likely to be a few more months before the agency offers its conclusions.
OWA organiser Stuart Langridge said not only is it the case that every iOS browser is just a re-skinned version of Safari but that the WebKit-based versions of Chrome, Edge, and Firefox are even less capable than WebKit-based Safari because they lack access to certain APIs that Apple makes available to its own browser.
As an example, he described how he has a shortcut to Wordle, a web app, on his iPhone home screen. "I normally use Firefox on iOS," he explained. "And I had to switch back to Safari because you can't add things to your home screen from another browser. It's only available to Safari. So third-party browsers, even if they're the same engine as Safari, don't have access to the same APIs."
Time to make a stand
The OWA's "Bringing Competition to Walled Gardens" paper outlines the following ways in which Safari is felt to be deficient:
1. Full Screen Video
Safari is allowed to make video full screen, but other "browsers" are prevented from doing so, except on iPad. It is hard to see the rationale for allowing it on iPad but disabling it on iPhone.
2. Full Screen Games
Canvas, a software component, which is essential for Games can not be made full screen. Apple derives most of its App Store revenue from games packaged as native apps.
3. No Web Apps
The other "browsers" can not install Web Apps. Only Safari can.
Only Safari can use browser extensions, including those that block advertising. End-user choice is therefore limited.
5. Apple Pay
Apple limits the integration of Apple Pay with the other browsers.
6. In-App Browsers
Regardless of the user's default browser setting, iOS will always force the user to use Safari instead of the user's choice of browser. An In-App Browser is a browser that you would see inside an application like Twitter when you visit a link from inside the application.
The paper also cites more than 30 missing functions or APIs for iOS WebKit browsers, including Push Notification, Navigation Preload, Web App Install Prompts, Web Bluetooth, Web NFC, Fullscreen API for
non-video elements, and WASM Threads.
Not a black and white issue
The API disparity is not entirely negative. Browser makers may choose not to implement APIs specifications out of concern the proposed features have potential privacy or security problems. Apple has done so, as have other browser makers like Mozilla. Google has tended to be more permissive and to push more boundaries with Chrome.
Langridge acknowledges that different browser teams have different tolerance levels for new proposals, but says there's a whole set of APIs that don't raise security or privacy issues that Safari tends to fall behind on because of its slower release cadence – Safari updates tend to come out with iOS updates, often with months between releases, while Chrome ships every four weeks.
Lawson argues Apple's leisurely handling of Safari (WebKit) bugs makes a mockery of its claims that its App Store rules are necessary to mitigate security threats.
"Over Christmas, there was a huge bug in something called IndexedDB," said Lawson. "That allowed any arbitrary website to see other websites you visited. Not all of them but those that use certain browser features. And that remained unpatched by Apple for 57 days. So for 57 days, every iOS user who used any web browser on iOS – because it was using WebKit – was leaking data left, right and center. If Apple actually did fix security errors fast, that would be a plausible defense, but they don't."
Apple is aware of the criticism and appears to have taken some steps to address it. There's been a noticeable increase in WebKit job postings, for example.
The Register told Apple that an advocacy group has formed to push for App Store rule changes and asked whether anyone from the company might wish to comment on why that might not be desirable.
To our astonishment, after having queries ignored for months, an Apple spokesperson responded, asking whether the company could correspond off-the-record. We replied that we would be happy to communicate off-the-record and then never heard back.
Or if we did, we couldn't say. ®