PWA in 2020, come on Apple!

A progressive web app is a web application that acts and feels like a device native one. It can be added to the user's home screen, can be installed even on desktop. It is fast, light-weight, reliable, should possess offline usage support.

In 2007, Steve Jobs, while introducing the iPhone at MacWorld, proposed about progressive web app, Apps that will remain as web apps but will have the capabilities of native applications through the safari engine. That idea has expanded since then, gained much traction and is now a reality.

In a research work published on the 23rd of march 2017, Gartner predicts that by 2020 PWAs will replace 50% of consumer-facing apps.

Here we are in 2020, and Steve's claims are not materializing. Despite Apple being a pioneer of this idea, they're not really helping developers - at least for one major reason.

What Makes a Progressive Web App

The following makes for a seemless progressive web application:

A Manifest File
Application must be served over https
A registered Service Worker Process
IndexedDB
Push Manager

Web Manifest File

In the words of the Google developers documentation, the web app manifest is a simple JSON file that tells the browser about your web application and how it should behave when 'installed' on the user's mobile device or desktop. It describes things such as the preferred screen orientation, start url, scope, theme, application name, application icons, etc.

Service Worker

Service Worker is a Worker process that runs in the background once registered, even when the web application is not active. This is the place to handle any background processes that your web application needs. A service worker runs in a separate thread to the main browser application. It can intercept network fetch requests made by the browser by registering a FetchEvent listener.

A progressive web application should make proper use of the Service Worker, to support offline usage by intercepting network calls and caching resources for later use, while respecting cache policies.

  //detect service worker support
if (
  typeof self !== "undefined" ||
  (typeof window !== "undefined" && "serviceWorker" in window.navigator)
) {
  console.log("service worker supported");
}

Note: Your detection script should check if you are running inside a worker environment or window the browser environment.

IndexedDB

In the words of Mozilla Docs, IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files/blobs. It is available in a service worker with the purpose of caching assets.

  let global = null;
if (typeof typeof window !== "undefined") {
  global = window;
} else if (typeof self !== "undefined") {
  global = self;
}

if (global && "indexedDB" in global) {
  console.log("indexedDB supported");
}

Push Manager

Push manager enables web applications to receive messages pushed to them from a server. That is regardless of whether the web app is in the foreground, or even loaded, on a user agent. This is critical as majority of applications will always need to notify user of one thing or another. One can integrate Google Firebase Messaging for a quick, secure and reliable implementation.

  let global = null;
if (typeof typeof window !== "undefined") {
  global = window;
} else if (typeof self !== "undefined") {
  global = self;
}

if (
  global &&
  "PushManager" in global &&
  PushSubscription.prototype.hasOwnProperty("getKey")
) {
  console.log("push manager supported");
}

At the time of writing in 2020, this was not supported in Safari on iOS or Mac. That statement is historical: Safari 16.1 added Web Push on macOS Ventura, and iOS/iPadOS 16.4 added Web Push for web apps installed on the Home Screen.

The Problem

At the time of writing, browser support varied. A contemporary estimate from the CEO of WonderPush said about 80% of users worldwide had devices supporting web push notifications.

The limitation this article identified in 2020 was the lack of Web Push on iOS. That has changed: macOS Ventura gained Web Push in Safari 16.1, and iOS/iPadOS 16.4 made it available to web apps added to the Home Screen. Permission on iOS/iPadOS must be requested in response to direct user interaction. Apple's older Safari Push Notifications documentation for APNS describes an earlier integration; Web Push on iOS and iPadOS now uses APNs behind the scenes.

For historical context, APNS was associated with Safari Push Notifications on Mac rather than Web Push for iOS Home Screen apps. An open thread records developers' earlier requests, before Web Push became available to iOS Home Screen web apps.

The Good News

What was a hoped-for change in 2020 has since shipped: Safari 16.1 brought Web Push to macOS Ventura, and iOS/iPadOS 16.4 brought it to Home Screen web apps. The image below reflects service-worker compatibility at the time this article was written; it is not a current Web Push support chart.

For current iOS and iPadOS setup and permission requirements, consult Apple's Web Push for Web Apps on iOS and iPadOS guidance.

For a PWA that needs notifications on Apple devices today, distinguish macOS Safari from iOS and iPadOS: on iOS and iPadOS, plan for installation to the Home Screen and request notification permission only after direct user interaction. Test that experience on the devices and browser versions your users actually use.