React Native

01How React Native works

Your app has two worlds. The JavaScript world runs your React components, state and business logic inside Hermes, a JavaScript engine built for mobile that compiles your code to bytecode at build time so apps start faster and use less memory. The native world owns the real UIView and Android View objects, the camera, the keychain and so on. React describes what the screen should look like; React Native turns that description into native views. A <View> becomes a UIView on iOS and a ViewGroup on Android; <Text> becomes native text. There is no WebView: scrolling, gestures and text input are native, which is why RN apps feel like real apps. Layout uses Yoga, an engine that implements Flexbox, so the same style works on both platforms.

02The New Architecture: JSI, Fabric, TurboModules

The old architecture sent every message between JavaScript and native as serialized JSON over an asynchronous 'bridge' — a queue that became a bottleneck for animations and big lists. The New Architecture, the default since 0.76 and the only option since 0.82, replaces it. JSI (JavaScript Interface) lets JavaScript hold direct references to C++ objects and call them synchronously, without serializing. Fabric is the new renderer: it builds the UI tree in C++, supports React 18+ concurrent features and can measure and update layout synchronously. TurboModules are native modules loaded lazily on first use and typed through Codegen, which generates the C++ glue from your TypeScript spec so mistakes show up at build time. Practical impact: smoother gestures and animations (Reanimated 4 needs it), faster startup, and libraries must be New-Architecture compatible — check before you install.

• JSI: direct, synchronous JS ↔ C++ calls, no JSON bridge
• Fabric: C++ renderer, concurrent React, synchronous layout
• TurboModules + Codegen: lazy, type-safe native modules
• Hermes: bytecode-compiled engine, default on both platforms

03Bare React Native or Expo?

The React Native team now recommends starting with a framework, and Expo is the main one. Expo gives you a large set of maintained native modules, file-based routing (Expo Router), config plugins that edit native projects for you, development builds, and EAS for cloud builds, submission and OTA updates. 'Bare' means you own the ios/ and android/ folders directly (started with the React Native Community CLI). Bare gives full control and fits teams with native experience or heavy custom native SDKs. The line has blurred: Expo apps can include any native code through config plugins or prebuild, and bare apps can use Expo modules. My rule: for a new product with standard needs, start with Expo; for an app that must integrate unusual native SDKs or follows an existing native template, bare is fine — just upgrade regularly.

1# Expo (recommended start)
2npx create-expo-app@latest my-app --template default
3cd my-app && npx expo start
4 
5# Bare React Native (Community CLI)
6npx @react-native-community/cli@latest init MyApp
7cd MyApp && npx react-native run-ios

04Building a real app from zero: structure, env, API, state

Structure by feature, not by file type, so a screen, its hooks and its components live together. Keep three layers separate. The API layer is one HTTP client with base URL, auth header, token refresh and timeouts; adapters turn backend responses into app types, so a renamed backend field changes one file, not twenty screens. Stores (Zustand is light and works well) hold app state like session, cart and settings; screens read stores and call actions, never fetch directly. For server data, TanStack Query adds caching, retries and refetch on focus. Environment: keep the API URL and keys per build (dev, staging, prod) through build-time config, never hard-coded, and never put real secrets in the app — anything in the bundle can be extracted. Retry only idempotent requests (GET, PUT with keys) automatically; a retried POST can create a duplicate order.

1src/
2  app/          # navigation, providers, deep links
3  features/
4    auth/       # screens, hooks, components for sign-in
5    cart/
6    orders/
7  shared/
8    api/        # http client, adapters, endpoints
9    stores/     # zustand stores (session, cart, settings)
10    ui/         # Button, Text, Card — built on tokens
11    theme/      # colors, spacing, typography tokens
12    i18n/       # en / hy / ru dictionaries
13  native/       # bridges to custom native modules

05Navigation, auth flow and push

React Navigation (stack, tabs, drawers on top of native screens) and Expo Router (file-based, built on React Navigation) are the standard choices. Model auth as navigation state: a root navigator shows the auth stack or the main tabs depending on whether a session exists, so a signed-out user cannot reach private screens by a deep link. Store tokens in the Keychain/Keystore (react-native-keychain or expo-secure-store), never in AsyncStorage. Let guests browse and gate only actions that need an account, returning them to the same place after sign-in. Configure deep links and Universal/App Links early; push notifications, emails and QR codes all depend on them. For push, register the device token after sign-in and send it to your backend, ask for permission at a meaningful moment rather than on first launch, and handle notification taps by navigating with the same deep-link routes.

1const Stack = createNativeStackNavigator<RootParams>();
2 
3export function RootNavigator() {
4  const session = useSession((s) => s.session);
5  return (
6    <Stack.Navigator screenOptions={{ headerShown: false }}>
7      {session ? (
8        <Stack.Screen name="Main" component={MainTabs} />
9      ) : (
10        <Stack.Screen name="Auth" component={AuthStack} />
11      )}
12      <Stack.Screen name="ForceUpdate" component={ForceUpdateScreen} />
13    </Stack.Navigator>
14  );
15}

06Styling, design tokens and lists performance

