React Native in Production: Lessons From Real Projects

What I learned shipping React Native apps for enterprise clients: the performance traps, the architecture calls, and what actually matters.

Published 12 August 2026, react-native, mobile, typescript, performance, architecture

I have shipped React Native apps professionally for companies like Serasi Auto Raya, one of Indonesia’s largest auto-fleet companies, and contributed to mobile work at Glovory and Ako Media. Here is what the tutorials do not tell you.

The Promise vs. Reality

React Native’s pitch is compelling: one codebase, two platforms, and your React knowledge carries over. That pitch is mostly true. What it undersells is the work of running a mobile app in production: over-the-air updates, native module compatibility across OS versions, and the discipline it takes to keep performance smooth on mid-range Android devices.

Architecture Decisions That Aged Well

The biggest architectural mistake I see in React Native codebases is coupling navigation logic to state updates. When a user action triggers navigation AND a state change, mixing them creates hard-to-debug flows.

Pattern I use:

// Action dispatched first, navigation is a side effect
dispatch(submitOrder(payload));
// Navigation handled in a saga/effect, not inline

This makes testing much easier, because you can test the state machine without mocking navigation.

TypeScript strict from day one

Starting with "strict": true in tsconfig.json is non-negotiable on mobile projects. The reason: mobile bugs are expensive. A web bug gets a hotfix in minutes; a mobile bug might require a store review cycle. TypeScript catches the category of bugs that are cheap on web and expensive on mobile.

Treat the native layer as a real dependency

Every third-party library that touches native code is a real dependency, not just an npm install. Track them carefully. Test them after every OS version bump. I have been burned by libraries that silently broke on Android 14 and iOS 17.

Performance Traps I Hit

FlatList vs. FlashList

The standard FlatList works fine for lists under ~100 items. Beyond that, on mid-range Android, frame drops become visible. Shopify’s FlashList is a drop-in replacement that performs much better for long lists. Switch early. Retrofitting it into a large codebase is painful.

Bridge overhead on animations

JavaScript-driven animations go through the JS-to-native bridge and will stutter on heavy screens. Use Animated with useNativeDriver: true for transform and opacity animations, and reach for react-native-reanimated for anything more complex. The worklet model in Reanimated 2+ is genuinely excellent.

Image handling

Image from React Native core does not cache. In a feed-heavy app, that wrecks performance. react-native-fast-image (or Expo Image on Expo projects) with proper cache headers from your CDN is not optional. It is essential.

What Actually Matters for Production

Crash reporting before everything else. Sentry for React Native catches JS errors and native crashes. Set it up before you ship a single feature.

Over-the-air updates are a superpower. CodePush (or EAS Update on Expo) lets you push JS bundle updates without a store review. Use it responsibly, only for non-breaking changes, but do use it. Fixing a production bug in hours instead of days is a real competitive advantage.

Test on real devices, not just simulators. Specifically, test on a mid-range Android device (Snapdragon 6xx series). The iPhone simulator and high-end Android emulator lie to you about performance.

Deep link handling is harder than it looks. Plan it early. Universal links on iOS and App Links on Android both require server-side configuration and native setup. Doing this after launch is a pain.

The Honest Tradeoffs

React Native is not the right tool when:

You need highly custom platform-specific UI that diverges significantly between iOS and Android
Your performance requirements are at the level of a camera app or a game
Your team has strong native iOS/Android engineers and no React knowledge

React Native is the right tool when:

Your team already knows React and TypeScript
Your app is primarily data-driven (forms, lists, dashboards, content)
You need to ship on both platforms with a team that cannot afford two separate native codebases

After years of shipping mobile apps, my honest assessment: React Native in 2026 is production-ready, battle-tested, and the right call for most business apps. The rough edges are well-documented and the ecosystem is mature.