Mobile apps
Expo or bare React Native?
For a new app, start with Expo, which is what React Native's own documentation points you towards. Keep managing native folders yourself only when you have an existing app that already does, or an unusual constraint you can name.
By itmarkerz Technologies. Updated 30 October 2026.
The question has changed
“Expo or React Native” is a slightly misleading comparison, since Expo is a framework for React Native. An Expo app is a React Native app. The React Native documentation calls Expo “a production-grade React Native Framework” and says: “if you’re building a new app with React Native, we recommend using a Framework.” You can use React Native without one, but you then write your own solutions for core features or assemble libraries yourself, and that path suits teams with unusual constraints or a preference for solving those problems directly.
Three things people confuse
| Term | What it is | What it means for you |
|---|---|---|
| Expo Go | A ready-made app for running Expo projects | Good for trying things. It can’t add arbitrary native libraries or change native configuration |
| Development build | Your “own version of Expo Go”, using expo-dev-client | Can use any native library and change native configuration. Expo recommends this for an app you will release |
| Prebuild (CNG) | Generates android and ios folders from your configuration when needed | You maintain configuration and config plugins, rather than native projects |
npx create-expo-app@latest
npx expo prebuild --clean # regenerate the native folders from configPrebuild is optional. Expo’s documentation says projects that manage their native folders by hand shouldn’t run it, because it can overwrite those changes. Avoid editing generated folders, since a clean run can lose those edits too. Put customisations in a config plugin.
How to choose
| Your situation | Our default | Why |
|---|---|---|
| New app, typical features | Expo with development builds | It is the recommended route, with less native maintenance |
| New app, one unusual native SDK | Expo with a config plugin or native module | Try it first, because one SDK rarely justifies leaving |
| Existing app with heavy native changes | Keep the native folders, and upgrade carefully | A migration may be a project of its own, and needs a reason |
| Brownfield: React Native inside an existing native app | Read the docs for your case, and prototype | Your native teams and build process set the limits |
| Strict rules against outside build services | Build locally or on your own CI | EAS is optional; check what your rules allow |
What decides it long term: upgrades
React Native releases about every two months and maintains the latest 3 minor series, so you will upgrade regularly whichever way you go. Without generated folders, each upgrade means working through native file changes by hand, using the Upgrade Helper. With Expo, you move one SDK version at a time, as the React Native docs recommend, and generated native projects can be recreated. That maintenance difference tends to matter more than any feature comparison, especially on a small team. For an app that has fallen behind, see upgrading an older React Native app.
React Native work in our portfolio
UK garage-booking SaaS: car owners book, pay, receive invoices and reminders from their phone; garages manage services and slots. Laravel API, Next.js web app, React Native iOS/Android apps. About one year.
- Sector
- Automotive
- Region
- UK
- Stack
- Laravel, Next.js, React Native
- Engagement
- Product build, about one year
Questions
Is Expo still just for simple apps?
That reputation comes from Expo Go, which can't include arbitrary native libraries. A development build can use any native library and change native configuration, so that limit no longer describes Expo as a whole.
Are we locked in to Expo?
Less than you might think. Your app is still React Native, and you can generate the android and ios folders with prebuild and take them over. EAS, Expo's hosted service, is separate from the framework, so check the pricing and terms of whichever parts you use.
Which do you use?
We choose per project and don't publish the setup used on client apps. The reasoning on this page is how we would approach the choice for you.
More on mobile apps
- Wrapped web app or React Native? We've shipped bothA decision table from a three-month wrapped app and a year-long React Native SaaS.
- One Laravel API, web and mobile: how we structure itOne API for a Next.js site and React Native apps, without two sets of rules.
- Getting a wrapped app through store reviewWhat Apple and Google publish about repackaged websites, and what to build.
- Upgrading an older React Native appThe support window, the New Architecture and an order of work.
Starting an app, or inherited one?
Tell us what it needs to do and how it is set up today. We will tell you what we would keep and what we would change.
We reply within one business day (IST).