PWA vs native app: what to choose for your MVP

PWA vs native app is a question that shows up as soon as a web MVP gets its first users on phones. A PWA (progressive web app) is a website that can be installed on the home screen and does a few things only apps used to do: work offline, send notifications, open without a browser bar. A native app is built for a specific platform and installed from a store.

There’s a third option between them — cross-platform frameworks — and for an MVP it’s often the sensible one. Let’s go through all three.

PWA vs native app vs cross-platform, in plain words

PWA. Your existing web code plus a manifest and a service worker, a script that caches files and receives notifications. One codebase, no stores, no review; an update is a normal deploy.
React Native or Flutter. One codebase that builds real iOS and Android apps. They ship through the stores and can reach almost everything the phone offers.
Native. Swift for iOS and Kotlin for Android, two separate codebases. The most capability and polish, and roughly twice the work.

There are also wrappers like Capacitor: your site inside an app shell. That works if what’s inside behaves like an app. If it’s just your website, a store may reject it for exactly that.

When a PWA is enough

A PWA fits when your product is mostly forms, lists and content, and people reach it through a link, an email or a laptop. Admin panels, B2B tools, dashboards, services people open once a week — a PWA gives you nearly everything there, and the stores add mostly paperwork.

The MVP upside is real: you already know how to deploy a website, a fix reaches everyone in a minute, and you can charge for digital goods through a regular payment provider.

Where a PWA hits the ceiling

The limits are mostly on iPhone, and it’s better to know them up front:

web push on iOS works only for people who added the site to their home screen, which you have to explain manually;
no App Store listing — people who only look for apps there won’t find you;
background work is limited: no background location, no long uploads after the app is closed;
some hardware is unavailable or patchy — Bluetooth, NFC, certain sensors;
for many people an “installed app” is something from the store, not an icon from the browser.

When to pick React Native or Flutter

If the product lives on the phone — used daily, needs reliable notifications, camera, location, offline — a cross-platform framework is usually the best MVP choice. One team, one codebase, two stores.

If your web MVP is built in React, React Native (especially with Expo) will feel familiar: same language, similar components, some logic you can reuse. Flutter is its own world with the Dart language, but gives you a very predictable UI on both platforms. Pick what your team will actually maintain, not what won someone’s comparison post.

When you need native

Fully native development pays off when the product pushes the platform’s limits: serious camera and video work, real-time audio, widgets and deep system integrations, heavy graphics, smoothness on weak devices. Most MVPs aren’t there, and two codebases at the start mean paying twice for every hypothesis.

When to switch

A good path for many products: web and PWA first, a store app once there’s a signal. Signals look like this:

users ask where the app is and can’t find you in the store;
retention suffers because people forget to come back, and push on iOS reaches only a handful of them;
you need a feature the browser simply doesn’t offer;
competitors get a visible share of installs from store search.

Switching is cheaper if business logic lives on the server from day one, not in the client. Then a new app is a new interface to the same API, not a port of the whole product.

In short

A PWA is a website that installs to the home screen: one codebase, instant updates.
Its main limits are on iPhone: notifications, background work, hardware, no store listing.
React Native or Flutter is a sensible choice for an MVP that lives on the phone.
Go native when the product pushes the platform’s limits, not by default.
Keeping logic on the server makes any later switch cheaper.

If you’re not sure which option fits your product, SUBXCAT can help you decide before the code gets written twice.