Choose an installable web app (PWA) when you need to reach people who already know you, quickly, with one build for iPhone, Android and desktop, and without going through the app stores or paying their commission. Choose a native or cross-platform app when you need to be in the App Store and Google Play, need push notifications that work reliably on every phone, or need device features the browser doesn't offer, such as Bluetooth, NFC or background tasks. For many businesses, a PWA is the right first step: it costs less, ships sooner and shows whether customers actually use an app. If they do, the native app can follow, built on the same foundations.
What a PWA is
A PWA is a website built to behave like an app. People open it in the browser and can install it on their home screen, next to their other apps. From then on it opens full screen, without an address bar, and keeps what it needs to carry on working offline. web.dev's guide to PWAs covers the technical pieces: a manifest with the name and icon, and a service worker that handles offline mode.
In practice, a PWA gives you:
- installation from the browser, no store involved; Android offers to install it, while on iPhone it's done from the Share menu;
- offline mode, for viewing data already loaded or filling in forms that send once the connection is back;
- push notifications on Android and desktop and, since iOS 16.4, on iPhone and iPad once the app has been added to the home screen, as Apple's documentation on web push explains;
- instant updates: we publish a new version and every user gets it on their next visit, with no store review;
- one build for every device, because it's the same web app.
What a native or cross-platform app is
A native app is written separately for each platform, in Swift for iOS and Kotlin for Android. A cross-platform app uses a framework such as Flutter, React Native or .NET MAUI to produce both versions from one codebase, with results very close to native. Either way, people install it from the App Store or Google Play.
What an app in the stores gives you that a PWA doesn't, or only partly does:
- a store listing, where many people look for apps and where the listing itself builds trust;
- push notifications that work on every phone with no extra steps, with more options for format and scheduling;
- device features such as Bluetooth, NFC, sensors, home-screen widgets and background tasks, which the browser restricts heavily on iPhone;
- system integration, such as in-app payments, sharing between apps, or opening straight from links;
- performance in demanding interfaces with heavy animation, maps or live camera use.
Where a PWA falls short
PWAs have real limits, especially on iPhone, and it's better to know them before you choose.
Discovery. A PWA doesn't appear in the App Store. People reach it through your website, a link or a QR code. For an audience that already knows you, that's fine. If you need strangers to find you while browsing the stores, it isn't.
Installing on iPhone. iPhone doesn't prompt people to install. They have to open the Share menu and choose "Add to Home Screen". A good PWA explains this step at the right moment, but some people won't take it. And on iPhone, no installation means no notifications either.
Device features. On Android, the browser exposes a lot. On iPhone the list is shorter: no Bluetooth or NFC on the web, and limited background work. If your app depends on these, a PWA won't do.
Stored data. Browsers can clear data stored by sites that haven't been used for a while, especially when they aren't installed. A well-built PWA keeps what matters on the server and treats local storage as a copy.
Where a native app costs more
Apps in the stores have costs of their own, and they're worth facing squarely.
Development. Even with a cross-platform framework, each platform needs specific work: screens that behave differently, permissions, testing on a range of devices. A PWA reuses more of the work already done on a website or web platform.
Stores and reviews. Publishing requires developer accounts with Apple and Google, each with its own fee, and every release is reviewed before it reaches users. Apple's App Store Review Guidelines also reject apps that are just a website in a frame: the app has to offer something of its own.
Commission. When an app sells digital content or subscriptions used inside it, the stores take a commission on those sales, under section 3.1 of the App Store Review Guidelines and Google Play's Payments policy. Selling physical goods, or services delivered outside the app such as an order or an appointment, follows different rules and can use your usual payment methods.
Maintenance. Apple and Google release new operating system versions every year, and apps have to keep up. A PWA needs maintenance too, but it's less tied to that calendar.
How to decide
We look at three things: your audience, the features and the budget.
Audience. Do your users already know you and arrive through your website, by e-mail or from a QR code in your shop? A PWA reaches them without friction. Do you need to be found by people browsing the stores? Then you need a store app. For internal tools, used by a team that can be shown how to install them, a PWA is usually enough.
Features. List what the app must do on day one. Browsing, booking, ordering, paying and getting reminders all fit comfortably in a PWA. Reading NFC tags, connecting to devices over Bluetooth, tracking location in the background or showing home-screen widgets call for a native app.
Budget. Without getting into figures, the general rule is this: a PWA is the more affordable first step, because it's one build and reuses your web foundations. A store app takes more work up front and more maintenance over time. Every project is quoted individually, based on the features the app needs.
Often the answer isn't one or the other, but one after the other. Start with a PWA, measure who installs it and what they use, and only then decide whether a store app is worth it. The server, the API and the data stay the same, so nothing already built goes to waste. It's the same thinking as an MVP for startups: validate first, invest after.
An example
Think of an appointments business, such as a gym or a clinic. The customers already exist, arrive through the website and come back every week. They need to see the timetable, book, cancel, pay and get a reminder the day before. All of that fits in a PWA, with notifications for those who install it and e-mail for those who don't.
If the same business later wants members to unlock the door with their phone over NFC, or to read data from a fitness watch over Bluetooth, that's when a native app starts to make sense. And it can be built on the same booking and scheduling system the PWA already uses.
Checklist
- Who are your users, and how do they reach you today?
- Do you need to be found in the app stores?
- Which features are essential on day one?
- Do any of them need Bluetooth, NFC, background tasks or widgets?
- Are notifications essential for iPhone users who won't install the app?
- Will the app sell digital content used inside it?
- Who will maintain the app over the years?
- Could you start with a PWA and decide later, with real data?
Where to start
If your answers point to reaching existing customers quickly, see our installable web app (PWA) service. If you need to be in the stores or use device features, see mobile apps for iOS and Android. If you're still unsure, ask us for a quote with your feature list: we'll help you choose before anything is built.