PWA or native app? How to choose before you spend a thing

1. Three routes, one home-screen icon

For the end user the difference is often invisible: an icon, a full screen with no address bar, notifications. Underneath, though, these are three different technologies.

• —Native app: Written separately for Android (Kotlin) and iOS (Swift). The smoothest experience and full hardware access — but two separate projects to build and maintain.
• —Hybrid app: One codebase (React, Capacitor) wrapped in a native container and published to both stores. You keep the camera, push notifications and file access; the cost drops roughly by half.
• —PWA: A web app the user “installs” straight from the browser — no store, no review, no developer account. It works offline and sends notifications, but reaches the phone's hardware only in part.

2. When a PWA is enough (and it often is)

A PWA works wherever the app is essentially a tool for an account, a booking, an order or content. A customer panel, an appointment system, an order catalogue, an internal tool for the team — none of that needs a store.

The argument that usually decides it is not technical but about distribution: a PWA opens from a link. There is no “download the app” step where most users drop off, and no waiting for App Store approval when you need to fix a typo in your prices.

3. When you genuinely need native

There are cases where the browser simply is not enough and fighting it makes no sense:

• —the app mostly runs in the background (route tracking, long measurements, syncing with the screen off),
• —you use Bluetooth, NFC, advanced camera work or motion sensors,
• —you need 3D graphics or animation holding a steady 60 fps under load,
• —selling digital content has to go through in-store payments,
• —being on the App Store and Google Play is part of what customers expect — because that is where they look for you.

That last point is often the strongest and it is not technical at all. If your customers ask “is it in the store?”, then being in the store carries marketing value regardless of what sits underneath.

4. Cost, time and what only shows up after a year

The biggest budget difference is not in the first release but in maintenance. Two separate native codebases mean every feature change is built and tested twice, for the whole life of the product.

Then come the fixed costs that are easy to forget at quoting time: an Apple developer account is an annual fee, a Google Play account a one-off, and every release goes through a review that can send the app back with notes.

That is why in the projects I build the middle option usually wins: one codebase serving the website, the PWA and the store-packaged version. Meety works exactly like that — an appointment booking app built on React and Capacitor, where the same logic drives the browser and the phone.

5. A simple way to decide

Ask yourself three questions. Does the app have to work while the screen is off? Does it reach hardware the browser does not expose? Is being in the store part of the promise you make to customers?

Three noes means a PWA — fastest, cheapest, with instant updates. One yes means hybrid. Two or three means it is time to talk about native.

Not sure where your idea sits on that list? Describe briefly what the app should do and I'll send a free quote with a technology recommendation within 48 hours.