We started Open Web Advocacy for one reason: to advocate to ensure that Web Apps could compete fairly with single-platform “native” apps on mobile, as they can on computers. We know that it’s a lot more work to develop, maintain and test two separate codebases, one for Android and one for iOS, which is onerous for smaller firms, charities and long tail businesses; web apps can run anywhere the web does, so you only need to maintain one codebase.
As an accessibility tester, I know that web tech is mature and exposes richer information to people with disabilities who use assistive technologies such as screen readers. For example, single-platform “native apps” can only say some text is a heading, or is not; the web can expose up to 6 levels of heading and sub-headings. Web apps run in browsers, and browsers fix accessibility bugs quickly. By contrast, React Native (a framework developed By Facebook that is write-once to produce “native” apps for each platform) has an outstanding bug I filed three years ago whereby people using an external keyboard on Android can’t focus in a text input field to enter information. Sucks to be disabled and reliant on some Facebook developers.
OWA’s first success was with the UK competition regulator, the Competition and Markets Authority (CMA) who wrote in their opening statements of the Market Investigation Reference into Browsers and Cloud Gaming
We all rely on browsers to use the internet on our phones, and the engines that make them work have a huge bearing on what we can see and do. Right now, choice in this space is severely limited and that has real impacts – preventing innovation and reducing competition from web apps. We need to give innovative tech firms, many of which are ambitious start-ups, a fair chance to compete.
The CMA has published its proposed remedies (PDF) (that is, fixes it could require of Apple and Google) in order to free up in the mobile app market in the UK. The fixes are good (thanks CMA!) but I’m worried they don’t go far enough, or aren’t specific enough, to avoid the kind of malicious compliance from Apple that we’ve been seeing in the EU as it attempts to wriggle around the Digital Markets Act. (The fixes aren’t only on Apple, but Apple has been the most egregious in stamping on competition and evading regulation).
Other browser engines are not enough
Obviously, allowing competing browser engines, like Firefox’s Gecko and Chromium (in Vivaldi, Chrome, Edge, Opera et al) is welcome, and vital. But that is not the goal; the goal is making web apps competitive with “native” apps, and the CMA does not go far enough because it only plans to mandate that Apple “grant equivalent access to APIs used by WebKit and Safari to browsers using alternative browser engines”.
The problem here is that Apple has long denied Safari access to some system features that “native” apps on iOS can access. For years, for example, native apps could send push notifications but Safari couldn’t. That recently changed (although the web push implementation is still reportedly pretty buggy). But still on iOS, Apple refuses to allow the web to access Bluetooth, USB etc, even though “native” apps can access these device capabilities.
Apple says that this is for security, but I note that Apple themselves told the CMAPDF that
WebKit’s sandbox profile on iOS is orders of magnitude more stringent than the sandbox for native iOS apps
So Apple’s web browser, according to Apple, is more secure than Apple’s own iOS native sandbox. Yet Apple has a worse track record than Firefox or Google in shipping patches for browser vulnerabilities. The CMA wrote(PDF)
it is not clear from the evidence available to date that WebKit has better security outcomes compared to other browser engines
If Apple itself does not believe that native iOS apps are more secure than browser sandboxes, why do they keep some device features away from Safari? It’s fair to think that Apple wants to force businesses to make native iOS apps instead of Web Apps, so that distribution and monetization is therefore controlled by Apple.
Missing remedy
To ensure that Apple cannot artificially hamstring all third party browsers, the CMA should mandate that all APIs and device integrations available to native iOS Apps, Apple’s own apps and services must be available to third party browsers.
Apple must implement install prompts
Apple likes to tell regulators that web apps are an alternative to native iOS apps in its App Store. In a submission to the Australian regulator PDF, Apple wrote
Web browsers are used not only as a distribution portal, but also as platforms themselves, hosting “progressive web applications” (PWAs) that eliminate the need to download a developer’s app through the App Store (or other means) at all. PWAs are increasingly available for and through mobile-based browsers and devices, including on iOS. PWAs are apps that are built using common web technology like HTML 5, but have the look, feel and functionality of a native app.
Let’s test the accuracy of Apple’s statement. Here’s an example of a PWA, Stuart Langridge’s Farmbound game, rendered by Chrome on Android:
Chrome has seen that Farmbound is an installable Progressive Web App and generated the install banner you can see ‘floating’ over the game (and which I’ve highlighted with a red box). Tapping it adds the game’s icon to your Android homescreen. Stuart didn’t need to do anything other than code the game correctly, and add a line in his HTML pointing to a manifest file:
<link rel="manifest" href="manifest.json">
(You can see Farmbound’s manifest; this is the Web! You can view source!)
The excellent image compression squoosh.app adds its own install button rather than rely on Chrome’s heuristics, using the beforeinstallprompt event that fires when the browser has detected that a website can be installed as a Progressive Web App. As MDN states,
The typical use for this event is when a web app wants to provide its own in-app UI inviting the user to install the app, rather than the generic one provided by the browser. This enables the app to provide more context about the app, explaining to the user why they might want to install it.
Safari on iOS does not prompt a user to install a Progressive Web App; neither does it support beforeinstallprompt. On iOS, the user must perform the following intuitive ritual:
- Press the share button. Yes, you choose “share” to install; makes sense, right?
- Scroll down below the share menu’s fold to discover the ‘add to homescreen’ option, assuming you somehow know that this exists
- Click ‘add to homescreen’
- Decide to accept the app’s name, or replace it
- Click ‘add’
Apple does offer an analogous one-tap installation mechanism for apps, but (you’ll be amazed to learn) it only works for native iOS apps that are in the Apple App Store. A web site owner can add a single line of HTML, much like the one linking to a PWA manifest, but this one pointing to the app in the App Store associated with the website:
<meta name="apple-itunes-app" content="app-id=myAppStoreID, app-argument=myURL">
Apple writes that its proprietary Smart App Banners allow site owners to “create a banner to promote your app on the App Store from a website”. Here’s an example from yuka.io, with the Safari-generated banner highlighted by me in a red box:
Apple says
If the app is already installed on a user’s device, the Smart App Banner intelligently changes its action, and tapping the banner simply opens the app. If the user doesn’t have your app on their device, tapping the banner takes them to the app’s entry in the App Store … Smart App Banners automatically determine whether the user’s device supports your app. If it doesn’t, or if your app is unavailable in the user’s location, the banner doesn’t appear.
How different from the clunky precess to install a PWA on iOS! So much for Apple’s claim to the Australian regulator that PWAs “have the look, feel and functionality of a native app”.
It’s hard to see why Apple make it so hard to install a PWA yet so easy to install a native app. And when I say “hard to see”, I mean because it’s in a tiny grey font against a white background, so I’ve emphasised it with a red rectangle:
Apple makes it easy to install a native iOS App from a webpage; a native app in the Apple App Store, from which Apple taxes 30% of in-app purchases. It earns nothing from PWAs because they are distributed from the owners’ sites, not an intermediary gatekeeper’s App Store.
The missing remedy
Apple cannot be allowed to continue self-preferencing native Apps over Web Apps. I don’t think Smart App Banners should be removed, but comparable functionality should be added for PWAs. Although 5.32 of CMA WP7 says
Apple would be required to eliminate its use of private APIs for WebKit and Safari without degrading currently available functionality made available for WebKit and Safari
I would like to remove any doubt and see CMA explicitly require Apple to implement install prompts for PWAs in Safari/iOS. It doesn’t have to be implemented in them the same way as Chrome, just with the same outcome.
Web Apps must open in the browser that installed them
The current suggested remedies allow for third-party browser engines on iOS, and those will be able to download PWAs. However, none of the remedies explicitly requires that those PWAs will subsequently run in the engine that downloaded them.
Apple is a master of malicious compliance, and would probably argue that it could fulfil CMA’s remedies by allowing browsers to use their own engine and providing them access to the share menu to install Apple’s WebKit implementation of Web Apps. This is actually the current state of affairs in the EU; Apple tried to completely kill PWAs (which it calls ‘Homescreen Apps’) in Safari, so that it wouldn’t have to allow them in other engines. They backed down after a campaign by EU web developers, but (so far, at least) all PWAs on iOS will continue to be hamstrung by running in Webkit. Apple said
we will continue to offer the existing Home Screen web apps capability in the EU. This support means Home Screen web apps continue to be built directly on WebKit and its security architecture, and align with the security and privacy model for native apps on iOS.
The CMA is aware of this problem. In their interim report in connection with our market study into mobile ecosystems, they wrote
By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.
This would also be very user-hostile. The browser that installs a PWA would almost certainly be the user’s default browser, and (on a personal device rather than, say, a locked-down corporate laptop) people choose their default browser for a reason.
I use Vivaldi browser, and prefer to browse with some accessibility settings that I can tweak as necessary if my Multiple Sclerosis is playing silly buggers:
You might use something else, with different settings. That’s your choice. But whatever your choice is, I believe it should be respected if you open up a PWA, and I believe that the CMA should make this explicit. Wouldn’t it be weird if your default browser settings worked fine while you played Farmbound on its website, but didn’t work if you opened the Farmbound PWA because, unknown to you, it was running in WebKit?
The missing remedy
The CMA should require that PWAs downloaded in one browser are subsequently run in that browser, running its own engine, with its user settings.
Otherwise, we could find ourselves in a situation where Microsoft could ship Edge on iOS, powered by Chromium; Edge could be my default in-app browser, but they couldn’t implement web Bluetooth in Edge (because Safari doesn’t have Bluetooth access so Edge doesn’t have to have it either) and they couldn’t add an Edge app to Home Screen (because Apple might/would mandate that add to Home Screen would add it as Safari).
And I don’t think that is what the CMA want, at all.
What you can do to help
You can write to CMA, explaining why these suggested ‘missing remedies’ would be useful for the PWA you make, or for your UK customers. I don’t want to give a template, because a deluge of “+1” mails isn’t helpful; what is helpful is for CMA to understand how their remedies should be tightened or augmented. But you might try something like:
Darling CMA [they are human! Make them feel loved!]. My organisation makes YrkshrPudz.io, an app aimed at UK customers to help them make crispier Yorkshire puddings. Our Android PWA is really well-received but we have to spend 20 developer hours a week making a native iOS app because Safari can’t access bluetooth, which we need to control the temperature of our YrkshrPudz™ bluetooth Yorkshire Pudding Oven (the “Krispinator XL™”). Allowing iOS browser engines to access the same device functions as native apps would save us £900,000 per year in developer time. Lots of love, Hang loose and stay gravy! etc
You need only comment on stuff which is relevant to you; you do not need a comprehensive position paper on the whole thing. If any part of your email is confidential, just tell them. Email the MIR team at browsersandcloud@cma.gov.uk, referencing Working Paper 7 (perhaps as the subject field) before end of Thursday 29 August, please!
We saw the power of 5,308 real, independent developers in getting Apple’s attempt to kill PWAs reversed in the EU. Your voice can make a difference; use it!
Further reading