Progressive Web Apps on iOS: How They Work, What They Can Do, and Where They Came From

Yes, Progressive Web Apps work on iPhone and iPad. Apple has supported the core PWA technologies in Safari since iOS 11.3 in March 2018, and the experience has improved a lot since then.

The biggest change came with iOS 16.4 in March 2023, when Apple added push notifications and app badges for web apps installed on the Home Screen. If you read an older guide that says PWAs on iOS can't send notifications or can only cache 50MB, that information is out of date.

A PWA on iOS is a website that a user saves to the Home Screen, where it runs in its own window without Safari's address bar. For product teams, that means one codebase can reach iOS, Android, and the desktop web without an App Store submission, without a 15 to 30 percent platform fee, and without waiting on review to ship a fix.

The trade-off is real: iOS still gives web apps less hardware access than native apps, and the install step is manual rather than promoted. This guide covers what PWAs can and can't do on iOS in 2026, how they got here, and how to decide whether one fits your product.

How PWAs work on iOS today

A PWA combines two web technologies that Safari now supports. A service worker is a script the browser runs in the background. It controls caching, serves the app when the network is slow or gone, and receives push messages. A web app manifest is a JSON file that tells iOS the app's name, icons, theme color, and how it should launch. Together they let a website behave like an installed app: its own icon, a full-screen window, and offline support.

On iOS, every web app runs on WebKit, the engine behind Safari. That is true even inside other browsers like Chrome or Firefox on iPhone, because Apple requires them to use WebKit under the hood. Once a site is on the Home Screen, it can do more than most people expect in 2026:

• Send push notifications that appear on the Lock Screen, in Notification Center, and on a paired Apple Watch, with Focus mode support.

• Show a number badge on its icon through the Badging API.

• Store significant offline data. Safari 17 raised storage limits to a large share of available disk space per origin and added the Persistent Storage API, replacing the old hard caps.

• Use Screen Wake Lock to keep the display awake, added in Safari 18.4.

The practical result is that a well-built PWA on a modern iPhone now feels close to a lightweight native app for content, commerce, and productivity use cases.

How PWAs came to be on iOS

Apple's relationship with web apps goes back to the first iPhone, but installable PWAs as we know them arrived in stages. The path was slow, and it explains why so much older advice is wrong today.

2018: a quiet start with iOS 11.3

In March 2018, Apple shipped Service Worker and Web App Manifest support in Safari 11.1 and iOS 11.3. There was no announcement aimed at developers and no install banner. You could add a site to the Home Screen and it would run offline, but features that Android already had, including push notifications and background sync, were missing.

2018 to 2022: a long plateau

For several years, iOS PWAs stayed limited. Web apps had small storage budgets, no push, no orientation lock, and Safari would clear unused site data after a period of disuse. This is the era the original version of this article described, and it is where most outdated claims come from.

March 2023: iOS 16.4 changes the calculation

iOS and iPadOS 16.4 added Web Push for Home Screen web apps, along with the Badging API. A user has to install the web app first and tap a button to grant permission, but from that point notifications behave like any other app's. This single release removed the most common reason teams skipped PWAs on iOS.

2024: the EU scare, then a reversal

Ahead of the Digital Markets Act deadline in early 2024, Apple announced it would remove Home Screen web apps for users in the European Union, citing security concerns tied to alternative browser engines. After developer backlash and a regulator inquiry, Apple reversed the decision and kept web apps, still powered by WebKit.

2025 and beyond: incremental gains

Safari 18.4 added Declarative Web Push and Screen Wake Lock, and iOS 26 made sites added to the Home Screen open as web apps by default, reducing one more point of friction.

How to install a PWA on iPhone or iPad

There is no automatic install prompt on iOS the way there is on Android. The user adds the app manually, so the website usually needs to show a short instruction. The steps are:

1. Open the website in Safari.

2. Tap the Share button (the square with an upward arrow) in the toolbar.

3. Scroll down and tap "Add to Home Screen."

4. Edit the name if needed, then tap "Add."

The app's icon then appears on the Home Screen and launches in its own full-screen window. For the install to work and feel native, the site must serve over HTTPS, register a service worker, and provide a valid manifest with the right icon sizes. Push notifications only become available after the app is installed and the user grants permission in response to a tap.

What PWAs still can't do on iOS in 2026

PWAs on iOS have closed most of the old gaps, but several limits remain. Plan around them before committing:

• No Web Bluetooth, Web USB, or Web NFC, so hardware-heavy apps are out.

• Limited background work. Reliable background sync and long-running background tasks are still weak compared to native.

• WebKit only. You cannot ship a faster or different rendering engine on iOS.

• Push requires installation. A site open in a normal Safari tab cannot send push notifications; the user must add it to the Home Screen first.

• No automatic install banner, which means lower install rates unless you guide users.

• No App Store listing by default, so you lose store search as a discovery channel.

None of these block content sites, stores, dashboards, or booking tools. They do rule out apps that depend on deep device integration or aggressive background processing.

PWA vs. native iOS app

The right choice depends on what your app needs to touch and how you want to distribute it. The table below compares the two on the factors that usually decide it.

How a PWA creates value is straightforward: you maintain one web build, ship changes the moment they're ready, and skip both the review queue and the store fee. That shortens the loop between a fix and the user seeing it, which tends to lift conversion and cut maintenance cost for content and commerce products.

For a PWA to be the right call, a few things must be true. Your features have to fit within WebKit's capabilities. If you need push, you have to design an install step and earn it. And you have to accept lower install conversion than the App Store flow, then make up for it with web reach. If you can't, a native or cross-platform build is the safer path.

Should you build a PWA for iOS?

A PWA is a strong fit when your app is content-first, transactional, or task-based, and when web reach matters more than store presence. News readers, e-commerce stores, booking and ordering flows, internal tools, and dashboards all run well as installed web apps on iPhone. Starbucks has run a widely cited PWA for ordering, and Tinder built one to reach users on lower-end and storage-constrained devices, both cases where a fast web app beat a heavy download.

A native app still wins when you depend on hardware the web can't reach, need guaranteed background processing, or rely on App Store discovery and trust to acquire users. Many teams run both: a PWA as the low-friction front door and a native app for power users. That hybrid keeps acquisition cheap on the web while reserving native effort for the features that actually require it. If you're weighing the engineering effort, it helps to scope PWA development and native mobile development against the specific capabilities your product needs rather than treating it as an either-or.