Expo vs React Native CLI

A few years ago, Expo meant a managed sandbox. You could not add arbitrary native code, and serious apps "ejected" to bare React Native sooner or later. That is out of date. Expo apps today can include any native library and any custom Swift or Kotlin code, and the React Native documentation now recommends starting new apps with a framework, naming Expo.

The real difference is who manages the native projects. With Expo's Continuous Native Generation, the ios and android folders are generated from your app config and config plugins whenever you need them. With a bare project from the React Native Community CLI, those folders are source code you own and edit by hand.

Pick Expo for almost every new app. Prebuild and config plugins mean native settings live in a few lines of config instead of scattered across Xcode and Gradle files, which makes upgrades far less painful: you bump the SDK and regenerate, rather than merging diffs into native projects.

Pick it when you want over-the-air updates. EAS Update ships JavaScript fixes to users without a store release, within the app store rules, and you can self-host an update server if you would rather not use Expo's service.

And pick it when the team is small. Expo Router, development builds, the SDK's native modules, and EAS Build and Submit remove a lot of toolchain work, so the hours go into the app.

Pick a bare React Native project when you are adding React Native screens into an existing native iOS or Android app, and the native projects are already the source of truth. Expo has brownfield support too, but in an established native codebase many teams prefer to integrate React Native directly.

Pick it when your team has strong native engineers who want full, direct control of the Xcode and Gradle projects and are happy to own upgrades by hand.

And pick it when a library you depend on needs native project changes that no config plugin covers and you would rather not write one. That case is rarer every year, but it exists.

"Expo means paying for EAS." It does not. Expo itself is open source, and you can build locally with npx expo run or in your own CI. EAS Build, Submit, and Update are hosted services with a free tier and paid plans, and they are worth it for many teams, but they are optional.

"Expo apps cannot use native code." They can. Expo Modules gives you a Swift and Kotlin API for writing your own native modules, and community native libraries work in development builds. Expo Go, the sandbox app, is only for quick prototypes and is not how production Expo apps run.