PWAs on iOS and Safari

In one line: iOS installs PWAs only through Safari’s manual Add to Home Screen (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 is the gatekeeper. Only Safari can install a Home-Screen web app. Third-party browsers on iOS render through WebKit but historically could not create Home-Screen PWAs.
• 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 Share menu only; 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.