PWA instead of a native app: when it saves you months and budget

When a business says “we need an app,” 7 times out of 10 the real job is one a PWA solves — a web app that installs to the home screen with an icon and runs without the browser bar. No store publishing, no long review, no two separate codebases for iOS and Android. But before picking a technology, it’s worth understanding what the word “app” actually hides.

What a PWA is, in plain terms

A PWA (Progressive Web App) is a regular website that behaves like an app: it opens full-screen, installs to the phone’s home screen, can work offline and send notifications. The user sees no difference from a “real” app, but you don’t have to pass Apple and Google review or maintain three versions of the product in parallel. The same code runs both in a desktop browser and as an icon on the phone.

When a PWA is the right call

• Content, a catalog, a user account, booking, placing an order.
• You need a fast launch — a PWA ships 1.5–2× faster than a native app.
• One budget instead of three: web, iOS and Android share a single codebase.
• Content changes often — an update ships instantly, with no waiting on store review.

How much time and money it saves

A typical MVP on a PWA takes us 4–8 weeks to launch. Native development of the same functionality means 3–6 months and two parallel teams — one writing for iOS, one for Android — with every change paid for twice. From there the economics only diverge: a PWA has one codebase, one update, one server. For validating a business idea the difference is critical: on the budget of a single native build you can launch the product, gather real users and rework it twice based on their feedback.

When you do need native

If the product lives on heavy graphics, push notifications as the core of the scenario, Bluetooth, NFC or offline maps — native is justified. Same if presence in the App Store and Google Play is itself a marketing asset. In every other case, starting with a PWA is cheaper: you validate demand first and build native against proven load.

An important caveat about iOS: on iPhones a PWA works a bit more modestly than on Android — push notifications, for instance, arrived later here and have limits. If your audience is almost entirely on iPhone and notifications are critical to the scenario, account for that at the start rather than discovering it after the fact.

Frequently asked questions

• Will a PWA get into the app stores? Google Play — yes: a PWA ships through a wrapper and users won’t notice the difference. The App Store is trickier — Apple is reluctant about web apps, so if presence there is critical, that’s an argument for native.
• Does a PWA work offline? Yes: key screens and data are cached, the app opens offline and syncs once the network is back.
• Will push notifications arrive? On Android — fully. On iPhone too, but with limits (they only arrived with iOS 16.4): if push is the core of your scenario and your audience is on iPhone, discuss it before the start.

Checklist: 5 questions before you decide

• What should the customer do from their phone — read, choose, order? All of that is a PWA.
• Do you need Bluetooth, NFC or heavy 3D graphics? If yes — native.
• Is your audience mostly on iPhone with critical push? Discuss iOS limits up front.
• Is App Store presence a marketing asset for your brand? An argument for native.
• Budget and timeline tight, demand unproven? Start with a PWA — build native against proven load.

Lifehack: frame the goal not as “I want an app” but as “I want the customer to do X from their phone.” That framing decides whether you need a store at all — or just an icon on the screen.