The migration question that comes up at year three

Migrating from React Native to native iOS and Android is one of the most expensive engineering decisions a mobile team can make. Two to three years into a React Native codebase, teams often hit a wall: performance is plateauing, hiring is harder, and the framework upgrades hurt. The migration question lands on someone's desk. This post is the framework we use when clients ask us if they should rewrite.

Signal 1: Performance budget broken consistently

React Native performance has improved significantly since the New Architecture rollout. Most business apps run fine on the JS engine plus Reanimated. The performance signal that justifies a migration is consistent failure to hit your performance budget on low-end devices, especially around list virtualization, animation jank, and cold start time. If you have profiled, tried Hermes plus Reanimated 3, optimized image pipelines, and the p95 still misses the budget, native is on the table.

Signal 2: Native module sprawl

When the React Native side of your codebase is 30% native modules wrapping platform features, the framework is no longer paying for itself. You are maintaining bridges across two languages on each side of the JS-to-native boundary. The maintenance cost of those bridges compounds over time. If you find your team rewriting native module bindings every quarter, the framework is fighting you.

Signal 3: Hiring friction

React Native hiring is harder than it was three years ago. Senior React Native engineers with mobile platform experience (not just web background) are rare. If you cannot hire enough people to maintain the app at the velocity you need, native is a recruiting argument. Senior native engineers exist in much larger numbers in most markets.

Signal 4: Platform features you cannot reach

App Clips, HealthKit, Live Activities, ARKit, advanced widgets, Watch app integration, CarPlay, deep audio work — these surfaces are reachable from React Native through native modules, but each one is a project. If your roadmap requires three or more of these platform-specific features in the next year, the cost of native modules adds up to roughly the cost of a partial native rewrite.

Signal 5: Team structure mismatch

React Native teams often have a web background. As the app matures and the platform surfaces it touches expand, the team needs more platform expertise. If your roadmap is no longer dominated by screens, forms, and lists, the team structure question is real.

The migration paths that actually work

A full rewrite from scratch is rarely the right move. Three paths we have used successfully: shared business logic via Kotlin Multiplatform with native UIs (best for serious B2C); strangler-pattern migration where new screens go native and existing screens stay React Native (best when the team is mixed); and a clean native fork that runs in parallel for six months while React Native is maintained, then a final cutover (best when the existing app is small).

The path that does not work: pausing all feature work for a year to rewrite. The business does not survive the freeze.

Migration cost estimate

For a mid-sized React Native app (50-80 screens, moderate native module usage), a parallel native rewrite costs 60-70% of the original build cost. Reused: backend, design system, business logic specifications, content. Replaced: every line of UI code, navigation, state management, platform integrations.

When to keep React Native

If the app is mostly screens and lists, performance is acceptable, the team is happy, and the roadmap does not require deep platform integration, keep it. Framework migration is one of the most rewriting-intensive moves an engineering team can make, and the right answer is often "not yet".

The decision is rarely about React Native being wrong. It is about whether the roadmap and team structure have moved past what cross-platform pays back. Re-evaluate annually and migrate when the signals are clear, not when fashion changes.