Expo or React Native: Which Cross-Platform Mobile Framework?

expo/expo is a framework and toolchain wrapped around React Native. You scaffold with npx create-expo-app, run npx expo start, and immediately have an app you can open on a physical device through Expo Go or a custom dev build. Expo ships a large library of prebuilt native modules — expo-camera, expo-notifications, expo-file-system — so you import a JS package instead of writing native glue code.

Its biggest strengths are EAS cloud builds (no local Xcode or Gradle needed to ship), over-the-air updates that push JS changes without an app-store round trip, and config plugins that automate native setup. The tradeoffs: the managed flow adds an abstraction layer some teams find opaque, certain niche native libraries require a custom dev client rather than Expo Go, and OTA updates carry store-policy limits. Cold-start and bundle size can run higher than a hand-tuned bare app.

Pick expo/expo for nearly every greenfield React Native app — it removes the most painful parts of the toolchain and is now the officially recommended way to start. Drop to bare facebook/react-native only when you need deep custom native code that Expo's plugin and config system can't express cleanly.

facebook/react-native is the framework at the base of this entire category. You write components in JavaScript and JSX, and react-native renders them to real UIKit and Android View objects rather than a webview, bridging your JS to native code through the newer Fabric renderer and JSI. A typical screen is plain React — <View>, <Text>, <FlatList> — styled with a flexbox-based StyleSheet, and hot reload shows changes instantly.

Its strengths are reach and maturity: one React codebase ships to both iOS and Android, the native module system lets you call any platform API, and a huge community means almost every problem has a package. The honest costs are real — you manage Xcode and Gradle yourself, native dependency upgrades can be painful, and performance-sensitive animation or graphics work pushes you toward add-ons like react-native-reanimated or react-native-skia. Debugging across the JS/native boundary is harder than pure web development.

Pick facebook/react-native directly when you need full native control, custom native modules, or are embedding React Native into an existing native app. If you're starting fresh and want the toolchain handled for you, pick expo/expo, which is built on react-native anyway and removes most of the setup pain.

invertase/react-native-firebase is a modular wrapper that exposes Google's Firebase SDKs to React Native. Instead of the web Firebase JS SDK, it binds the native iOS and Android Firebase libraries, so you install @react-native-firebase/app plus per-feature packages like @react-native-firebase/auth or /firestore and call typed JS methods that run on the native SDK underneath.

Its strengths are native performance and access to features the web SDK lacks — Analytics, Crashlytics, push via FCM, and on-device persistence — a modular install so you pull only the services you use, and strong TypeScript types. The costs: it requires native config files (google-services.json and GoogleService-Info.plist) and a rebuild, version upgrades must track the native Firebase SDKs closely, and under Expo you need a custom dev build plus config plugins rather than plain Expo Go.

Pick invertase/react-native-firebase when your backend is Firebase and you want native Analytics, Crashlytics, and FCM messaging. If you only need basic auth or a few Firestore reads, the plain Firebase web SDK can be lighter to integrate; but for native push and analytics specifically, this library is the standard choice.

microsoft/react-native-windows extends React Native's component model to native Windows desktop apps. Maintained by Microsoft, it renders your <View> and <Text> trees to native WinUI/XAML controls instead of mobile views, so the same React components and JavaScript business logic can target Windows 10 and 11. You add it to a project and build a Visual Studio solution that produces a real Windows binary.

The strengths are a genuine native Windows UI, reuse of your existing React Native JavaScript, and first-party Microsoft backing that keeps it aligned with the core framework. Drawbacks: the Windows ecosystem of community RN packages is far smaller than iOS or Android, so many libraries lack Windows support; the C++/C# build toolchain is heavier than mobile; and you'll hit API gaps that require writing native Windows modules yourself in C++ or C#.

Pick microsoft/react-native-windows when you already have a React Native app and need a native Windows desktop version that shares the JS layer. If your target is mobile only, ignore it; if you need a Mac desktop build instead, reach for microsoft/react-native-macos, which is its sibling project.

Shopify/react-native-skia brings the Skia 2D graphics engine — the same library behind Chrome and Flutter — to React Native. You compose drawings declaratively with components like <Canvas>, <Path>, <Circle>, and <Shader>, or draw imperatively, and Skia renders them GPU-accelerated, enabling custom shapes, gradients, blurs, and shaders that ordinary React Native views cannot produce.

