People almost always ask me the question backwards. "Would you build this in React Native or as a PWA?", as if you had to pick a side once and for all and defend one stack against the other. I do both, and because I do both, I have no loyalty either way. The real question is never which one is better. It's what your app needs to do, for whom, and how much you can spend on it. Once you've answered that, the choice mostly makes itself. Three or four criteria settle it, and they settle it fast.
Hardware is the first thing that decides
If your app has to talk to hardware, the discussion is often over before it starts. An NFC badge reader, a Bluetooth sensor, a connected scale, a payment terminal, a camera you control precisely (focus, exposure, raw stream), accurate motion sensors. The moment you go down to that level, the web shows its limits, and on the iPhone it's a wall.
Concretely: Web Bluetooth, Web NFC, WebUSB and Web Serial aren't supported on iOS. Since every browser on the iPhone runs on Safari's engine, this isn't a case of "Chrome on iOS will handle it". No iOS browser has access, and Apple shows no sign of wanting to change that. Code says it more clearly than a long paragraph:
// On Android, in Chrome: navigator.bluetooth exists, you scan your sensor.
// On the iPhone, in any browser: undefined. Door closed.
if ('bluetooth' in navigator) {
const device = await navigator.bluetooth.requestDevice({ /* filters */ })
} else {
// no pure-web fallback on iOS
}
On Android, a PWA can absolutely speak BLE to a device, and it works well. But if your app also has to run on the iPhone (and for most clients that's non-negotiable), you can't lean on an API that half your install base will never have. React Native goes through the native building blocks with battle-tested modules (BLE, NFC, advanced camera) on both platforms. When hardware sits at the heart of the need, React Native or going fully native wins, and there isn't really a debate.
One honest caveat: the "simple" camera (snap a photo, scan a QR code) works fine on the web, on iOS as everywhere else. It's plugged-in hardware, low-level protocols and fine-grained sensor control that tip you toward native.
Serious offline, the other thing that doesn't forgive
There's offline and there's offline. A PWA handles "I'm checking my data on the subway with no signal" perfectly well: a service worker, a cache, a bit of IndexedDB, and the app responds offline. For a lot of business apps, that's enough.
Then there's the other offline. The one where there's never any network, where the app is the only software running, where it has to take hours of use without ever calling back to a server. I built Prolog on exactly that: a React Native app that talks over direct WiFi to a drilling probe and runs an embedded machine learning model, on a ruggedised Android tablet, next to a drill rig, with no internet connection whatsoever. The model lives in the app, inference happens on the device, the measurements are written locally. A PWA would not have met that spec, if only because on iOS mechanisms like background sync aren't there, and running an embedded ML model that talks to a sensor over a direct link is not browser territory.
So if your app lives in the field, on a dedicated device, and it has to be reliable without a network and keep its grip on the system, lean React Native without hesitating. If your "offline" comes down to convenience caching for a desk user or a salesperson on the road, a PWA does the job.
Distribution and cost, where the PWA takes the lead back
We've covered the cases where the web stalls. The rest of the time it's the one in front, by a wide margin.
A PWA is a URL. You deploy, it's live, everyone reaches it from their browser, and your update is instant for all of them on the next reload. No App Store submission, no review that holds you up three days over a comma in the description, no per-platform build to sign, no paid developer account to renew every year, no version 1.2.4 that half your users will never install. A single web codebase that reaches mobile, tablet and the desktop. To get started, and above all to maintain over time, it's clearly cheaper and lighter.
React Native asks for more investment, and it's worth saying plainly. You've got two stores to manage, builds to produce and sign, sometimes native code to write when a module doesn't cover your need, and the stores' review cycle sitting between you and your users. It's all very manageable (the tooling around Expo has smoothed a lot of this out), but it stays a real cost, in time and money, that a PWA doesn't carry. If reach, upfront budget and update simplicity are your priorities, and nothing in the list above forces you to go native, start with a PWA. You can always build a native app later, when a genuine need justifies it.
Perceived experience, more often a fake argument than a real one
This is the argument people throw at me to justify going native "by default": it'll be smoother, prettier, more "real". Sometimes that's true. On complex gestures, animations that hug the system, deep integration (native sharing, widgets, fine-grained interactions), React Native is ahead, and you can feel it.
But look honestly at what your business app actually does. Forms, lists, dashboards, browsing, data entry, filters. For 80% of those screens, a well-made PWA is indistinguishable from a native app to the user. Nobody, in real life, pulls out their phone to guess whether the app they log site data into is "native or not". They want it to open fast, not crash, and respond. The "native because it's more professional" reflex costs a lot for a gain the end user never perceives. I'd advise against it as long as no real technical criterion calls for it.
iOS, the stone in the PWA's shoe
Let's be precise, because this is where the disappointments hide. The PWA's weak spot isn't "the web", it's iOS. On Android the PWA experience is solid: an install prompt at the right moment, access to a fair bit of hardware, notifications. On the iPhone it's rougher.
Push notifications finally exist on iOS as of Safari 16.4, but with one condition: the user has to have added the PWA to their home screen. As long as your site lives in a Safari tab, no push, full stop. And that home-screen install is precisely a manual gesture: no automatic install banner like on Android, it's up to the user to dig it out of the share menu. Which means you have to explain it to them, and a good share of people never will. Add the missing hardware APIs already mentioned and some background mechanisms, and you get the real face of the decision: a PWA is excellent everywhere, and a little hemmed in on the iPhone. If your audience is heavily on iOS and you need reliable notifications or a strong home-screen presence, that friction has to weigh in your call.
How I decide, in practice
My default, concretely: I go PWA when reach, cost and simplicity rule, and nothing demands hardware or hard offline. I switch to React Native the moment I need to talk to a sensor, hold up without a network on a dedicated device, or deliver a genuinely native experience that the use case justifies. And I do sometimes build both on the same project: a PWA for the general public, reaching everyone with no friction, and a native app for the field operators, who need the hardware and the offline. That's not a wobbly compromise, it's often the right answer, each tool on the ground where it's unbeatable.
The trap is picking the tech before you've looked at the need. Start by listing what your app actually has to do, and the answer is already half written.
Stuck on your own project? Let's talk, and I'll tell you honestly which way I'd go.
Top comments (0)