Shipping Six Wallpaper Apps From One Codebase: A White-Label Build Setup with app.config.ts and EAS

Make app.config.ts a dynamic function

If you place an app.config.ts (exporting a function) instead of app.json, Expo evaluates it at build time. That's where we load the variant and assemble the config from its values.

// app.config.ts
import type { ExpoConfig, ConfigContext } from "expo/config";
import { resolveVariant } from "./config/variants";
 
export default ({ config }: ConfigContext): ExpoConfig => {
  const v = resolveVariant();
 
  return {
    ...config,
    name: v.name,
    slug: v.slug,
    scheme: v.scheme,
    icon: `./assets/variants/${v.id}/icon.png`,
    userInterfaceStyle: "automatic",
    splash: {
      image: `./assets/variants/${v.id}/splash.png`,
      resizeMode: "contain",
      backgroundColor: v.themeColor,
    },
    ios: {
      bundleIdentifier: v.bundleId,
      supportsTablet: true,
      infoPlist: {
        GADApplicationIdentifier: v.admobAppIdIos,
      },
    },
    android: {
      package: v.bundleId,
      adaptiveIcon: {
        foregroundImage: `./assets/variants/${v.id}/adaptive-icon.png`,
        backgroundColor: v.themeColor,
      },
    },
    extra: {
      variantId: v.id,
      themeColor: v.themeColor,
      eas: { projectId: v.easProjectId },
    },
    plugins: [
      [
        "react-native-google-mobile-ads",
        {
          androidAppId: v.admobAppIdAndroid,
          iosAppId: v.admobAppIdIos,
        },
      ],
    ],
  };
};

Place assets under assets/variants/{id}/ using the same file names per variant (icon.png, splash.png, adaptive-icon.png). Since paths are built from v.id, adding a new variant means adding one folder and one entry in variants.ts.

I include extra.variantId and extra.themeColor so the runtime code can also know which variant it is. Reading Constants.expoConfig?.extra?.themeColor via expo-constants lets you pull the theme color from the single source of truth in variants.ts instead of hardcoding it.

// theme.ts (runtime side)
import Constants from "expo-constants";
 
const extra = Constants.expoConfig?.extra as
  | { variantId?: string; themeColor?: string }
  | undefined;
 
export const THEME_COLOR = extra?.themeColor ?? "#1B1B1F";
export const VARIANT_ID = extra?.variantId ?? "zen";

Pin the variant with EAS Build profiles

A local prebuild is just APP_VARIANT=zen npx expo prebuild. For EAS Build, fix the environment variable per profile so CI selects the right variant from --profile alone. Put the variant in env inside eas.json.

{
  "cli": { "version": ">= 12.0.0" },
  "build": {
    "zen-production": {
      "extends": "base",
      "env": { "APP_VARIANT": "zen" }
    },
    "ocean-production": {
      "extends": "base",
      "env": { "APP_VARIANT": "ocean" }
    },
    "base": {
      "autoIncrement": true,
      "ios": { "resourceClass": "m-medium" }
    }
  },
  "submit": {
    "zen-production": {
      "ios": { "ascAppId": "1111111111" }
    },
    "ocean-production": {
      "ios": { "ascAppId": "2222222222" }
    }
  }
}

Inherit shared settings with extends: "base" and keep the only difference the APP_VARIANT in env. Putting the variant name in the profile name means that the moment you type eas build --profile ocean-production, you yourself can see what's being built. The ascAppId on the eas submit side is the one thing that has to be per variant, so write it out alongside.

The official docs introduce APP_VARIANT mainly to "separate development and production builds," but the real value in production is that the exact same mechanism transfers directly to being your multi-app axis. Expo's design was built to hold up to this kind of use.

One thing the docs underplay: always give each variant its own easProjectId. If you share one, an EAS OTA update you meant for Zen can land on Ocean's users too — a low-reproducibility incident that's miserable to trace. I initially reused a single project ID across all six and gave myself a scare when OTA deliveries crossed wires. Once I split the project IDs and pulled extra.eas.projectId from the variant, mis-targeted deliveries stopped entirely.

A validation script that fails before the build

This is the last line of defense against drifting back to copy-paste. An omission — added a variant but forgot the AdMob ID, forgot to create the icon folder — will let the build pass and stay hidden until right before store submission. Getting rejected after submitting costs half a day to a full day. So I drop these failures mechanically, before the build.

// scripts/validate-variants.ts
import { existsSync } from "node:fs";
import { VARIANTS, type AppVariant } from "../config/variants";
 
const REQUIRED_ASSETS = ["icon.png", "splash.png", "adaptive-icon.png"];
const errors: string[] = [];
 
for (const [id, v] of Object.entries(VARIANTS) as [string, AppVariant][]) {
  // 1. required fields not empty or placeholder
  for (const key of ["name", "bundleId", "scheme", "easProjectId"] as const) {
    if (!v[key] || v[key].trim() === "") {
      errors.push(`[${id}] ${key} is empty`);
    }
  }
  // 2. AdMob IDs are real-looking (reject test/dummy IDs)
  for (const key of ["admobAppIdIos", "admobAppIdAndroid"] as const) {
    if (!/^ca-app-pub-\d{16}~\d{10}$/.test(v[key])) {
      errors.push(`[${id}] ${key} has an invalid or missing format`);
    }
  }
  // 3. duplicate bundle ID (a clash overwrites a different app)
  const dup = Object.values(VARIANTS).filter((o) => o.bundleId === v.bundleId);
  if (dup.length > 1) {
    errors.push(`[${id}] bundleId "${v.bundleId}" collides with another variant`);
  }
  // 4. assets actually exist
  for (const asset of REQUIRED_ASSETS) {
    const path = `assets/variants/${id}/${asset}`;
    if (!existsSync(path)) {
      errors.push(`[${id}] missing asset: ${path}`);
    }
  }
}
 
if (errors.length > 0) {
  console.error("Variant validation failed:\n" + errors.map((e) => "  - " + e).join("\n"));
  process.exit(1);
}
console.log(`✅ all ${Object.keys(VARIANTS).length} variants passed validation`);

Run it as a prebuild step in package.json or as the first step in CI: node --import tsx scripts/validate-variants.ts. The third check — duplicate bundle IDs — looks minor but earns its keep. When you create a new variant by copying an existing entry, it's easy to forget to change bundleId, and building in that state can overwrite a different app on upload. You can't catch a duplicate value with types, so you walk the data and fail on it.

If you run it on EAS's remote builds, put the validation in the eas-build-pre-install hook so the cloud build halts before it starts. Placing the same gate both locally and in CI was the configuration that betrayed me least over the long run.

Where to start the migration — don't do all six at once

Finally, the order for collapsing multiple apps that already run in separate repos. I first tried to integrate everything at once and froze. The right move was to make the most actively-updated app the "reference variant," build the code out completely there, and reduce the rest to just adding variant definitions.

In practice: move the most frequently updated app's code into the new single repo first, and rework it to emit via APP_VARIANT. Once that one ships reliably, test whether the second app can be reproduced with nothing more than "one entry in variants.ts + an asset folder + an EAS profile." If it reproduces, that's proof the design is right. If it needs an extra code branch, that branch is a signal: the difference hasn't been fully extracted into variants.ts yet.

My grandfather was a miyadaiku — a traditional shrine carpenter — and I remember him finishing slightly different fittings from the same drawing. The frame is shared; the per-site difference drops down into dimensions, into data. Once I realized software can do the same thing, maintaining the six apps got a lot quieter.

I hope this helps any solo developer wrestling with config drift. Start by picking two similar apps you already have, make one of them the reference variant, and write two entries in variants.ts.