Summary I’m requesting first-class Expo support for multiple environment configuration files such as: app.json (default) app.dev .json app.staging.json app.production.json Expo should automatically load the appropriate file based on the selected build profile (e.g., EAS --profile staging) and fall back to app.json when a key is not overridden. This would eliminate the need for custom logic in app.config.ts and create a clean, scalable configuration system for multi-environment apps. Problem Many Expo apps require different settings across environments: App name & slug Bundle identifiers / package names API endpoints Feature flags Deep link configs Runtime and update settings Right now, developers must manually implement these differences using JavaScript logic inside app.config.ts. A typical setup looks like this: Conditional names Conditional icons Conditional bundle IDs Conditional package names Conditional schemes Conditional runtime settings This results in large, complex, and repetitive configuration logic, and Cannot automatically write to dynamic config at: app.config.ts Current Workaround (TypeScript Example) Here is the kind of environment-switching logic developers currently need to maintain: name: process.env.APP _ENV === "production" ? "The App" : The App - (${process.env.APP_ENV}) , slug: process.env.APP _ENV === "production" ? "theapp" : theapp-(${process.env.APP_ENV}) , ios: { bundleIdentifier: process.env.APP _ENV === "production" ? "com.theappt" : com.theappt-${process.env.APP_ENV} , }, android: { package: process.env.APP _ENV === "production" ? "com.theappt" : com.theappt_${process.env.APP_ENV} , }, This manual branching works, but it leads to config sprawl and is easy to break over time. Proposal: Native Environment-Based Config Files Expo should support the following behaviour: Config Files per Environment app.json // Base config for all environments app.dev .json // Overrides for development app.staging.json // Overrides for staging app.production.json // Overrides for production Selection by EAS Profile or Env Variable Examples: eas build --profile staging → loads app.staging.json EXPO_ENV=dev expo start → loads app.dev .json Automatic Deep Fallback to app.json If a field is missing in app.staging.json, Expo should automatically use the value from app.json before failing. Example: Plugins defined once in app.json Only environment-specific values go into the env file Reduces duplication dramatically Clear Precedence Rules Expo should apply: app.{env}.json overrides app.json Unspecified keys fall back to app.json. Benefits Much cleaner configuration Significantly reduced duplication Eliminates the need for large JS/TS conditionals Easier onboarding for new team members Works naturally with EAS profiles Less risk of breaking bundle IDs or package names More aligned with how other platforms handle env-based config files Why This Matters Environment-based configuration is a core requirement for most production apps. Many Expo developers already simulate this manually using code, but the ecosystem would benefit greatly from a first-class, fully supported system. This feature would modernise Expo’s config experience and simplify builds across all environments.
