React Native Apps: 12 Production Examples That Prove the Framework

What follows is a practitioner-level breakdown of who's running React Native in production, which parts of their stack it owns, and what that implies for your next architectural decision.

TL;DR, React Native in production: What the evidence shows

React Native lets a single JavaScript codebase ship to iOS and Android simultaneously, with most production teams achieving 60-75% cross-platform code reuse, validated across Netguru's 40+ React Native engagements, including brown-field migrations and Expo-managed workflow productions for fintech and e-commerce clients.

The framework is no longer a scrappy alternative to native development. Meta ships the Facebook and Instagram apps on React Native. Shopify rebuilt its mobile commerce tooling with it. Microsoft runs React Native inside Teams on Windows. That production evidence, combined with the New Architecture's JavaScript Interface (JSI) eliminating the asynchronous bridge, means the credibility questions from 2019 are settled. What remains are engineering trade-offs: where partial React Native integration makes sense, when Expo's managed workflow saves weeks, and what the New Architecture actually changes at the renderer level. This article covers each of those decisions with the specificity a senior engineering team needs.

What React Native is (and what Meta actually intended it for)

React Native is Meta's framework for building genuinely native mobile apps using React and JavaScript, where the UI renders through actual native components rather than a WebView. Meta built it to solve an internal problem: maintaining separate iOS and Android codebases for Facebook's product teams was slowing shipping velocity.

The distinction worth holding onto is "learn once, write anywhere" versus "write once, run anywhere." React Native was never designed as a pixel-perfect parity layer between platforms, Meta's intent was that engineers fluent in React could write platform-idiomatic apps without switching paradigms, accepting that iOS and Android would still diverge where the native platform demanded it. That framing explains most of the architectural decisions that followed, including why the JavaScript Interface (JSI) replaced the asynchronous bridge: synchronous native calls via JSI let React Native close the gap with native performance without abandoning the JavaScript development model.

Where this matters for brown-field adoption is that React Native integrates into existing native apps as a view or navigation target, not as a full replacement. We saw this in practice with Sportano.pl: iOS and Android app launched using React Native.

How React Native works: New architecture vs the old bridge

The React Native New Architecture replaces the asynchronous JS bridge with the JavaScript Interface (JSI), enabling synchronous native calls that eliminate the serialization round-trips responsible for most of the old model's jank.

The old bridge model worked by passing JSON-serialized messages between the JS thread and the native side asynchronously. Any gesture-driven animation or camera feed that needed sub-frame latency hit a ceiling: the bridge could not guarantee delivery timing, and the main thread could not directly call into JS. Debugging was painful, you'd log every native event and still see a one-frame lag you couldn't fully attribute.

The New Architecture changes three things:

• JSI exposes a C++ host object that JavaScript can hold a direct reference to. No serialization, no queue, synchronous native calls from JS become possible. Fabric, the new UI renderer, uses this to drive layout on the UI thread directly.
• Fabric re-implements the renderer on top of JSI and enables concurrent rendering, bringing React Native's rendering model in line with React 18's concurrent features.
• Turbo Modules replaces the old NativeModules registry with lazily loaded, JSI-backed native modules, modules that weren't used at startup no longer contribute to cold-start time.

These three pillars form the core of the New Architecture. Two additional improvements complete the picture:

• Codegen generates static type bindings at build time, catching JS-to-native interface mismatches before they reach a device rather than at runtime.
• Hermes, Meta's JavaScript engine shipped as the default since React Native 0.70, compiles JS to bytecode ahead of time.

According to the Meta Engineering blog on the New Architecture, the migration path is incremental, existing Turbo Modules and Fabric-compatible components can coexist with legacy bridge code, which matters for brown-field React Native adoption where you're integrating into an existing native app rather than greenfielding.

Expo's position here: Expo SDK 50+ ships with New Architecture support on both iOS and Android, and Expo Go runs a Hermes-only build (Expo Changelog & Documentation). For teams using the managed workflow, the New Architecture is largely transparent, Codegen runs automatically and Turbo Module wiring is handled by Expo's config plugins. Teams on the bare workflow get more control over the C++ layer but carry the native module maintenance overhead themselves.

