Build a responsive website when people arrive from search or links and use it now and then. Make it a progressive web app (PWA) when the same people come back often and want it on their home screen, some offline use or notifications, but don't need deep device features. Build a native or cross-platform app when the product depends on fast barcode scanning, Bluetooth, background location, reliable offline work, or being found in the App Store and Google Play. Most businesses should start with the first and add the others only when there is a clear reason.
What each option actually is
A responsive website is one site that changes its layout to fit phones, tablets and desktops. It opens in the browser, needs nothing installed, and search engines can index it.
A progressive web app is a responsive website with two extra pieces: a web app manifest (name, icons, start URL, display mode) that lets people install it, and usually a service worker, a script that can cache files and data so the app opens quickly and works with a poor connection. Installed, it opens in its own window without the browser bar. It is still a website: one codebase, deployed on your server, updated the moment you release.
A native app is built for iOS and Android, either with each platform's own tools (Swift, Kotlin) or with a cross-platform framework such as Flutter or React Native, and distributed through the App Store and Google Play. It gets full access to the device and the operating system, and it goes through store review for every release.
How they compare on the things that decide it
| Responsive website | PWA | Native or cross-platform app | |
|---|---|---|---|
| How people find it | Search, links, ads | Search and links, then install from the browser | App stores, or a link to the store listing |
| Install step | None | Optional, from the browser | Required, through a store |
| Offline | No | Yes, as far as the service worker is built for it | Yes, with a local database and sync |
| Push notifications | No | Yes on Android and desktop; on iPhone only once added to the Home Screen | Yes |
| Device access | Basic (camera upload, location) | Whatever the browser allows, which differs by browser | Full, including background tasks and Bluetooth |
| Releasing an update | Deploy | Deploy | Store review, then users update |
| Codebases | One | One | One per platform, or one shared with a cross-platform framework |
What a PWA can and cannot do today
PWAs are much more capable than they were a few years ago, but the details depend on the browser, and that is where plans go wrong.
- Installing. Chrome, Edge and Samsung Internet install a PWA when it has a manifest with a name, icons, a start URL and a display mode, served over HTTPS. On Android, Chrome turns it into something close to a real app. On iPhone and iPad, users install through the Share menu with "Add to Home Screen"; since iOS 16.4 other browsers on iOS can do this too. There is no automatic install prompt on iOS, so you have to explain the step to users yourself.
- Notifications. Apple added Web Push in iOS and iPadOS 16.4, but only for web apps added to the Home Screen, and only after the user taps something that asks for permission. A PWA that depends on notifications on iPhone must first persuade people to install it.
- Offline. A service worker can cache the app and recent data, and queue actions to send when the connection returns. That is good enough for reading a price list or filling a form in a weak signal area. It is not the same as a mobile app with a local database built to work for days offline and sync properly afterwards.
- Device features. Camera and location are fine. Bluetooth, NFC, background location and similar features have partial support at best, and less on iOS than Android.
When each is the right choice
Responsive website
Marketing sites, content, e-commerce for occasional buyers, booking forms, dashboards people check from their desk. If most visits start from Google or a link in a WhatsApp message, asking people to install anything loses them. Make it fast and usable on a phone and stop there.
PWA
Tools people return to every week: a B2B reorder portal, an internal approvals app, a dealer catalogue, a staff rota. You get a home screen icon, faster repeat loads, some offline use and notifications on Android, with no store accounts or review delays. It is also the cheapest way to test whether people will use an "app" before paying for native ones.
Native or cross-platform app
Field service and delivery apps that must work all day without signal, apps that scan barcodes at speed or talk to Bluetooth printers and scales, consumer products whose customers look for them in the app stores, and anything that needs reliable notifications on iPhone without an install explanation. Our guide to choosing a mobile framework covers the choice between Flutter, React Native and fully native, and when web technology is enough covers the middle ground of wrapping a web app for the stores.
How we decide with a client
- Who uses it, and how often? Occasional visitors mean website. Daily users mean PWA or app.
- List the device features. Write down every hardware or OS feature the product needs and check each one on iOS Safari and Android Chrome. One must-have that the web can't reach decides it.
- Define offline honestly. "Opens without signal and shows recent data" is a PWA. "Works for a whole shift in a basement warehouse and syncs later" is an app.
- Decide whether store presence matters. For consumer products it often does. For internal and B2B tools it rarely does.
- Plan the path. Build the responsive web app with an API behind it, so a PWA is a small step and a mobile app can reuse the same backend later.
The expensive mistake is not choosing the wrong one. It is building the app first and then discovering the audience wanted a link.
Our default
For business tools, especially ones connected to Odoo, we build a responsive web app on a clean API, add PWA features when people use it daily, and build a mobile app when a device or offline requirement demands it. That order keeps the backend work shared and avoids paying for native builds too early. If you are weighing this up for a specific product, see our web application work, our mobile work, or get in touch.
Questions we get asked
Is a PWA as good as a native app?
For many business tools, yes: a PWA can be installed, opens in its own window, loads quickly, works partly offline and sends notifications on Android and desktop. It falls short when you need Bluetooth, background location, long periods offline, reliable iPhone notifications without an install step, or a listing in the app stores. For those, a native or cross-platform app is the better choice.
Do PWAs work on iPhone?
Yes, with limits. Users install a PWA on iPhone through the Share menu and "Add to Home Screen", since iOS has no automatic install prompt. Web Push notifications work from iOS 16.4, but only for web apps added to the Home Screen and only after the user grants permission. Support for hardware features such as Bluetooth is weaker on iOS than on Android.
Can a PWA be published on Google Play or the App Store?
A PWA can be packaged for Google Play as a Trusted Web Activity, which opens your web app in a full-screen Chrome view. For the App Store, Apple's review guidelines expect an app to go beyond a repackaged website, so teams usually use a wrapper such as Capacitor and add real native features. If store presence is essential, plan for a proper app build.
Should a small business build an app or a responsive website first?
Start with a responsive website or web app in almost every case. It reaches everyone through search and links, needs no store accounts or review, and one codebase serves every device. Build it on an API so a PWA is a small next step, and a mobile app can later reuse the same backend once you know people will use it often enough.