PWA or a native app? A working decision framework

A founder asked us last month: "Do we actually need a real app, or can we just make our site a PWA?"

Our answer is usually the boring one. For most businesses, at most stages, a progressive web app ships in a fraction of the time, costs a fraction of the money, and covers ninety percent of what a native app would have done. Native — built properly with React Native — earns its keep when specific things matter. Outside those specific things, an app store presence is a marketing preference dressed up as a technical requirement.

Here's the framework we walk clients through before we quote.

What we mean by "PWA" and "native"

Terms first, because half the confusion in this decision comes from imprecise language.

Progressive web app (PWA). Your website, built well, with the handful of extra capabilities modern browsers give you: installable to the home screen, works offline for the pages you cache, sends push notifications on Android and (with real caveats) on iOS, and opens without an address bar so it feels like an app.

Native app. A binary that lives in the App Store and Play Store, downloaded and installed. We build these almost exclusively with React Native on Expo — one codebase, both stores, real native performance for the shapes of app most businesses need. Actual Swift

• Kotlin is a separate conversation that only about one in ten of our clients need to have.

Framing PWA vs native as "web vs mobile" is misleading. Both are mobile. The real question is whether being in the stores, with the full native capability set, is worth the cost of getting there.

The comparison at a glance

	PWA	Native app (React Native on Expo)
Time to launch	4–8 weeks (if you already have a site)	10–16 weeks
Cost to build	1x	3–5x
App-store presence	None	Yes (both)
Discoverable via Google	Yes — same as your website	No (store SEO only)
Push notifications	Android yes, iOS partial	Yes, both platforms
Offline	Cached pages	First-class
Native hardware (camera, BLE, biometrics)	Limited via web APIs	First-class
Update cadence	Deploy anytime	App Store review each release (OTA for JS-only)
User perception	"A website that saves to my phone"	"A real app"
Failure mode	iOS Safari edge cases and no store credibility	Cost of getting downloads no one asked for

The pattern is consistent: PWA wins on speed to market, cost, and discoverability. Native wins on capability, credibility, and re- engagement. The rest is detail.

The four criteria that actually matter

Every business we've quoted mobile work for asks about the same four things. In our experience, these are the criteria that predict the right answer.

1. Do you need to be in the App Store? For B2B tools, most SaaS products, most content sites, most ecommerce, the honest answer is no. Nobody discovers a B2B dashboard by searching the App Store. But for consumer apps, marketplaces, and products where the App Store is where your users actually look — fitness, dating, finance, travel, delivery — being outside the stores is a real discovery tax. If your customers expect to find you in the App Store, they expect it because that is where they search.

2. Do you need push notifications, offline, or native hardware? This is the honest capability test. If your product depends on push re-engagement on iPhones (retention, transactional alerts), or has to work offline in the field (logistics, healthcare, warehouse), or needs BLE, biometrics, HealthKit, ARKit, or serious camera work — native has already made the decision for you. PWA hits real walls here, especially on iOS. Everything else — the camera scan, the share sheet, the fingerprint login — is a nice-to-have that PWAs mostly cover in 2026.

3. Is discovery search-driven or app-store-driven? A PWA is part of your website. It benefits from every backlink, every SEO investment, every piece of content you ship. Users search "how to do X", land on you, and install with one tap. A native app benefits from none of that. It benefits from App Store Optimization, paid UA, and word of mouth. Both are legitimate distribution strategies. They cost different amounts of money.

4. What is the true cost of ownership over 24 months? Not the build cost — the total. Native apps have App Store review cycles, two versions of everything to test, paid developer accounts, crash monitoring, and eventually a marketing budget to drive downloads nobody asked for. PWAs have one codebase, one deploy pipeline, and inherit whatever web ops discipline you already have. Over two years the delta is usually 3–5x, not the 1.5x people assume from build cost alone.

The two questions that decide it for most clients

Once we've named the four criteria, the decision is usually made by two of them. The rest is noise.

Question 1: Where do your users actually look? If the honest answer is "they Google their problem," a PWA is your first move. If the honest answer is "they open the App Store expecting us to be there," native is table stakes.

Question 2: Is there a capability the web can't cheaply reach? Real background push on iPhones. Serious offline. Bluetooth peripherals. HealthKit integration. If yes, native has already made the decision. If no, the PWA covers you.

Two yeses to search-driven + no native capability required → PWA. A yes to your users expect an App Store presence, or you need a capability the web can't reach → native. Everyone else sits in the middle, and we default to PWA and iterate to native only when the data says so.

The failure modes on both sides

Every failing mobile decision we've been asked to rescue falls into one of these.

1. Over-building a native app that could've been a PWA. The budget went to app-store presence for a product that gets all its traffic from Google. Six months later, the store install numbers are disappointing, and the marketing team is asking for a "regular" website as well. Fix: ship the PWA first. Add native later against a real growth thesis, not a hunch.

2. Under-building a PWA that then hits an iOS Safari wall. The brief assumed background sync, tight push, or reliable offline. iOS Safari didn't cooperate. The fix mid-project is usually painful. Fix: name the three capabilities you're relying on in Discover, and have someone confirm they work on iOS Safari's current build before scoping.

3. Shipping both without a strategy. A PWA and a native app, neither optimised, both under-invested, competing for the same users. Two things done at half the quality of one. Fix: commit. PWA for the next twelve months, native later — or the reverse — but one at a time.

The scoping shape

For most mobile projects we ship, the shape is:

• Weeks 1–2: Discover + a working prototype of the two hardest screens (usually the primary flow and the notification / offline behavior). This settles the PWA-vs-native question with data, not opinion.
• Weeks 3–8: Build against the locked scope, on whichever stack the prototype validated.
• Weeks 9+: Launch, monitor, and iterate against a stated goal.

If you want the long version of that shape, see the five phases we run every project through.

The answer

PWA unless there's a specific reason we can point to. React Native when the App Store presence, the push behavior, the offline requirement, or the hardware integration makes the decision. Actual native (Swift + Kotlin) only for games, deep hardware, or sub-16ms interactions — a much smaller set than most teams assume.

If you're weighing this call for your own product, we're happy to walk through it. See how we scope mobile apps and web builds, or send us a short brief. We reply within one business day.