React Native New Architecture: What Actually Changed When We Migrated

We just finished migrating our first production React Native app to the New Architecture. After weeks of anticipation, we expected dramatic performance improvements and breakthrough features. What we got was more nuanced: some genuine wins, several unexpected compatibility issues, and a clearer understanding of when this upgrade actually matters.

React Native 0.82, released October 8th, 2025, is the first version running entirely on the New Architecture. The old "bridge" is gone, replaced with direct JavaScript-to-native communication through JSI (JavaScript Interface). On paper, this promises faster rendering, reduced memory usage, and smoother animations. In practice, the results depend heavily on what your app actually does.

Here's what we learned migrating a real production app—including the performance metrics we measured, the libraries that broke, and the decision framework we're now using for client projects.

Why the New Architecture Matters (And Why It Might Not)

The React Native team has been working toward this architecture for years. The core promise: eliminate the asynchronous bridge that previously sat between JavaScript and native code.

What changed under the hood:

JSI (JavaScript Interface) - Direct synchronous access to native modules, no more async bridge
Fabric renderer - New rendering system with better support for concurrent features
Turbo Modules - Lazy-loaded native modules that initialize only when needed
Codegen - Type-safe JavaScript-to-native interfaces generated at build time
Hermes V1 - Rewritten JavaScript engine optimized for the New Architecture

For apps with heavy native module usage (camera, maps, complex animations), these changes can be transformative. For simpler apps that mostly render lists and forms, the benefits are less pronounced.

What We Actually Measured

We migrated a mid-complexity app: e-commerce functionality with product browsing, real-time inventory updates, payment processing, and push notifications. About 15,000 lines of JavaScript, 8 third-party native modules.

Performance benchmarks (iPhone 13, Android Pixel 6):

iOS Results

App launch (cold start): 1,840ms → 1,520ms (17% faster)
Screen navigation: 180ms → 145ms (19% faster)
List scrolling (60fps maintained): 73% of frames → 89% of frames
Memory usage (peak): 142MB → 128MB (10% reduction)

Android Results

App launch (cold start): 2,340ms → 1,780ms (24% faster)
Screen navigation: 245ms → 180ms (27% faster)
List scrolling (60fps maintained): 61% of frames → 84% of frames
Memory usage (peak): 187MB → 159MB (15% reduction)

The Android improvements were more dramatic, which tracks with what the React Native team has been saying: Android was more constrained by the old bridge architecture.

Where we saw the biggest impact:

Complex animations (particularly gesture-driven interactions)
Rapid screen transitions
Large list rendering with images
Real-time updates from WebSocket connections

Where we barely noticed a difference:

Simple form screens
Static content pages
One-off API requests

The Migration Process (And What Broke)

The official migration guide makes it sound straightforward: upgrade to 0.82, enable New Architecture, rebuild. Reality was messier.

Phase 1: Dependency Audit (3 hours)

We maintain a spreadsheet of every native module we use. Before touching anything, we checked each one's compatibility with the New Architecture.

Immediate red flags:

react-native-camera - No New Architecture support (switched to react-native-vision-camera)
react-native-maps - Partial support, required upgrade to v1.8+
@react-native-firebase - Required v20+ for full compatibility
Custom native module - We had a legacy in-app review module that needed complete rewrite

Out of 8 native dependencies, 3 required upgrades, 1 needed replacement, and 1 required custom code changes.

The lesson: Budget 30-50% of migration time just for dependency wrangling.

Phase 2: Enable New Architecture (30 minutes)

This was the easiest part. Updated the config in both ios/Podfile and android/gradle.properties:

iOS (Podfile):

# Enable New Architecture
ENV['RCT_NEW_ARCH_ENABLED'] = '1'
 
# Update to React Native 0.82
pod 'React', :path => '../node_modules/react-native/'

Android (gradle.properties):

# Enable New Architecture
newArchEnabled=true
 
# Enable Hermes
hermesEnabled=true

Then rebuild:

# iOS
cd ios
pod install
cd ..
npx react-native run-ios
 
# Android
npx react-native run-android

The first build took 12 minutes on iOS (compared to 3-4 normally) because Xcode had to recompile everything with the new architecture. Subsequent builds were back to normal speed.

Phase 3: Fix Breaking Changes (8 hours)

This is where the real work happened.

1. Native Module API Changes

Our custom in-app review module used the old NativeModules API:

Before (Legacy Architecture):

import { NativeModules } from 'react-native';
const { InAppReview } = NativeModules;
 
export const requestReview = () => {
  InAppReview.requestReview();
};

After (New Architecture with Turbo Modules):

import { TurboModuleRegistry } from 'react-native';
 
export interface Spec extends TurboModule {
  requestReview(): Promise<boolean>;
}
 
export default TurboModuleRegistry.getEnforcing<Spec>('InAppReview');

We also had to update the native iOS and Android implementations to conform to the Codegen spec. This wasn't documented well—we cobbled together examples from React Native core modules and community libraries.

2. Removed PropTypes

The New Architecture enforces TypeScript types through Codegen. PropTypes no longer work. We had about 40 components still using PropTypes:

// This broke in New Architecture
MyComponent.propTypes = {
  title: PropTypes.string.required,
  onPress: PropTypes.func,
};

We converted everything to TypeScript interfaces. Annoying, but probably overdue.

3. ViewPropTypes Removed

Several custom components used ViewPropTypes for style inheritance:

// This no longer exists
import { ViewPropTypes } from 'react-native';
 
MyComponent.propTypes = {
  style: ViewPropTypes.style,
};

