react-native-config puts a .env file behind a native Config module

A .env file in the app root becomes a Config object in JavaScript

The mechanism is narrow on purpose. You drop a `.env` file in the root of your React Native app, a key and a value per line, and the library turns those keys into properties of a single object in your JavaScript. `Config.API_URL` is a property read, not a function call and not a request, so the value is already inside the bundle by the time your code runs. Underneath sits a native module: the repository carries `android/`, `ios/` and `windows/` folders, a `react-native-config.podspec`, and a `codegen/` directory wired through `codegenConfig` as `RNCConfigSpec`, with the Android java package `com.lugg.RNCConfig` and the iOS class `RNCConfigModule`. The project frames this as 12 factor config for mobile apps, and that is the entire contract: environment values in plain sight, not a secret store with an API.

yarn add, pod install, and a rebuild before anything appears

$ yarn add react-native-config

On React Native 0.60 and above there is no link step, because the library is autolinked, but the native side still has to exist before JavaScript can see anything. On iOS and macOS that means installing the pod:

(cd ios; pod install)

and then rebuilding the app so the native side is picked up. With a `.env` in the app root:

API_URL=https://myapi.com
GOOGLE_MAPS_API_KEY=abcdefgh

reading a value takes one import:

import Config from "react-native-config";

Config.API_URL; // 'https://myapi.com'
Config.GOOGLE_MAPS_API_KEY; // 'abcdefgh'

Both come back as the plain strings you typed, with no coercion and no types at runtime.

Android additionally needs the dotenv.gradle apply

iOS and macOS need the pod. Android needs a gradle plugin applied by hand. `npx react-native-integrate react-native-config` applies the extra steps automatically, and the manual equivalent sits in `android/app/build.gradle`:

// 2nd line, add a new apply:
apply from: project(':react-native-config').projectDir.getPath() + "/dotenv.gradle"

BuildConfig is resolved by namespace, and logcat names every package tried

Android is also where the lookup turns subtle. `BuildConfig` is generated in your module's `namespace`, which is not always the same as its `applicationId`, because `applicationIdSuffix` and a per-flavor `applicationId` change the latter and leave the former alone. The library looks for `BuildConfig` in the package that declares your `Application` class, which is the `namespace`, before falling back to the `applicationId`, so the usual variant setups need no extra configuration. When your `BuildConfig` lives somewhere neither of those points at, name the package yourself in `android/app/build.gradle`:

defaultConfig {
    ...
    resValue "string", "build_config_package", "YOUR_NAMESPACE"
}

`YOUR_NAMESPACE` matches the `namespace` in `android/app/build.gradle`, or on React Native 0.72 and older the `package` attribute of `<manifest>` in `AndroidManifest.xml`, and that value wins over the automatic resolution. If the config reaches JavaScript as `{}`, logcat prints `ReactConfig: Could not find BuildConfig class` and lists every package that was tried, which turns a silent Android failure into a two minute fix.

Hand written settings.gradle lines leave the module resolving to null

The old manual recipe is still in the repository, under a heading that limits it to React Native below 0.60 or react-native-windows below 0.63. Run it on a current app and you get the error people search for by name: `TypeError: Cannot read property 'getConfig' of null`. Adding the Gradle lines registers a Gradle project, nothing more. It does not register the native module, and on the New Architecture it does not generate the TurboModule bindings, so the module resolves to `null` at runtime and every property read fails. The guidance is explicit: do not link this library by hand on React Native 0.60 or above, and do not disable autolinking in `react-native.config.js`.

For the versions where manual linking is still correct, the Android recipe adds the project, the dependency and the package class:

+ include ':react-native-config'
+ project(':react-native-config').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-config/android')

Plain strings reach JavaScript, so .env is not a secrets vault

The module does not obfuscate or encrypt secrets for packaging, and the documentation says plainly that you should not store sensitive keys in `.env`. The reason offered is structural rather than a missing toggle: it is basically impossible to prevent users from reverse engineering mobile app secrets. The consequence for your app design is that everything in `.env` is readable in what you ship, so the surrounding code has to treat those values as public. A value that is already exposed by the platform, such as a maps key your app embeds anyway, fits. A key that authorises writes against your own backend does not, because the app you ship is the leak.

React Native 0.87, react-native-windows 0.79, and the 0.60 linking cutoff

The compatibility statements are specific and worth reading before you upgrade anything. The current release is tested with React Native 0.87 on the New Architecture, against the example app in `Example/`, and on Windows with react-native-windows 0.79, described as the newest React Native version react-native-windows supports, using `Example.windows/`. Android carries its own floor: react-native-config v1.6.0 and later require React Native 0.74 or higher, with older React Native versions sent to the troubleshooting notes. Peer dependencies ask for react-native-windows 0.61 or newer and mark it optional, while autolinking on Windows starts at react-native-windows 0.63. Below those lines the manual path applies, and `react-native link react-native-config` is documented there with the reminder that `react-native link` was removed from the React Native CLI. `package.json` sits at version 1.7.2, the license is MIT, and the test entry point is `ruby test/run.rb`.

One import in JavaScript, four native folders behind it

What actually ships is narrower than the repository. The `files` array in `package.json` limits the published package to `android/`, `ios/`, `windows/`, `codegen/`, `index.js`, `index.d.ts` and `react-native-config.podspec`, so the example apps and the screenshots stay out of your node_modules. That same `index.d.ts` is the `types` entry. Windows developers on react-native-windows below 0.63, where manual linking applies, add a Visual Studio project from the library's `windows` folder, picking `RNCConfig.vcxproj` for react-native-windows 0.62 and newer or the separate `RNCConfig61` project for 0.61, then add `#include "winrt/RNCConfig.h"` to `pch.h` and this line before `InitializeComponent();`:

PackageProviders().Append(winrt::RNCConfig::ReactPackageProvider());

The project also asks for Open Collective sponsorship, with contributions described as going toward the maintenance that keeps it working across new React Native releases. That is a reasonable signal about who pays for the upkeep, and it is worth weighing before a long-lived app depends on it.

Editorial conclusion

Use react-native-config when you want per-build endpoints and keys inside a React Native app and can accept that those values ship in the binary as plain strings. Do not reach for it to keep an API secret safe, and check your React Native version first, since v1.6.0 and newer require RN 0.74 or higher while the manual linking path exists only below RN 0.60. Verify the Android side early by reading logcat for ReactConfig: Could not find BuildConfig class.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. react-native-config/react-native-config on GitHub
4. README
5. Releases