React Native in 2025: Does It Actually Work in Production?

The New Architecture in React Native 0.76+ was supposed to be the holy grail - no more bridge, better performance, fewer crashes. After migrating three production apps to it, here's what actually happened.

The official architecture documentation promises a lot, and early benchmarks from Meta showed impressive improvements. But community reports tell a different story.

JSI: Finally, No More Bridge From Hell

The JavaScript Bridge was React Native's original sin. Every call between JS and native had to be serialized, queued, and batched. It was slower than dial-up internet and twice as frustrating.

JSI replaces this with synchronous calls. Sounds great, right? The JSI documentation and engineering blog posts made it sound revolutionary.

What actually works: Native calls don't block the UI anymore. Getting device info is instant instead of waiting forever. Animations stutter less, especially on Android. Camera libraries like VisionCamera can actually process real-time video without killing performance.

What broke: Half our custom native modules. JSI is picky about data types in ways the old bridge wasn't. The Codegen requirements are strict, and migration guides don't cover edge cases. Spent two weeks debugging why passing a nullable string crashed the app with "TypeError: Cannot read property of null" instead of just handling it gracefully like before.

The debugging nightmare: When JSI crashes, you get C++ stack traces. The debugging documentation doesn't help with native crashes, and Flipper integration becomes hit-or-miss. Good luck reading those at 3am when the app store review is due tomorrow.

Fabric: The Renderer That Sometimes Works

Fabric was supposed to make everything smooth as butter. React 18's concurrent features on mobile! Native performance! The Fabric renderer deep dive promises synchronous layout and useLayoutEffect support.

Reality check: It works great... until it doesn't. List performance is legitimately better - 60fps scrolling through thousands of items actually works now. The automatic batching and concurrent rendering features do help. But then you hit edge cases that GitHub issues barely document.

Real example: Had this one screen that worked fine on the old renderer. After Fabric, it would randomly freeze for a few seconds. No crash, no error, just frozen UI. Users would tap frantically and nothing would happen. Turns out we had a FlatList nested inside a ScrollView that Fabric didn't like. Spent forever figuring this out because the app would work fine 90% of the time.

Migration pain: Converting custom components to Fabric isn't just changing imports. The layout calculation system is completely different. Components that used to work fine now have weird spacing issues or don't render at all. The component migration guide helps, but community libraries are still catching up.

TurboModules: Lazy Loading That's Not So Lazy

TurboModules load native code on demand instead of at startup. Great idea in theory. The TurboModule specification and lazy loading benefits sound promising.

What improved: Apps do start faster. My test app went from taking forever to boot to being usable in under 2 seconds on older Android phones. Startup feels snappier overall.

What got complicated: Debugging. When a TurboModule fails to load, you get cryptic errors like "TurboModuleRegistry.get('RNSomeModule') returned null". Was the module not installed? Not linked? Wrong version? The troubleshooting guide doesn't cover half these scenarios, and community debugging tips are scattered across GitHub discussions.

Library hell: Half the libraries don't work with TurboModules yet. react-native-camera is dead. react-native-maps sometimes works. react-native-vector-icons crashes on random Android versions. You'll spend hours finding libraries that actually work with the new architecture.

The Migration Reality: Weeks, Not Days

"Just enable the new architecture" they said. "It'll be easy" they said.

Week 1: Enabling the flags and watching 40% of the app break in exciting new ways.

Week 2: Hunting down library incompatibilities. Some have new architecture versions, some don't, some claim to work but crash mysteriously.

Week 3: Debugging performance regressions. Turns out JavaScript-heavy screens actually got slower because JSI has overhead for complex data structures.

Week 4: Fixing platform-specific crashes that only happen on certain Android versions or iOS devices we didn't test on.

Pro tip: Don't believe anyone who says they migrated in a day. They either have a trivial app or they're lying.

What Actually Ships in Production

Discord: Still using React Native across iOS and Android since they unified on it in 2022. Their engineering blog details the custom tooling they built, but they have an army of 50+ mobile engineers and custom performance monitoring most of us don't have access to.

Microsoft Office: Uses React Native for parts of their mobile app, detailed in their technical case study. But notice how the performance-critical features like document editing are still native? The Office mobile architecture keeps RN for UI, native for heavy lifting.

Instagram: Meta's own app uses React Native for specific screens, not the whole app. Their React Native at Meta blog shows they're selective about where they use it. If Meta won't bet their flagship product entirely on React Native, what does that tell you?

Other production examples: Shopify's mobile app, Bloomberg's consumer app, and Walmart's grocery app all use React Native strategically, not universally. Check the React Native showcase for more examples and their specific use cases.

