PWA vs native app: an honest decision tree

“We need an app” is one of the most expensive sentences a business can say without examining it, because it usually means a native iOS and Android app: two codebases, two app stores, two review queues, and ongoing maintenance on both. A progressive web app would often have done the job for a fraction of the cost and effort. Sometimes native is genuinely the right call. Often it isn’t. Here’s how to tell.

First, what’s a PWA?

A progressive web app is a website built to behave like an app. Users can install it to their home screen straight from the browser, no app store, and it can work offline, send notifications, and feel like a native app rather than a webpage. One codebase, served over the web, installable everywhere.

A native app is software written specifically for iOS and/or Android, distributed through the app stores, with full access to the device’s capabilities. More powerful, more polished where it counts, and considerably more expensive to build and maintain.

When native is genuinely the right call

Native earns its cost when you need things only native can do well:

• Deep device integration, heavy camera use, Bluetooth, background location, processing-intensive features, tight hardware access.
• Peak performance and polish, games, complex animations, anything where the experience has to be flawless and fast in ways the web can’t quite match.
• App store presence as a channel, if meaningful numbers of your users will discover you by searching the App Store, being there matters.
• Platform features, rich notifications, widgets, deep OS integrations that genuinely drive your experience.

If your product lives or dies on any of these, build native and don’t apologize for the cost.

When a PWA is the smarter choice

A PWA is often the better answer when:

• Your audience is focused, not massive. Two native codebases for a specialized community is overhead wildly out of proportion to the audience. One PWA reaches everyone.
• The experience is mostly content and standard interaction, browsing, reading, forms, dashboards, rather than hardware-intensive features.
• You want to ship fixes instantly. A PWA updates the moment you deploy. Native updates wait on app-store review and on users choosing to update, which fragments your audience across versions.
• Budget and speed matter. One codebase costs far less to build and maintain than two, and ships faster.
• You don’t want the app-store tax or gatekeeping, the cut, the review delays, the risk of rejection.

For a great many businesses, especially smaller ones with focused audiences, a PWA delivers most of the value of native at a fraction of the cost. That’s not a compromise; it’s the right-sized tool.

The decision tree

Walk it in order:

1. Do you need deep hardware access or peak native performance? Yes → native. No → keep going.
2. Is App Store discovery a real acquisition channel for you? Yes → native (or both). No → keep going.
3. Is your audience large and broad enough to justify two codebases? No → PWA looks strong. Yes → keep going.
4. Do you value instant updates, lower cost, and one codebase? Yes → PWA.

Most businesses that think they need native discover, walking this honestly, that a PWA does what they need.

The most senior decision is sometimes not building the heavy thing

There’s a quiet bias in this industry toward the bigger, more impressive build, because bigger builds are bigger invoices. The genuinely senior move is often the opposite: recognizing that the focused, cheaper option does the job, and saying so. We built exactly this case for a specialized community in our Don Vitola case study, a PWA, deliberately, because native would have been cost out of proportion to the audience.

We build both native and PWAs, which means we have no incentive to push you toward one, we’d rather build the right thing than the expensive thing. If you’re weighing “do we need an app, and what kind,” let’s think it through.