2. Workflow selection and environment configuration

In the Expo system, the choice of workflow directly determines your project complexity, R&D efficiency, and maintainability. This chapter systematically sorts out the boundaries and combinations of the three modes of Managed, Dev Build and Bare from the perspective of "why you choose this" to "how to implement it", and provides environment configuration paradigms, standard scaffolding and troubleshooting lists suitable for team collaboration and production environments. After reading this chapter, you should be able to make solid choices at the beginning of a project and evolve it smoothly throughout the life cycle without being weighed down by technical debt.

1. Workflow selection: the real boundaries between Managed, Dev Build and Bare

• Managed:

• Core value: Hand over the "complexity and fragility of native engineering" to Expo, and developers focus on JS/TS business. Most official SDK modules are plug-and-play.

• Capability limit: Config Plugins can be used to modify Info.plist, AndroidManifest, and Gradle configurations to solve native layer configuration issues such as permissions, dependencies, and initialization. Combined with Dev Build, clients containing custom native dependencies can be debugged and run in managed mode.

• Typical adaptation: small and medium-sized teams, business lines pursuing rapid verification and high-frequency iteration, products based on JS layer.

• Dev Build:

• What it is: Generate a dedicated debugging App that "contains the native dependencies you need" in Managed mode, replacing Expo Go's capability boundaries.

• Core function: Allows you to use third-party native libraries or self-developed modules for real-machine debugging without ejection.

• When needed: When a module is not in the Expo Go built-in collection (such as IAP, some Bluetooth libraries), or the native configuration needs to be modified.

• Bare (bare workflow):

  • Core value: Full control over ios/ and android/, you can deeply customize the compilation chain, merge with existing native warehouses, and use any native library.
  • Cost: You need to maintain native dependencies, CI, certificates, build scripts and upgrade paths; upgrade costs are high and require greater experience.
  • Adaptation: Strong native requirements (self-developed SDK/deep integration from manufacturers/specific ABI or compiler version requirements), existing native team and infrastructure. Best practice: Choose Managed first, and use Config Plugins and Dev Build to solve 80–90% of the requirements; only switch to Bare when it is confirmed that in-depth native transformation is necessary. This can delay complexity and reduce maintenance costs.

2. For Managed/Bare workflow and local environment

In my opinion, the difference between Managed and Bare is not "whether it is more professional", but "who will drive the native engineering". The starting point of Managed is to try not to touch native, and write permissions, dependencies, manifests, certificates and other changes into app.config.ts and Config Plugins; when actually packaging, EAS "understands these intentions" in the cloud and completes pre-construction and packaging in a clean computer room environment.

Bare is the opposite: you maintain everything about ios/ and android/ yourself, including how to organize the project, how to manage certificates, and how to align the versions