React Native: a mobile app without doubling the teams

Building a mobile app quickly raises a costly question: an iOS appand an Android app, meaning two teams, two codebases?React Native offers another path: a single codebase for both platforms.

One codebase, two platforms

React Native lets you write the app once in TypeScript/React and deploy it to iOS and Android. For a team already familiar with the React ecosystem, this means major time savings and consistency, with just one codebase to maintain.

One important technical change is worth knowing, because it makes a good share of online comparisons obsolete. React Native’s “New Architecture” has been enabled by default since version 0.76: the asynchronous bridge that serialised every exchange between JavaScript and native code has been replaced by a direct interface (JSI) and a new rendering engine (Fabric). In practice, the classic “the bridge slows everything down” argument no longer holds in the same terms, and performance measurements from before 2024 no longer describe the current tool. It is also a reason to check third-party library compatibility before picking up an older project.

When React Native is the right choice

• A business app, a mobile back-office, a field tool, where the experience doesn’t require extreme native effects.
• A budget and timeline that don’t allow for duplicate native development.
• A need for offline mode, photos, scanning, signatures, geolocation, all of this works very well in React Native.

One budget point escapes the technical debate and applies in every case: publishing is still subject to the app stores. The Apple Developer Program costs $99 a year and membership is required to distribute on the App Store; Google Play charges its own registration fee and requires identity verification. Add review delays on every update, privacy details to declare and, for in-app sales, commissions. A shared codebase halves the development cost; it does not halve the distribution cost, which stays double.

This is typically what we deploy for business tools that have a field component.

When to prefer native (or a PWA)

For highly demanding applications in terms of graphics (games, 3D animations, precise hardware access), native still has the edge. And for purely consultative use, a PWA (installable web app) may even suffice, without going through app stores.

The PWA alternative deserves quantifying rather than mentioning, because it changes the nature of the project. A web application becomes installable on the home screen by adding three things, a service worker, a manifest and HTTPS, whose exact conditions the MDN guide describes. What you gain: no developer account, no review, no commission, an immediate update for everyone. What you lose: full hardware access, whose coverage varies by browser and operating system, and discovery by search inside the stores. For a business tool or a field back-office, the equation often favours the PWA; for a consumer app, rarely.

The right approach: frame the actual use case

Native mobile, React Native, or PWA: the choice is based on actual usage, not trends. We decide this during scoping, for our application development.

Have a mobile app in mind? Let’s find the most efficient path together.