One codebase
Screens, navigation, state and business logic are shared across iOS and Android. Platform-specific code is the exception, written only where the platforms truly differ.
Technology · React Native · ExpoReact Native app development
React Native app development
one codebase, two stores.
React Native lets one team build iOS and Android apps from a single TypeScript codebase that renders real native interface components. For most startup and business apps it is the most economical route to both stores. It is not the right tool for every app, and this page says where the line is.
What it isReact on the phone,
React on the phone,
native components on screen.
React Native is an open-source framework created at Meta. You write components in TypeScript using the React model, and the framework renders them as native iOS and Android views. Expo adds the tooling around it.
Native where needed
Camera, push notifications, biometrics, location, in-app purchases and similar features are reached through maintained native modules, with custom native code possible when nothing exists.
One language across the product
TypeScript in the app, the web front end and a Node.js back end means shared types, shared validation and engineers who can move between layers.
How BBR uses it
What we can honestly say.
BBR’s mobile work uses two approaches, chosen per project:
- React Native with Expo and TypeScript. Nora, BBR’s own AI companion app, is being built on this stack. It is in development and has not been released, so we do not present it as a shipped product.
- Capacitor, which wraps a web application in a native shell. BBR’s two apps published on Google Play, Grow.io and Live Gold & Silver Prices, use Capacitor. The case studies explain why it suited those products.
So the shipped store experience BBR can point to (Google Play release, AdMob, in-app purchases, local notifications) was gained with Capacitor apps, and React Native is the stack of our current in-house build. We think it is better to state that plainly than to imply a React Native portfolio we do not have. The wider service, including backend and store release, is described under mobile app development.
FitWhen React Native is the right choice,
Good fit Not a fit
When React Native is the right choice,
and when it is not.
The question is not whether React Native is good. It is whether your app’s hard parts are the kind it handles well.
React Native suits the app if
- It is mostly screens, lists, forms, media and API calls: marketplaces, booking, social, fintech front ends, content, companion apps for a SaaS
- You need iOS and Android at or near the same time on one budget
- You have, or plan, a React web app and want one team and shared code
- You want to ship frequent updates and keep both platforms in step
- You expect to hire later and want a large pool of JavaScript and TypeScript engineers to draw from
Look at another approach if
- The core of the app is heavy real-time graphics, a 3D game, or advanced camera, audio or video processing
- It depends on the newest platform APIs on release day, or deep OS integration such as complex widgets, watch apps or CarPlay as the main experience
- It needs sustained background processing or low-level Bluetooth work as the central feature; possible, but much of it ends up as native code anyway
- You are building for one platform only and already have native engineers
- A responsive web app would test the idea just as well; build that first
Alternatives
How it compares.
| React Native (Expo) | Flutter | Native (Swift / Kotlin) | Capacitor | |
|---|---|---|---|---|
| Language | TypeScript / JavaScript | Dart | Swift and Kotlin | Web stack (HTML, CSS, JS) |
| Interface rendering | Platform’s native components | Its own rendering engine; consistent look across platforms | Native | Web view inside a native shell |
| Codebases for iOS + Android | One | One | Two | One, shared with the web app |
| Strongest at | Product apps; teams already using React | Highly custom, animation-rich interfaces | Performance-critical and deeply platform-integrated apps | Putting an existing web app or HTML5 game in the stores quickly |
| Main cost | Keeping up with framework and dependency upgrades | Smaller hiring pool for Dart; no code shared with a React web app | Two teams, roughly double the front-end effort | Web-view feel and performance limits on demanding interfaces |
| Does BBR build with it? | Yes | No | No | Yes |
We keep this table short on purpose. The full reasoning is in two guides: Flutter vs React Native for the framework choice, and native vs cross-platform development for the broader decision.
What a typical React Native project includes
- Expo with TypeScript, file-based navigation and a small set of well-maintained libraries
- A Node.js and PostgreSQL back end, or a managed backend such as Supabase or Firebase where that is enough
- Push notifications, authentication, and store billing or Stripe-style payments depending on what is sold
- Cloud builds, internal test distribution and over-the-air updates for JavaScript-only fixes, within store rules
- Submission to the App Store and Google Play under your own developer accounts
- Source code and documentation handed over, as with every BBR project
QuestionsFrequently asked
Frequently asked
questions.
Is a React Native app a real native app?
Yes, in the sense that matters to users and stores. The interface is drawn with the platform's native components rather than in a web view, the app is distributed through the App Store and Google Play like any other, and it can use device features through native modules. Application logic runs in JavaScript, which is the main architectural difference from an app written in Swift or Kotlin.
What is Expo, and should we use it?
Expo is a framework and toolset built around React Native that handles project setup, a large library of device APIs, cloud builds and over-the-air updates. The React Native documentation itself recommends starting new projects with a framework such as Expo. We use it by default. If an app needs native code that Expo does not provide, custom native modules can be added through development builds, so starting with Expo does not close that door.
Can you take over an existing React Native app?
Yes. BBR can join or take over existing codebases. We begin with a short review of the repository, dependencies and build setup, since React Native projects that have missed several version upgrades usually need that addressed first, and we tell you what we find before quoting.
Do you build with Flutter or fully native Swift and Kotlin?
No. BBR builds mobile apps with React Native (Expo) and, for web-technology apps, Capacitor. We do not offer Flutter or dedicated Swift and Kotlin teams. If your project needs one of those, you should choose a team that specializes in it. Our comparison of Flutter and React Native is written to help with that decision either way.
How much does a React Native app cost?
The framework affects cost less than the scope does. Sharing one codebase across iOS and Android saves a large part of the front-end effort compared with two native apps, but backend, design and testing are the same. See the app development cost guide for how to estimate a range.
Your next movePlanning an iOS and Android app?
Planning an iOS and Android app?
Let’s check the fit.
Tell us what the app does and which device features it needs. We will tell you whether React Native suits it, and what a first release would involve.
Discuss your app ↗