Strengths: high-performance custom graphics and canvas effects, real shader support for advanced visuals, and smooth integration with software-mansion/react-native-reanimated for animated drawings. Drawbacks: it's a low-level drawing toolkit, so you build UI primitives yourself instead of using ready-made components; the API and graphics concepts — paths, paints, shaders — have a steep curve; and it adds meaningful native binary size to your app.

Pick Shopify/react-native-skia when you need custom data visualization, drawing tools, image filters, or shader effects beyond what styled views allow. For ordinary screens and layouts you don't need it — use standard components and reach for Skia only at the specific points that demand custom rendering.

mrousavy/react-native-mmkv is a fast key/value storage library backed by Tencent's MMKV, a memory-mapped native store. You create an instance and call synchronous methods — storage.set('key', value), storage.getString('key') — with no promises and no asynchronous bridge round-trip, because it's implemented natively via JSI. Its README cites it as roughly 30x faster than AsyncStorage.

Strengths: synchronous, very fast reads and writes ideal for app state and feature flags, typed getters for strings, numbers, and booleans, and built-in optional encryption. Drawbacks: it's a JSI native module, so under Expo it needs a custom dev build rather than Expo Go and doesn't run in plain remote-JS debugging; it stores small key/value data, not large structured datasets; and synchronous access can block the thread if misused for big blobs.

Pick mrousavy/react-native-mmkv when you need fast synchronous local storage to replace AsyncStorage for settings, auth tokens, and cached flags. For large relational or queryable data, use a real database like SQLite or WatermelonDB instead — MMKV is for fast small key/value access, not heavy persistence.

callstack/react-native-paper is a UI component library implementing Google's Material Design for React Native. You wrap your app in a PaperProvider and compose prebuilt components — Button, Card, TextInput, Appbar — that arrive themed, accessible, and consistent across iOS and Android. Theming is centralized, so a single theme object restyles the entire app at once.

Strengths: a comprehensive Material component set, built-in light and dark theming, solid accessibility defaults, and active maintenance by Callstack. Drawbacks: it imposes a Material look that can feel un-native on iOS, customizing components beyond the theme system sometimes means fighting the library, and it adds bundle weight even if you only use a handful of components. Its Material You / MD3 support arrived later than the core Material set.

Pick callstack/react-native-paper when you want a coherent Material-styled app quickly and don't need a bespoke design language. If you want a more neutral, freely brandable kit, consider react-native-elements/react-native-elements; if you need fully custom visuals, build on lower-level primitives instead.

callstack/react-native-testing-library is a set of testing utilities that render React Native components in a test environment and let you assert on them the way a user would. Following the Testing Library philosophy, you render(<Screen />) and query by text, role, or testID, then fire events like fireEvent.press(button) and assert on the resulting rendered output rather than internal component state.

Strengths: it encourages tests that survive refactors by querying user-visible output, integrates cleanly with jestjs/jest, and supports async queries like findByText for data-loading UIs. Drawbacks: it runs in Node, not on a device, so it can't catch native-layer bugs or real gesture and animation behavior; complex native-module interactions still need mocking; and leaning too hard on testID undermines its user-centric intent.

Pick callstack/react-native-testing-library for component and screen tests in any React Native project, paired with jestjs/jest as the runner. Use it for logic and rendered-output coverage; for true end-to-end device behavior you still need a separate native E2E layer that it does not replace.

software-mansion/react-native-reanimated reimplements React Native's Animated API to run animations on the native UI thread instead of the JS thread. You write animations as worklets — JS functions tagged to execute natively — using hooks like useSharedValue and useAnimatedStyle, so a drag or spring stays at 60fps even when the JS thread is busy rendering or fetching data.

Its strengths are smooth gesture-driven animation, a declarative hook API that co-locates animation logic with components, and tight integration with software-mansion/react-native-gesture-handler for interactive transitions. The drawbacks: the worklet mental model has a genuine learning curve, major versions changed the API and broke older code, and debugging worklets is harder than ordinary JS because they run off the main JS context. Its Babel plugin setup is mandatory and a common source of first-run errors.

