Expo or React Native CLI?
Once you've chosen React Native, the choice is between Expo and the plain CLI. Expo automates builds, certificates, and updates, and in 2026 it's the standard recommendation for most new projects. The bare workflow is needed mainly for unusual native modules Expo doesn't support. You can switch later if needed, so simplicity rarely costs anything in practice.
You’ve landed on React Native. Then a technical choice remains that affects daily work more than it sounds: should the app be built with Expo or with the plain React Native CLI? These aren’t two different frameworks but two ways of working within the same one, with different amounts of automation. Here’s the difference from a buyer’s and team’s perspective, and why the pendulum swung toward Expo in 2026.
What Expo automates for you
Expo is a toolkit on top of React Native that handles a lot of infrastructure that would otherwise sit with the team. The most important things it manages:
- Builds. Expo builds finished app files for you, in the cloud or locally, without anyone having to configure the Xcode and Android projects by hand.
- Certificates and signing. It manages the certificates and keys that Apple and Google require, a step that’s otherwise a classic source of hassle and lost time.
- Over-the-air updates. Expo can push certain updates straight to users without going through store review, which speeds up small fixes.
- The development workflow. Simpler startup, simpler sharing of test builds, and fewer local tools for each developer to install.
The price for this convenience used to be control: older Expo locked you out of certain native libraries. That limitation is effectively gone today through config plugins and custom builds, which is the whole reason the recommendation changed.
When the plain CLI or bare workflow is needed
The plain CLI gives you the bare native projects and full control, but it also puts all responsibility for the build and certificate infrastructure on your team. That’s justified in a clear minority of cases:
| Situation | Reasonable choice |
|---|---|
| Ordinary business app, new project | Expo |
| Team without its own native infrastructure | Expo |
| Unusual native module Expo doesn't support | Bare workflow / CLI |
| Need for deep control over the native projects | Bare workflow / CLI |
| Unsure about the need | Start in Expo, switch if needed |
The key insight is that the choice isn’t permanent. Expo has a way out: the day a concrete need requires the underlying native projects, you can leave Expo and continue as a bare project. So you don’t need to hedge in advance by opting out of the simplicity.
What it means for cost and pace
For you as the buyer, the choice ultimately comes down to time, and time is money. With Expo, the team spends less of the first weeks setting up build chains, handling certificates, and wrestling with signing, work that doesn’t show up in the finished app but still has to be done and paid for. That time can instead go into the app’s actual features.
With the plain CLI, you’re paying for the team to build and maintain that infrastructure itself. Sometimes that’s warranted, but often it’s work a well-run toolkit has already solved for you. A common misconception is that more control is always better, in practice, unneeded control is just a cost without matching benefit. The question to ask isn’t “do we want control?” but “do we have a concrete need that requires it?”
Another everyday plus with Expo is that new developers get up to speed faster, since fewer local tools need to be installed and configured. For a team that grows or changes people over time, that lowers the bar every time someone new joins the project.
A concrete scenario
Say you’re building a booking app with login, payment, and push notifications, features that all have ready-made, well-maintained Expo solutions. Choosing Expo lets the team focus on the app’s actual value instead of spending the first weeks configuring build chains and certificates. If you want to add a very unusual hardware integration a year later that Expo doesn’t support, you take the step out to the bare workflow then, with a year of faster progress behind you. Choosing the CLI from day one “just in case” instead would have cost that time without you yet knowing whether you needed it.
The recommendation for 2026
For the vast majority of new React Native projects, Expo is the default choice. The reason is simple: you get back the time that would otherwise go into infrastructure, without really sacrificing flexibility, since both native libraries and a way out exist when you need them. The bare workflow is reserved for projects with a known, concrete reason to sit closer to the native layer.
At Weapp we build apps in React Native and make this call per project based on what the app actually requires. Want to talk through what setup fits your idea? Take a look at our services or get in touch.
Frequently asked questions
What's the actual difference between Expo and React Native CLI?
Both build apps in React Native, the difference is how much of the surrounding work you handle yourself. Expo is a framework and toolkit on top of React Native that takes care of builds, certificates, and updates for you. The plain CLI gives you full control over the native projects but also puts all responsibility for that infrastructure on your team.
Is Expo only for simple apps?
No, that's an outdated picture. Expo used to have clear limitations, but nowadays you can use pretty much any native library through so-called config plugins and custom builds. Most serious apps can be built fully in Expo today. That's why the recommendation has swung to Expo as the default choice, even for larger projects.
When do you need the plain CLI or the bare workflow?
Mainly when the app depends on an unusual native module that Expo's build system doesn't handle, or when the team needs deep control over the native projects for other reasons. That's a minority of projects. If you're unsure, the advice is to start in Expo, the need to leave will then show itself clearly further down the road.
Can you switch from Expo to the CLI later?
Yes. Expo has a way out where you get access to the underlying native projects and can continue as a bare project. That means the choice isn't a dead end: you can start in the simple Expo flow and take control only the day a concrete need requires it, instead of hedging in advance.
What do Expo's cloud services cost?
Expo can be used for free, and builds can also run locally without a cloud service. The paid plans are mainly about queuing and scaling cloud builds and distributing updates smoothly across teams. For many smaller projects, the free tier goes a long way; for larger teams, the paid plans can save time that would otherwise go into building your own infrastructure.