"Just build a PWA" has become the default advice for almost any new app idea, and often it is right. But it is also repeated by people who have not had to explain to a client why their app cannot scan a loyalty card at checkout, or why it keeps getting rejected from the App Store. The honest answer is that both sides of this decision have moved, and the choice comes down to a shorter list of real questions than the debate usually suggests.
What a PWA can now do that it could not a few years back
Modern PWAs install to the home screen, work offline through service workers, send push notifications on Android and, as of recent iOS releases, on iPhone too. Performance on a capable device is close enough to native that most users cannot tell the difference for a typical content, booking or ecommerce app. One codebase, one deployment, no app store review queue standing between a fix and your users.
Where native still wins outright
- Deep hardware access - Bluetooth peripherals, NFC payments, background location, camera features beyond a basic photo upload
- App store discoverability and trust, when a meaningful share of your users will search the App Store or Play Store rather than the web
- Heavy background processing, like continuous fitness tracking or offline-first sync of large datasets
- Platform-specific polish - iOS and Android users notice when an app does not feel like it belongs on their device
The budget and timeline reality
A PWA is typically the faster, cheaper route to a working product: one team, one codebase, instant updates. Native - or a cross-platform layer like the React Native or Flutter approach we cover for most builds - costs more upfront but is the only route when the features above are non-negotiable. The mistake we see most often is teams choosing native by default out of habit, then paying to maintain two platforms for an app that never needed hardware access in the first place.
How we actually decide with clients
We start with the feature list, not the platform. What does this app genuinely need from the device that a browser cannot give it? Where will most users actually find and open it - a link, a QR code, a store listing? What is the realistic budget for maintaining two codebases versus one? Those three answers usually make the decision for you.
“The platform should follow the feature list, not the other way around. Most apps lose nothing real by starting as a PWA.”
If you are scoping a new app and not sure which side of this you land on, walk us through what it needs to do and we will tell you honestly whether a PWA gets you there.
