Mobile — Expo Development

Expo vs Bare React Native: Decision Framework for Startups

Direct answer

For most startups I recommend starting with Expo. With continuous native generation (prebuild) and config plugins, there is almost no native capability that Expo blocks anymore, and EAS handles the build and signing pain that kills early velocity. Go bare only if you are embedding React Native into an existing native app, maintaining large amounts of custom native code in-repo, or your build infrastructure cannot accommodate prebuild. The old advice to eject once you get serious is outdated.

The Expo-vs-bare question is the first architectural decision every React Native startup makes, and most founders decide it based on blog posts from five years ago. The tradeoffs have changed completely, and picking wrong costs real engineering weeks. Here is the framework I actually use when advising teams.

Key facts, with sources

71% of State of React Native 2024 respondents reported using Expo's EAS Build, ahead of manual builds with Xcode (59.7%) and Android Studio (54.5%). (InfoQ)
Expo SDK 52, released November 12, 2024, enabled the New Architecture by default for all new projects, and Expo Go for SDK 52 and higher supports only the New Architecture. (Expo Changelog)
The official React Native documentation now recommends starting new apps with a framework, naming Expo, rather than initializing a bare project. (React Native documentation)
EAS build caching can speed up subsequent Android and iOS builds by up to 30% and is available to all users at no additional cost as of the SDK 57 cycle. (Expo Changelog)
Doctolib runs Expo tooling without EAS to scale developer experience on a healthcare app serving 90 million users, showing Expo's open-source tools work independently of its paid cloud services. (Doctolib Engineering (Medium))

Why the old advice is wrong

The classic objection to Expo was that you couldn't use arbitrary native modules without ejecting, and ejecting was a one-way door into a messy hybrid project. Neither is true today. Modern Expo projects use continuous native generation: the ios and android directories are build artifacts generated from app.json and config plugins, not hand-maintained source. Any native module that works in bare React Native works in an Expo project — you install it, add its config plugin if it needs one, and rebuild.

When I audit startup codebases, the teams that went bare 'to be safe' usually have the worst upgrade posture: they are stuck two or three React Native versions behind because nobody wants to hand-merge native project changes. Expo teams run a single upgrade command and fix JS-level breakage. That difference compounds every quarter.

What Expo buys a startup commercially

The technical features matter less than what they translate to in runway. EAS Build means nobody on the team needs to babysit Xcode signing or keep a Mac build machine alive — iOS builds run in the cloud from any laptop. EAS Update means a critical JS bug ships to users in minutes instead of waiting days for store review. Managed upgrades mean you track React Native releases instead of falling behind.

There is also a hiring angle I see constantly: junior and mid-level React Native developers are dramatically more productive in an Expo project because the sharp native edges are abstracted. For a seed-stage team that can't afford a dedicated native specialist, that alone often justifies the choice.

When bare is genuinely the right call

Bare React Native earns its keep in three situations. First, brownfield: you are adding React Native screens to an existing native iOS or Android app. Expo's tooling assumes it owns the whole project, so brownfield integration belongs in bare territory. Second, heavy in-repo native development: if your product's core is custom native code — a specialized camera pipeline, an audio engine, deep Bluetooth work — and native engineers live in the ios and android folders daily, generated native projects get in their way.

Third, hard build-infrastructure constraints: some enterprises require builds on their own audited machines with hand-controlled native projects. You can run prebuild locally and build without EAS, but if the organization treats generated native code as unacceptable, don't fight that battle.

The decision framework I use

I ask four questions in order. One: is this a new app or an addition to an existing native app? Existing native app means bare, full stop. Two: will more than roughly a fifth of engineering time be spent writing custom native code? If yes, lean bare; if native work is occasional module integration, Expo. Three: does the team have dedicated iOS and Android expertise? If no, Expo removes the categories of failure that stall teams without it. Four: are there compliance constraints on where builds run? EAS supports local builds, so this is rarely disqualifying, but verify before committing.

For a typical B2B or consumer startup MVP the answers land on Expo every time. I've stopped treating this as a close call — the burden of proof is now on choosing bare.

Switching costs in both directions

Moving from Expo to bare is cheap: run prebuild once, commit the generated native projects, and stop regenerating them. You lose config-plugin automation but keep everything else, and the app keeps working. This makes Expo a low-risk default — the exit door is wide open.

Moving from bare to Expo is harder and I've done it several times for clients. Every hand-edit in the native projects has to be reproduced as a config plugin or dropped, which means archaeology through years of undocumented Xcode tweaks. It typically takes a week or two for a mature app. That asymmetry is the strongest argument for starting with Expo: the cheap migration is the one you might actually need.

When to hire senior help

Senior help pays off when deciding between managed and prebuild workflows, setting up EAS-based CI/CD and OTA update channels, or untangling a project that was ejected prematurely. An experienced Expo engineer can usually configure build, submit, and update pipelines in days, a task that costs first-time teams weeks of trial and error. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — Expo Development projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

✕Ejecting to the bare workflow at the first native requirement instead of using config plugins and development builds, permanently giving up managed upgrades
✕Testing only in Expo Go and misconfiguring runtime versions for expo-updates, so an OTA update ships JavaScript that crashes against mismatched native binaries
✕Burning EAS build minutes on every commit in CI without caching or local builds, turning a convenience service into a surprise line item
✕Skipping several SDK upgrades in a row, then being forced into a large breaking migration when app store target API level deadlines arrive

Frequently asked questions

Can Expo apps use any React Native native module?

Yes. Modern Expo projects generate their native code with prebuild, so any module that works in bare React Native works in Expo — you install it and rebuild with a development build. Modules needing native configuration usually ship a config plugin. The only real exception is brownfield setups where React Native is embedded inside an existing native app.

Is Expo production-ready for a serious startup app?

Yes. Expo is a build and tooling layer on top of React Native, not a separate runtime, so the shipped app is a normal native binary. Plenty of high-scale production apps run on Expo tooling. The practical question isn't whether Expo can handle production — it's whether your team has unusual native or build-infrastructure requirements that make bare React Native a better fit.

How hard is it to leave Expo later if we outgrow it?

Easier than most founders assume. Running prebuild generates standard native iOS and Android projects; commit those and you're effectively a bare React Native app. Your JavaScript code doesn't change. The reverse migration — bare to Expo — is the expensive one, because manual native edits must be converted to config plugins. Starting with Expo keeps the cheap exit available.

Should we use Expo or plain React Native for a new app?

The React Native docs themselves now recommend starting with a framework, and Expo is the primary one; 71% of surveyed developers already build with EAS. Expo today supports custom native code through development builds and config plugins, so the old limitations that forced teams to avoid it mostly no longer apply.

Does Expo lock us into their platform?

No; expo prebuild can generate standard native iOS and Android projects at any time, and the open-source tooling works without Expo's paid EAS services, as demonstrated by Doctolib running Expo without EAS on an app with 90 million users. EAS Build, Submit, and Updates are optional conveniences, not requirements.

Is Expo production-ready for a serious commercial app?

Yes; Expo Go is only a development sandbox, while production apps ship as normal store binaries built with EAS or locally. Plan for the SDK release cadence of roughly three versions per year, since staying current is required to keep up with store policy and React Native releases.

Bottom line: Dhairya Senjaliya ships Mobile — Expo Development projects worldwide. Book a scoping call at https://dhairyasenjaliya.com/#book-call.