Expo vs Bare Workflow
A decision guide for teams choosing the right React Native setup.
This decision comes up on almost every new project, and it's usually framed as more of a binary than it actually is. Here's how I actually think about it.
The Old Tradeoff Mostly Doesn't Apply Anymore
A few years ago, choosing Expo meant giving up native code access entirely, and 'ejecting' to bare workflow was a one-way door that was painful to walk through. That's no longer how it works. Modern Expo (with EAS Build and config plugins) supports custom native code via development builds — you get Expo's tooling, over-the-air updates, and simplified build pipeline, while still being able to add native modules that aren't in the Expo SDK. The strict either/or framing is outdated for most projects.
When I Default to Expo
For the large majority of product builds — especially anything client-facing where the team wants to move fast and doesn't have deep native iOS/Android expertise in-house — I default to Expo. EAS Build removes the need to maintain Xcode and Android Studio build environments locally or in CI, over-the-air updates via EAS Update let you ship JS-only fixes without a full store review cycle, and the managed set of well-maintained modules (camera, notifications, secure storage, etc.) covers most product requirements without custom native code.
- New product builds without unusual native requirements
- Teams without dedicated native iOS/Android engineers
- Projects where fast iteration and OTA update capability matter
- Apps that need every SDK Expo already wraps well (camera, location, notifications, in-app purchases)
When I Go Bare (or Expo + Dev Client With Heavy Custom Native Code)
The cases where I reach for bare React Native — or Expo with an extensively customized dev client — are when a project needs a native SDK with no Expo config plugin available and building one isn't worth the investment, when there's an existing native codebase being integrated into (brownfield), or when the team has strong native engineering capacity and wants full direct control over the native project files without any abstraction layer in the way.
The Real Cost Isn't Technical, It's Operational
The honest tradeoff isn't 'Expo is limited' versus 'bare is powerful' — it's operational overhead. Bare React Native means your team owns Xcode project configuration, Android Gradle setup, CocoaPods version conflicts, and CI build environments directly. That's a real cost that either needs dedicated native expertise or eats into feature velocity. Expo shifts that overhead onto EAS Build's managed infrastructure. For most teams, that trade is worth it. For teams that already have strong native tooling expertise and specific reasons to want full control, it isn't.
How I'd Decide for a Specific Project
I ask three questions: does the product need a native SDK without Expo support, and is building a config plugin for it worth the effort versus just going bare? Does the team have native iOS/Android expertise to maintain a bare project, or would that expertise need to be hired/contracted? And how much does OTA update capability matter for this specific product's release cadence? The answers usually make the decision obvious — it's rarely a coin flip once the actual constraints are on the table.
