React Native: Cross-Platform Mobile with React

Q: React Native or Flutter?

Both deliver near-native cross-platform apps. React Native wins if your team knows React/JavaScript and you want to share concepts (and sometimes code) with a web app — it renders to native views and has a huge JS ecosystem. Flutter uses Dart and its own rendering engine, giving extremely consistent, highly-custom UI and strong performance. Choose React Native for JS/React familiarity and ecosystem; Flutter for pixel-perfect custom UI and consistency.

Q: Should I use Expo or bare React Native?

Start with Expo unless you have a concrete reason not to — it handles builds, updates (OTA), and a large set of native APIs without touching Xcode/Android Studio, dramatically speeding development. Modern Expo (with config plugins and dev clients) supports most native needs. Choose bare when you require a native module Expo can't accommodate or need deep custom native integration. You can also eject later, though it adds maintenance.

React Native

React Native lets you build iOS and Android apps using JavaScript/TypeScript and React. You write React components, but instead of rendering to the DOM they render to native platform views — so the result is a genuinely native UI, not a webview. For teams that already know React, it's the fastest path to a shared mobile codebase.

The honest expectation: "write once, run anywhere" is mostly true, but polish and edge cases need platform-specific work. Plan for some native code and per-platform tweaks. A foundational early decision is tooling — Expo (managed, batteries-included) vs a bare/custom native setup.

TL;DR

Great for shared mobile code across iOS and Android.
Expect some platform-specific work for polish and edge cases.
Choose tooling early: Expo (managed) vs custom native setups.
Components render to real native views, not a webview.

Quick Example

React components with native primitives (View, Text) instead of DOM elements:

Core Concepts

Components, props, and state — the standard React model.
Native UI primitives — View, Text, Image, ScrollView, FlatList (no HTML elements).
Styling — a subset of CSS-like properties via StyleSheet/inline objects (Flexbox layout).
Native modules / bridging — access platform APIs not covered by the JS layer.

Navigation

Most apps need stack navigation (push/pop screens), tab navigation, and deep linking — typically via React Navigation:

Keep navigation state predictable; avoid global singletons that drift out of sync. See Mobile Navigation.

State Management

Local component state for UI state.
Global state (Redux, Zustand) when state is shared widely.
Server state (TanStack Query / React Query patterns) for API data — caching, refetching, and loading/error handling.

See Mobile State Management.

Performance

Avoid unnecessary re-renders — memoize and keep state local.
Use windowed lists (FlatList/FlashList) instead of mapping huge arrays.
Optimize images — appropriate sizes and caching.
Keep the JS thread light — heavy work blocks UI; offload where possible.

Best Practices

Decide Expo vs bare up front — migration later is costly.
Test on both platforms continuously; don't assume iOS behavior matches Android.
Use FlatList/FlashList for any non-trivial list.
Set up crash reporting and analytics (Sentry, etc.) before launch.
Automate builds, signing, and staged rollouts for reliable shipping.

Common Mistakes

Rendering large lists with map

Blocking the JS thread

FAQ

React Native or Flutter?

Both deliver near-native cross-platform apps. React Native wins if your team knows React/JavaScript and you want to share concepts (and sometimes code) with a web app — it renders to native views and has a huge JS ecosystem. Flutter uses Dart and its own rendering engine, giving extremely consistent, highly-custom UI and strong performance. Choose React Native for JS/React familiarity and ecosystem; Flutter for pixel-perfect custom UI and consistency.

Should I use Expo or bare React Native?

Start with Expo unless you have a concrete reason not to — it handles builds, updates (OTA), and a large set of native APIs without touching Xcode/Android Studio, dramatically speeding development. Modern Expo (with config plugins and dev clients) supports most native needs. Choose bare when you require a native module Expo can't accommodate or need deep custom native integration. You can also eject later, though it adds maintenance.

Is React Native truly "native" performance?

For most apps, yes — UI renders to real native components, so it looks and feels native. The caveat is the JavaScript thread: heavy JS work or bridge-heavy interactions can cause jank. The newer architecture (JSI, Fabric, TurboModules) reduces bridge overhead significantly. For typical apps, performance is excellent; for very animation- or computation-heavy workloads, you may need native modules or careful optimization.

How much platform-specific code will I really write?

Usually a minority, but rarely zero. Core UI and logic are shared, while you'll handle platform differences for permissions, native look-and-feel, some navigation/gesture behavior, push notifications, and store requirements. Budget for testing and tweaking on both iOS and Android — the "90% shared, 10% platform-specific" rule of thumb is a reasonable planning baseline.