Progressive web apps on iOS: what works and what does not

A PWA is a web app the user adds to the phone home screen without going through an app store — it opens with its own icon, full screen, and underneath it is still a website. On Android it behaves almost like a native app. On iOS it runs into a set of limits that decide whole projects, and a progressive web app on iOS is exactly where most plans quietly break. This article is about that second half: what a web app on iPhone will not do, and when that settles the decision for you.

What a PWA is and what its technical minimum looks like

A PWA is a website that meets three technical conditions: it has a service worker, a manifest file and it runs over HTTPS. That is the whole minimum — there is no separate technology and no separate programming language involved.

• A service worker is a script that sits between the app and the network. It handles the cache, which is why the app shows anything at all on a weak connection, and it receives notifications.
• A manifest file describes the name, icons, colour and display mode. It decides how the app looks once it is on the home screen and whether it opens without an address bar.
• HTTPS is a hard requirement: without an encrypted connection the service worker will not register.

Everything outside that trio — notifications, offline work, camera access — is optional and depends on the operating system the app runs on. That is the source of the confusion: this is not one feature you either “have” or “do not have”, but a set of capabilities switched on separately by each platform. Whether you need a mobile release at all is an earlier question with different criteria, and it is covered in the piece on a web app or a mobile app.

What a PWA gives you on Android

On Android a web app gets almost the full set of behaviours a user expects from a store app. It installs straight from the browser, has its own icon, opens full screen and works without a connection as far as your caching plan allows.

Push notifications work with no preconditions. Background Sync is available too — the mechanism that sends data once the connection returns. A user fills in a form in a warehouse basement, closes the app, and the data goes out when the phone finds a network.

On top of that comes something a store release cannot buy: updates are immediate. You deploy a fix to the server and the user has it on the next launch, with no review process and no waiting for anyone to update the app.

What a progressive web app does on iOS, and what it will not do

On iOS a web app works, but in a narrower range and under one hard condition: the key features only switch on once it has been added to the home screen. Apple added Web Push support for home-screen web apps in iOS 16.4, in March 2023. Notifications work only for an app installed through Safari, using the Share menu and Add to Home Screen. In an ordinary browser tab the Push API is not available.

The consequence is operational rather than technical. A user who gets a link from you and simply opens it will receive no notifications at all — and will not learn why. The three screen taps between them and a working installation are something you have to explain yourself, in the page content or in the message.

The rest of the limits are less visible and often more dangerous. A web app on iOS has narrower access to hardware than on Android, tighter offline storage limits and restricted background processing. Background Sync is among the things missing, so the “save now, send when the signal returns” scenario has to be designed differently on iOS, or dropped. Web apps on iPhone run on the WebKit engine.

Did Apple remove web apps in the European Union

It did not. On 1 March 2024 Apple withdrew its previously announced removal of home-screen web apps in the European Union. The feature stayed in iOS 17.4 and still works, still built on WebKit. The line “Apple switched off PWAs in the EU” is still repeated online and it is simply untrue.

The lesson to take from that episode is not the usual one. The point is not that the platform is unstable — it is that the feature range of a web app depends on decisions made by the operating system vendor, not on your code. If the app is meant to carry a process the company cannot afford to lose, keep a fallback ready: a backup channel for notifications, and data you can export without the app.

When a PWA is enough instead of a store app, and when it is not

A PWA is enough when the value of the product sits in data and forms rather than in phone hardware, and when users arrive from a link rather than from a store search. Four typical situations where it holds up:

• an internal tool for staff who get the link from the IT department,
• a portal for customers or trade partners logging in to their own data,
• a product you release often, where waiting for a review on every fix is a real cost,
• an app in which notifications are useful but not critical.

A PWA is not enough when push notifications are the core of the product — dispatch instructions for drivers, service alarms, on-call rotas — because a share of iOS users never add anything to the home screen and will never see them. It is also not enough when you need background work or wide sensor access, or when being present in the store is a purchasing condition on the client’s side.

If you do not yet know which features are genuinely critical, settle that first at the level of the scope of the first release — and only then check whether iOS can carry them.

Maintenance cost: one codebase or two releases

A PWA is one codebase and one deployment, while a store app is two releases and two publishing cycles — but the maintenance difference is not just a count of repositories. With one codebase a fix reaches every user at once, and you do not have to keep old versions installed on phones working. That is a real, repeating saving in every month of the product’s life.

A web app moves the cost to two other places, though. The first is performance: there is no package downloaded from a store, so every launch means loading assets from the network or from the cache, and Core Web Vitals describe the real comfort of using it here, not only a position in search. The second is support for iOS users — the add-to-home-screen instructions, the questions about missing notifications, and the explanations of why it behaves differently on a colleague’s Android.

How to settle this in a week instead of debating for six months

The PWA decision is made on a list of features, not on a comparison of technologies. Five steps you can work through in a few days:

1. List separately the features that need notifications, background work or hardware access. The rest do not matter here, because they will work everywhere.
2. Check your own analytics for how much of your traffic is on iOS. Your data, not general market statistics.
3. For every feature from step one, mark whether it works on iOS or only on Android.
4. For features that will not work on iOS, pick one of three: drop it, work around it (email or SMS instead of a notification), or go for a store release.
5. Record the decision together with its reasoning, so it does not come back at every subsequent meeting.

If that exercise says a store release is unavoidable, the next steps — technology, testing, publishing — are covered in the guide on how to build a mobile app. And if you want those findings written up in a form ready for a conversation with a supplier, describe the features your product depends on and we will come back with where the platform genuinely makes a difference.