If you are starting a new React Native project in 2025, you are almost certainly starting with Expo. It has become the recommended default even in React Native's own documentation. But Expo presents you with a choice early on: the Managed Workflow or the Bare Workflow. This choice is more consequential than it appears, and picking the wrong one can mean painful migration work six months into development. This guide gives you a clear-eyed view of what each workflow actually means, where the limits are, and how to make the right call for your project.
What Expo Actually Is — and What It Is Not
Before comparing the workflows, it is worth clarifying what Expo is. Expo is not a separate framework from React Native — it is a platform built on top of React Native that provides a set of tools, libraries, and services. The core of Expo is the Expo SDK: a collection of well-maintained native modules that cover the most common app needs — camera, location, push notifications, file system, sensors, payments, and dozens more. These modules have consistent APIs, are kept up to date with OS changes, and are tested together.
Beyond the SDK, Expo provides a suite of services under the EAS (Expo Application Services) umbrella: EAS Build for cloud-based native builds, EAS Submit for automated App Store and Play Store submission, and EAS Update for over-the-air JavaScript updates to deployed apps. These services are available to both Managed and Bare Workflow projects.
The workflow choice is fundamentally about how much of your project's native layer Expo manages for you.
The Expo Managed Workflow: Maximum Abstraction
In the Managed Workflow, Expo manages your native projects entirely. You do not have an ios/ or android/ folder in your repository. Instead, you configure native settings through app.json (or app.config.js for dynamic configuration). Expo translates those settings into the correct native project configuration when it builds your app — either locally via Expo Go for development, or in the cloud via EAS Build for production.
The experience for a developer on a Managed Workflow project looks like this: write JavaScript and TypeScript, use Expo SDK modules for native features, configure everything through app.json, and use EAS Build to produce your .ipa and .apk files without ever opening Xcode or Android Studio. For many projects, this workflow is entirely sufficient — and it is dramatically simpler to operate.
What the Managed Workflow Gets Right
Zero native toolchain setup. New team members clone the repo, run npm install, and have a working development environment in minutes. No Xcode configuration, no Android SDK path issues, no Gradle version conflicts. For teams with web developers contributing to a mobile project, this is enormously valuable.
OTA updates with EAS Update. Because the Managed Workflow controls your app's structure, EAS Update can push JavaScript changes directly to users' installed apps, bypassing the App Store review process. A bug fix that would normally take 24-48 hours to clear Apple's review can reach users in minutes. This is one of the most practically valuable features in the Expo ecosystem, and it is available to Managed Workflow projects with essentially zero configuration.
Consistent SDK compatibility. Expo SDK versions are tested as a cohesive unit. When you upgrade from Expo SDK 51 to SDK 52, the upgrade guide tells you exactly what changed, which packages to update, and what breaking changes to watch for. This is a significant operational advantage over managing a collection of individually versioned native modules in a Bare Workflow project.
Config plugins for native customization. The Managed Workflow is not as rigid as it used to be. Config plugins — introduced in Expo SDK 41 — let you modify native project files at build time without permanently checking in an ios/ or android/ folder. Many common customizations (adding a native module, configuring entitlements, adding background modes) are now achievable through config plugins while staying in the Managed Workflow.
Where the Managed Workflow Has Limits
The Managed Workflow's power comes from its constraints. If you need a native module that does not have an Expo SDK equivalent and does not have a config plugin, you are stuck. You either wait for the ecosystem to catch up, write your own config plugin (which requires native development knowledge), or migrate to the Bare Workflow.
Common scenarios that push projects out of the Managed Workflow include: deeply customized push notification handling (beyond what Expo Notifications provides), certain Bluetooth Low Energy integrations, custom native SDKs from enterprise vendors (some analytics, DRM, or hardware SDKs), and apps requiring custom native build phases or Xcode capabilities that Expo's config plugin system does not yet support.
It is also worth noting that the Managed Workflow requires using EAS Build for production builds. You cannot build a Managed Workflow app locally without first running expo prebuild to generate the native projects — which is effectively migrating to the Bare Workflow temporarily. EAS Build has a generous free tier (30 builds/month), but organizations that build frequently may hit limits on the free plan.
The Expo Bare Workflow: Full Native Access
The Bare Workflow gives you what the Managed Workflow withholds: the ios/ and android/ folders live in your repository. You have full, direct access to the native projects. You can open them in Xcode or Android Studio, add any native module, modify any native file, and configure the build process exactly as you would with a vanilla React Native CLI project.
The Bare Workflow is still very much an Expo project — you still use the Expo SDK, EAS Build, and EAS Update. You just also have the native layer checked into version control and under your direct control.
A project created with npx create-expo-app --template bare-minimum starts with the native folders present and no assumptions about which SDK modules you will use. Alternatively, running npx expo prebuild in a Managed Workflow project generates the native folders from your current app.json configuration — this is the standard migration path from Managed to Bare.
What the Bare Workflow Gets Right
No native restrictions. Any React Native library works. Any native SDK works. Any Xcode capability or Android manifest configuration is available. If you need to integrate a proprietary hardware vendor's iOS SDK, add a custom iOS App Extension (for widgets, share extensions, or notification service extensions), or configure a custom Gradle build variant, the Bare Workflow handles all of it without friction.
Familiar tooling for native developers. iOS developers already know Xcode. Android developers already know Android Studio. If your team includes experienced native developers, the Bare Workflow lets them work in their native environment while JavaScript developers work in theirs. The projects coexist cleanly.
Explicit control over native dependencies. In the Bare Workflow, your Podfile and build.gradle files are explicit and version-controlled. You know exactly what native dependencies are included, at what version, and why. In the Managed Workflow, this is opaque — Expo controls it, and you see the result only at build time.
Where the Bare Workflow Has Costs
That access comes with operational overhead. Your repository now includes native project files that require maintenance. When you upgrade React Native or a native dependency, you may need to follow a native migration guide and resolve native code conflicts — not just update a package.json version number. New team members need Node, Xcode, and Android Studio correctly configured. Your CI/CD pipeline needs either EAS Build or a self-hosted native build environment.
Native merge conflicts are real. If two developers modify the same native file — AppDelegate.mm, MainApplication.kt, or a Podfile — resolving those conflicts requires understanding native code. For a team without native expertise, this can be a significant pain point.
EAS Build: The Great Equalizer
One of the most important things to understand about the Managed vs. Bare choice in 2025 is that EAS Build works equally well for both. EAS Build runs your builds in the cloud on macOS virtual machines (for iOS) and Linux machines (for Android). It handles code signing, provisioning profiles, and certificate management automatically through EAS Credentials.
For Managed Workflow projects, EAS Build runs expo prebuild before compiling — generating the native projects on the fly and then building them. You never need to commit native files. For Bare Workflow projects, EAS Build uses your committed native projects directly.
The practical implication: teams using the Managed Workflow do not need Mac hardware to build iOS apps. A Windows or Linux developer can trigger an iOS build via EAS Build and have a testable .ipa file in 10-20 minutes. This is genuinely transformative for cross-platform teams and removes one of the traditional barriers to iOS development.
OTA Updates: How EAS Update Works in Each Workflow
Over-the-air updates are one of React Native's most compelling operational advantages over native development. EAS Update lets you push new JavaScript bundles to users' installed apps without going through App Store review — within the limits Apple and Google permit (you cannot change an app's core functionality or add new permissions via OTA).
In the Managed Workflow, EAS Update is configured with essentially zero setup — add the expo-updates package and configure your update URL in app.json. In the Bare Workflow, EAS Update requires a few additional configuration steps in your native files, but it works identically once set up. Both workflows support update channels (production, staging, preview), rollback, and update analytics.
The real-world impact of OTA updates is significant. Critical bug fixes that affect user experience or cause crashes can reach users within minutes of deployment, rather than waiting 24-72 hours for App Store review. For apps serving business-critical workflows — field service, logistics, retail — this responsiveness is a meaningful operational advantage.
When to Choose the Expo Managed Workflow
The Managed Workflow is the right default for the majority of React Native projects. Choose it when:
- Your feature requirements are met by the Expo SDK. Before assuming you need native access, check whether Expo already covers your use case. The SDK covers camera, location, biometrics, push notifications, sensors, haptics, file system, contacts, calendar, payments, in-app purchases, and much more.
- Your team has limited native iOS and Android experience. The Managed Workflow removes native complexity from the day-to-day development experience. Teams of JavaScript developers can build production-quality apps without touching Xcode or Android Studio.
- Development speed is a priority. Onboarding is faster. Upgrades are more straightforward. OTA updates require less configuration. If you are building an MVP or running lean, the Managed Workflow reduces operational overhead substantially.
- You want to defer the Bare Workflow decision. You can always migrate from Managed to Bare by running
expo prebuild. Starting Managed and migrating later is a viable and commonly used path — you are not locked in.
When to Choose the Expo Bare Workflow
The Bare Workflow is the right choice in specific circumstances:
- You need a native module with no Expo SDK equivalent and no config plugin. If a vendor SDK, hardware integration, or custom native capability requires direct native code modifications, the Bare Workflow is necessary.
- Your team includes experienced iOS and Android developers. If native developers are already on the team, the Bare Workflow lets them work in their native environment without friction. The overhead of maintaining native files is not a burden if you have people who understand them.
- You are building app extensions. iOS widgets (WidgetKit), share extensions, notification service extensions, and Safari extensions all require native targets added to your Xcode project. These are achievable in the Managed Workflow via config plugins for common cases, but complex configurations benefit from direct native access.
- You have very specific build configuration requirements. Custom Gradle flavors for white-label apps, custom build phases, code obfuscation configurations, or specific certificate chain requirements are simpler to manage when you own the native project files.
The Migration Path: From Managed to Bare
If you start Managed and later discover you need native access, the migration is well-defined. Running npx expo prebuild generates your ios/ and android/ folders from your current app.json configuration. From that point, you are operating in the Bare Workflow. Your existing Expo SDK modules continue working. EAS Build, EAS Update, and EAS Submit all continue working. The transition is largely transparent to the rest of the project.
The reverse migration — from Bare back to Managed — is not supported and is rarely needed. If you find yourself wanting to go back to Managed, it usually means the native files have not grown particularly complex, and the correct move is to clean up the native project and rely on config plugins for any remaining customizations.
A Practical Decision Framework
Here is how to think through the choice for your specific project:
Start by listing every native capability your app requires. Cross-reference that list against the Expo SDK documentation and the Expo community config plugins directory. If every item on your list is covered, start with the Managed Workflow. If one or two items are not covered, check whether a config plugin exists in the community. If native requirements are clearly beyond what the Managed Workflow can address — proprietary SDKs, complex app extensions, custom native targets — start with the Bare Workflow.
If you are unsure, default to Managed. It is the lower-risk starting point, and the migration path to Bare is straightforward when you know exactly what you need from it.
The Managed Workflow removes complexity you do not need. The Bare Workflow gives you access to complexity you do. Most projects need the former; some eventually need the latter. You can always get there from here.
What We Use at mobilapp.net
Our default at mobilapp.net is the Expo Managed Workflow with EAS Build and EAS Update for most client projects. It delivers the fastest development cycle, the lowest operational overhead, and still covers the native requirements of the vast majority of business applications. For projects requiring proprietary SDK integrations or complex native extensions, we use the Bare Workflow from day one — or migrate when the requirement is confirmed, which avoids carrying native complexity before it is needed.
Both workflows are production-ready and used by large-scale apps in 2025. The choice between them is not about quality — it is about the right level of abstraction for your project's specific requirements and your team's specific skills.