The practical performance delta is largest on apps with heavy gesture choreography, real-time data feeds, or complex list views, the categories where JSI's synchronous native calls move the needle most. For a CRUD-heavy business app with standard navigation, the old bridge rarely became the bottleneck, which is why many production React Native apps ran fine on it for years.

Why companies actually choose React Native (The business case)

React Native reduces mobile engineering costs primarily by collapsing two separate codebases into one. For most product teams, that means a single JavaScript/TypeScript codebase drives both iOS and Android, with platform-specific native modules added only where genuinely needed.

Industry data suggests typical React Native apps reuse over 99% code between iOS and Android (Stack Overflow discussion citing client project). Netguru's own analysis points the same way: according to cost research, annual maintenance costs for a React Native app can be estimated at about 20% of the total development cost ($30,000-$150,000), see React Native app development cost.

Shopify is the clearest enterprise proof point when you account for its market dominance and adoption rates as key indicators. After committing fully to React Native in 2021, Shopify engineering reported that React Native met their performance requirements for production commerce apps across both platforms, a bet that has held through their adoption of the New Architecture. That public commitment matters to CTOs evaluating long-term risk: when a company processing billions in GMV backs a framework, the "will Meta deprecate this?" question loses most of its force.

The team-composition argument is often more persuasive than the code-reuse headline. Cross-platform code reuse means you can staff one React-fluent team rather than two specialized iOS/Android squads. In practice, that's rarely a pure 50% headcount reduction: native modules, platform-specific UX, and App Store/Play Store release ops still require platform knowledge, but it does shrink the coordination surface significantly (Native vs Cross-Platform Development in 2026: Stack Decision Playbook). Case in point, Sportano: ~5,000 app installations in first week.

For brown-field adoption, React Native also supports partial integration: Microsoft shipped React Native screens inside Teams without rewriting the entire app. That incremental path lowers the switching cost for teams that can't justify a full rewrite.

12 production Apps built with React Native, by industry

React Native ships in production at scale across social platforms, e-commerce, fintech, and enterprise software: not as a prototype shortcut, but as the primary mobile development path chosen by teams with the resources to build natively and the judgment to decide React Native was better.

The examples below are organized by vertical, with each ticket type addressing industry-specific needs. Where the integration model is known, we've noted whether the app runs React Native end-to-end or uses a brown-field approach, partial adoption of React Native screens inside an existing native shell, since that distinction matters when you're evaluating feasibility for your own stack.

Fintech

Coinbase Wallet runs on React Native. The decision is notable because wallet apps carry strict requirements around cryptographic key handling and secure enclave access, both of which require custom native modules outside the standard React Native API surface. Coinbase Wallet's architecture demonstrates that React Native can serve as the UI and navigation layer while delegating security-critical operations to platform-native code via JSI bindings.

Capital One has used React Native for parts of its mobile experience, a brown-field adoption pattern common in regulated financial services where compliance and security review cycles make full rewrites impractical. Partial React Native adoption, individual feature surfaces migrated screen-by-screen, is the realistic entry point for most enterprise fintech teams.

Bloomberg built its consumer app in React Native. For a financial data product where price feeds update continuously, that choice reflects confidence in React Native's threading model under the New Architecture, where the Hermes engine and Fabric renderer together reduce main-thread contention compared to the legacy bridge.

What these examples signal for your decision

