Skip to main content

Command Palette

Search for a command to run...

PWA vs React Native: How to Make the Right Choice

Finding the Ideal Mobile Development Approach

Published
16 min read
PWA vs React Native: How to Make the Right Choice

Your startup just closed its seed round. The investors are happy, the product roadmap is locked, and everyone agrees: you need a mobile app — fast.

Your CTO wants to go with React Native. "Native performance, app store presence, the real deal," he says.

Your lead developer pushes back. "We're a web team. We don't know Xcode. We don't know Android Studio. A PWA gets us to market in two weeks — React Native takes two months."

Your marketing lead doesn't care about either argument. She just wants to know: "Will it show up in the App Store? Because our users expect that."

Three smart people. Three different answers. One deadline.

Now you're stuck with one question:

Do we build a Progressive Web App or go all-in on React Native?

And the answer depends entirely on things most comparison articles never ask you about.


Why This Matters

In modern mobile development, this decision impacts:

  • Time to market — a PWA can ship in days using your existing web codebase; React Native requires new toolchains, new build pipelines, and platform-specific knowledge

  • Development cost — the wrong choice can burn 30–50% more budget than necessary, or worse, force a complete rebuild six months later

  • User acquisition strategy — App Store presence versus SEO discoverability are fundamentally different growth channels, and your architecture locks you into one of them

  • Long-term maintenance — one team managing one codebase versus coordinating iOS builds, Android builds, OS updates, and app store reviews

Choosing the wrong approach can lead to:

  • Spending three months building a React Native app for a use case a PWA would have handled perfectly

  • Launching a PWA and discovering your core feature requires background processing that iOS flat-out blocks

  • Burning through budget on native developers when your team's strength is entirely in web

  • Missing your App Store launch window because you underestimated the review process timeline

So let's break it down — properly, without the hype on either side.


What is a PWA?

A Progressive Web App is a website that behaves like a native app. Built with standard web technologies — HTML, CSS, JavaScript — it leverages modern browser capabilities to deliver app-like experiences without going through an app store.

Think of it like a chameleon. On desktop it's a website. On mobile, if the user taps "Add to Home Screen," it installs like an app, launches full-screen, works offline, and sends push notifications — all from the same codebase you already have.

Key capabilities of a modern PWA:

  • Works offline using service workers that cache resources and handle network failures gracefully

  • Installable directly to the home screen — no App Store, no 50MB download, no permissions dialogs before first use

  • Responsive across every device and screen size from a single codebase

  • Fully indexable by search engines — your app can rank in Google

  • Instant updates — push changes and every user gets them immediately, no review process

The bar for what PWAs can do keeps rising. Camera, geolocation, push notifications, background sync — the modern web API surface is impressive. But there are still real ceilings, and we'll get to those.


What is React Native?

React Native is a cross-platform framework developed by Meta that lets you build genuinely native mobile apps using JavaScript and React. Unlike PWAs running inside a browser runtime, React Native compiles to actual native code — the UI components you render are real iOS and Android components, not web elements dressed up to look native.

Think of it like a universal translator. You write your app logic once in JavaScript and React — concepts your web team already knows — and React Native translates it into the native language each platform speaks. <View> becomes UIView on iOS and ViewGroup on Android. <Text> becomes UILabel and TextView. The experience users get is indistinguishable from a fully native app.

Key capabilities of React Native:

  • Renders actual native UI components — the scroll physics, animations, and gestures feel like platform-native because they are

  • Full access to native device APIs — camera, GPS, accelerometer, biometric auth, background processing, Bluetooth

  • Distributed through the Apple App Store and Google Play — with all the discoverability and credibility that comes with it

  • Shared codebase between iOS and Android (typically 80–90% of code is shared)

  • Can drop down to native Objective-C, Swift, Kotlin, or Java when you need capabilities that don't exist as a module yet


How They Work Under the Hood

Understanding the architecture helps you predict where each approach will hit its limits.

How PWAs Work

Step 1: Service Worker registration When a user first visits your PWA, the browser registers a service worker — a JavaScript file that runs in the background, separate from the main browser thread. This is the engine behind offline support and push notifications.

Step 2: Asset caching The service worker intercepts network requests and caches responses according to your strategy — cache-first for static assets, network-first for fresh data.

Step 3: App manifest A manifest.json file tells the browser how to present the app when installed — the icon, name, theme color, display mode (fullscreen, standalone), and orientation.

Step 4: Browser runtime executes everything All rendering happens inside the browser engine. Your React or Vue components produce DOM elements — the same elements the browser renders for any website. The "native feel" is achieved through CSS and JavaScript, not actual native components.

