React Native for business apps: what one codebase covers

React Native with Expo is a good fit when iOS and Android users need the same workflows. That is common in customer and employee apps: the screens, rules and API calls can share one codebase.

Plan separately for platform differences, native SDKs, device testing and store releases. Each remains part of delivery, even when most application code is shared.

This article explains where a shared codebase helps, where it needs extra work, and which questions to settle before choosing it. It expands on the React Native section of our mobile app development page.

When is one codebase enough?

React Native lets an iOS and Android app share application code, and TypeScript adds types to that code that are checked before the app runs. For most business apps, the bulk of the work is the same on both platforms:

• Screens: Lists, detail views, forms and dashboards using data from your API.
• Business rules: Validation, request states and how the interface presents permissions.
• Sessions and data: Sign-in, session handling and backend calls.
• Notifications: Routing a returning user to the right task.

When both platforms serve the same users and workflows, one set of screens helps keep the apps consistent. A shared change can be included in both builds; store review and rollout timing remain separate.

Expo supports this workflow with tooling for building, configuring and releasing React Native apps, and it can work with native modules when the app needs them.

When should you consider native development?

Some projects need a more detailed technical discussion before a shared codebase is chosen:

• The app depends on specialist hardware or unusual device integrations.
• The product relies on demanding graphics or animation beyond typical business interfaces.
• There is already a substantial native iOS or Android codebase that the new work must fit into.

None of these automatically rules React Native out, but each belongs in the first technical conversation rather than halfway through the build.

What shared code does not remove

The split is easier to see when each concern has an owner. This table describes a common starting point, not a guarantee for every app:

Platform-specific behaviour

iOS and Android have different conventions: navigation gestures, the Android back button, how permission prompts appear, how notifications are grouped and shown. React Native provides ways to write platform-specific code where the two versions need to differ (React Native documentation). In most business apps there is little of this code, but it exists, and it has to be designed and tested.

Native SDKs

Payment providers, identity verification, maps, scanning and device features are often delivered as native SDKs for iOS and Android. Before agreeing a scope, check whether each required SDK has a maintained React Native or Expo integration, or whether a native module has to be written. Expo Modules provide a way to write that bridge in Swift and Kotlin (Expo documentation).

For a fintech app, a payment or card SDK is the typical example. It is worth checking early which platform versions it supports, how it presents its own screens and what it requires from your backend.

Offline behaviour

Offline work needs an explicit product decision. Agree which tasks work without a connection, which data stays on the device, how queued changes are sent and how conflicts are resolved.

A field app may need to complete a whole visit offline. An app showing a live account balance may instead need a clear connection error. The requirement determines the design.

Testing on both platforms

Test every release on both platforms. Shared code still runs across different operating systems, screen sizes and OS versions. Include real devices as well as simulators, and check sign-in, notifications, permissions and native SDK flows.

Two releases

The App Store and Google Play have separate accounts, signing, review processes and requirements (App Store Review Guidelines, publishing on Google Play). Someone needs to own the developer accounts, the store listings and the release decisions. Agree before launch who is responsible for each.

Questions to settle before choosing

1. Do iOS and Android users need the same tasks, or does one platform matter more?
2. Which native SDKs and device features does the app need, and do they have React Native or Expo integrations?
3. Which tasks, if any, must work offline?
4. Is there an existing native app, and what happens to it?
5. Who owns the developer accounts and the store releases?

If the answers point to shared workflows and to SDKs that are available or can be bridged, one codebase is usually a sensible default. If not, the project's constraints should shape the technical choice, not the other way round. The technology should fit the product.

An illustrative decision

Consider a fictional approval app for managers. Both platforms show the same queue, request detail and approve-or-return form. Those screens, validation rules and API calls are shared.

Platform work: Face ID and Android biometrics use a maintained Expo-compatible module, with fallback behaviour tested on each platform. Push notifications open the same request, while Apple and Google credentials remain separate.

First-release boundary: Drafts remain only while the app is open. Full offline approval is excluded until the business defines conflict rules.

The decision would be: start with one React Native codebase, assign the product owner to the shared workflow, the backend owner to notification events, the app team to platform behaviour, and the client organisation to both store accounts. Revisit the decision if a required approval or security SDK cannot be supported without disproportionate native work. This is an illustrative decision, not a claimed Tolaron project result.

What the app needs from your backend is a separate question, covered in what your API needs before we build a mobile app. What to include when you ask for an estimate is in what to send before asking for a mobile app proposal.

Next step

If you are weighing React Native for a business app, send a short description of the users, the main tasks and any SDKs or device features the app depends on through the contact page. Please keep credentials and customer data out of the first message; they are not needed to discuss fit.