PWAs on iOS and Safari

In one line: on iOS/iPadOS 16.4+ PWAs install through manual Add to Home Screen in Safari and supporting third-party browsers (there is no beforeinstallprompt and no install banner). Once added, the app runs in standalone mode with its own service worker, and — for Home-Screen apps — Web Push and badging. Design for the WebKit feature set, ship explicit install instructions, and test on a real device.

How installation works

• Add to Home Screen only. Installation happens through Safari’s Share menu → Add to Home Screen. There is no programmatic install: beforeinstallprompt does not fire on iOS, so you cannot trigger or defer a native prompt.
• Safari and supporting third-party browsers. Since iOS/iPadOS 16.4, Safari and third-party browsers that adopt the WebKit Add to Home Screen support can both create Home-Screen web apps. Earlier versions restricted installation to Safari only.
• No install UI from the browser. There is no omnibox install button or banner, so users who don’t know the flow will never discover it on their own.

What works once installed

• Standalone display. With display: standalone (or fullscreen) the app opens chromeless — no address bar — using your manifest name, icons, and theme color.
• Service workers. Service workers run for caching, offline support, and background fetch handling, subject to WebKit’s lifecycle and storage rules.
• Web Push. Web Push and the Notifications API work only for apps added to the Home Screen — not for the same site open in a Safari tab. Permission must be requested from a user gesture inside the installed app.
• Badging. The App Badging API can set a count on the Home-Screen icon for installed apps that have notification permission.

Constraints to design around

• Storage eviction. Browser-managed storage (Cache Storage, IndexedDB) can be evicted after an extended period without use. Treat the cache as disposable and re-fetch or re-sync critical data on launch; never assume local data survives indefinitely.
• No install prompt or banner. Because the browser shows nothing, discovery depends entirely on your own UI.
• Limited hardware/API surface. Some capabilities common on Chromium (Bluetooth, USB, NFC, ambient sensors, persistent background sync) are unavailable or restricted under WebKit. Feature-detect and degrade gracefully.
• Per-app isolation. Each Home-Screen instance gets its own storage and session, so state and logins are not shared with the Safari tab the user installed from.

Capability matrix

Feature	iOS / WebKit support	Notes
Add to Home Screen	Yes (manual)	Safari and supporting third-party browsers (iOS 16.4+) via Share menu; no programmatic install.
beforeinstallprompt	No	Event never fires; no custom install prompt.
Install banner / omnibox button	No	Provide your own install instructions.
Standalone display mode	Yes	display: standalone / fullscreen; chromeless window.
Service workers	Yes	Caching and offline; subject to WebKit lifecycle.
Web Push & Notifications	Yes (Home-Screen apps only)	Not in Safari tabs; request from a user gesture.
App Badging	Yes (installed apps)	Requires notification permission.
Persistent storage guarantee	No	Cache/IndexedDB may be evicted after non-use.
Web Bluetooth / USB / NFC	No	Unavailable under WebKit; feature-detect.

Practical guidance

• Provide manual install instructions. Detect iOS Safari and show a short, illustrated “tap Share, then Add to Home Screen” hint — the platform will not prompt for you.
• Design for the WebKit feature set. Feature-detect every capability, supply fallbacks for unsupported APIs, and avoid hard dependencies on hardware APIs WebKit lacks.
• Gate push behind installation. Only request notification permission inside the installed Home-Screen app, triggered by a user gesture.
• Assume storage can vanish. Re-validate and re-sync important data on launch; keep the source of truth on your server.
• Test on a real device. Standalone behavior, push, badging, and storage eviction differ from desktop simulators — verify on actual iOS hardware.