React Native App Development: When It Fits and How We Build It

React Native app development lets one team ship an iOS app and an Android app from a single TypeScript codebase, and the screens render real native components, not a web page. For a large class of products, it’s the most economical way to be in both stores with an app that feels right on each.

It has trade-offs, and good React Native work means knowing where the framework ends. You need to know which features will need native modules and what over-the-air updates can and can’t do. Sometimes the right answer is to build natively instead. This article covers how we make those calls.

What we build with React Native

• Marketplaces with buyer and seller flows, listings, messaging and payments.
• Booking, ordering and account apps that sit on top of an existing backend.
• Shopping and loyalty apps with catalogs, carts and push campaigns, which our article on m-commerce app development covers in detail.
• Financial app front ends that combine standard screens with native SDKs for identity verification or card scanning.
• Companion apps for IoT devices, with a native module handling the Bluetooth protocol.
• Internal and field apps, where one codebase keeps the maintenance burden small.

Often there’s a React web product next door. In that case types, API clients, validation and business logic can be shared between the web app and the mobile app in one repository, and the same engineers can work on both.

Is React Native app development the right fit?

It’s a good fit when:

• You need both iOS and Android, with one team and one roadmap.
• The app is mostly screens: lists, forms, media, maps, and payments through provider SDKs.
• Your team, or the team that will own the app later, knows React and TypeScript.
• You want to share code and people with a React web application.

It’s a poor fit when:

• The core of the product is heavy graphics, 3D or a game. A game engine or native code will serve you better there.
• The app processes camera, audio or sensor data in real time, or augmented reality is the main feature.
• Most of the value lives outside the app, in widgets, a watch app or CarPlay, all of which are native code anyway.
• Startup time and memory on very low-end devices are critical, since React Native adds a JavaScript runtime to every launch.
• You need every new OS feature as soon as it ships.

For those products, see our take on native mobile app development. If what you mainly need is reach rather than a store presence, an installable web app may be enough, and HTML5 app development covers that option.

The new architecture, and what it changes

For most of its history, React Native connected JavaScript to native code through an asynchronous bridge that serialized every message. It worked, but batching and serialization added latency. Anything that needed an immediate answer from the native side, like measuring a layout during a gesture, was awkward. The new architecture removes that bridge and is built from four pieces:

• JSI, a C++ interface that lets JavaScript hold references to native objects and call their methods directly, including synchronously when that’s appropriate.
• TurboModules, native modules that load lazily and expose typed interfaces instead of loosely typed messages.
• Fabric, the new rendering system, which can measure and update layout synchronously and supports React’s concurrent features.
• Codegen, which generates the glue between JavaScript and native code from typed specifications, so mismatches fail at build time instead of in a user’s hands.

Alongside it, the Hermes engine compiles JavaScript to bytecode at build time, which shortens startup and lowers memory use. Users get smoother gestures and animations and faster launches. Developers get native modules that are easier to write safely.

It also means a dependency audit. Every library in the app has to support the new architecture, and unmaintained libraries are the main obstacle when we migrate an older app. We upgrade React Native in steps, replace abandoned packages and retest every native integration.

New apps start on Expo, the framework the React Native team recommends. With development builds and config plugins, Expo no longer limits which native code you can use, and generating the native projects from configuration makes version upgrades far less painful. Brownfield projects, where React Native screens are added to an existing native app, need a more hands-on setup.

Native modules: planning for Swift and Kotlin

Well-maintained libraries cover most needs: navigation, camera, maps, secure storage, push notifications, and the official React Native SDKs that many payment providers publish. Animations and gestures run on the UI thread with Reanimated and Gesture Handler, and long lists use a recycling list component so scrolling stays smooth.

Some things still call for native code:

• Vendor SDKs with no React Native wrapper, such as some identity verification, card reader or proprietary hardware SDKs.
• Custom Bluetooth protocols for IoT devices, and background processing with platform-specific rules.
• Home screen widgets, Live Activities and watch apps, which are written in Swift or Kotlin and share data with the main app through app groups or shared storage.
• Performance-critical paths such as image processing.

