Table of contents
It’s that time again when we explore all the changes with the latest iOS version — iOS 14 Beta 6 — and discuss with you what’s changed, what’s new with the state of PWA adoption on iOS. As seen in our last PWA iOS 13 article, there was plenty of good news to be had in the last version, and it sure looked like Apple was becoming more PWA-friendly. But are they keeping their pace of PWA adoption, or are they dropping PWA altogether in fear of losing app revenues? Well, that’s what we’re here to find out.
Release notes
Here are some of the important changes that we know to be coming to Safari in this new version (some of the irrelevant parts were omitted):
- Support for Safari Web Extensions on macOS.
- Support for HTTP/3.
- Improved Web Platform Tests pass rate for WebDriver, XHR+Fetch, Service Workers, CSS, and SVG.
- Enabled full third-party cookie blocking, and the Storage Access API in Private Browsing mode.
- Removed support for Flash
- Added a Web Authentication platform authenticator using Face ID or Touch ID, depending on which capability is present.
We can tell what you’re thinking about — not so significant changes, aren’t they? Well, turns out there’s more to PWA iOS 14 than meets the eyes.
Digging more into it
This is the part when we dig more into the operating system and find out about the current state of PWA in iOS 14 —including what are the changes and how has PWA been improved, and what can we expect when iOS 14 hits global stable release.
The goods
First sign of Service Worker
There’s a new WebKit feature in this update which is called App-Bound Domains and, with this feature enabled, the service workers API can actually be enabled on the bound domains. Although there’s no official documentation regarding what we can expect from service workers — nor is there any confirmation about whether or not this feature is here to stay — we think it’s still a very promising news for PWA enthusiasts out there.
App-Bound Domains
What this new feature brings to the table is a way for developers to restrict in-app navigation to a number of domains and in turn, guaranteeing more security for the end-users. These “app-bound” domains are specified in the info.plist file, under the WKAppBoundDomains key, like so:
<plist version="1.0">
<dict>
<key>WKAppBoundDomains</key>
<array>
<string>example1.com</string>
<string>example2.org</string>
...
</array>
</dict>With the App-Bound Domains enabled, we can now have service workers registered:
There are, however, only vague explanations as to why service workers are enabled when we have App-Bound Domains configured. And since there’s no way to debug instances of service workers, the whole thing is still relatively vague even to the more experienced developers.
Let’s take Cache Storage — the defining feature of service workers — for example. It is nowhere to be found under Storage in Safari DevTools, and the service worker registration, to quote the experienced developers that did the major work:“is not shared with Safari, home screen web apps, or other apps using WKWebView and App Bound Domains on the same origins.”
Although we don’t have the full picture yet, the fact that Service Worker is a thing in iOS is still a cause for celebration, and we can only hope that the stable release can give us a fuller picture.
New support for TouchID and FaceID
Recently introduced in the Apple Worldwide Developers Conference (WWDC), Touch ID and Face ID are now finally available on Safari via the WebAuthn API. When integrated, these features will provide a frictionless experience for your PWA and in turn, driving better user experience.
Ability to change default browser
Starting from iOS 14, users can now finally choose different browsers as default. This is (kind of) a nice move from Apple and good news for Apple users everywhere, as changing default apps just wasn’t possible before. But hold your horse just yet, this doesn’t mean that Apple users can benefit from all the exciting features that different web browser engines will bring — in fact, it’s all the same. Third-party browsers are still under the restriction of relying on Apple’s WebKit as their underlying browsing engine, which means that while your new default web browsers may look shiny and different on the outside, nothing is really changed on the inside.
Geolocation for the Web
So what’s up with the state of the W3C Geolocation API in Safari? Well, there’s some changes that result in better location-tracking, but not as a direct result of any improvements made on the W3C Geolocation API. Strange? We know. Let’s dive more into this:
When Precise Location is enabled per app in the new iOS 14 Beta, we can have Safari track our approximate location:
The approximate location is known by the OS only, and during the process of analyzing this new location-tracking behavior in iOS, no one has really found a conclusive answer to how the new iOS 14 Beta 6 delivers approximate locations to PWAs. But looking at the data so far, it seems promising. Below is an example from Flirt’s work which uses Iguazú as the tracking location.
As you can see, the API accurately determines and shows the subject’s location. Our guess is that this impressive result has something to do with the coming changes to the Core Location API which was showcased in this WWDC2020 video.
App Clips — might be a good thing
With the new App Clip, developers can deliver a “PWA-installation-like” experience simply through the use of a meta tag:
<meta name="apple-itunes-app" content="app-id=myAppStoreID, app-clip-bundle-id=appClipBundleID, affiliate-data=myAffiliateData, app-argument=myAppArgument">
You can imagine this new App Clip feature to function similarly to the Instant App on Android, only that it’s more focused on NFC and QR scanning — and getting the users to eventually install native apps.
[Source: Apple’s Newsroom]
What’s the potential of this new feature? We don’t know — but it might prove to be a step toward the installable PWAs that we have on Android.
The bads
New App Gallery ignoring PWAs
The new App Library is an automated feature that sorts and organizes your app by app use, categories, etc. PWAs that are added to home screen can now have the advantage of appearing in the user’s Home Screen and under the Webclips category, although this behavior isn’t consistent and is subjected to changes.
In reality, early testers have found that PWAs are ignored and are not shown at all in the new App Library — whether it be on the “Recently Added” or “Suggestions” group. So while it could be nice that PWAs got the same kind of treatment as native apps, this is still a shocking news for us since we didn’t expect PWAs to be simply ignored.
No change to Web App Manifest support
As you would have expected, there’s no movement whatsoever from Apple to push for Web App Manifest support. The status for Web App Manifest support remains Partially Supported, which means there’s no support for icons, minimal-ui, fullscreen, orientation, or theme-color.
Source: WebKit
Status Bar
While it’d be nice to see iOS taking in the value(s) from theme-color from the Web App Manifest, we would have to settle for less in the meantime. From iOS 14 beta version 5 onwards, we can’t have white status bar anymore and the only accepted values are black and black-translucent.
The uglies
Core features are still unsupported
It is a big update, but something still feels lacking. It mostly probably has something to do with the fact that some core features of PWA are still left unsupported, and there’s almost no movement from Apple to push for these features:
- Web Push
- Background Sync
- Page Lifecycle
- Service Workers on WebViews (which means no PWAs on Chrome, Firefox, Instagram, or Facebook where web browsing is not the main goal)
- Universal Links / Link Capturing
Conclusion
How do you feel about all these coming changes? As for us, we feel that we’re left with a disappointing note after reviewing all the changes. There are some changes — e.g. App-Bound Domains, Geolocation — that seem to be a step in the right direction, but Apple didn’t really bother to push for more PWA’s core features in this update. And it makes sense, we guess, since it’s Apple that’s we’re talking about here — who we have always known to be so adamantly against the Web.
