- A PWA is enough for content, forms, ordering, booking and dashboards when you do not need deep device features or app store discovery.
- On iPhone, PWAs install manually from the Share menu, and push notifications work only after the app is added to the Home Screen (iOS 16.4 and later).
- Choose a native or cross-platform app for background tasks, Bluetooth and other hardware, heavy offline sync, or App Store presence.
- Build the back end as a clean API so you can start with a PWA and add store apps later without rebuilding.
When is a progressive web app enough instead of a native app?
A progressive web app is enough when your users mainly need forms, content, ordering, booking or dashboards, when notifications that require adding the app to the iPhone Home Screen are acceptable, and when you do not need app store discovery or deep device features. Choose a native or cross-platform app when the product depends on background tasks, Bluetooth and other hardware, heavy offline data, or being found in the App Store and Google Play. Many products start as a PWA and add store apps once users ask for them.
Below is how we help clients make that call when they come to us for a mobile app.
What is a progressive web app?
A progressive web app (PWA) is a website built so it can behave like an installed app. Three pieces make that possible:
- A web app manifest with the app's name, icons and how it should open, so browsers can offer to install it.
- A service worker, a script that can cache pages and data and serve them when the network is slow or missing. MDN's guide shows the common cache-first pattern: if a resource is in the cache, return it from there; otherwise fetch it and store it for next time (MDN: offline and background operation).
- HTTPS and a responsive, app-like interface, so it feels at home on a phone.
The same code serves every device through one URL, and an update is live for everyone the moment you deploy it.
What can a PWA do on an iPhone today?
More than it could a few years ago, with a few important limits:
- Installation is manual. On iOS and iPadOS there is no browser prompt to install a PWA. People add it from the Share menu and confirm the name (web.dev: PWA installation). You need to show them how.
- Push notifications work, from the Home Screen. Since iOS and iPadOS 16.4, a web app that has been added to the Home Screen can ask for permission to send push notifications, and the request must follow a user action such as tapping a subscribe button (WebKit: Web Push for web apps on iOS and iPadOS). A visitor who only uses the site in Safari cannot receive them.
- Display is standalone. Installed web apps open without the browser bar, which is what most products want.
If your users are on iPhones and your engagement depends on notifications, plan the "add to Home Screen" step into onboarding, or accept that a native app will reach more of them.
What can a PWA do on Android?
Android is friendlier to web apps. Chrome can offer an install prompt, and a PWA can also be published on Google Play by wrapping it in a Trusted Web Activity, an Android app that opens your web app full screen. Google's Bubblewrap tool generates that Android project from your PWA, and the site and app are linked through Digital Asset Links so they are verified as coming from the same developer (Chrome for Developers: Trusted Web Activity). You still go through Play Console, store listing and review like any app.
When do you need a native or cross-platform app?
Choose a store app when one or more of these is central to the product:
- Background work, such as location tracking, timers or uploads that must continue when the app is closed.
- Hardware, such as Bluetooth printers and scanners, NFC, advanced camera features or health and fitness sensors, which browsers support unevenly.
- Heavy offline use with two-way sync and conflict handling, for example field service or a POS that must keep selling with no signal.
- App Store presence. Apple's guideline 4.2 says an app should include features, content and UI that elevate it beyond a repackaged website (App Review Guidelines), so a simple web wrapper is unlikely to be accepted on iOS.
- Deep platform features such as widgets, voice assistants and other OS integrations.
A cross-platform framework gives you both stores from one codebase. Our comparison of React Native and Flutter explains how to choose between the two main options.
How do PWAs and native apps compare?
| Progressive web app | Native or cross-platform app | |
|---|---|---|
| Distribution | A link, search results and QR codes | App Store and Google Play |
| Install | Optional; manual on iPhone | Through the store |
| Updates | Live as soon as you deploy | Through store review and user updates |
| Offline | Cached pages and data via a service worker | Full local storage and background sync |
| Notifications | Yes; on iPhone only after adding to Home Screen | Yes |
| Device access | Camera, location and more, unevenly across browsers | Full access through native APIs |
| Search visibility | Pages can be indexed and ranked | Store search; screens are not web pages |
Is a PWA cheaper to build and run?
Usually, for the same features, because one codebase serves desktop and mobile and there is no store release process for every update. You also avoid the store developer accounts and their review cycles; our App Store and Google Play release checklist shows what that process involves.
The savings shrink when you fight the platform. If you spend weeks working around missing device features or iPhone install friction, a cross-platform app may have been the cheaper route. Decide by the features your users need, not by the build cost alone.
Can you start with a PWA and add native apps later?
Yes, and it is a common path for new products. Build the back end as a clean API from the start, so a later mobile app uses the same accounts, data and business rules. If the web app is built in React or Next.js, a React Native app can share types, API clients and validation logic with it. Launch the PWA, watch how people use it, and build store apps when the data shows that notifications, offline use or store discovery would make a real difference.
How do you decide for your product?
- List the device features your core flow needs, and check each one in the browsers your users run.
- Decide how important notifications are, and whether iPhone users will add the app to their Home Screen.
- Ask how people will find the product: search and links favour a PWA, store browsing favours native apps.
- Estimate how often you will ship updates; weekly changes are easier on the web.
- Consider offline needs honestly: cached reading is easy, full offline editing is not.
If most answers point to the web, start with a PWA and keep the door open. If the product lives or dies on hardware, background work or store presence, plan a store app from the start. For a first version, our SaaS and MVP development service can scope either route with a fixed quote.
Frequently asked questions
Will a PWA show up in Google search?
Yes. A PWA is made of web pages, so its public pages can be crawled, indexed and ranked like any website, with their own titles, descriptions and structured data. Screens inside a native app are not web pages and are found through the app stores instead.
Can I put a PWA in the Apple App Store?
Not as a simple wrapper. Apple's guideline 4.2 says an app should go beyond a repackaged website, so a shell that only loads your site is likely to be rejected. If App Store presence matters, plan a native or cross-platform app with genuine app features.
Do PWAs work offline?
Yes, to the extent you design for it. A service worker can cache pages, assets and recent data so the app opens and shows content without a connection. Saving new data offline and syncing it later is possible but harder to build well, which is where native apps still have an edge.
Do I need separate designs for the PWA and a later app?
Not necessarily. A design system built in Figma can serve both, with components adapted to each platform's conventions where they differ. Reusing the same components keeps the brand consistent and makes the later native app faster to design.
Last updated