Three Builds on One iPhone: Environment Separation for Rork (Expo) Apps

Switching app.config.ts dynamically with APP_VARIANT

Replace static app.json with app.config.ts and build the values from an APP_VARIANT environment variable. This is the heart of the setup.

// app.config.ts
import { ExpoConfig, ConfigContext } from "expo/config";
 
const VARIANT = process.env.APP_VARIANT ?? "development";
 
const variants = {
  development: {
    name: "MyApp (Dev)",
    bundleId: "net.dolice.myapp.dev",
    scheme: "myapp-dev",
    icon: "./assets/icon-dev.png",
  },
  preview: {
    name: "MyApp (Stg)",
    bundleId: "net.dolice.myapp.stg",
    scheme: "myapp-stg",
    icon: "./assets/icon-stg.png",
  },
  production: {
    name: "MyApp",
    bundleId: "net.dolice.myapp",
    scheme: "myapp",
    icon: "./assets/icon.png",
  },
} as const;
 
export default ({ config }: ConfigContext): ExpoConfig => {
  const v = variants[VARIANT as keyof typeof variants];
  return {
    ...config,
    name: v.name,
    slug: "myapp",
    scheme: v.scheme,
    icon: v.icon,
    ios: { ...config.ios, bundleIdentifier: v.bundleId },
    android: { ...config.android, package: v.bundleId },
    extra: { variant: VARIANT },
  };
};

Keep slug identical across all three environments. slug is the EAS project identifier, so splitting it makes EAS treat each variant as a separate project, fracturing your build history and secrets. What you split is the bundle ID and the display name — not the project itself.

Icons and names you can tell apart on the home screen

Three identical-looking icons on one device invite mistakes. I start from the production icon and overlay a red band for dev and a yellow band for staging, and append (Dev) and (Stg) to the names. That alone makes them instantly distinguishable on the home screen and in Spotlight.

It's a small thing, but that "tell at a glance" state all but eliminates the human error of operating dev while thinking it's production, or the reverse.

Organizing eas.json into three build profiles

Feeding APP_VARIANT at build time is eas.json's job. Pin the environment variable per profile.

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "env": { "APP_VARIANT": "development" }
    },
    "preview": {
      "distribution": "internal",
      "channel": "preview",
      "env": { "APP_VARIANT": "preview" }
    },
    "production": {
      "autoIncrement": true,
      "channel": "production",
      "env": { "APP_VARIANT": "production" }
    }
  }
}

Here is how the three environments divide the work.

You build by naming a profile, e.g. eas build --profile preview. There's no risk of getting APP_VARIANT wrong because CI pins it to the profile.

Isolating notifications, analytics, and billing per environment

Even with split bundle IDs, data contamination continues if the app points at the same service keys as production. Use extra.variant as the anchor for one small map that swaps service config per environment.

// config/services.ts
import Constants from "expo-constants";
 
const variant = (Constants.expoConfig?.extra?.variant as string) ?? "development";
 
const table = {
  development: {
    apiBaseUrl: "https://dev-api.example.com",
    revenueCatKey: "YOUR_RC_KEY_DEV",
    analyticsKey: "YOUR_ANALYTICS_KEY_DEV",
    sendAnalytics: false,
  },
  preview: {
    apiBaseUrl: "https://stg-api.example.com",
    revenueCatKey: "YOUR_RC_KEY_STG",
    analyticsKey: "YOUR_ANALYTICS_KEY_STG",
    sendAnalytics: true,
  },
  production: {
    apiBaseUrl: "https://api.example.com",
    revenueCatKey: "YOUR_RC_KEY_PROD",
    analyticsKey: "YOUR_ANALYTICS_KEY_PROD",
    sendAnalytics: true,
  },
} as const;
 
export const services = table[variant as keyof typeof table];

From experience, I strongly recommend separating RevenueCat per environment. Reuse the same API key and your sandbox purchases from debugging bleed into production conversion and LTV, inflating your measured conversion rate by a few % and skewing decisions. Split the project (or at least the App), and set sendAnalytics: false for dev so your own taps never land in the numbers — your future self analyzing the data will thank you.

The same goes for AdMob: always use test ad units in dev and staging. Hitting production units during device testing risks being flagged as invalid traffic and having serving suspended.

Aligning EAS Update channels with environments

OTA accidents happen when channels and profiles drift apart. When you push an update, always name the same channel you built with.

# OTA to staging
eas update --branch preview --message "checkout fix"
 
# OTA to production
eas update --branch production --message "checkout fix"

Because each profile pins a channel in eas.json, a preview build only receives preview-branch updates and never production ones. The worst-case accident — "a test update flowed to production" — is prevented simply by keeping this correspondence aligned.

Pitfalls you tend to hit in practice

Once it's running, a few stumbles are common.

On Google Play, each bundle ID (package name) is a separate app, so accidentally uploading the staging package to the production track gets rejected for a signing-key mismatch. Build a habit of confirming you built with APP_VARIANT=production before uploading.

Push tokens and ATT state are also managed per environment. A notification permission you granted in dev does not carry over to staging. That's by design, but before you panic that "notifications aren't arriving," recall which build you granted it in.

Finally, extra from expo-constants may not be replaced with new values via an OTA update. For values you want to change through updates — like a service endpoint — it's safer to derive them from the expo-updates channel or from server-side remote config rather than extra.

Splitting environments is unglamorous, and the initial setup takes about half a day. But once you can test without fear of breaking production on your everyday phone, pre-release checks become remarkably light. Indie development is partly a contest over how much you can reduce the friction of verification, and this is an investment I always recoup first. Thank you for reading.