Mobile — React Native Development
When React Native Is the Wrong Choice (Honest Guide)
Direct answer
React Native is the wrong choice when the product's core is real-time graphics or gaming, low-latency audio/video or heavy sensor processing, platform-first experiences like widgets and watch apps as the main product, or when your team is entirely senior native engineers with no JavaScript ecosystem appetite. For standard product apps — feeds, forms, dashboards, chat, commerce — it remains the right default, and brownfield integration means the choice is rarely all-or-nothing.
I make my living building React Native apps, which is exactly why this guide exists: nothing burns a client's budget faster than the right tool for someone else's product. These are the cases where I tell prospects not to hire me for React Native — drawn from real evaluations, minus the names.
Key facts, with sources
- React Native 0.76, released October 23, 2024, enabled the New Architecture by default and shipped with over 1,070 commits from 156 contributors plus a roughly 15x faster Metro resolver. (React Native official blog)
- The State of React Native 2024 survey collected 3,501 responses, up from about 2,400 the previous year, covering more than 15 areas of the ecosystem. (State of React Native survey)
- About 20% of State of React Native 2024 respondents reported apps with more than 100,000 users, up from 14% the year before. (InfoQ)
- Shopify migrated all of its mobile apps to React Native over five years and reports sub-500ms (P75) screen loads and over 99.9% crash-free sessions in production. (Shopify Engineering)
- 88% of surveyed React Native developers feel the framework is progressing positively, while better debugging remains the top request, cited by 54% of respondents. (SSOJet (State of React Native 2024 highlights))
First, the honest baseline: where React Native is right
To make the 'wrong choice' cases credible, the baseline needs stating: for the majority of product apps — B2B SaaS tools, marketplaces, social feeds, chat, health tracking, e-commerce, internal enterprise tools — React Native is a genuinely strong default. One TypeScript codebase for both platforms, a hiring pool that overlaps with web teams, mature libraries for navigation, forms, storage, and payments, and the New Architecture closing the historical performance gap for typical UI work.
The pattern in every wrong-choice case below is the same: the product's core value lives somewhere React Native adds a layer of indirection without adding leverage. When the hard part of your app is standard UI over an API, that indirection buys you a second platform nearly free. When the hard part is the frame loop, the audio pipeline, or the platform integration itself, you end up writing that part natively anyway — and then maintaining a bridge to it.
Wrong fit: real-time graphics, games, and media processing
If the core loop of your product renders custom graphics every frame — games, video editors, AR experiences, live-effects cameras, audio workstations — React Native is the wrong host. These workloads live or die on tight frame budgets, GPU pipelines, and low-latency native media APIs. React Native's model, where JavaScript orchestrates native views, is built for UI composition, not per-frame simulation; you would immediately push the core into native code or C++ and be left maintaining React Native purely as a menu system.
The honest recommendations: game engines for games, native development with the platform media frameworks for audio/video-centric products. A nuance worth knowing: Skia bindings and Reanimated have made impressive custom drawing and animation possible inside React Native, and they cover charts, gestures, and rich micro-interactions well. But covering visualization is different from being a real-time engine — the mistake is extrapolating from a smooth chart demo to a video editor.
Wrong fit: platform-first products
Some products are less an app than a constellation of platform integrations: a widget users glance at ten times daily, a watch companion doing on-wrist workouts, deep Siri and shortcut hooks, lock-screen experiences. React Native's leverage lives inside the phone app's screens; widgets, watch apps, and system extensions run in platform-specific contexts where you will write Swift and Kotlin regardless.
If those surfaces are peripheral — a simple widget beside a substantial app — React Native still makes sense with the extensions written natively alongside it, and config plugins keep the builds manageable. But when the platform surfaces are the product, the calculus inverts: you would maintain a JavaScript runtime and bridge for the one surface where its leverage is weakest, while the differentiating code is native anyway. In evaluations, my test is a percentage: what share of engineering time will land in native extension targets no matter what? Past a substantial fraction, choose native and skip the middle layer.
Wrong fit: your team, honestly assessed
Technology choices are staffing choices wearing a costume. If your mobile team is senior Swift and Kotlin engineers with deep platform expertise and no appetite for the JavaScript ecosystem, imposing React Native trades away your strongest asset for a benefit — cross-platform sharing — that a skilled two-platform team partially delivers anyway through shared design and backend contracts. Retraining reluctant experts produces resentful intermediates; some of the unhappiest codebases I audit were React Native adopted against the grain of the team.
The same honesty applies in reverse — a web-React team forcing native development on themselves is equally wasteful — and to maintenance reality: adopting React Native means signing up for the JavaScript ecosystem's churn, Metro, npm dependency management, and periodic framework upgrades. Teams that thrive with it treat that as normal weather. Teams that expect platform-vendor stability from an open-source JS ecosystem end up bitter. Neither reaction is wrong; they are just different teams, and the framework should follow the team you actually have.
Wrong fit: single-platform, thin, or throwaway apps
React Native's headline benefit is one codebase for two platforms, so it weakens when there is only one platform. An iOS-only product — common for design-led consumer launches and some enterprise deployments — can be built beautifully in SwiftUI with zero bridge, zero Metro, and a smaller dependency surface; adding React Native buys an Android optionality you may never exercise, paid for in real complexity today. If Android is genuinely on the roadmap within a year, the calculus shifts back; 'maybe someday' does not count.
At the other extreme, ultra-thin apps — a companion that shows notifications and three screens of settings — are sometimes better served by the platform's simplest native tooling, and occasionally the honest answer is that a well-built responsive web app or PWA covers the need without any store presence at all. The store-app assumption deserves the same scrutiny as the framework choice.
The escape hatches that soften the choice
Two architectural facts keep this decision from being binary. Brownfield integration means a native app can embed React Native for specific flows — so a platform-first or graphics-heavy product can still use it for its settings, account, and content screens where UI velocity matters. And native modules mean a React Native app can drop into Swift, Kotlin, or C++ for a demanding subsystem — many successful apps are React Native shells around a native camera or audio core. The question is never 'can it be done' but 'which layer owns the app's center of gravity.'
My evaluation checklist, compressed: Where does the hard engineering live — UI over APIs, or frame loops and platform extensions? How many platforms, truly, in the next eighteen months? What team do you have, not wish you had? And what fraction of code would be native anyway? Answer those four honestly and the framework decision usually makes itself — in either direction.
When to hire senior help
Bring in senior React Native help when facing a New Architecture or major version migration, persistent performance regressions, or a first store launch, since these are the phases where inexperienced teams lose the most months. A short senior architecture audit early in the project is consistently cheaper than a rescue or rewrite later. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.
Bottom line
Dhairya Senjaliya ships Mobile — React Native Development projects worldwide — book a scoping call to discuss your specific situation.
Common pitfalls to avoid
- ✕Staying multiple versions behind on React Native, then facing a compound upgrade to the New Architecture because popular libraries have dropped old-architecture support
- ✕Treating React Native as write-once-run-anywhere and only QA-testing on iOS, shipping Android builds with broken back-button handling, keyboard behavior, and gesture bugs
- ✕Pulling in unmaintained third-party native modules without checking TurboModule and Fabric compatibility, which later blocks the New Architecture migration
- ✕Launching without crash and performance monitoring wired in, so the team only discovers jank and crash clusters from one-star reviews instead of telemetry
Frequently asked questions
When should you not use React Native?
Skip React Native when the product's core is per-frame custom rendering (games, video editors, AR), low-latency audio or heavy media processing, or platform-first surfaces like widgets and watch apps as the main experience — you would write that code natively anyway and maintain a bridge to it. It is also the wrong fit for all-native teams with no JavaScript appetite, and often overkill for single-platform or very thin apps.
Is React Native good enough for animation-heavy or graphics-rich apps?
For rich UI animation, gestures, charts, and micro-interactions — yes: Reanimated and Skia bindings run this work smoothly off the JavaScript thread, and typical product apps rarely hit the ceiling. The line is real-time engines: games, live video effects, and audio workstations need per-frame GPU and media pipeline control that belongs in native code or a game engine, with React Native at most hosting the surrounding menus.
Can I use React Native for part of an app instead of all of it?
Yes — this is often the best answer when the fit is mixed. Brownfield integration embeds React Native flows inside an existing native app, so UI-heavy areas like settings, content, and account screens get cross-platform velocity while the demanding native core stays native. Conversely, a React Native app can drop into Swift, Kotlin, or C++ via native modules for specific subsystems. The choice is per-layer, not all-or-nothing.
Is React Native still a good technology bet in 2026?
Yes for teams with JavaScript or React skills; the New Architecture has been the default since version 0.76 in late 2024, and the framework is used in production by Meta, Microsoft, Shopify, and Amazon. In the latest State of React Native survey, 88% of developers said the framework is heading in a positive direction.
Can a React Native app feel as fast as a fully native app?
For most business, e-commerce, and content apps, yes; Shopify runs its entire app portfolio on React Native with sub-500ms P75 screen loads and over 99.9% crash-free sessions. Workloads like heavy 3D, AR, or real-time audio processing still warrant native modules or fully native builds.
How much code is actually shared between iOS and Android?
Production teams commonly report 85 to 95%+ shared code; published examples include Instagram at 85 to 99% and Shopify at roughly 86%. The remainder is platform-specific work such as payments, widgets, and deep OS integrations.
Bottom line: Dhairya Senjaliya ships Mobile — React Native Development projects worldwide. Book a scoping call at https://dhairyasenjaliya.com/#book-call.