React Native when JS shapes the stack. Write-once isn't why.

React Native earns its place when the product is JavaScript-shaped from end to end. A B2B product with a web admin and a companion mobile app, both built by the same engineers, both consuming a shared Next.js-emitted TypeScript SDK — that is RN's home turf. The native primitives users care about (camera, geolocation, push, in-app purchase, biometrics) all work fine through the bridge. Update velocity is the second axis. Expo's EAS Update ships JS-only bug fixes in hours rather than waiting on app-store review windows. For products that iterate weekly, that compounding speed is hard to give up. The third axis is hiring leverage. React engineers are the largest mobile talent pool today; the same TypeScript fluency staffs both the web and mobile sides of the product.

Honest counter-cases. Heavy real-time graphics — games, AR, complex 60fps animations with custom shaders — make the bridge the bottleneck; either drop to native modules or pick Flutter, which renders directly to Skia. Niche device APIs are the second pressure point: Bluetooth Low Energy with custom protocol parsing, hardware-accelerated video processing, anything where the JavaScript thread cannot keep up. Possible in RN, but the work-to-result ratio gets ugly. Pure marketplace mechanics — onboarding, listings, request flow, booking, payment — are list-and-form heavy and ship faster on a no-code stack; we made that exact call on Cobeau, a peer-to-peer pet care marketplace. And greenfield Flutter teams already fluent in Dart should not be retrained into JavaScript just to use RN; that is a productivity tax with no payoff.

Patterns that hold up across the projects we ship:

- Expo for product builds, bare workflow only when needed. EAS handles builds, Over-The-Air updates, certificates, and submission. We drop to bare workflow only when a third-party module needs custom native code that Expo's plugin system cannot wrap. - Shared TypeScript SDK. Backend, web app, and mobile app import from a single workspace package containing types, API clients, validation schemas, and business logic. Schema changes propagate at build-time. Drift between platforms becomes a compiler error, not a runtime surprise. - EAS Update for OTA fixes. JavaScript bug fixes ship in hours. App-store review cycles are reserved for native binary changes — bumping the SDK version, swapping in a new native module, or shipping a new icon. - Custom native modules sparingly. When in-app purchase needs platform-specific tweaks or a BLE protocol needs raw access, we write Swift and Kotlin and bridge them. We do not pretend RN is pure JavaScript when it is not. - Reanimated for performance-critical animations. Runs animations on the UI thread, sidesteps the bridge bottleneck for gestures and transitions. Most "RN feels slow" complaints are gesture-thread issues that Reanimated fixes outright.

For the broader mobile engagement, see our mobile development team and the app development approach.

Five dimensions we walk through with every cross-platform mobile decision:

Time to MVP. RN: roughly eight to twelve weeks for a feature-complete app with auth, push, payments. FlutterFlow: four to six weeks for a marketplace-shaped MVP. Native Dart and Flutter: twelve to sixteen weeks. Our take: FlutterFlow wins for marketplace MVPs, RN wins for product apps with ongoing iteration, native Dart only when the product is mobile-first and a strong custom design language matters from day one.

Team requirements. RN: needs React and TypeScript fluency plus native module skills as a backstop. FlutterFlow: visual builder skills plus enough engineering to integrate APIs and write custom code blocks. Native Dart and Flutter: Dart fluency and direct Flutter SDK experience, a smaller talent pool than React. Our take: RN amortizes best across a full-stack team that already writes React for the web, FlutterFlow lets product-shaped people ship without a deep engineering org, native Dart needs a committed mobile-first team.

Performance ceiling. RN: good enough for most products, struggles at high-frequency UI updates without Reanimated. FlutterFlow: capped by no-code abstractions; complex custom interactions hit a wall. Native Dart and Flutter: the highest ceiling of the three; Skia rendering bypasses the JS bridge entirely. Our take: if 60fps animations across the whole app matter, native Dart. If they do not, RN or FlutterFlow are fine.

Long-term maintenance. RN: established ecosystem, but framework-version upgrades occasionally break dependencies — the RN upgrade dance is real, and budget should reflect it. FlutterFlow: lock-in to FlutterFlow's runtime, ejecting to native Flutter is possible but lossy. Native Dart and Flutter: stable, fewer upgrade surprises, smaller talent pool. Our take: RN for products with active engineering teams who can absorb upgrades, FlutterFlow when the product's lifespan is a known timeframe, native Dart when long-term ownership is the explicit goal.

Update velocity. RN: OTA via EAS Update or CodePush ships JS changes in hours. FlutterFlow: deployments through their hosted build system, similar speed. Native Dart and Flutter: app-store review for every change, days minimum. Our take: if rapid iteration matters, RN or FlutterFlow. If the app changes quarterly, native Dart's slower cycle stops being a problem.