PWA Limitations in iOS Safari
PWA limitations in iOS Safari are something every team running iOS traffic eventually hits, and some of them can't be engineered around — only designed around. WebKit has consistently shipped PWA capabilities later and narrower than Chrome on Android, and that's a standing fact, not a temporary bug. Here's exactly what doesn't work and how to build a funnel that accounts for it.
No automatic install banner
Unlike Chrome, Safari doesn't support the beforeinstallprompt event — there's simply no one-tap install app banner on iOS. Users have to manually open the Share menu and pick Add to Home Screen, and if the creative or pre-lander doesn't spell that step out, iOS install rates drop because of the interface, not the offer. A step-by-step instruction inside the pre-lander helps here — a wheel-of-fortune or quiz screen (APEX pre-landers) can double as a game element and a reason to hold the user's attention through that exact step.
Push only works on iOS 16.4+, and only after install
Web push on iOS has been available since iOS 16.4, and only for a PWA already added to the home screen — a regular open Safari tab never gets push at all. In practice that means part of your audience on older iOS versions will never see a push notification, so planning for 100% push coverage on iOS traffic isn't realistic. Segmenting your base by install status and OS version (APEX's push engine handles this) means you're not wasting sends on people who physically can't receive them.
Storage and data aren't guaranteed to persist
Safari applies its own storage-limiting policy to web content, and a rarely-opened PWA's local data can get cleared if the user hasn't opened it in a while. That's different from a native app, where data survives until the user deletes the app manually. Flows that depend heavily on persistent local state — a long session, a cache that skips re-login — need to be designed on iOS assuming that state might reset.
Some APIs are missing or behave differently
Features that feel standard on native apps or Android Chrome — app icon badges, background sync, certain camera and microphone APIs — are either unavailable on iOS Safari or work with caveats that shift between versions. Building a funnel that hard-depends on the same API behaving identically on iOS and Android is risky — on iOS, part of that functionality may simply not fire. Treat graceful degradation on iOS as the default, not the exception.
Designing a funnel around all of this
Split creative and pre-lander guidance for iOS and Android at least at the install-instruction level — show the explicit Share, then Add to Home Screen step on iOS, and rely on the system banner on Android. Test the two paths separately with a sticky-per-visitor split test rather than looking at one blended number, or a weak iOS flow just gets buried by a strong Android one. For iOS audiences, treat push as a bonus channel rather than the main retention lever, and design the first session to hold attention on its own, push or not.
FAQ
- Do push notifications work in a PWA on iPhone?
- Yes, but only from iOS 16.4 onward and only for a PWA already added to the home screen — a regular Safari tab never gets push.
- Why doesn't iPhone show an install app banner?
- WebKit doesn't implement the beforeinstallprompt event, so install only happens manually through the Share menu and Add to Home Screen, and that step needs to be spelled out for users.
- Can Safari delete a PWA's data on its own?
- Yes, after a long stretch without visits Safari can clear a rarely-used PWA's local storage, so flows shouldn't hard-depend on persistent local state.
- Do you need a separate funnel for iOS?
- Yes, at minimum separate install instructions and realistic push expectations — test iOS and Android separately with a split test rather than reading one blended number.
Cloaking, anti-bot, push, split tests and your own domains — in one service.
Get started free