React Native in 2026: When to Go Native vs PWA vs Expo for a SaaS Mobile App
The React Native vs PWA question almost never starts as an engineering question. It starts as a growth assumption: "our competitors have an app, so we need one too." By the time it reaches the founding team it has hardened into a roadmap item, and nobody has stopped to ask whether being in the App Store actually changes anything for the business. For most B2B SaaS products the honest answer is that it does not, and the cost of finding that out the expensive way is a native codebase that two of your five engineers now maintain forever.
This post is a decision framework, not a technology overview. The goal is to help you decide whether you need native at all, and if you do, whether Expo or a bare React Native workflow fits your team. We audit codebases for a living, and the mobile decision is one of the most common places where a small team quietly commits to a maintenance burden it never scoped.
Framing React Native vs PWA: Start With Five Questions, Not a Technology Choice
Native is justified when your product needs a platform capability the browser cannot reach, or when App Store distribution is a business requirement rather than a preference. Everything else is a web problem wearing an app costume. Before anyone writes a line of React Native, answer these five questions honestly.
Does the core experience require push notifications that arrive reliably when the app is closed? Web push exists, and on Android it is solid, but if push is central to your product loop, native still gives you the most dependable delivery and the richest notification surface.
Does it need deep hardware access, such as the camera as a first-class input, biometric authentication tied to the secure enclave, Bluetooth, or NFC? A document scanner, a field-inspection tool, or a payments terminal companion has a real native case. A dashboard does not.
Does it need offline-first data with conflict resolution, where users create and edit records with no connection for hours and sync later? This is buildable on the web with IndexedDB and service workers, but the ergonomics of a native local database and background sync are meaningfully better once the data model gets complex.
Does it need real background processing: location tracking, large uploads that continue after the app is backgrounded, or scheduled local work? The browser deliberately limits this. Native does not.
Is App Store presence a business requirement, because your buyers search the store, your enterprise customers require MDM distribution, or your pricing depends on in-app purchase? Sometimes the store itself is the feature. That is a legitimate reason, but name it as a distribution decision, not a technical one.
If you answered no to all five, you do not have a native problem. You have a web app that should be installable, and you should stop reading job postings for React Native developers.
The PWA Ceiling in 2026, Stated Honestly
The strongest case against native for most SaaS is that a progressive web app now covers the boring middle of the market. A PWA installs to the home screen, runs full-screen without browser chrome, works offline through a service worker, and ships instantly with no review queue. For a data-entry tool, an internal admin surface, or a dashboard companion to a desktop product, that is frequently the entire requirement.
What changed is that iOS caught up on the parts that used to be dealbreakers. Since the iOS 16 and 17 cycle, installed web apps on iPhone support web push, badging, and a genuinely usable installed experience, closing the gap that made Android-only PWAs a hard sell for years. On Android the story has been good for a long time. So in 2026 a PWA is a serious answer, not a fallback.
The ceiling is still real, though, and you should know exactly where it is before you commit. On iOS, web push works only for installed apps and remains less reliable than native for time-critical delivery. Background execution is tightly capped: you cannot run continuous location tracking or guaranteed background sync the way a native app can. Deep hardware integration such as Bluetooth and NFC is inconsistent or unavailable in Safari. And you are not in the App Store, which matters if and only if your buyers actually look there.
Read that list against your five answers. If none of those limits touches your product, a PWA plus a well-built responsive web app is not a compromise. It is the correct architecture, and it is the one we recommend most often during a tech stack strategy engagement because it removes an entire platform from the maintenance surface.
Where Expo Fits, and Why Bare React Native Is Rarely the Right Start
Suppose you worked through the questions and native is justified. The next fork is Expo versus a bare React Native project, and this is where teams underestimate the operational cost of the bare path.
Expo's managed workflow lets a team ship a real React Native app without owning a native build environment. You write JavaScript and TypeScript, Expo Application Services builds the binaries in the cloud, over-the-air updates let you push JavaScript changes without a new store review, and the config plugin system handles most native module needs without ejecting. For a five-person company with no dedicated mobile engineer, this is close to mandatory. The alternative is maintaining Xcode and Android Studio toolchains, provisioning profiles, signing certificates, and native dependency graphs, which is a part-time job nobody on a small team has spare capacity for.
The old objection to Expo, that you hit a wall the moment you need a native module it does not support, is largely obsolete. The config plugin ecosystem and development builds mean you can add custom native code and still keep the managed build and update pipeline. Bare React Native makes sense when you have genuinely unusual native requirements or an existing native app you are extending, but for a greenfield SaaS mobile app it is usually the wrong default. Start managed, and eject only when a concrete requirement forces it.
The Shared Code Illusion With Your Next.js Web App
The most seductive argument for React Native is code sharing: "we already have a Next.js app, so React Native means one team, one language, shared logic." Part of this is true and part of it is a trap, and the difference decides whether the shared codebase saves money or quietly costs it.
What genuinely shares is the non-visual layer. TypeScript types, validation schemas, API client code, formatting and business logic, and domain models move between web and native cleanly. Put that in a shared package and both apps consume it. This is real leverage and worth structuring for.
What does not share is the component tree. React Native does not render HTML or use CSS; it uses its own primitives and layout system. A React web component and a React Native component sharing a name does not mean they share an implementation. Teams that expect to reuse their web UI in the app discover that navigation, gestures, lists, forms, and platform conventions all diverge, and the "shared component" turns into two implementations behind one interface. React Native for Web can bridge some of this, but treating it as a way to run your existing site inside an app usually produces something that feels wrong on both platforms.
The correct mental model is: share the logic aggressively, share the components almost never, and budget for the app UI as net-new work. If you scope the project believing the UI is mostly reuse, you will be wrong by roughly the entire cost of the app. This is a common finding when we do a code quality review on a stalled cross-platform project.
The Maintenance Cost Nobody Puts in the Estimate
The build estimate is the small number. The maintenance cost is the one that surprises a five-person company, and it is worth modeling explicitly before you commit.
App Store review adds latency to every release. A urgent fix that ships to your web app in minutes waits in a review queue for the mobile version, so you either adopt over-the-air updates for JavaScript changes or you accept that mobile and web are on different release cadences. Native dependency upgrades arrive on the platforms' schedule, not yours: each year iOS and Android ship changes that can break builds, and you must keep pace or fall off supported toolchains. On Expo, the SDK migration cadence is real ongoing work, since staying current is required to keep the managed pipeline and the latest React Native version. And every native library you add is a dependency that can be abandoned, break on the next OS version, or block an upgrade.
None of this is a reason to avoid native. It is a reason to make sure the value is there before you sign up for it, and to staff for it honestly. A native app is not a one-time build; it is a second product with its own release train, and a team that scopes it as a feature will feel the drag within two release cycles. Folding that reality into the plan is exactly the kind of thing a custom software development partner should force into the conversation before the first sprint.
A Decision Summary You Can Act On
Work the questions in order. If no platform capability and no distribution requirement justifies native, build an excellent responsive web app and make it an installable PWA. That covers more B2B SaaS products than most founders expect, and it keeps your whole team on one codebase.
If native is genuinely justified, start with Expo's managed workflow rather than bare React Native, share your TypeScript logic across web and mobile but plan the app UI as new work, and put the ongoing maintenance train, review delays, dependency upgrades, and SDK migrations into the budget from day one. Choose native because a requirement demands it, not because a competitor has an icon on a home screen.
If you are staring at this decision and want a second opinion grounded in your actual product and team size rather than a generic best practice, that is the kind of call we help with. Reach us at hello@wolf-tech.io or at wolf-tech.io, and we will tell you honestly whether you need an app at all.