The New Architecture is better, but it's not magic. It fixes some problems and creates new ones. Whether it's worth the migration pain depends on how much you're willing to debug and how much time you have. The migration timeline estimates from the working group are optimistic at best.

Here's what nobody tells you about React Native in production: the problems aren't the ones in the documentation. They're the weird edge cases that happen when real users do unpredictable shit with your app. The production debugging guide barely scratches the surface, and error reporting tools only catch crashes, not performance degradation.

The Performance Lottery: 90% Great, 10% Hell

Most of your app will feel fine. Then you'll hit that one screen that randomly stutters, and you'll spend three weeks figuring out why.

Example that ate my weekend: Feed screen worked great in development - smooth 60fps scrolling, looked perfect. Shipped to production and it started stuttering like crazy, but only on some user devices.

The problem? Long usernames. Some user had a name that was like 50 characters with emojis and unicode, and the text rendering choked hard. The old renderer would just drop a few frames. Fabric completely locked up for 2-3 seconds while trying to calculate text layout. Users thought the app crashed.

Fix: Had to add text truncation and pre-calculate text sizes. Also cache everything because text measurements are apparently expensive as hell. Spent more time fixing this one stupid edge case than building the entire feed feature.

Memory Leaks: The Silent App Killer

React Native doesn't manage memory like you think it does. Components unmount but their native counterparts stick around. Images cache forever. Navigation libraries hold onto screens. The memory profiling guide shows the tools but not the real problems you'll face.

Memory nightmare: App would crash after 10-15 minutes of normal use. Memory would climb from 80MB to 400MB and then Android would just kill it. No warning, no graceful degradation, just dead.

The problem: Images in FlatList. Every image that loaded stayed in memory forever, even after scrolling way past it. removeClippedSubviews prop did nothing. Image caching is completely broken and the docs don't explain how it actually works.

Fix: Built a custom image component that manually unloads images when they go off-screen. Had to track scroll position, calculate visible bounds, and force garbage collection. The app uses normal memory now but the codebase is a mess of workarounds. Still not sure why this isn't built into FlatList.

Library Hell: Dependency Roulette

You know what's fun? When a library update breaks your app in a way that only happens on Tuesday afternoons.

react-native-video nightmare: Updated from 5.2.1 to 6.0.0 and videos stopped working. But not on all devices - just Samsung phones running Android 11 with certain security patches. So it worked fine in testing but failed for random users in production.

Debugging hell:

1. Assumed it was our video files - spent a week re-encoding everything
2. Thought it was our implementation - rewrote the video component from scratch
3. Tried different video formats - converted everything to different codecs
4. Finally found an obscure GitHub issue buried deep in the search results

Solution: Downgraded back to 5.2.1 and pinned the version. The new version might be "stable" but it randomly fails. Still using the old version because I can't afford to spend another week debugging video playback.

Platform-Specific Nightmares

Write once, debug everywhere. Here's the Android/iOS bullshit you'll deal with:

iOS quirks that will make you drink:

• Text input loses focus when you navigate and come back
• Images load fine in simulator, crash on device with "memory pressure"
• App works in development, white screen in production because of some Metro bundler edge case
• Push notifications work until the app is backgrounded for more than 2 minutes

Android quirks that will make you question life choices:

• Back button handling that changes between Android versions
• Keyboard pushes content off-screen differently on every device
• Build fails on CI but works locally because of case-sensitive file names
• App crashes on launch after updating target SDK version, no error message

The New Architecture Gotchas

The New Architecture fixes old problems and creates exciting new ones:

JSI crashes with cryptic errors: "RCTBridge required dispatch_sync to load RCTDevLoadingView. This may lead to deadlocks." Cool, which of my 47 libraries is causing this?

TurboModule linking issues: Works in debug, crashes in release. The error message? "TurboModuleRegistry.get('SomeModule'): null is not an object." Thanks, super helpful.

Fabric layout bugs: Components randomly don't render or render in the wrong position. The fix is usually to wrap everything in an extra View with specific flex properties that make no sense.

Real Company Stories (Not The Marketing Bullshit)

Discord: Uses React Native since 2022 for both platforms. They make it work because they have 50+ mobile engineers and custom tooling. Your team of 3 developers doesn't have their resources.

Shopify: Their React Native success comes with a massive caveat - they rewrote most of React Native's core components and maintain their own fork. That's not "React Native worked great," that's "we replaced React Native with our own framework."

Facebook/Meta: Instagram uses React Native for some screens. Notice how the main feed, stories, and messaging are all native? The parts that actually matter for user engagement? Yeah, those aren't React Native.

What Nobody Budgets For

