React Native architecture,React Native architecture,the way engineersevaluate it.the way engineers evaluate it
React Native architecture means understanding what actually happens under a cross-platform app — the New Architecture replacing the old bridge with JSI's synchronous C++ calls, the Fabric renderer, the Hermes engine compiling bytecode ahead of time, and where Expo's managed workflow ends and bare React Native begins. This is what separates an app that feels native from one that janks on real devices.
- New Architecture / JSI
- Fabric renderer
- Hermes engine
- Expo vs bare
Why Entalogics for React Native
Four things every React
Native app development
project actually needs.
Most React Native codebases we inherit still run the legacy bridge — FlatList on 500-item lists, Redux managing everything from server cache to modal visibility, and no OTA pipeline. The New Architecture makes those problems go away, but only when the React Native development company you hire actually builds on it.
The bridge is dead. Build like it.
JSI replaces the async JSON bridge with synchronous C++ calls. Fabric renders concurrent React. Hermes compiles bytecode ahead of time. We build on the New Architecture from the first commit — not as a migration afterthought that ships in version 4.0.
Expo-managed, until bare is genuinely required.
Expo SDK 55 provides full native module access, EAS Build in the cloud, and OTA updates — without ejecting a single file. We go bare only when a native integration genuinely cannot be handled by config plugins. Most React Native apps never reach that point.
Server state and UI state belong in different places.
TanStack Query owns server data. Zustand handles local UI state. MMKV persists preferences fast. Redux stays only when an existing codebase already depends on it and migration costs more than it saves. Less global state means fewer re-renders and a codebase the next React Native developer can actually read.
TypeScript strict, from API contract to navigation param.
Zod validates every API response at the boundary. Expo Router types every navigation param. Design tokens are typed. When the backend changes a field, the React Native app fails to compile — not to render in a real user's hand on a Tuesday morning.
When React Native, when not
React Native
development is a tool.
Not always the answer.
React Native is the fastest path to two app stores from one TypeScript codebase. It's also not native — the abstraction layer is real and it costs something. We'll tell you on the first call whether that trade-off works for your product, without a sales agenda attached to the answer.
PICK REACT NATIVE DEVELOPMENT WHEN
- iOS and Android both need to ship and your team already knows TypeScript — the ramp into React Native is near zero
- OTA updates matter — pushing a JS fix to production without waiting for App Store or Play Store review is a real operational advantage
- The product is data-driven — lists, forms, navigation, API calls — where React Native matches native on feel while beating it on speed and cost
- Sharing logic and types with a Next.js or Node.js web stack is a genuine requirement, not a nice-to-have
CONSIDER NATIVE WHEN
- Deep hardware integration — Bluetooth LE, ARKit, camera pipelines — where the React Native abstraction layer costs more than it saves
- A specific performance surface is non-negotiable and every runtime layer adds measurable latency
- You only need one platform and the budget supports a focused native team without cross-platform overhead
WE SAY NO WHEN
- "React Native because we already know React." Knowing React is necessary but not sufficient for mobile — we won't take the work and pretend otherwise.
- "Wrap our website in a WebView and ship it to both stores." That's not React Native development, and Apple and Google will both reject it.
- "Two app stores in three weeks with no design." That ship has sailed.
Under the hood
The parts of React Native
that decide how an app feels.
Six layers of the framework, and what each one changes when you build a production React Native app.
- S01
The New Architecture: JSI replaces the bridge.
The New Architecture: JSI replaces the bridge.The old async JSON bridge is gone. JSI (the JavaScript Interface) lets JavaScript hold direct references to native objects and call them synchronously in C++. TurboModules load native modules lazily, and Codegen generates the type-safe glue between JS and native. This is the change that removes the single biggest source of legacy React Native latency.
JSITURBOMODULESCODEGENNEW ARCH - S02
Fabric: concurrent rendering on a new host tree.
Fabric: concurrent rendering on a new host tree.Fabric is the New Architecture's renderer. It builds an immutable shadow tree in C++, supports React's concurrent features, and lets native and JS share the same view hierarchy without bridge round-trips. Yoga still handles Flexbox layout underneath — but Fabric is why UI updates and gestures can stay in sync under load.
FABRICCONCURRENTSHADOW TREEYOGA - S03
Hermes: the engine that compiles JS ahead of time.
Hermes: the engine that compiles JS ahead of time.Hermes is React Native's default JavaScript engine. It compiles to bytecode at build time instead of parsing JS on launch, which cuts cold-start time and memory use measurably on mid-range Android hardware. Understanding Hermes is how you reason about startup performance instead of guessing at it.
HERMESBYTECODESTARTUPMEMORY - S04
Native modules: where JavaScript meets platform APIs.
Native modules: where JavaScript meets platform APIs.Anything the OS exposes but React Native doesn't — Bluetooth, secure storage, a custom SDK — crosses through a native module. Under the New Architecture these are TurboModules; in Expo, most are reachable through config plugins without ejecting. Knowing where that boundary sits is what decides whether you need bare React Native at all.
TURBOMODULESNATIVECONFIG PLUGINSEXPO - S05
Expo vs bare: where the managed workflow ends.
Expo vs bare: where the managed workflow ends.Expo's managed workflow gives full native module access, cloud builds via EAS, and OTA updates without touching Xcode or Gradle. Prebuild generates the native projects on demand. You only eject to bare when a specific native integration genuinely can't be expressed as a config plugin — and most apps never reach that line.
EXPOEASPREBUILDBARE - S06
OTA updates: shipping JavaScript without store review.
OTA updates: shipping JavaScript without store review.EAS Update ships JS-and-asset changes straight to devices, skipping the App Store and Play Store review queue — with staged rollout and rollback if a metric degrades. The rule that matters: anything touching native code still needs a full store submission. Knowing which change is which is the whole discipline.
EAS UPDATEOTAROLLBACKJS BUNDLE
The playbook
React Native development
patterns we ship on repeat.
Proven in production React Native apps across real device profiles — not Expo Snack demos.
P01
Expo-managed by default.
EAS Build in the cloud, EAS Update for OTA patches that skip app store review, config plugins for native configuration. Ejecting to bare happens only when a specific native integration genuinely cannot be handled any other way. Most React Native apps never reach that point.
P02
FlashList over FlatList everywhere.
FlashList is measurably faster on long lists — we use it everywhere a FlatList would go, with estimated item sizes, stable keys, and memoised renderers. It's not a premature optimisation; it's what Shopify built for exactly this problem.
P03
Typed navigation with Expo Router.
File-based routing, typed params, deep link support from the first screen. A navigation refactor that changes a param type fails the build — not the QA pass three days and one App Store rejection later.
P04
Reanimated for native-thread animations.
Worklet-based animations running on the UI thread at 60fps — no JS bridge involved, no dropped frames when the JavaScript thread is busy. Gesture Handler for native-feel swipes and drags.
P05
Detox or Maestro for E2E tests.
Real device end-to-end tests on the critical user flows — onboarding, purchase, deep link. CI on every PR. Catches what unit tests can't before the App Store reviewer finds it instead.
P06
OTA updates with rollback.
EAS Update pushes JS fixes in minutes without waiting for app store review. Rollback if a metric degrades. For any change that touches native code, standard store review still applies — we scope every update correctly.
Signature case
A fintech app,
rebuilt from legacy bridge to New Architecture on Expo.
A B2C fintech app on React Native 0.68 with the legacy bridge — 3.8s cold start, Redux store with 22 reducers, FlatList jank on transaction history, and zero OTA capability. Migrated to Expo SDK 55 with New Architecture, FlashList, and EAS Update in 9 weeks. Cold start dropped to 1.2s. First OTA fix shipped 48 hours after launch.
Before
RN 0.68 bridge · cold start 3.8s · Redux 22 reducers · FlatList jank · no OTA
After
Expo SDK 55 New Arch · cold start 1.2s · Zustand + TanStack · FlashList 60fps · EAS OTA live
- Cold start improvement−68%
- List scroll performance60fps
- To fully migrated9wk
- Shipped regressions0
How it comes together
How a React Native app
goes from audit to store.
The technical lifecycle of a production React Native build, screen by screen — the current app stays live on both stores throughout.
- W01
Audit + RFC
Two senior React Native engineers go through the codebase — bundle analysis, bridge usage audit, New Architecture compatibility check for every native module. A ranked RFC with real effort estimates, not a list of architecture opinions.
- W02–03
Foundation + first screen
Expo SDK 55 baseline, Expo Router established, FlashList and Reanimated wired in, one production screen built end-to-end. Real cold start numbers on a physical device — not a simulator.
- W04–08
Build screen by screen
Feature by feature under feature flags, with TestFlight and internal Play Store track releases weekly. The existing app keeps shipping while the new architecture lands underneath it.
- W09+
App Store submission + handoff
Store assets, compliance, first submission to both stores. EAS Update configured for post-launch OTA. Runbook handed to your team — or we stay on retainer.
Stack
Tools we
Tools we reach
reach for for first.
Picked for production React Native — not Expo snack demos.
Sharp questions,
straight answers.
Expo vs. bare, New Architecture migrations, OTA updates — the questions engineers ask most about React Native architecture.Founder-direct
Tell us whatyou're building.
Thirty minutes with the founder — a senior React Native developer in the room, the relevant playbook on the table, and a straight answer on whether cross-platform is the right call or native gets you there better.