Handling Multiple Environments

Most React Native apps ship more than one flavour — for example Dev, QA, and Production — each with its own APIs and config. To keep those flavours separated in Stallion, use a separate project per flavour, each with its own Project ID and App Token wired into the matching native build. For how Organization, Project, Bucket, and Release relate, see Stallion Hierarchy.

One Project Per Flavour

Create a Stallion project for each flavour (for example myapp-dev, myapp-qa, myapp-prod). Each project has its own Project ID and App Token. Publish and promote releases into the project that matches the flavour you are targeting.

The Stallion SDK reads StallionProjectId and StallionAppToken from the native build (strings.xml on Android, Info.plist on iOS). Those credentials determine which project the installed app talks to, and which promoted releases it can receive.

Wire ProjectId and AppToken Per Flavour

Follow the Installation guide for the base setup, then override the values per flavour so each native build gets the correct credentials.

Android — product flavours

First declare the flavours in android/app/build.gradle. Without this, flavour resource folders are ignored:

android {
  flavorDimensions "env"
  productFlavors {
    dev {
      dimension "env"
    }
    qa {
      dimension "env"
    }
    prod {
      dimension "env"
    }
  }
}

Then put each flavour's Stallion values in its own source set:

android/app/src/
  main/res/values/strings.xml
  dev/res/values/strings.xml
  qa/res/values/strings.xml
  prod/res/values/strings.xml

Example flavour strings.xml:

<resources>
  <string name="StallionProjectId">YOUR_PROJECT_ID</string>
  <string name="StallionAppToken">spb_YOUR_APP_TOKEN</string>
</resources>

Once the flavours are declared, Gradle automatically merges only the active flavour's resources at build time. No Stallion SDK code changes are required.

You can also inject values with resValue inside productFlavors if tokens come from CI secrets.

iOS — build configurations + .xcconfig

You do not need multiple Info.plist files.

1. Create configurations for each flavour (for example Release-Dev, Release-QA, Release-Prod).
2. Add one .xcconfig per flavour with the Stallion values.
3. Reference them from a single Info.plist:

<key>StallionProjectId</key>
<string>$(STALLION_PROJECT_ID)</string>
<key>StallionAppToken</key>
<string>$(STALLION_APP_TOKEN)</string>

4. Point each scheme at the matching configuration.

Xcode substitutes the values at build time.

Publishing Bundles for a Flavour

Upload each OTA bundle to the Stallion project that matches the flavour, then promote it for that flavour's app version.

Your app's other environment variables

Apart from the Stallion credentials above, your app likely reads its own environment values — API base URLs, feature flags, keys. Whether an OTA bundle picks these up correctly depends on which library you use:

• react-native-config — values are packed at the native layer and exposed to JS through NativeModules. Any JS bundle, OTA or not, reads whatever the installed flavour's native build already contains, so nothing extra is needed at publish time.

• react-native-dotenv — Babel inlines the values into the JS bundle itself, so the OTA bundle carries whichever .env file was active when it was built. Set APP_ENV / NODE_ENV on the publish command so the correct file is packed:

APP_ENV=staging npx stallion publish-bundle \
  --upload-path=<org>/<project>/<bucket> \
  --platform=android \
  --release-note="staging build"

NODE_ENV=production npx stallion publish-bundle \
  --upload-path=<org>/<project>/<bucket> \
  --platform=android \
  --release-note="production build"

Clear the Metro cache before switching environments, or a stale transform can bake the wrong values into the bundle:

# macOS / Linux
rm -rf "$TMPDIR/metro-"* node_modules/.cache/metro

For full publish-bundle flags, see the Publish Bundle API Reference.

Checklist

1. Create one Stallion project per flavour.
2. Put each project's StallionProjectId and StallionAppToken into that flavour's native config.
3. Build and ship each flavour with its matching credentials.
4. Publish and promote OTA releases into the matching project.
5. If you use dotenv-style env files, set the env on publish and clear the Metro cache between environments.