Ask what is Expo in React Native circles and you will get answers from three different eras. Someone who last touched it in 2019 will tell you it is a toy sandbox you have to “eject” from. Someone from 2022 will say it is fine until you need a native module. And someone shipping today will tell you it is simply how you build React Native apps now. The third person is right, and the gap between these answers causes real teams to make wrong decisions based on expired information.
Here is the current picture, with versions checked as of August 2026, and an honest section on when Expo is still the wrong call.
What is Expo, exactly?
Expo is a framework and a toolchain built on top of React Native. React Native itself gives you the rendering engine and the bridge to native APIs; Expo adds everything around it: a curated SDK of native modules (camera, notifications, filesystem, sensors and about 80 more), a build system, an over-the-air update service, file-based routing, and the developer workflow that glues it together. If you are new to the distinction between React and React Native itself, start with our React vs React Native breakdown.
It is also, notably, the official recommendation. The React Native documentation’s getting-started path tells you to create a new app with a framework, and Expo is the framework it names. The days of Expo as the unofficial side quest are over; bare React Native without a framework is now the special case you opt into, not the default.
As of August 2026 the current release is Expo SDK 57, which pairs with React Native 0.86.2 and React 19.2.3. Expo ships a new SDK roughly three times a year, each tracking a recent React Native release, and patches continuously (57.0.15 landed this month).
The mental model: Expo Go, development builds, and CNG
Three concepts explain modern Expo. Get these and everything else falls into place.
Expo Go is a demo, not your app
Expo Go is the sandbox app from the app stores that runs your JavaScript instantly. It is genuinely great for learning and prototyping, and it is where the “toy” reputation comes from, because your code is limited to the native modules Expo Go happens to include. Production teams do not ship through Expo Go. They use development builds.
Development builds are Expo Go for your app
A development build (via the expo-dev-client package) is your actual app, with your exact native dependencies compiled in, plus the fast-refresh developer experience. Any native module works. This single feature killed the old “Expo cannot do native code” objection years ago, and it is remarkable how many comparison articles have not noticed.
Continuous Native Generation replaced ejecting
The old story: Expo hides the ios and android folders until the day you “eject,” receive ten thousand lines of generated native project, and maintain them forever after. The current story: those folders are treated as build artifacts. Your app is defined by app.json and config plugins, and npx expo prebuild regenerates the native projects from config on demand. Upgrades stop being archaeology on hand-edited Xcode projects. You can still drop to raw native projects when you truly need to; the point is you no longer pay that cost by default.
# the modern loop
npx create-expo-app my-app
cd my-app
npx expo prebuild # generate native projects from config
npx expo run:ios # or build in the cloud with EASEAS: the paid layer (and the strategic question)
Expo Application Services is the hosted infrastructure: EAS Build compiles iOS and Android binaries in the cloud (no Mac required for iOS builds), EAS Submit pushes to the stores, EAS Update delivers over-the-air JavaScript updates, and EAS Observe, which left preview and went generally available on August 20, 2026, adds monitoring and performance insights. There is a free tier that comfortably covers side projects; production teams typically land on paid plans priced by build volume and usage.
The honest strategic note: EAS is optional (everything builds locally too), but it is deliberately convenient, and Expo now covers builds, distribution, updates and observability in one subscription. That consolidation is mostly great. It also means a growing share of your delivery pipeline lives with one vendor, which is worth a conscious decision rather than a sleepwalk.
expo-router: file-based navigation
expo-router (now version-aligned with the SDK, 57.0.15) gives React Native the file-based routing model web developers expect: screens are files, routes are directories, deep links work by construction, and every screen is URL-addressable across iOS, Android and web. It sits on top of React Navigation, so you are not betting on an exotic stack. For new Expo apps it is the default and, in our experience, the right one.
When you should NOT use Expo
The list is shorter than it used to be, but it is not empty.
- Brownfield apps. Adding React Native screens to an existing native iOS or Android app is a bare React Native integration story. Expo’s tooling assumes it owns the project.
- Heavy custom native architecture. If your team writes substantial Swift and Kotlin daily, owns custom build pipelines, or maintains forks of native dependencies, CNG’s regenerate-from-config model can fight you. Config plugins cover most cases; they do not cover all of them.
- Binary size obsessives. An Expo app carries some modules you may not use. The margin has shrunk with tree-shaking improvements, but if every megabyte is a KPI, measure before committing.
- Teams that refuse cloud build dependencies. You can run everything locally, but you will be swimming against the tooling’s current. Decide up front whether that friction is acceptable.
Everyone else, which in practice means most product teams building an app-store app from scratch, should default to Expo. That is not fanboy talk; it is what the upgrade experience, the module ecosystem and the official recommendation all point to. If you are still weighing React Native itself against alternatives, our Flutter vs React Native comparison covers that decision.
So, should you use it?
Use Expo if you are starting a new React Native app in 2026: you get the officially recommended framework, native module freedom via development builds, upgrades that do not require native project surgery, and an optional cloud pipeline that takes builds, store submission, OTA updates and now monitoring off your plate. Skip it for brownfield integrations and deeply custom native setups. And update your priors if they are from the eject era; the framework you remember no longer exists.
FAQ
Is Expo free?
The framework and tools are open source and free. EAS cloud services have a free tier; production usage of builds, updates and monitoring is paid.
Can Expo apps use any native module?
Yes, via development builds and config plugins. The limitation people remember applies only to the Expo Go sandbox app.
What React Native version does Expo SDK 57 use?
React Native 0.86.2 with React 19.2.3, as of August 2026.
Do I still need to eject from Expo?
No. Ejecting was replaced by Continuous Native Generation: native projects are generated from your config with npx expo prebuild and can be regenerated at any time.