// manifest.json — what makes a web app installable
{
  "name": "My App",
  "short_name": "MyApp",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#000000",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

How React Native Works

Step 1: JavaScript runs on the Hermes engine Your app logic executes on Hermes — a JavaScript engine optimized specifically for React Native. It compiles your JS ahead-of-time for faster startup.

Step 2: JSI bridges JS and native code The JavaScript Interface (JSI) enables direct communication between your JavaScript and native C++ code — no JSON serialization, no async bridge bottleneck like the old architecture had.

Step 3: Fabric renders native views The Fabric renderer takes your React component tree and creates actual native views. <View> becomes a real UIView. <Text> becomes a real UILabel. These aren't simulated — they're the same components Apple and Google ship in their own apps.

Step 4: TurboModules handle device APIs Native device features (camera, GPS, sensors) are exposed through TurboModules — loaded lazily, accessed via JSI, with none of the performance overhead of the old bridge architecture.


PWA vs React Native: Head-to-Head

Feature PWA React Native
Development speed Fast — reuse existing web code Slower — new toolchain, new concepts
Initial cost 30–50% cheaper to build Higher upfront investment
Native UI feel Close, but subtle differences remain Genuinely native — indistinguishable
Performance Browser-bound, improving with WebAssembly Native performance, consistently 60fps
Offline support Excellent via service workers Excellent, more control
App Store presence No (PWA-to-Play workarounds exist) Yes — iOS App Store + Google Play
SEO & discoverability Full web SEO — Google indexes it Invisible to search engines
Push notifications Limited on iOS, full on Android Full control on both platforms
Background processing iOS severely restricts this Full native background capabilities
Camera / sensors Basic access Full native API access
Bluetooth / NFC Limited / experimental Full access
Update delivery Instant — no app store review Requires app store submission
Codebase Single codebase (web + mobile) iOS + Android (80–90% shared)
Team requirements Web developers — no new skills needed React knowledge + native platform awareness
Maintenance cost Low — deploy once, all users updated 20–30% higher — two platform builds

Real-World Example

Let's walk through four real products and show which strategy each one demands — and what happened when companies made the choice.


App 1: A Content Platform or News App

You're building a developer news aggregator — think Hashnode, Dev.to, or a niche content community. Users browse articles, bookmark posts, read offline on the train.

Use a PWA.

Why? Starbucks rebuilt their ordering experience as a PWA and it came in at 99.84% smaller than their iOS app. Users could browse the menu and add items to cart even with no network connection. Daily active users doubled after launch. Twitter Lite reduced data consumption by 70%, increased pages per session by 65%, and decreased bounce rate by 20% — all by switching to a PWA. For content-heavy platforms where SEO drives discovery, the combination of web indexability and app-like experience is a genuine growth advantage.


App 2: A Fitness Tracking App

You're building a workout tracker. It needs to run in the background tracking GPS during a run, access the accelerometer to count steps, sync heart rate data from a Bluetooth wearable, and send motivational push notifications at 6am even when the app is closed.

Use React Native.

Why? iOS flat-out blocks background processing for PWAs. There is no workaround. Your GPS tracking stops the moment the user locks their screen. The Bluetooth API is experimental in browsers and inconsistent across devices. React Native gives you full access to CoreMotion on iOS and SensorManager on Android, proper background location tracking through libraries like react-native-background-geolocation, and rock-solid push notifications via APNs and FCM. Apps like Nike Run Club and fitness trackers across the board are React Native for precisely these reasons.


App 3: An E-Commerce Store

You're building a mobile shopping experience. Products need to load fast, the checkout flow needs to be smooth, and you want SEO to drive organic product discovery.

Use a PWA — seriously.

Alibaba saw a 76% increase in conversions after launching their PWA. Pinterest rebuilt their mobile web as a PWA and saw 60% increase in core engagements and 44% increase in user-generated ad revenue. The lower installation friction (no app store download, just browse and buy) means you capture impulse purchases that a React Native app would lose at the "download the app" prompt. For pure e-commerce where the funnel starts on Google, PWAs consistently outperform native apps.


App 4: A B2B SaaS Mobile Companion

You're building a mobile companion app for a project management tool — think Jira or Asana's mobile app. Your users are enterprise teams. Their IT department requires apps to be distributed through MDM (Mobile Device Management). The app needs deep integration with device calendars, notifications, and file system.

Use React Native.

Enterprise users expect to find work apps in the App Store. MDM distribution requires proper app store presence. Shopify uses React Native for their merchant mobile app — complex inventory management, camera-based barcode scanning, and push notifications for order alerts are all capabilities that required native access. Discord rebuilt their iOS app in React Native to achieve feature parity with Android faster, and the development speed and code sharing made it the clear choice.


How to Choose

Choose a PWA if:

  • Your team is built around web technologies and native expertise would require expensive new hires

  • SEO and organic web discovery are central to your user acquisition strategy

  • You need to move fast — a PWA ships in days, not months

  • Your app is content-heavy: news, e-commerce, documentation, community

  • You're validating an MVP and don't want to sink budget into native before proving the concept

  • Your users are in emerging markets where app download friction (storage, data costs) is a real barrier

Choose React Native if:

  • You need features iOS or Android block for web: background processing, Bluetooth, advanced camera, NFC

  • App Store presence is non-negotiable for your acquisition strategy or enterprise distribution

  • Your product demands consistently smooth 60fps animations and native gesture physics

  • Your team already knows React — the learning curve is gentle and the code sharing is real

  • You're building media-intensive features: video recording, audio processing, AR

  • You need deep platform integration: biometric auth, widgets, share extensions, Siri/Google Assistant

Rule of thumb: If your app primarily delivers content and your users find it through search — build a PWA. If your app primarily uses the device and your users expect to find it in a store — build with React Native.


Key Insights

What production teams learn that tutorials don't tell you:

  • The PWA vs React Native debate is often really a PWA vs nothing debate. Many teams choosing between the two are actually a web team with no mobile presence. For them, a PWA isn't a compromise — it's the right tool. A well-built PWA beats a poorly maintained React Native app every single time.

  • iOS is the real constraint on PWAs, not the technology. Android supports PWAs beautifully — full push notifications, background sync, home screen install prompts. Apple has historically dragged their feet on PWA capabilities. Before choosing a PWA, audit your user base. If 70% of your users are on iOS, the limitations hit harder.

  • React Native's new architecture changes the conversation. The old bridge was a real performance bottleneck. JSI, Fabric, and Hermes in React Native 0.73+ make the performance gap between React Native and fully native Swift/Kotlin apps negligible for most applications. "React Native is slow" is an outdated take.

  • The hybrid approach is a legitimate strategy, not a cop-out. Build a PWA first to validate product-market fit and grow your user base. Once you've proven the core value and identified which native features you actually need (not just want), invest in React Native. Pinterest, Twitter, and Starbucks all have both — PWA for acquisition, native app for power users. It's not either/or.

  • Update velocity is a hidden PWA advantage. React Native apps require a build, a review (2–4 days for Apple), and user adoption. PWA updates are live the moment you deploy. For early-stage products iterating fast, this compounds into a significant speed advantage over months.


Common Mistakes

Choosing React Native to seem more "serious": A React Native app doesn't make your product more credible — a good product does. Many successful products with millions of users run entirely as PWAs. Don't let the "native = professional" perception drive an architectural decision.

Building a PWA without checking your iOS feature requirements first: Push notifications on iOS PWAs, background sync, Bluetooth, persistent storage — all have limitations on Safari that don't exist on Chrome. If 60% of your target users are on iPhones and your core feature requires reliable push notifications, a PWA will frustrate you and them. Audit the Web API support on iOS Safari before committing.

Underestimating React Native's operational overhead: React Native isn't just "React for mobile." You're maintaining two platform builds, dealing with native module compatibility on every dependency update, navigating Apple's review process, and potentially needing native iOS/Android developers for complex integrations. Budget for that overhead honestly.

Treating a PWA as a "good enough" placeholder you'll replace later: If your roadmap genuinely requires native capabilities, commit to React Native now. Building a PWA with the intention of rebuilding it in six months means you build the same product twice. Ship the MVP as a PWA only if you're genuinely willing to live with PWA limitations long-term.

Not considering the team you actually have: The best mobile framework is the one your team can ship, maintain, and debug. A React Native app built by a team that doesn't understand native mobile debugging will be a liability. A PWA built by a strong web team will be an asset. Skills on the ground matter more than architecture on a whiteboard.


TL;DR

  • PWA = Web technology, no app store, instant updates, great SEO. Best for content, e-commerce, and MVPs. Limited by iOS and browser API ceilings.

  • React Native = Native performance, app store presence, full device API access. Best for feature-rich apps with native requirements. Higher cost and complexity.

Best choice:

  • Content platform, news, e-commerce → PWA

  • MVP or tight budget with web team → PWA

  • Fitness, health, location tracking apps → React Native

  • Enterprise app requiring MDM / App Store → React Native

  • Media-intensive: video, audio, AR → React Native

  • Not sure yet → Build a PWA first. Graduate to React Native when you hit the ceiling.


Conclusion

At the end of the day, there's no perfect solution.

But there is a smart one — and it starts with being honest about what your product actually needs versus what sounds impressive in a tech stack conversation.

PWAs are not a compromise. They power some of the highest-traffic, highest-converting mobile experiences in the world — built by teams shipping faster, spending less, and reaching users that would never have downloaded an app. React Native is not overkill. It's the right tool for every product where the device itself is the product — where the camera, the sensors, the background processing, and the app store are core to the value you're delivering.

Don't choose React Native because native sounds more legitimate.
Don't default to a PWA just because your team is afraid of a new toolchain.

Choose based on the device capabilities your product needs, the users you're trying to reach, and the team you actually have. Build for your users — not for your tech preferences.


What Did You Build — PWA or React Native?

Are you running a PWA that punches above its weight, or a React Native app that justified every bit of the complexity?

Did you start with one and migrate to the other? What was the breaking point?

Drop it in the comments — especially if you've hit the iOS PWA limitations wall, dealt with a nightmare app store review, or shipped a PWA that outperformed a native app in ways you didn't expect.