Migrating from Native iOS/Android to React Native

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))

Why teams migrate — and who shouldn't

The legitimate driver is almost always the two-codebase tax: every feature specified once and built twice, subtle behavioral drift between platforms, two hiring pipelines, and releases blocked on whichever platform team is behind. When the same company also runs a React web app, consolidation onto one TypeScript-centered stack compounds the payoff — shared types, shared business logic, one on-call rotation that understands the code.

But some teams should not migrate. If your apps are stable, feature-complete, and in maintenance mode, a migration is cost without benefit. If your product's core value is deeply platform-specific — heavy camera pipelines, real-time audio, platform-first experiences like widgets and watch apps — you would be rebuilding your hardest code as custom native modules anyway. And if the motivation is that one influential engineer prefers React, that is a preference, not a business case.

Incremental beats rewrite, nearly every time

The big-bang rewrite fails for a predictable reason: feature parity is a moving target. Your existing apps embody years of edge cases — payment quirks, notification behaviors, accessibility fixes — that no spec captures. A rewrite team chases that target while the legacy apps keep shipping, the gap refuses to close, and leadership eventually faces the choice between launching a worse app or writing off the effort.

The incremental path inverts the risk. React Native embeds inside existing native apps, so you ship one migrated flow inside the app users already have — same icon, same reviews, same analytics. Each ported screen is a small, reversible bet: if the React Native version underperforms, you route users back to the native screen with a flag. The native shell — navigation entry points, push handling, deep links — keeps working throughout, and you delete native screens only after their replacements have proven themselves in production.

Choosing the first flow to port

The first migration target sets the political and technical trajectory of the whole effort, so choose it deliberately. Good first candidates share three traits: low native dependence (forms, lists, settings, content screens — not the camera flow), meaningful enough that success builds organizational confidence (not the licenses page nobody visits), and clear analytics so you can prove parity in crash rates and engagement.

Settings and profile areas are my usual recommendation: real screens with real traffic, almost entirely UI and API calls, and failures there are recoverable. Explicitly avoid starting with your most complex flagship screen to 'prove RN can handle it' — you will be learning the toolchain, the brownfield seams, and the team workflow simultaneously, and stacking maximum difficulty on maximum unfamiliarity is how migrations get cancelled in month three.

The capability audit before you commit

Before anyone writes a timeline, inventory every platform capability your apps actually use: camera and media pipelines, Bluetooth and NFC, background tasks and location, widgets, watch or TV companions, platform payment and identity integrations, and any vendor SDKs. For each, determine whether a maintained React Native library covers it, whether the interop requires a custom native module your team will own, or whether it must simply remain native.

This audit typically reshapes the plan more than any other input. A long tail of well-covered capabilities is a green light. A core feature with no library coverage becomes either a native module project — real but plannable work, and your native engineers are the right authors — or a permanent native island inside the app, which the brownfield architecture happily accommodates. The audit converts the scariest unknown into a costed list, which is exactly what a credible migration plan is built from.

Team and timeline realities

The human transition matters as much as the technical one. Your native engineers are not obsolete — they become the most valuable people on the migration, owning the brownfield seams, the native modules, and the build pipelines, while some of them will happily pick up TypeScript and some will not. Plan for both outcomes honestly rather than assuming universal enthusiasm, and bring in React Native experience early — the brownfield seams and Metro-in-native-build integration are exactly where hard-won experience saves months.

On timelines: expect the full migration of a substantial app to span quarters, not weeks, with the dual-maintenance period — running native and React Native pipelines simultaneously — as the most expensive stretch. The discipline that controls cost is a freeze on building new features twice: once migration starts, new work lands in React Native, and the native codebases enter maintenance-only mode.

Exit criteria and knowing it worked

Define success measurably before you start, because 'it feels done' is how migrations linger half-finished for years. My standard criteria per migrated flow: crash-free rate at parity or better than the native screen it replaced, key funnel metrics unchanged or improved, and startup and interaction performance within agreed budgets on your low-end device tier. Per the overall program: percentage of sessions spent in React Native screens, and the eventual removal of native screen code — deleted, not commented out.

The endgame decision is when to flip the shell: at some point the app stops being a native app embedding React Native and becomes a React Native app with a few native modules, which simplifies builds and unlocks the standard tooling ecosystem. Take that step only after the migrated majority has soaked in production. And keep the final honest option open: if metrics say a specific flow is worse in React Native, let it stay native — the architecture permits it, and shipping the better product beats ideological completeness.

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

Sources

• React Native official blog
• State of React Native survey
• InfoQ
• Shopify Engineering
• SSOJet (State of React Native 2024 highlights)