Pick software-mansion/react-native-reanimated whenever animation quality matters — bottom sheets, swipe gestures, shared-element transitions — and pair it with react-native-gesture-handler. If you only need a one-off fade or simple timing animation, React Native's built-in Animated API is enough and avoids the extra setup.

jestjs/jest is the JavaScript testing framework that React Native ships with by default. You write tests in *.test.js files with describe, it, and expect, and Jest runs them in Node, providing built-in mocking, snapshot testing, and code coverage with little configuration. The React Native template comes preconfigured with a jest preset so tests run immediately.

Strengths: near zero-config for most projects, fast parallel test runs, powerful automatic mocking, and snapshot tests that catch unintended changes to a rendered component tree. Drawbacks: snapshot tests are easy to overuse and rubber-stamp, mocking native modules in React Native requires extra setup, and Jest runs in Node — it verifies logic and rendered output, not real device behavior, so it never replaces on-device QA.

Pick jestjs/jest as the test runner for essentially every React Native project — it's the default and the surrounding tooling assumes it. Pair it with callstack/react-native-testing-library for component tests that assert on rendered output the way a user actually sees it.

software-mansion/react-native-gesture-handler exposes the native touch and gesture systems of iOS and Android to React Native declaratively. Instead of RN's JS-based responder system, you wrap views in gesture detectors — pan, pinch, tap, long-press — that are recognized on the native thread, so gestures stay responsive even under heavy JS load. You define and compose gestures with its Gesture API.

Strengths: native-thread gesture recognition for smooth interaction, composable simultaneous and exclusive gestures, and tight pairing with software-mansion/react-native-reanimated for gesture-driven animation. Drawbacks: it requires wrapping your root in a GestureHandlerRootView, a frequent setup gotcha that silently breaks gestures when missing; the API changed significantly across versions; and reasoning about gesture composition gets complex for intricate multi-touch UIs.

Pick software-mansion/react-native-gesture-handler whenever you build custom interactive gestures — swipeable rows, draggable sheets, pinch-zoom — and it underpins libraries like gorhom/react-native-bottom-sheet. If your app only uses simple taps through standard buttons, you may not need to add it directly.

react-navigation/react-navigation is the most widely used routing library for React Native. It's JavaScript-based: you declare navigators — stack, tabs, drawer — as React components and move between screens with a typed navigation.navigate('Screen') call. Its native-stack navigator uses the platform's native screen primitives so transitions feel like real iOS and Android navigation.

Strengths: a flexible declarative API, deep-linking and state persistence built in, strong TypeScript support, and adoption so broad that most tutorials and libraries assume it. Drawbacks: because navigation state lives in JS, very complex apps can occasionally see transition jank versus a fully native solution, configuring deeply nested navigators gets verbose, and past major versions required nontrivial migrations between releases.

Pick react-navigation/react-navigation as the default for almost every app — it's flexible, well documented, and depended on by libraries like th3rdwave/react-native-safe-area-context. If you need truly native navigation performance and platform-exact behavior, consider wix/react-native-navigation instead, accepting its heavier native setup.

react-native-elements/react-native-elements is a cross-platform UI toolkit offering a broad set of general-purpose components — buttons, cards, list items, avatars, inputs, badges — with a consistent, neutral design that isn't tied to one platform's look. You import components and customize them with props and a shared theme provider rather than adopting a strict design system.

Strengths: a large component catalog, an unopinionated style that's easy to brand to your own identity, and straightforward prop-based customization that lowers the entry barrier for new teams. Drawbacks: it's less strictly designed than a Material system, so visual consistency depends on your own discipline; its maintenance cadence has been more uneven than some rivals; and deep customization can mean overriding styles component by component.

Pick react-native-elements/react-native-elements when you want a flexible, lightly-opinionated component set you can brand freely. If you specifically want Material Design with built-in theming and accessibility, choose callstack/react-native-paper instead; for a fully custom design language, compose your own primitives.

wix/react-native-navigation, from Wix, is a navigation library built on each platform's native navigation primitives rather than JavaScript. Screens are registered with Navigation.registerComponent and pushed onto real native navigation controllers — UINavigationController on iOS, fragments on Android — so transitions, gestures, and screen lifecycle behave exactly like a native app.

