What Is a Progressive Web App (PWA)? When It Can Replace a Native App

Building separate iOS and Android apps is expensive. You pay for 2 platforms (or a cross-platform framework), app store accounts, review cycles and ongoing updates. And then you have to convince customers to download yet another app.

A progressive web app offers a different path: one web codebase that customers can install on their home screen, use offline and get notifications from, without visiting an app store. For many businesses, that’s enough. For others, the gaps, especially on iPhone, are deal-breakers. This guide explains what a PWA is, how it works, and how to decide.

What a progressive web app is

MDN defines a progressive web app as an app built with web platform technologies that provides a user experience like a platform-specific app. Like a website, it runs on many devices from a single codebase. Like a native app, it can be installed, work offline and integrate with the device.

In plain terms, a PWA is a website that:

• Can be installed to the home screen or desktop and opens in its own window, without the browser address bar.
• Works offline or on a weak connection, at least partly.
• Can send push notifications, on platforms that allow it.
• Loads fast because key files are cached on the device.
• Updates automatically whenever you publish a new version of the site. No app store review needed.

The “progressive” part means it works for everyone as a normal website, then adds app-like features on devices and browsers that support them.

How a PWA works under the hood

3 building blocks turn a website into a PWA:

1. HTTPS. PWA features require a secure connection.
2. A web app manifest. A small JSON file that tells the device the app’s name, icons, colors and how it should open (for example, full screen without browser controls).
3. A service worker. A script that runs in the background, separate from the page. It can cache files for offline use, intercept network requests and receive push messages.

The service worker is what makes the experience feel like an app. When a user opens your PWA on a train with no signal, the service worker serves the cached menu, account page or last-viewed content instead of an error screen.

Most modern web frameworks have plugins or templates that generate the manifest and service worker for you. The hard part isn’t the setup; it’s deciding what should work offline and how to sync data when the connection returns.

PWA vs native app vs website

If you’re still deciding between a site and something more interactive, our guide to web app vs website is a good first read.

The iOS limitations to know

Android and desktop Chrome and Edge have supported PWAs well for years. iPhone and iPad support has improved but still has real gaps. Here’s what matters for planning:

No automatic install prompt. On Android, Chrome can show an install banner, and your site can offer its own install button using the beforeinstallprompt event. Safari doesn’t support that event. A WebKit engineer explained in a bug thread that Safari has no install prompt at all. iPhone users have to tap Share, then Add to Home Screen, so you’ll need on-screen instructions.

Push notifications only after installing. Since iOS and iPadOS 16.4, home screen web apps can receive web push notifications, according to the WebKit team. But the app must be added to the home screen first, and the permission request must follow a direct user action, like tapping a “Turn on notifications” button. The same release added the Badging API for showing a count on the app icon.

Home screen default changed in iOS 26. Starting with iOS 26, any site added to the home screen opens as a web app by default, and users can switch this off in the Add to Home Screen dialog. That makes the install experience more consistent, but users still have to do it manually.

No background sync. The Background Sync API, which lets a PWA finish uploading data after the user closes it, isn’t supported in Safari on iOS. If your app needs reliable uploads from the field, plan to keep the app open during sync or consider native.

All iPhone browsers have historically used WebKit. Apple has required browsers on iOS to use its WebKit engine, with exceptions for alternative engines in the EU under the Digital Markets Act. In early 2024, Apple briefly planned to remove home screen web apps in the EU, then reversed course before iOS 17.4 shipped and said they would continue to be built directly on WebKit. The practical point: test on real iPhones, because Chrome on iOS doesn’t give you Android-style PWA behavior.

Apple’s App Store is a poor fit for wrapped websites. Apple’s App Review Guideline 4.2 says apps should offer more than a repackaged website. A PWA wrapped in a thin native shell risks rejection.

Key takeaway: On Android, a PWA can feel close to a native app. On iPhone, it works well for content, ordering and booking, but you’ll need to teach users to install it and accept limits on background work.

When a PWA can replace a native app

A PWA is often the smarter choice when:

• Your app is mostly forms, content and transactions. Ordering, booking, account management, loyalty, menus, catalogs, field forms.
• Customers use it occasionally. Few people will download an app for a monthly booking, but many will tap a link.
• You want one codebase and instant updates without app store review cycles.
• Search visibility matters. PWA pages can be indexed like any website.
• Budget is tight. One web team instead of iOS, Android and web.

A native or cross-platform app is still the better fit when:

• You rely on deep hardware access: Bluetooth devices, advanced camera features, sensors or NFC on iPhone.
• You need reliable background processing: location tracking, background uploads or audio.
• App store presence is part of your marketing or customer expectations.
• Performance is the product: games, AR, real-time video editing.

For those cases, compare options in native vs cross-platform app development and Flutter vs React Native.

Getting a PWA into app stores

You don’t need an app store, but you can use one on some platforms:

Store listings come with developer account fees and review rules, so weigh whether the extra visibility is worth it.

What a PWA costs compared with native

A PWA is usually cheaper than building separate native apps because there’s one codebase and no store review cycle for updates. But it isn’t free: offline data, sync logic, push notifications and testing across browsers and devices all take real development time. Prices vary widely with features and team, so compare quotes for both approaches against the same scope. Our guide to how much it costs to build an app explains the main cost drivers.

Where to start

1. List your must-have features and mark any that need background work, special hardware or an App Store listing.
2. Check support for each feature on iOS Safari, Android Chrome and desktop browsers.
3. Start with your existing website. Make it fast and mobile-friendly; a CDN helps with speed.
4. Add a manifest and service worker, and decide which pages and data should work offline.
5. Add an install guide for iPhone users with simple Share and Add to Home Screen steps.
6. Test on real devices, especially iPhones, before launch.
7. Measure usage for a few months before deciding whether native apps are worth the investment.

If you’ll need outside help, our guide on how to hire a mobile app developer covers the questions to ask, and many of them apply to PWA projects too.

Conclusion

A progressive web app gives you most of what customers want from an app, including home screen access, offline use, notifications and speed, from a single web codebase. It’s a strong default for businesses whose app is really about ordering, booking, content or account access. Just plan around iOS: no install prompt, push only after install, and limited background work. If those limits don’t touch your core features, start with a PWA and go native only when the data says you need to.

Sources

• MDN Web Docs: Progressive web apps — PWA definition, installability, manifest and service workers
• WebKit: Web Push for Web Apps on iOS and iPadOS — web push for home screen web apps from iOS 16.4
• WebKit: Badging for Home Screen Web Apps — Badging API limited to home screen web apps
• WebKit Bugzilla: beforeinstallprompt request (bug 193959) — Safari has no install prompt
• Android Developers: Trusted Web Activities — packaging a PWA in an Android app with Digital Asset Links and Bubblewrap
• Apple App Review Guidelines — Guideline 4.2 on minimum functionality and repackaged websites