React Native and Expo explained for business owners
React Native and Expo explained: how one codebase becomes iOS and Android apps, what OTA updates and EAS Build do, and when this stack fits your app.
React Native lets a team build real iOS and Android apps from one shared codebase written in JavaScript/TypeScript. Expo is the toolkit on top of it that handles the painful parts: builds in the cloud, publishing to the stores and pushing small updates without waiting for store review. For most business apps, that combo means one team, one codebase and a faster route to both stores.
Here's what that actually means for your budget, timeline and product — no jargon required.
What is React Native?
React Native is an open-source framework created by Meta. Developers write the app once using React (the same library behind many modern websites), and React Native turns it into native interface components on each platform. A button in a React Native app is a real iOS button on an iPhone and a real Android button on Android — not a web page pretending to be an app.
That's the key difference from "wrapped websites": the app looks, scrolls and feels like it belongs on the phone, and it can use the camera, notifications, location, biometrics and other device features.
Meta uses React Native in Facebook and Instagram, and the official showcase lists apps from Microsoft (Office, Outlook, Teams), Amazon and Shopify, which builds all its mobile apps with it. It's a mainstream, well-supported choice, not an experiment.
What is Expo?
Expo is a framework and set of services built around React Native. The official React Native docs recommend starting new apps with a framework, and Expo is the one they point to. In practice, Expo gives you:
- A ready project setup — navigation (Expo Router), fonts, icons, splash screen and a large set of device modules (camera, notifications, location, file system and more).
- EAS Build — cloud builds for iOS and Android. Your developer doesn't need to maintain a local build machine for each platform, and iOS builds can be produced even without a Mac.
- EAS Submit — uploads builds to App Store Connect and Google Play Console.
- EAS Update — over-the-air (OTA) updates for the JavaScript part of the app.
EAS stands for Expo Application Services. It has a free tier and paid plans; check the current limits on expo.dev before you plan releases around it.
One codebase: what's shared and what's not
"One codebase" is true for the vast majority of an app, but not 100%. Here's the honest split:
| Part of the app | Shared between iOS and Android? |
|---|---|
| Screens, business logic, API calls | Yes |
| Design system, navigation | Yes, with small platform tweaks |
| Push notifications, camera, location | Yes, via Expo modules (setup differs per store) |
| Store listings, icons, screenshots | No — each store has its own requirements |
| Testing | No — you still test on both platforms |
| Rare native features (unusual hardware, newest OS APIs) | Sometimes needs a native module |
So you don't pay twice for the app itself, but you do pay for two sets of testing and two store presences. That's still usually far less than building separate Swift and Kotlin apps. For the "do I even need an app?" question, see PWA vs React Native app.
OTA updates: fixes without store review
Normally, every change to a mobile app goes through a new build and store review. With EAS Update, many changes don't have to. A developer can push an update to the JavaScript and assets, and users get it the next time they open the app.
# publish an update to users on the production channel
eas update --channel production --message "Fix checkout button text"What OTA updates can change: texts, layouts, styles, bug fixes in app logic, images.
What they can't change: anything native — new permissions, new native libraries, app icon, SDK upgrades. Those need a new build and a normal store release.
One more rule: store policies still apply. OTA is for fixes and improvements, not for turning the app into something reviewers never saw. Used that way, it's a huge time saver — a typo on the checkout screen shouldn't wait for review, fr.
EAS Build and publishing, step by step
A typical release flow with Expo looks like this:
- Development — the team works in development builds on real phones.
- Preview builds — testers get installable builds (TestFlight on iOS, internal testing on Google Play).
- Production build —
eas buildcreates store-ready binaries for both platforms. - Submission —
eas submituploads them to the stores. - Review and release — Apple and Google review the app; you publish when approved.
- Updates — small JS fixes via EAS Update, bigger changes via new builds.
The store side (accounts, review, screenshots, privacy policy) is its own topic — see publishing an app to the App Store and Google Play.
When React Native and Expo are a great fit
- Business and service apps — booking, delivery, loyalty, marketplaces, client portals.
- Content and commerce apps — catalogs, orders, notifications.
- MVPs that need store presence — one team can ship both platforms, which fits a lean MVP launch.
- Products that already have a React website — knowledge and sometimes logic can be reused.
When to think twice
- Graphics-heavy 3D games — game engines are usually a better tool.
- Apps built around very new or unusual native APIs — possible, but may need custom native modules and more time.
- If a website would do — a PWA can be cheaper when you don't need the stores or deep device access.
Checklist before you start an Expo project
- Clear list of device features needed (camera, push, location, payments)
- Decision on iOS, Android or both at launch
- Apple and Google developer accounts owned by your company
- Access to the Expo/EAS account for your organization, not only the developer's personal one
- Update strategy agreed: what goes via OTA, what needs a store release
- Analytics and crash reporting planned from day one
FAQ
Is a React Native app a "real" native app?
Yes. It uses native UI components and is distributed through the App Store and Google Play like any other app. Users usually can't tell the difference.
Do I need Expo if I use React Native?
Not strictly, but for most new apps it's the recommended path. Expo removes a lot of setup and maintenance work, and you can still add custom native code when needed.
Can OTA updates replace store releases completely?
No. They cover JavaScript and asset changes. Anything that touches native code, permissions or the app's core purpose still goes through a new build and store review.
Can React Native and Expo also build a web version?
Expo supports web as a target, so parts of the app can run in the browser. For a marketing site or SEO-heavy pages, a dedicated website is usually the better choice.
Thinking about an app?
If you want an app for iOS and Android without paying for two separate teams, React Native with Expo is the stack I use for mobile app development. Open the project builder, pick "mobile app", choose the features you need — and you'll get an estimate and a clear next step.
