Managing Per-Environment Configuration in React Native

WHAT THIS TESTS Whether you can ship distinct, reproducible builds per environment without leaking config or shipping the wrong endpoint to users.

A GOOD ANSWER COVERS Keep configuration in per-environment files such as .env.development, .env.staging, and .env.production, consumed by a tool like react-native-config or, on Expo, by app.config.js with EAS build profiles. The build process selects which file to bake in, so the chosen environment is fixed at build time rather than decided at runtime. On the native side use Android product flavors and iOS schemes or configurations so each environment can have its own bundle identifier, app name, and icon, letting all three install side by side on one device. Surface values to JS through Config.API_URL or Expo Constants. Treat anything in the JS bundle as public, because it is shipped to the device and can be extracted, so real server secrets stay on the backend.

COMMON WRONG ANSWERS Branching on a runtime flag inside one universal bundle, which still ships every environment's URLs. Hardcoding endpoints in the source. Putting API secret keys in env files thinking they are hidden.

LIKELY FOLLOW-UPS How to give each environment a separate bundle id. How EAS build profiles map to env files. How to rotate or override config without a new build, which points toward OTA or remote config.

ONE CONCRETE EXAMPLE You define API_URL in three env files, add staging and production schemes in Xcode plus debug, staging, and release flavors in Gradle, and run a build script that copies the matching env file before building. The staging app installs as com.acme.app.staging next to production, and Config.API_URL resolves to the staging host only in that build.