Debugging time: Plan for 30% more debugging than native development. Platform-specific issues are harder to track down when they go through JavaScript first.

Upgrade tax: Every React Native upgrade is a project. Libraries break, APIs change, platform integration needs updates. Budget a sprint every 6 months just for upgrades.

Custom tooling: You'll end up writing shell scripts for:

• Cleaning Metro cache when shit breaks
• Resetting iOS simulator when it gets confused
• Automating the 5-step process to fix Gradle after a dependency update
• Converting platform-specific assets because React Native can't handle them

The Bottom Line

React Native works when you accept its limitations and work around them. It doesn't work when you expect it to be native development with JavaScript syntax.

If you've got experienced React developers and you're building a business app that doesn't need cutting-edge performance, React Native will probably save you time. If you're building anything performance-critical or your team is new to mobile development, you're signing up for pain.

After three app launches with React Native, here's what I actually think: it works for some stuff, sucks for others.

The showcase page only shows success stories

• they don't mention the apps that got rewritten in native after months of fighting performance issues.

React Native Is Good At Some Things

Shipping business apps quickly: If you're building a typical CRUD app with forms, lists, and basic navigation, React Native will get you there faster than going native.

The component reuse is real, and hot reload actually works most of the time.

Keeping one team instead of two: Not having separate iOS and Android teams is genuinely nice.

Your React developers can ship features to both platforms without learning Swift or Kotlin. That's worth something.

Iterating fast: When you need to A/B test features or push quick updates, React Native's flexibility is helpful. CodePush lets you fix bugs without app store reviews, though Apple's guidelines restrict what you can update. Over-the-air updates from Expo provide similar capabilities.

React Native Sucks At Other Things

Anything performance-critical: Games, real-time graphics, heavy image processing

• forget it.

The Java

Script overhead will kill you. Even with the New Architecture, you're still running JS on top of native.

Deep platform integration: Want to use that cool new iOS 18 feature or Android 15 capability?

Hope someone made a React Native library for it.

Want to customize the camera experience? Good luck, you're writing native modules anyway.

The native module creation guide assumes you know both React Native and native development.

Predictable development timelines: "This should be easy in React Native" becomes "Why did we spend three weeks debugging this Android-specific crash?" more often than you'd like.

When React Native Makes Sense

Use React Native if:

• Your team already knows React well
• You're building a standard business app (not pushing any boundaries)
• You value shipping speed over perfect performance
• You're okay debugging weird cross-platform issues
• You have at least one person who understands mobile platforms

When To Just Go Native

Skip React Native if:

• Performance matters more than development speed
• You're doing anything graphics-heavy or real-time
• Your team is new to mobile development
• You need cutting-edge platform features
• You prefer predictable problems over exciting new ones

The Real Talk on Costs

React Native might save money up front.

You ship faster, need fewer developers, can iterate quickly.

But you'll pay later:

• Endless library maintenance headaches
• Debugging weird platform-specific crashes
• Performance tuning that needs native knowledge anyway
• Rewriting everything when you hit React Native's limits

My Actual Recommendation

For typical business apps with experienced React teams: Yeah, use it. You'll ship faster and the performance trade-offs probably don't matter for your use case.

For anything else: Just go native. The pain you'll save yourself is worth the extra development time.

The 2025 React Native Reality

The New Architecture fixed some problems and created others. JSI eliminated the bridge bottleneck but introduced new crash types that native debugging tools struggle with. Fabric improved list performance but made layout debugging harder

• layout inspection tools work differently now. TurboModules speed up startup but complicate library integration with new compatibility requirements.

It's better than old React Native, but it's still React Native. The fundamental trade-offs haven't changed: faster development in exchange for less predictable performance and more debugging complexity. Performance benchmarks show improvements, but real-world results vary wildly based on your specific use case.

What Nobody Tells You

The 90/10 rule is real: 90% of your app will work fine.

That other 10% will consume 50% of your debugging time.

Library roulette never ends: Every dependency update is a gamble.

Something will break in a way that only affects Samsung Galaxy S21s running Android 12 with the March security patch.

Platform differences multiply: "Write once, run anywhere" becomes "Write once, debug everywhere." Android and i

OS handle things differently, and React Native can't always hide that from you.

Final Score

React Native in 2025: Good enough for basic apps, will frustrate you for anything complex.

If you've only built simple React Native apps, this probably sounds harsh. If you've debugged memory leaks at 3am or spent a week figuring out why video playback fails on Samsung phones, you know I'm being generous.

Use React Native for boring business apps where your team already knows React. Skip it for anything performance-critical or if your team is new to mobile.

Simple business app + React team = Use React Native
Anything else = Just write native code