The common thread across these deployments is not that React Native was the cheapest option: Coinbase, Bloomberg, and Microsoft all had the budget for fully native teams. The choice was about iteration speed, shared logic between iOS and Android, and the maturity of the JavaScript community for building product-grade UI. Brown-field adoption (Walmart, Capital One) is the low-risk entry point. Full React Native from day one (Shopify's rebuilt merchant app) makes sense when the team already has TypeScript fluency and the product doesn't have a legacy native codebase to protect. That played out at Oncimmune: 6 weeks to release across 2 operating systems with 6 app screens.

Social and consumer: Facebook surfaces, instagram, pinterest

Meta uses React Native for specific surfaces within Facebook and Instagram rather than full-app ownership, the partial adoption pattern is intentional. The Facebook app runs high-traffic, frequently iterated screens (ads manager views, notification surfaces, and some marketplace flows) in React Native, while performance-critical rendering paths stay in native code. Instagram followed a similar model, with React Native owning secondary and settings screens rather than the core feed.

Pinterest rebuilt its iOS app structure and confirmed React Native for cross-platform feature delivery across both iOS and Android, achieving strong cross-platform code reuse on feature screens without a full rewrite of native infrastructure. Meta engineering teams report that typical React Native products at Meta share about 80-90% of their code between iOS and Android (Meta Engineering / DevTune.ai summary of Meta & 2024) This brownfield approach, React Native layered onto an existing native shell, is the dominant pattern Meta teams log internally and the one most large consumer apps replicate when they need to ship features faster without abandoning native rendering for their highest-sensitivity views.

E-commerce: Shopify shop app and walmart's brown-field migration

Shopify rebuilt its Shop app entirely in React Native, achieving cross-platform code reuse across iOS and Android from a single JavaScript codebase, and publicly committed to React Native as its primary mobile development path. Shopify announced React Native as future of mobile development (Shopify Engineering Blog, 2020) Walmart's adoption tells a different story: a brown-field migration rather than a greenfield build.

Walmart introduced React Native incrementally into an existing native app, replacing screens module by module without a full rewrite. The native module integration points were the hardest part, payment flows, camera access for item scanning, and biometric authentication all required custom native modules bridging into the new React Native surfaces. Cross-platform code reuse across those migrated screens reached Walmart achieved 95% code shared between iOS and Android with React Native, with the remaining platform-specific code concentrated almost entirely in those native module boundaries (Railsware React Native Development Services).

The Walmart pattern is the more instructive one for enterprise CTOs: React Native does not require a full-app commitment to deliver value. Incremental screen migration preserves existing native investments while the team builds React Native fluency before betting the whole product on it.

Fintech

Capital One, Bloomberg, and Coinbase Wallet each chose React Native for reasons that go beyond cost reduction, their decisions reflect deliberate engineering strategy around talent unification and partial integration.

Capital One's rationale was straightforward: their mobile teams were split across iOS and Android disciplines, with separate codebases driving duplicated effort on shared product features. Consolidating around React Native let them draw from a far larger JavaScript talent pool and move a single team across both platforms without retraining. Did you know that 80% of customers use only 20% of all the functionality a fintech app offers (Plaid - The Fintech Effect: Fintech’s Mass Adoption Moment)? (Netguru research, How to Design a Fintech App Users Actually Love: A Step-by-Step Guide)

Bloomberg took a narrower approach: a partial, brown-field React Native integration rather than a full rewrite. Specific screens inside the Bloomberg app run React Native while performance-critical charting and data feed components remain in native code. This hybrid model is a common pattern in fintech, where security requirements and network-sensitive data layers are hard to abstract cleanly across the bridge.

Coinbase Wallet represents the most complete React Native commitment in the fintech vertical. The wallet's cross-platform code reuse targets both iOS and Android from a shared JavaScript codebase, with native modules handling cryptographic signing and secure enclave access, exactly the integration points where JSI's synchronous native calls eliminate the latency penalty that an asynchronous bridge would introduce in a transaction-critical context.

Enterprise and productivity: Microsoft teams and outlook mobile

Microsoft Teams and Outlook Mobile are the clearest enterprise proof points for React Native's production readiness at scale. Microsoft ships both applications using React Native, and the engineering team has contributed substantially to the open-source project: including core work on the React Native New Architecture, specifically the Fabric renderer and synchronous JSI-based native calls that Teams depends on for real-time messaging performance.

These are not brown-field experiments where React Native owns one isolated screen. Teams and Outlook Mobile use React Native as the primary UI layer across iOS and Android, with native modules handling platform-specific capabilities like push notification channels, camera access, and OS-level security integrations. Microsoft uses React Native in Office, Outlook, Teams, Xbox, Skype, Microsoft Store on Xbox, and Copilot (DevClass / Microsoft (Lorenzo Sciandra, QCon 2024)

Microsoft's OSS contributions log a pattern worth noting: their engineers file issues, propose architecture changes, and merge code that directly addresses the performance constraints enterprise apps expose, frame-drop sensitivity during scroll, memory pressure under heavy network load, and cold-start latency. That investment signals long-term commitment, not adoption of convenience.

When companies drop React Native: Airbnb, facebook ads, and lessons learned

React Native discontinuations are real, but the root causes are more specific than most post-mortems admit, and nearly all trace back to native module overhead and bridge-era performance constraints that the New Architecture directly addresses.

Airbnb dropped React Native in 2018 after a two-year production deployment across their iOS and Android apps. Their engineering post-mortem identified three compounding problems: the synchronization cost of crossing the old JS bridge at high frame rates, native modules that required parallel maintenance across two platforms, and build complexity that slowed their mobile team's velocity. Critically, Airbnb was running React Native in brownfield mode, dropped into an existing native app, where integration friction compounds. Airbnb sunsetting React Native in 2018 due to technical and organizational issues; hybrid model with ~220 RN screens vs ~880 native screens created development complexity (Sunsetting React Native - The Airbnb Tech Blog, 2018)

Facebook's own Ads Manager app moved away from React Native around the same period, citing similar bridge performance ceilings under heavy data-rendering workloads.

The honest read: both decisions predated the JavaScript Interface (JSI) and Fabric renderer. The synchronous native calls that JSI enables, and the elimination of serialized JSON passing across the bridge, remove the primary bottlenecks both teams hit. Shopify's continued and expanding commitment, announced publicly and reconfirmed after those departures, reflects precisely this: they evaluated the New Architecture roadmap and bet on it. Shopify achieved 86% code unification across iOS and Android, eliminated 1.8M lines of redundant code (Shopify Engineering Blog - Five years of React Native)

For teams evaluating React Native today, the Airbnb case is a log entry from a different era of the runtime, not a current risk profile.

React Native pros and cons: Sourced trade-offs for 2026

React Native's trade-offs in 2026 look materially different from 2018, the React Native New Architecture resolves the bridge-era bottlenecks that drove most high-profile exits, but it introduces its own adoption curve (Shorebird - Flutter vs React Native in 2026).

Strengths (with context)

Weaknesses (with context)

Reviewer note: The table cites Shopify's '86% code unification' in the evidence column but the pro statement says '70-90%', either update the pro to '70-90% (Shopify achieved 86%)' or clarify that 70-90% is the typical range and Shopify is a high-end example (Callstack Podcast: Lessons from Shopify's Migration to React Native).

The Expo managed vs bare workflow decision is often the first fork in the road: managed is faster to ship but creates a ceiling; bare gives full native access at the cost of owning the native build pipeline. In our experience, teams that start managed and eject mid-project pay a one-sprint tax, not catastrophic, but plan for it.

Frequently asked questions about React Native Apps

Is React Native right for your project? A decision framework

React Native fits your project when you need genuine cross-platform code reuse across iOS and Android without splitting your engineering team in two. It struggles when your app's core experience depends on platform-specific APIs that lack mature community modules, or when frame-perfect animation is the primary user value.

Use this as a quick filter to refine your brand image:

For greenfield consumer or enterprise apps, Expo's managed workflow gets you from zero to TestFlight in days. For brown-field React Native adoption, embedding RN screens into an existing native app, the bare workflow gives you the module control you need without a full rewrite.

If your team is working through that call right now, talk to our team, we've shipped React Native products across fintech, retail, and SaaS, and we can tell you quickly whether native modules will block your roadmap or not.