PWAs on iPhone: What Installing, Push Notifications and Storage Really Look Like

Almost every progressive web app conversation we have includes the same question, usually from someone who has heard that PWAs do not really work on iPhone. That was close to true a few years ago. It is not true now, but iOS is still the platform where a web app has the most caveats, and those caveats decide whether a PWA is the right tool or whether you should wrap the same code as a native app.

This is a practical summary of what our progressive web app team plans around on iPhone and iPad. Apple changes Safari regularly, so we keep it general where details move between releases, and we test on the devices your users actually carry before committing to a feature.

Installing: It Works, but Nobody Prompts

On Android, Chrome can offer an install prompt when a site meets its criteria, and your app can show its own install button. On iPhone there is no automatic prompt and no button that installs directly. The user opens the Share menu and chooses Add to Home Screen. Recent iOS versions extend this to some other browsers as well as Safari, but it is still manual and still one menu deep.

That has consequences for adoption:

• Show people how. Detect iOS and show a short, dismissible instruction with a picture of the Share icon. For a workforce app, make installing part of onboarding; two minutes in a team meeting beats any banner.
• Get the manifest and icons right. A proper web app manifest, an Apple touch icon and a sensible start address make the installed app open full screen with your name and icon, rather than looking like a bookmark.
• Expect a separate session. An installed web app on iOS keeps its own storage, separate from Safari. A user logged in on the website will usually have to log in again inside the installed app, so plan the login flow, and any magic links, around that.

Push Notifications: Available, With Conditions

Web push arrived on iPhone and iPad with iOS 16.4. It uses the same web standards as other browsers, so one server-side push setup can serve Android, desktop and iPhone. The conditions are what catch teams out:

• Installed apps only. Push works for a web app added to the home screen, not for a site open in a Safari tab. A user who never installs never gets notifications.
• Permission needs a tap. The permission request must follow a user action, such as pressing a "Turn on notifications" button. Asking on page load does not work, which is good practice everywhere anyway.
• Delivery is best effort. Notifications arrive reliably in normal use, but timing is not guaranteed, and Focus modes and notification settings apply as they do to any app. Do not build anything safety-critical on them.
• No silent background work. A native app can receive a quiet push and refresh its data in the background. A web app should expect every push to show the user something.

Installed web apps can also set a badge on their home screen icon, which is often enough for "you have three new jobs" without a notification at all.

Storage: Plan as if It Can Be Cleared

Offline web apps keep their data in the browser: the Cache API for the app itself and IndexedDB for records, photos and queued changes. Safari supports both. What it does not offer is a promise that the data stays forever. Safari has policies for removing website data that has not been used for a while, and quotas tied to device storage, and both have changed over several releases. Installed home screen apps are treated more generously than websites in a tab, but more generously is not guaranteed.

The design rules that follow are simple:

• The server holds the truth. The device keeps a working copy and a queue of unsent changes, never the only copy of anything important.
• Send early. Unsynced work should leave the device as soon as there is a connection, not at the end of the week.
• Ask for persistent storage. Where the browser supports the persistence request, ask; treat a refusal as normal, not as an error.
• Keep photos small. Resize and compress images on the device before storing them. Full-resolution phone photos fill quotas faster than anything else.
• Sync when the app opens. The Background Sync API, which lets Chrome finish uploads after the app is closed, is not available in Safari. On iPhone the queue must also flush when the app is opened or returns to the foreground, and the app should say clearly how many items are still waiting.

Our inspection app for a utility contractor's field crews runs on Android phones and iPhones, installed to the home screen, with jobs, forms and photos stored locally and uploaded through a sync queue. Compressing photos on the device and showing crews exactly which records are still waiting are what make it dependable on both platforms. The broader offline design is in our article on offline-first PWAs for field teams.

What an iPhone Web App Still Cannot Do

Some capabilities are not available to web apps on iOS, and no amount of engineering changes that. The ones we most often see on feature lists:

• Bluetooth and NFC, for example to read sensors, tags or payment terminals.
• Location tracking while the app is closed or the screen is off.
• Scheduled background tasks, such as refreshing data every hour while unused.
• Deep integration with system features such as health data, widgets or Siri.
• An App Store listing, if being found in the store is part of how you sell.

The camera, file uploads, location while the app is in use, offline storage, notifications and full-screen display all work. For forms, checklists, photos, bookings, dashboards and lookups, that covers most business needs.

When to Wrap It in Capacitor Instead

If the feature list includes something from the list above, you do not have to start again in a different technology. Ionic and Capacitor take the same web codebase and package it as a real iOS and Android app, with plugins for native push, background tasks, Bluetooth, biometrics and secure storage, and the option of a small Swift or Kotlin plugin for anything else. Your web developers keep maintaining one codebase.

The trade-off is the store. You gain a listing and native capabilities; you take on signing, store review, privacy declarations and release management. Apple also expects a wrapped app to offer genuine app functionality rather than simply loading a website, so it needs real offline behaviour and a mobile interface before submission. The route is covered in detail in getting a web app into the app stores.

A sensible pattern for many projects is to launch as a PWA, learn how people use it, and wrap it later if a native capability or a store listing becomes necessary. Because the code is shared, that step is an addition rather than a rewrite. If the product depends on native features from day one, a native iOS build or a cross-platform framework may be the better starting point.

A Quick Decision Checklist

1. Will users install it? If not, push on iPhone is off the table.
2. Does anything need Bluetooth, NFC or background location? If so, wrap or go native.
3. Is the store listing a sales channel? If so, Capacitor or native.
4. Can the server hold the truth, with the device as a working copy? If not, rethink before choosing a platform.
5. Have you tested on the oldest iPhone your users still carry? Do it before signing off the feature list.

For the general comparison between approaches, see our PWA versus native guide. Or send us your feature list and the devices your people use, and we will mark each line as PWA, Capacitor or native, with the reason.