Expo or bare React Native: how I decide
The choice is less about features than about how much native code you expect to own in six months.
Hammad Iqbal
Software Engineer
Every new React Native project starts with the same question: Expo or a bare workflow? The old answer was 'Expo until you hit a wall'. The walls are much further away now, so the question has changed. It is no longer what Expo can do, but how much native code you realistically expect to maintain.
- Start with Expo unless you already know you need a custom native module that has no config plugin.
- Prebuild and config plugins cover most native needs without giving up the managed tooling.
- The real cost of going bare is upgrades, not setup.
Start from the upgrade story
Creating a project is a one-day cost. Upgrading React Native across two or three versions is the cost that shows up every few months. Expo's tooling keeps native folders generated and consistent, which makes those upgrades a diff review instead of an archaeology project.
Config plugins cover more than people think
Most native setups people reach for, such as permissions, URL schemes, and push notification entitlements, are covered by config plugins. If a library ships one, you stay in the managed flow. If it does not, writing a small plugin is often easier than ejecting.
When bare is the honest answer
If the app wraps a vendor SDK that needs hand-edited Gradle or Xcode project changes, or you maintain your own native modules, owning the native folders is simply the accurate description of the project. Choose it on purpose, not as a reaction to the first error.
Pick the workflow that matches the native code you will actually own, and revisit it only when that changes.
Have a project this kind of thinking applies to?
Tell me what you're building — I read every message myself.