Environment variables are fine locally and undefined in the build, where are they supposed to live?

That distinction is the whole thing, and everything else follows once you have it.

A mobile app has no environment at runtime. There is no shell, no process environment, nothing to read from. So anything your JavaScript reads as a configuration value has to be baked into the bundle at build time. It becomes a literal string in the shipped code.

Which means your local file works in development for a reason that does not generalise: the development server is running on your machine, in your shell, and substitutes the values as it bundles. On a build machine, that file does not exist, so the substitution produces undefined: which is exactly what you shipped.

So the answer to where they go: into the build configuration, per build profile, so the build service has them when it bundles.

The consequence people miss, and it matters more than the mechanics: a value baked into the bundle is readable by anyone with the app. Not obscured, not protected - present as a string in a file anyone can extract. So this mechanism is for configuration, never for secrets.

If something must stay secret, it belongs on a server you control, and the app calls that server. There is no arrangement in which a key in a mobile binary is private.

Anything genuinely secret goes behind your own endpoint. The app calls you, you call them.

Practically, put the values in build profiles rather than in a file, because a file that works is a file that is either committed or absent, and both are bad.

The shape that works:

A profile per target - development, preview, production: each with its own values. Then building for production picks up production configuration without you remembering anything.

Values that differ per environment go in the profile. API URLs, feature flags, the analytics key for that environment.

Values that are genuinely sensitive go in the build service's secret storage, which keeps them out of your repository. Note this protects them from your git history, not from the shipped app - see the previous answer.

Keep the local development file for convenience, and make sure it is git-ignored and that nothing depends on it existing.

Two things to check once you have done it:

Confirm the value made it into the bundle rather than assuming. Log it once at startup in a preview build. Undefined at runtime and undefined at build time look identical from the app's side and the fix is different.

Watch out for names that are only substituted with a specific prefix. Bundlers commonly only inline variables whose names match a convention, and a value with the wrong prefix silently becomes undefined without any warning.

Adding the practical audit, because almost everyone reading this has already shipped something they should not have.

Take a release build and look inside it. The bundle is a file; you can extract it and search it. Search for anything that looks like a key. It takes ten minutes and the results are usually educational.

What commonly turns up and is fine: API base URLs, public identifiers meant to be public, analytics keys designed to be client-side, publishable payment keys.

What turns up and is not fine: anything with the word secret in its name, database credentials, admin tokens, a third party API key that allows writes.

If you find one of the second kind, the fix is not to hide it better. It is to rotate it and move the operation behind an endpoint you control, with the app authenticating as a user rather than holding the key.

One related thing worth knowing while you are in here: over-the-air updates carry the bundle, not the native configuration. So a value baked at build time stays whatever it was when the binary was built, even after an update. People change a profile, push an update, and are confused that the old URL is still in use - the update replaced the JavaScript, not the build-time substitution that happened before it.