Expo vs React Native CLI in 2026: Which to Pick
"Should I use Expo or the plain React Native CLI?" is probably the question we get asked most, by clients, by buyers of our kits, and by developers starting their first mobile app.
A few years ago the honest answer was "it depends, and Expo has real limits". Today the answer is much simpler for most people. But the CLI still has its place, and picking the wrong one can make the first months harder than they need to be.
Here is how we think about it, in plain terms.
The 30-second version
- Start with Expo if you are building a typical app: accounts, lists, forms, payments, maps, notifications, a backend API. That covers most apps people actually ship.
- Consider the React Native CLI if your app depends heavily on custom native code, you have an existing native iOS or Android app to integrate with, or your team wants full manual control over the native projects.
If you are not sure which group you are in, you are almost certainly in the first one.
What the difference really is
Both options give you the same thing at the core: React Native. You write the same components, use the same JavaScript or TypeScript, and most libraries work in both.
The difference is in everything around that core:
- Who manages the native iOS and Android projects. With the CLI, the
iosandandroidfolders live in your repository and you maintain them yourself. With Expo, those folders can be generated from your configuration whenever you need them, so you rarely edit them by hand. - How you build and release. Expo comes with a build and release service (EAS) that builds your app in the cloud and can push certain updates without a new store release. With the CLI, you set up builds yourself, usually with Xcode, Android Studio or your own CI pipeline.
- How much is decided for you. Expo makes sensible choices for routing, configuration and native modules. The CLI leaves those choices to you.
The React Native team itself now recommends starting new apps with a framework, and Expo is the one they point to first. That alone tells you where the ecosystem is heading.
The old myth: "Expo can't do native code"
This is the reason many developers still avoid Expo, and it is out of date.
Years ago, Expo apps ran inside a fixed container, and if you needed a native library that wasn't included, you had to "eject" and deal with the consequences. That is no longer how it works. Today you can add native libraries, write your own native modules, and use config plugins to change native settings, all while staying in Expo.
What is still true is that Expo Go, the app you install from the store to preview projects quickly, only supports the native code it ships with. Once you add your own native libraries, you switch to a development build, which is basically your own version of Expo Go with your libraries included. It takes a few minutes to set up and then works the same way.
So the real question is no longer "can Expo do it?" but "how much native work will this app need, and who will maintain it?"
Side by side
| Expo | React Native CLI | |
|---|---|---|
| First run | Minutes | Longer: Xcode and Android Studio setup first |
| Native code | Yes, through development builds and config plugins | Yes, full direct access |
| iOS and Android folders | Generated from config when needed | Kept in your repo and maintained by you |
| Upgrades | Usually smoother, one SDK at a time | More manual, especially for native files |
| Builds | Cloud builds with EAS, or local | Your own setup: local or CI |
| Over-the-air updates | Built in (EAS Update) | Possible, with extra tools |
| Best for | Most new apps, small teams, fast launches | Heavy native work, brownfield apps, full control |
When Expo is the better choice
You want to launch quickly. Setup is fast, and you spend your first days on the app, not on build tools.
Your team is mostly JavaScript developers. Nobody needs to be an Xcode or Gradle expert to get a build out. That matters a lot for small teams and freelancers.
You care about smooth upgrades. React Native moves fast. Expo bundles a tested set of versions into each SDK, which takes much of the pain out of upgrading. With the CLI, upgrades can mean comparing and editing native files by hand.
You want quick fixes after launch. With over-the-air updates you can ship JavaScript fixes to users without waiting for app store review. You still need a store release for native changes, but for a typo or a small bug, it is a big relief.
When the CLI still makes sense
You are adding React Native to an existing native app. If you already have a large iOS or Android codebase and want to add a few React Native screens, the CLI approach fits that "brownfield" setup more naturally.
Your app is built around custom native work. Think specialised camera or audio processing, unusual hardware, or SDKs that require deep native setup. Expo can handle much of this, but if most of your work happens in Swift or Kotlin anyway, managing the native projects directly may simply be more comfortable.
Your team already has a native pipeline it trusts. If your company has existing CI, signing and release processes for native apps, there may be little reason to change them.
Can you switch later?
Mostly, yes, and that should take some pressure off the decision.
If you start with Expo and later need full control, you can generate the native projects and continue as a regular React Native app. Going the other way, from a CLI project to Expo, is also possible because Expo modules can be added to existing React Native apps, though it usually takes more work.
Because of this, starting with Expo is the lower-risk choice. You keep most of your options open, and you only take on native complexity when your app actually needs it.
What this means if you are buying a UI kit
If you are buying a ready-made React Native kit, check which setup it uses, because it decides how you will run, build and update the app from day one.
- An Expo kit is usually the fastest to get running. You can often open it on your phone within minutes and start changing colours and screens straight away.
- A CLI kit suits teams that already work with native projects, or apps that will need a lot of native code.
Many sellers, including us, offer the same app in both versions. Pick the one that matches how your team works, not the one with the longer feature list. If you want a full checklist for comparing kits, read our guide on how to choose a React Native UI kit.
Our recommendation
For most new apps in 2026, start with Expo. It removes a lot of setup and upgrade work, it no longer locks you out of native code, and you can still move to a fully custom native setup later if you have to.
Choose the React Native CLI when you know from day one that native code will be a large part of the project, or when you are adding React Native to an app that already exists.
If you want to see what a production-ready Expo project looks like, you can browse our Expo projects, such as the GS ChatApp messaging kit, or everything we build with React Native. And if you are still unsure which setup fits your idea, tell us about it. We are happy to give you an honest answer, even if it is "you don't need to buy anything".