We write these with the Expo Modules API or as TurboModules, with typed interfaces on both sides. It’s also why we staff React Native projects with engineers who are comfortable in Xcode and Android Studio, since signing, Gradle and native build errors come with the job. When choosing libraries, we check maintenance activity, new architecture support, TypeScript types and how the maintainers handle issues. We’d rather keep the dependency list short.

Over-the-air updates: useful, with caveats

Much of a React Native app is JavaScript, so you can ship a new bundle straight to users without a store release, using Expo’s EAS Update or a self-hosted update server. Used well, that’s a safety net for urgent fixes and a quick way to adjust copy and small UI details. The caveats are real, though:

• Only JavaScript and assets can change. A new native module, an SDK upgrade, a new permission or a React Native upgrade still needs a store release, and each update has to target the native runtime it was built for, or it can crash older installs.
• Apple allows downloaded JavaScript only within limits: it must not change the app’s primary purpose or introduce features that skip review. Google Play allows interpreted code updates, but its policies still apply to whatever you ship. Use updates for fixes and refinements, and send new features through review.
• Depending on configuration, a user gets an update on the next launch or the one after, so even an urgent fix takes time to reach everyone.
• Updates need operational work: separate channels for staging and production, staged rollouts, monitoring, a rollback plan and signed update bundles.
• A fix that can ship in minutes still needs regression testing before it goes out.

Quality in a React Native codebase

TypeScript runs in strict mode. Unit tests use Jest, component tests use React Native Testing Library, and E2E tests run with Maestro or Detox against real iOS and Android builds. For performance, we profile release builds on mid-range Android phones, where unnecessary re-renders and oversized images show up first, and keep animations on the UI thread.

Accessibility labels, roles and states map to VoiceOver and TalkBack, but the two screen readers behave differently, so we test with both. Tokens go in Keychain- and Keystore-backed storage, never in plain async storage. Nothing secret ships in the JavaScript bundle either, because it’s easy to extract from an app package.

Store review works by the same rules as for any native app: privacy details, account deletion, in-app purchase for digital goods, and a demo account for reviewers.

How an engagement works

A React Native team with us usually has a business analyst, a product designer, React Native engineers (at least one of them with deep iOS or Android experience), a backend engineer if the product needs one, and QA. Iterations are short. Fast Refresh keeps day-to-day development quick, every iteration ends with a demo and installable builds for both platforms, and CI builds, tests and signs every change.

You receive one repository, both store listings under your own accounts, update channels configured for staging and production, and documentation your own team can pick up. Startups often choose React Native for exactly these reasons; mobile app development for startups covers how we scope a first release. We also take over existing React Native apps to upgrade old versions, migrate them to the new architecture and replace abandoned libraries.

Frequently asked questions

Does a React Native app feel native?

It uses the platform’s own UI components, so text, inputs and scrolling behave natively. Custom animations and gestures need care, but with the right libraries most users won’t notice a difference on typical screens.

Expo or bare React Native?

Expo, for almost every new app. It doesn’t restrict native code anymore, and it simplifies builds, updates and upgrades. The main case for a more manual setup is adding React Native to an existing native app.

Can we share code with our React web app?

Business logic, API clients, validation and types, yes. UI components mostly not, because web and native primitives differ. You can share UI through React Native for Web, but it brings its own compromises.

Can you migrate our older React Native app to the new architecture?

Yes. We first audit the React Native version, every dependency and every custom native module, then upgrade in steps and test at each one. Abandoned libraries get replaced or rewritten.

What happens when a library we depend on is abandoned?

If it’s small, we fork and maintain it. If a healthy alternative exists, we switch. Otherwise we write a focused native module. Choosing libraries carefully up front keeps this rare.

For an app that has to be in both stores, send us your feature list with anything device-specific marked, and we’ll point out which parts React Native covers and which would need native modules.