Strengths: truly native transition performance and look, native handling of tab bars and stacks, and better memory behavior for screen-heavy apps. Drawbacks: setup is heavier because it touches native project files and is harder to integrate with Expo's managed flow; the API is more imperative than react-navigation; and most community libraries and tutorials assume react-navigation, so you may swim upstream for integrations.

Pick wix/react-native-navigation when native-grade navigation performance and platform-exact behavior are hard requirements and you can absorb the native setup cost. For most apps, react-navigation/react-navigation is simpler and sufficient — start there unless you've measured a concrete need for native navigation.

microsoft/react-native-macos extends React Native to native macOS desktop apps, maintained by Microsoft alongside react-native-windows. It renders your React component tree to native AppKit controls, letting a React Native codebase target the Mac with shared JavaScript logic and a real .app build produced through Xcode using the standard RN component model.

Strengths: a genuine native macOS UI via AppKit, reuse of existing React Native JavaScript, and first-party Microsoft maintenance that keeps it tracking the core framework. Drawbacks: a much smaller library ecosystem than iOS or Android means many community packages lack macOS support, it sometimes trails the core react-native version, and AppKit gaps often force you to write native Objective-C or Swift modules yourself.

Pick microsoft/react-native-macos when you have a React Native app and need a native Mac desktop version that shares the JS layer. If you also target Windows desktop, pair it with microsoft/react-native-windows; if desktop isn't a requirement, skip it and stay mobile-focused.

infinitered/ignite is a battle-tested project boilerplate and CLI from Infinite Red, not a runtime library you import. You run its CLI to scaffold a complete React Native app preconfigured with navigation, state management, an API client, testing, and component and model generators, so you skip days of wiring opinionated defaults together by hand.

Strengths: nearly a decade of production refinement, generators that stamp out screens and models consistently, and a curated, coherent stack that tracks current best practices (Expo, react-navigation, MMKV, and similar). Drawbacks: it's opinionated, so teams that disagree with its choices end up fighting the structure; the generated app carries patterns you must learn; and a boilerplate is a starting point, not an upgradable dependency — you own the code after generation.

Pick infinitered/ignite when you're starting a new app and want a proven architecture out of the box rather than assembling one yourself. If you prefer a minimal start and want to choose every library deliberately, scaffold with plain expo/expo and add packages as you need them.

gorhom/react-native-bottom-sheet is a performant, configurable bottom-sheet component for React Native. You render a <BottomSheet> or <BottomSheetModal> with snapPoints like ['25%', '50%', '90%'], and it slides up over your content with native-feeling drag, built on software-mansion/react-native-reanimated and react-native-gesture-handler for UI-thread-smooth interaction.

Strengths: smooth gesture-driven dragging and snapping, flexible snap points and dynamic sizing, and built-in support for scrollable content via BottomSheetFlatList inside the sheet. Drawbacks: it depends on reanimated and gesture-handler being configured correctly, so version mismatches cause subtle breakage; keyboard handling and nested scrolling need care; and very custom sheet behavior can mean fighting its layout model.

Pick gorhom/react-native-bottom-sheet whenever you need a real interactive bottom sheet — filters, detail panels, action menus. Make sure software-mansion/react-native-reanimated and react-native-gesture-handler are already set up first; if you only need a simple centered modal, React Native's built-in Modal is lighter.

th3rdwave/react-native-safe-area-context provides safe-area inset values — the padding needed to avoid notches, status bars, home indicators, and rounded corners — to your JS layout. You wrap the app in a SafeAreaProvider and read insets with the useSafeAreaInsets hook or the SafeAreaView component, then apply them as padding so content never sits under a notch.

Strengths: accurate per-edge insets that update on rotation, a hook API more flexible than React Native's built-in SafeAreaView, and cross-platform support including Android and web. Drawbacks: it's narrow by design — it only reports insets, it doesn't lay anything out for you — and forgetting the provider or misusing SafeAreaView inside scroll views is a frequent source of layout bugs that are easy to miss.

Pick th3rdwave/react-native-safe-area-context for essentially every app targeting modern notched phones — react-navigation/react-navigation already depends on it. There's no real competitor here; the only alternative is hand-coding platform inset math, which you shouldn't do.