TL;DR: React Native is the right default for most business apps targeting both iOS and Android. The New Architecture (standard since 2024) closed the main performance gap with fully native. A React Native MVP costs $60k–$120k over 8–12 weeks; a standard business app runs $120k–$280k. React Native is the wrong choice for games, heavy on-device ML, and apps where one platform dominates 95%+ of users. The biggest ongoing cost is library maintenance and framework upgrades, not initial development.
What React Native actually is (and what changed in 2024)
React Native is a framework created by Meta that lets you write a single JavaScript or TypeScript codebase that compiles to native iOS and Android UI components. This is the first thing to understand correctly: React Native does not render inside a web view. It maps your React components to the platform's actual native widgets — UIKit on iOS, Android Views on Android — which is why a well-built React Native app is visually indistinguishable from a native one.
For most of React Native's history, the framework used an asynchronous JS bridge to pass messages between the JavaScript thread and the native layer. This bridge was a genuine bottleneck for high-frequency operations: animations that needed to fire at 60 fps, gesture responders that needed sub-10ms latency, and operations that had to be synchronous by nature. The result was occasional jank that careful engineers could work around — but couldn't eliminate entirely.
The New Architecture, which Meta shipped progressively from 2022 and which became the default in React Native 0.74 (2024), replaced that bridge with a synchronous JSI layer. The new renderer, Fabric, communicates directly with the native thread without serialising every call through a message queue. The result is that most of the historical performance arguments against React Native no longer apply to apps built on the current stack.
For our React Native development projects, we've been on the New Architecture since late 2023. The practical difference: gesture-driven animations that previously required a workaround with react-native-reanimated and the native thread now work correctly through the standard gesture system. Layout calculations that previously crossed the bridge synchronously now stay on the native side.
When React Native is the right choice
React Native earns its place in the following situations:
- Business apps with standard UI patterns. Forms, lists, dashboards, navigation, modals, notifications — anything that maps cleanly to native components. The vast majority of B2B and SaaS mobile apps live here.
- You need both platforms at once. If iOS and Android have roughly comparable user bases in your target market, building two native apps means two codebases, two sets of engineers, and two upgrade cycles every time Apple or Google changes their APIs. React Native collapses that to one.
- You already have a React web product. The component mental model is shared, you can reuse business logic, and hiring is straightforward because you're drawing from the same JavaScript talent pool as your web team.
- Content and commerce applications. Catalogs, media players, reading apps, e-commerce storefronts, loyalty programs — all are well-served by React Native's component library ecosystem.
- Frequent iteration cycles. The hot reload development experience, OTA update capability, and unified codebase make React Native faster to iterate than two separate native codebases.
- MVPs and early-stage products. When you're validating a market and want to reach users on both platforms quickly, React Native's time-to-market advantage is real — typically 30–40% faster than building two native apps in parallel.
When React Native is the wrong choice
React Native is not the answer to every mobile problem. Be honest about these scenarios:
- Graphics-heavy applications and games. If you need GPU-bound rendering, real-time 3D, or frame-level control over the graphics pipeline, you want Unity, Unreal, or direct Metal/Vulkan access from native code. React Native cannot help you here regardless of architecture version.
- Heavy on-device ML or computer vision. Core ML on iOS and TensorFlow Lite on Android perform significantly better when called from Swift or Kotlin directly. Running inference through a native module wrapper adds latency and complexity that is hard to justify when you could write the feature natively.
- Deep, cutting-edge platform features. When Apple or Google ships a new API — WidgetKit updates, Dynamic Island interactions, new Bluetooth profiles — React Native's community bindings follow with a lag. If being first with platform features is a competitive differentiator for your product, native is the right tool.
- One platform dominates 95%+ of your users. If your analytics show that 95% of users are on iOS, you are paying a cross-platform tax with almost no cross-platform benefit. Build for iOS natively and add Android later if the distribution shifts.
- Your team is already expert in Swift or Kotlin. The strongest argument for React Native is the shared codebase and the JavaScript talent pool. If your team is already senior in native and has no JavaScript experience, adding React Native means a significant ramp-up cost with no long-term benefit in team size.
- Ultra-low footprint requirements. IoT devices, wearables and embedded targets need runtimes that React Native's JavaScript engine and bridge overhead simply can't fit into. Use native or C/C++.
Cost table: what React Native projects cost in 2026
These are all-in figures for a senior EU nearshore team — the tier that represents the best quality-to-cost ratio for US and EU clients in 2026. US onshore teams run roughly 2.2–2.5x higher for equivalent seniority.
| Project type | Budget range | Timeline | What's included |
|---|---|---|---|
| MVP | $60k–$120k | 8–12 weeks | Core flows, auth, push, analytics, store submission |
| Standard business app | $120k–$280k | 3–5 months | Payments, integrations, offline, backend, GDPR |
| Complex / enterprise | $300k+ | 6+ months | Compliance, native modules, deep integrations, multi-tenant |
What these numbers assume: a senior team (not junior-heavy), proper discovery phase, TypeScript codebase, New Architecture, Expo-managed or bare workflow, and a backend built alongside the app rather than integrated after the fact.
What moves the cost up
Two categories of work reliably push React Native projects past their initial estimates:
Third-party integrations. Every integration that requires a native module — a hardware peripheral, a biometric SDK, a specific payment provider's SDK — requires writing bridging code in Swift and Kotlin in addition to the JavaScript layer. Each native module adds 1–3 weeks of engineering work and is an ongoing maintenance liability. Before scoping a project, audit which integrations require native code and which can be handled by Expo modules or community packages that are actively maintained.
Compliance requirements. GDPR with proper consent management and data mapping: add 2–3 weeks. HIPAA-aligned data flows with encryption, audit logging, and BAA management: add 4–8 weeks and a compliance review. PCI scope: depends on whether you're using a hosted payment form (minimal scope) or handling raw card data (significant scope). Compliance work does not appear in screen counts, which is why comparing quotes without specifying compliance requirements is meaningless.
Savings versus two native apps
The short version: React Native saves roughly one third of the initial build budget compared to building separate iOS and Android apps at the same quality and seniority level.
The saving comes from the shared codebase: business logic, API layer, state management, navigation, and most UI components are written once. The parts that are not shared — native modules, platform-specific gestures, push notification configuration, App Store vs Google Play submission — are a minority of the total work.
The saving shrinks if: your app has many native modules (each one requires platform-specific code anyway); your team needs to hire specialised React Native engineers at a premium; or you make platform-specific design decisions that effectively create two different UIs from the same codebase.
Over a five-year horizon, the comparison shifts. Each year, iOS ships a major OS update in September and Android ships in August. With two native codebases, you run two upgrade cycles. With React Native, you run one RN upgrade cycle plus native module compatibility checks. For most teams, the cross-platform maintenance advantage holds over time — but it requires active investment. A React Native codebase that is not actively maintained diverges from the platform faster than a native one, because it depends on the RN runtime plus the community ecosystem, not just the platform APIs.
Hidden ongoing costs
This is the section most vendor proposals skip. The ongoing cost of a React Native app is often 20–30% of the initial build cost per year, and it breaks down into categories that are easy to miss at the proposal stage:
- Library decay. The React Native ecosystem moves fast. A library that was the community standard for navigation in 2023 may be deprecated or unmaintained by 2025. Auditing and replacing abandoned dependencies is real engineering work that costs time and money, and it tends to surface at the worst moment — when a new iOS release breaks something you haven't touched in two years.
- Framework upgrades. React Native releases new minor versions frequently and a new major version roughly annually. Staying on a supported version is not optional: unmaintained RN versions start accumulating security issues and store-review failures. A typical version upgrade takes 1–3 weeks of engineering time depending on how many native modules need updating.
- Native module maintenance. Every native module in your project has its own release cycle, which may not align with React Native's. When you upgrade RN, some modules lag behind. Keeping them compatible is your engineering team's responsibility unless you pay the module authors (which usually means switching to a supported commercial SDK).
- Platform divergence. iOS and Android evolve independently. A UI pattern that works well on one platform may look wrong on the other after an OS update. Budget for a platform parity review after every major iOS and Android release.
- Cross-layer debugging. When something breaks in a React Native app, the bug may be in the JS layer, the native bridge, the native module, or the device OS. Debugging across layers takes longer than debugging within a single stack. Senior engineers with native experience in addition to JavaScript are not optional for production support — they are a requirement.
Over-the-air updates: what you can and cannot do
One of React Native's most operationally valuable features is OTA (over-the-air) update capability. Because the JavaScript bundle is loaded at runtime, it can be replaced without going through the App Store or Google Play review cycle. In practice this means you can push a bug fix, a UI change, or a content update to 100% of your users in minutes rather than waiting for Apple's typical 24–48 hour review window.
The limits matter, and violating them can get your app rejected or removed from the stores:
- OTA updates must stay within the functionality reviewed in the last store submission. If your app was submitted as a personal finance tracker, an OTA update that adds a social feed is out of scope and violates both Apple and Google policy.
- OTA updates cannot add substantially new functionality. Minor UI tweaks, bug fixes, performance improvements and content changes are fine. Adding a new feature category is not.
- OTA updates cannot change native code. Anything in your native modules, the RN runtime itself, or any binary that was compiled and shipped in the last store submission requires a full store release. OTA reaches the JS bundle only.
The most common OTA use case we see in production: fixing a crash that's at 0.8% of sessions and is causing App Store rating damage, without waiting for store review. Budget for an OTA infrastructure (Expo Updates is the standard in 2026) from the start of the project rather than adding it later.
Already have a React Native app? When to migrate to the New Architecture
If you have an existing React Native app still running on the old async bridge, the migration question is genuine. Here are the signals that indicate you should migrate now rather than defer:
- You're experiencing jank you can't resolve. Gesture-driven animations that drop frames, list scrolling that stutters on mid-range Android devices, or UI updates that visibly lag behind user input — these are classic old-bridge symptoms that the New Architecture resolves at the framework level.
- You're on a React Native version with dropped support. Meta announced that versions below 0.73 are no longer receiving security patches. Running an unsupported RN version in production is a security and compliance risk.
- You've accumulated deferred upgrade debt. If you're more than two major versions behind the current release and you've been deferring upgrades because each one breaks something, the compounding cost of continued deferral is higher than the one-time migration cost.
- You're using old native modules that have not been updated. Many community modules that were built for the old architecture have been unmaintained for 2–3 years. Running them on a modern iOS or Android version is a gamble; they break unpredictably with OS updates.
Migration from the old bridge to the New Architecture is incremental — you don't have to rewrite the entire app at once. Most well-maintained apps can migrate their core navigation and state management in 4–8 weeks of focused engineering work, with the remaining native modules migrated module by module.
The team you need for React Native
This is where proposals often mislead. A React Native project is not just a JavaScript project. The team needs:
- React Native engineers with TypeScript fluency. Not general JavaScript developers who have read the React Native docs. Engineers who have shipped production RN apps and know the difference between a rendering issue in the JS layer and a bridge timeout.
- Native experience on the team. At least one engineer who can write Swift and one who can write Kotlin. You will need to debug native modules, review platform-specific code, and handle the parts of store submission that require native tooling. A pure JavaScript team will get stuck at the first native module.
- Backend engineers. Mobile apps are front-ends. The backend is where business logic, data persistence, authentication, and integrations live. Budget for a backend team alongside the mobile team.
- QA with a device matrix. React Native apps must be tested on real devices across a range of OS versions, screen sizes and manufacturers (Android fragmentation is real). Automated testing on simulators is not sufficient for production release.
- A release engineer or DevOps engineer familiar with Fastlane, EAS Build, code signing, and store submission. The App Store and Google Play submission process is more complex than it looks, particularly for enterprise distribution, TestFlight management, and Android signing key lifecycle.
The 2026 React Native stack
Decisions that were previously architectural debates have largely settled by 2026:
- TypeScript is the default. Not optional, not "we'll add it later." TypeScript-first from day one prevents a class of runtime errors that are expensive to debug on mobile.
- Expo is the standard starting point. The Expo ecosystem (Expo SDK, EAS Build, Expo Updates) has matured to the point where it covers the vast majority of production use cases without the overhead of a fully manual bare workflow. Start with Expo unless you have a specific reason not to.
- Navigation: React Navigation 7 remains the standard. Expo Router (file-based routing built on React Navigation) is now production-ready and is the preferred choice for new projects.
- State management: Zustand or Jotai for simple state; TanStack Query for server state; Redux Toolkit only when you have a specific reason to need its patterns.
- Data fetching: TanStack Query handles caching, revalidation and optimistic updates better than any custom solution.
This is the foundation for a standard mobile app development project in 2026. Deviations are justified case by case — not by preference.
Vendor evaluation: five questions to ask before signing a contract
Most React Native proposals look similar on the surface. These five questions surface the meaningful differences:
- "Show me native code you've written for this platform." A React Native shop that cannot show you Swift and Kotlin they've written is a shop that will get stuck on your first native module requirement. Demand examples.
- "What's your policy on abandoned community libraries?" Every React Native project inherits dependencies that will eventually be abandoned. Does the vendor have a process for identifying and replacing them before they block an upgrade? Or do they discover them when something breaks?
- "How do you handle React Native version upgrades?" The vendor should have a documented process for major version upgrades: testing strategy, native module compatibility check, regression suite, and timeline estimation. "We do it when we need to" is the wrong answer.
- "What does your device testing matrix look like?" Minimum: iOS 16 and 17, three iPhone screen sizes, one iPad; Android 12 and 13, three manufacturer brands (Samsung, Pixel, one mid-range). Simulator-only testing is not acceptable for production release.
- "Who holds the App Store and Google Play accounts?" You should own the developer accounts, the signing certificates, and the provisioning profiles. A vendor who insists on managing these on their own accounts is creating a dependency that will cost you time and money to resolve when the engagement ends.
Our own React Native development practice maintains a native module library, a device farm for testing, and a documented upgrade playbook updated with each new RN release. We also compare React Native against Flutter development and native iOS development or Android development options during discovery, rather than defaulting to the technology we find easiest to sell. If React Native is not the right fit for your specific product, we will tell you before you've committed budget.
FAQ
What is React Native?
React Native is a framework by Meta that lets you write a single JavaScript or TypeScript codebase that compiles to native iOS and Android components. It is not a web view — it renders real native UI widgets. The New Architecture (shipped in 2024 and now standard) replaced the old async JS bridge with a synchronous JSI layer, which closes most of the remaining performance gap with fully native apps.
How much does React Native development cost?
An MVP costs $60k–$120k over 8–12 weeks with a senior EU nearshore team. A standard business app runs $120k–$280k over 3–5 months. Complex projects with deep native integrations, compliance requirements or enterprise backends start at $300k and take 6+ months. React Native typically saves roughly one third of the budget compared to building two separate native apps.
Is React Native slower than native?
For most business applications, no — the difference is imperceptible to users. The New Architecture's synchronous JSI bridge and Fabric renderer resolve the jank issues common on the old bridge. The gap matters mainly for GPU-bound rendering (games, camera filters), on-device ML inference, and apps making very frequent fine-grained native API calls. For content, commerce, dashboards, forms, and most B2B workflows, React Native performance is production-grade.
When should you not use React Native?
Avoid React Native when the app is graphics-heavy or game-like; when you need heavy on-device ML or computer vision; when you need cutting-edge platform features the day Apple or Google releases them; when one platform represents 95%+ of your users; when your team is already expert in Swift or Kotlin with no JavaScript experience; or when the device footprint must be ultra-small.
What can you do with React Native over-the-air updates?
The JavaScript layer can be updated without a store review, which means you can push bug fixes and minor UI changes to all users in minutes. OTA updates must stay within the functionality reviewed in the last store submission, cannot add substantially new functionality, and cannot update native code. Expo Updates is the standard OTA infrastructure in 2026.
Should I migrate my existing React Native app to the New Architecture?
Yes, if you're experiencing jank that can't be resolved, running an unsupported RN version, carrying significant upgrade debt, or using old native modules that break with OS updates. Migration is incremental and most apps can migrate core navigation and state in 4–8 weeks of focused engineering work.
React Native vs Flutter: which should I choose?
Choose React Native if your team knows React or TypeScript, you have a web product to share logic with, or you're hiring from the JavaScript talent pool. Choose Flutter development if you want pixel-perfect UI consistency across platforms or you're targeting beyond mobile (desktop, embedded). Both are production-grade. The decision is primarily about team skills and ecosystem fit.
Get a scoped React Native proposal
We scope React Native development projects with named features, named team and named milestones within 5 working days. No "starting from" pricing, no hourly-rate cards, no technology bias — if custom software development with a different stack is the better answer, we'll tell you that first.
Published 22 August 2026. Based on YuSMP Group project data and 2026 market rates. React Native version references current as of React Native 0.75.
