React Native for business apps: what one codebase covers
When one React Native and Expo codebase fits an iOS and Android business app, and what it does not remove: native SDKs, offline, testing and releases.
One React Native codebase, built with Expo, fits a business app when iOS and Android users need the same tasks and workflows, which is the usual situation for customer and employee apps. Shared code avoids writing the same application twice. It does not remove platform-specific behaviour, native SDK integration, testing on each platform or two separate store releases, and those are worth planning from the start.
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 for lists, detail views, forms and dashboards built on data your API provides.
- Business rules: validation, the states a request moves through, what each user may see.
- Sign-in, session handling and calls to the backend.
- Notifications that bring a user back to a specific task.
When both platforms serve the same users and the same workflows, writing this once and maintaining one set of screens keeps the two apps consistent. A change to a form or a rule reaches both platforms in the same release.
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
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
Whether an app works without a connection is a product decision, not a framework feature. Decide which tasks must work offline, what is stored on the device, how changes made offline are sent later, and what happens when two changes conflict. A field or on-site app often needs this; a customer app showing live account data often does not.
Testing on both platforms
Shared code still runs on two operating systems, many screen sizes and several OS versions. Each release needs testing on iOS and Android, on real devices as well as simulators, including sign-in, notifications, permissions and any 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
- Do iOS and Android users need the same tasks, or does one platform matter more?
- Which native SDKs and device features does the app need, and do they have React Native or Expo integrations?
- Which tasks, if any, must work offline?
- Is there an existing native app, and what happens to it?
- 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.
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.