Fix:

import { ViewStyle } from 'react-native';
 
interface MyComponentProps {
  style?: ViewStyle;
}

4. Concurrent Rendering Edge Cases

The new Fabric renderer supports React 18 concurrent features, which exposed some race conditions in our state management. We use Zustand, which handled it fine, but we had one screen with manual subscriptions to native events that needed refactoring.

The problem: event listeners weren't cleaning up correctly during fast screen transitions. Fixed by ensuring cleanup in useEffect return functions and using AbortController for async operations.

Library Compatibility: The Reality Check

Here's what we had to deal with:

Worked immediately:

✅ React Navigation (v6.3+)
✅ Zustand (state management)
✅ React Query (data fetching)
✅ React Native MMKV (storage)
✅ Reanimated (v3.6+)

Required updates:

⚠️ Firebase (v18 → v20, breaking config changes)
⚠️ Maps (v1.3 → v1.8, API changes)
⚠️ Permissions (v3.x → v4.x)

Needed replacement:

❌ react-native-camera (unmaintained) → react-native-vision-camera
❌ AsyncStorage (deprecated) → MMKV

Required custom work:

🔧 Our legacy in-app review module
🔧 Custom native event listeners

The migration would have been significantly easier if we'd been on the latest versions of everything beforehand. Lesson learned: keep dependencies current even when things are working fine.

When Should You Migrate?

After this experience, we've developed a decision framework for client projects:

Migrate Now If:

You're starting a new app - No migration pain, all upside
Your app is animation-heavy - Gesture-driven UIs, complex transitions, gaming elements
You have performance problems - Especially on Android, especially with list rendering
You're already on React Native 0.75+ - The gap is smaller, dependencies likely compatible
Your dependencies are well-maintained - Check GitHub activity, New Architecture support

Wait If:

You rely on unmaintained libraries - They won't get New Architecture support
You're on React Native 0.71 or earlier - Too big a jump, too many breaking changes
Your app is stable and performant - "If it ain't broke" is valid here
You don't have 1-2 weeks for migration - It takes longer than you think
You use lots of custom native modules - Each one needs individual attention

Our General Advice:

For new projects, absolutely use the New Architecture. For existing projects, assess based on pain points. If your app scrolls smoothly and launches quickly, there's no urgent reason to migrate. If you're fighting performance issues, it's worth the effort.

Migration Timeline & Costs

For transparency, here's what it actually took us:

Total time: 12 days

Dependency research & planning: 1 day
Dependency updates & testing: 3 days
Custom native module rewrites: 4 days
Migration & build config: 1 day
Bug fixes & edge cases: 2 days
QA & final testing: 1 day

Team: 2 developers (one focused on native modules, one on JavaScript/React layer)

Budget estimate for client work:

Small app (< 10 screens, few native modules): 3-5 days
Medium app (20-30 screens, typical dependencies): 1-2 weeks
Large/complex app (40+ screens, custom native code): 2-4 weeks

Add 30% if you're more than 2 versions behind on React Native.

Real-World Benefits We're Seeing

Three weeks post-migration, here's what users are noticing:

Measurable:

App Store review sentiment improved (4.1 → 4.4 stars)
"Smooth animations" mentioned in 8% of recent reviews (previously 2%)
Crash rate down 15% (fewer memory-related crashes on older Android devices)

Anecdotal:

Product images load visibly faster in grid views
Search feels snappier (real-time filtering)
Push notification handling is more reliable

What users don't notice:

Architecture changes (obviously)
Faster initial render (too subtle)
Memory reductions (invisible unless they're comparing side-by-side)

The improvements are real but incremental. This isn't a night-and-day transformation—it's a solid 20-30% improvement in overall perceived performance.

Common Gotchas & How to Avoid Them

Things that caught us off guard:

1. iOS Build Cache Issues

After enabling New Architecture, our iOS builds kept failing with cryptic Xcode errors. Solution: completely clean rebuild.

cd ios
rm -rf Pods Podfile.lock
pod deintegrate
pod install
cd ..
rm -rf ~/Library/Developer/Xcode/DerivedData/*
npx react-native run-ios

2. Metro Bundler Needed Reset

The first few times running the app, Metro cached old module resolution. Always run:

npx react-native start --reset-cache

3. Hermes Debugger Changes

Chrome DevTools debugging works differently with Hermes V1. We switched to Flipper for better debugging experience with the New Architecture.

4. Android Gradle Sync Issues

Our Android build failed initially because Gradle was resolving incompatible versions of React Native dependencies. Fixed with explicit version constraints in android/build.gradle:

configurations.all {
  resolutionStrategy {
    force 'com.facebook.react:react-native:0.82.0'
  }
}

Key Takeaways

Migrating to React Native New Architecture is worthwhile, but it's not trivial:

Performance gains are real - Especially on Android, especially for animation-heavy apps
Library compatibility is the hardest part - Budget most of your time for dependency wrangling
Migration timeline: 1-3 weeks depending on app complexity and custom native code
Start with dependency audit - If key libraries don't support New Architecture, you're stuck
TypeScript becomes mandatory - PropTypes are gone, Codegen requires type definitions
New apps should use it immediately - No reason to start with Legacy Architecture now

For our studio, we'll migrate existing client apps opportunistically—when we have a planned feature update and the dependencies align. For new projects, we're using New Architecture from day one.

Planning a React Native app migration or starting a new project? We've now got production experience with the New Architecture and can help you navigate the transition. Let's talk about your mobile app needs.

We also offer comprehensive mobile app development using React Native and native technologies.