There is no CSS cascade: each component gets a style object, and StyleSheet.create keeps them static. Build a small theme of tokens — colors (light and dark), spacing scale, radii, typography — and a handful of base components (Text, Button, Card, Screen) that only use tokens. Screens then never contain raw hex values or magic numbers, and dark mode or a rebrand is one file. Respect safe areas (react-native-safe-area-context), Dynamic Type/font scaling and Android edge-to-edge layouts. For long lists never render with map inside a ScrollView; use FlatList or, better, FlashList, which recycles cells. Give items stable keys, memoize row components, avoid inline heavy work in renderItem, and size images properly (expo-image or a cached image library). Animate with Reanimated, which runs animations on the UI thread so they stay smooth even when JavaScript is busy.

1export const theme = {
2  color: { bg: "#FFFFFF", text: "#111111", primary: "#0A6CFF", muted: "#6B7280" },
3  space: { xs: 4, sm: 8, md: 16, lg: 24, xl: 32 },
4  radius: { sm: 6, md: 12, pill: 999 },
5  font: { body: 16, title: 22, caption: 13 },
6} as const;
7 
8<FlashList
9  data={products}
10  keyExtractor={(p) => p.id}
11  renderItem={({ item }) => <ProductRow product={item} />}
12/>

07Native modules, platform differences and debugging

When no library exists — a regional payment SDK, a printer, a custom scanner — write a TurboModule: a TypeScript spec, Codegen, then Kotlin/Swift implementations (Expo Modules API is a friendlier alternative). Keep the surface small and promise-based. Expect platform differences: permissions flows, back button on Android, keyboard behaviour, shadows (iOS shadow props vs Android elevation), date pickers, fonts, and stricter background limits on iOS. Use Platform.select or file suffixes (Button.ios.tsx) only where behaviour truly differs. Debugging: React Native DevTools (press j in Metro) gives a Chrome-style debugger, console, React components and profiler for Hermes. Use Xcode and Android Studio logs (Logcat) for native crashes, Crashlytics or Sentry for production, and the performance monitor to watch JS and UI frame rates. Test on a real low-end Android phone — the simulator lies about performance.

08Threads and the render pipeline

A React Native app runs on several threads. The JavaScript thread runs React, your state updates and business logic in Hermes. The main (UI) thread owns native views, touches and the platform's frame loop. Fabric renders in three phases. Render: React produces elements and Fabric builds a shadow tree of C++ nodes. Commit: Yoga calculates layout for that tree, often on a background thread, and the new tree is promoted as the next one to show. Mount: the differences are applied to real native views on the UI thread. At 60 Hz each frame has about 16.7 ms; at 120 Hz about 8 ms. If the JavaScript thread is busy parsing a big JSON response or re-rendering a large tree, touches still arrive but React cannot respond, and the app feels frozen. That is why Reanimated worklets run animations on the UI thread, and why startTransition can mark non-urgent updates as interruptible.

09Writing a TurboModule with Codegen

A TurboModule starts as a typed JavaScript spec. The file name must start with Native, and package.json declares a codegenConfig that tells Codegen where specs live. At build time Codegen reads the spec and generates C++ and platform interfaces; your Kotlin and Objective-C++ or Swift classes implement them, and the compiler complains if a method signature does not match. Keep the surface small: plain data types, promises for anything slow, and events for streams of updates such as payment status. Never block the JavaScript thread with synchronous native calls that touch the network or disk; synchronous methods are for cheap reads only. If the team is not native-heavy, the Expo Modules API offers a simpler Swift and Kotlin DSL that works in bare apps too.

1// specs/NativePayments.ts
2import type { TurboModule } from "react-native";
3import { TurboModuleRegistry } from "react-native";
4 
5export interface Spec extends TurboModule {
6  isAvailable(): boolean; // cheap, synchronous
7  startPayment(amountMinor: number, currency: string): Promise<string>;
8}
9 
10export default TurboModuleRegistry.getEnforcing<Spec>("NativePayments");
11 
12// package.json
13// "codegenConfig": { "name": "PaymentsSpec", "type": "modules",
14//   "jsSrcsDir": "specs", "android": { "javaPackageName": "com.example.payments" } }

10Startup time and bundle size

Cold start is the first impression, and most of it is under your control. Hermes already ships precompiled bytecode, so the remaining cost is mostly what your code does at module load: importing every screen and heavy library up front, reading large data from storage synchronously, or initialising many SDKs before the first frame. Load screens lazily, defer analytics and non-critical SDKs until after the first render, and keep the splash screen up only until the first meaningful data is ready. Measure on a release build on a mid-range Android device, never in development mode, which is many times slower. On Android, enable R8 minification for release and keep its mapping files for Crashlytics. Watch the JavaScript bundle size over time; a single date or chart library can add hundreds of kilobytes that every user downloads and parses.

11Security and offline robustness

Assume the bundle will be read: anyone can unpack an APK or IPA and inspect the Hermes bytecode and assets. Secrets stay on the server; the app holds only user tokens in Keychain or Keystore. To make API abuse harder, add device attestation (Play Integrity on Android, App Attest on iOS) and verify it on the server. Certificate pinning blocks some interception attacks but can lock every user out if a certificate rotates unexpectedly, so pin to public keys with a backup key and a remote kill-switch. Offline behaviour needs explicit design: detect connectivity, show cached data with a clear offline banner, queue user actions locally and replay them with idempotency keys so a retried order is never duplicated. Clear caches containing personal data on sign-out, and exclude sensitive screens from screenshots and the app switcher where the domain demands it.