Taming 70 Flutter Flavors: flavorizr + Batch CI for White-Label Releases

How we ship dozens of branded photography apps from one Flutter codebase—without drowning in manual Xcode/Gradle edits or one-off store uploads.

This is the approach we use at Kamero — an AI-powered event photography platform (kamero.ai) that delivers white-label guest apps for studios and photographers.

The problem: white-label means real store binaries

At Kamero, our product is a multi-tenant event photography app. Each photography studio often needs:

• Its own App Store / Play Store listing
• Its own bundle ID / applicationId
• Its own icon, splash, Firebase config, and deep-link host
• Its own signing key (especially on Android)
• A seed brand palette before any network call

That is not “swap a hex in JSON and ship one binary.” Store policy, OAuth clients, push configs, and client branding push you toward flavors—one installable app per tenant.

At around 70 flavors, the naive approach dies:

• Hand-editing android/app/build.gradle and Xcode schemes per client
• Remembering which tenants to release this week
• Rebuilding everything because one version bump was missed
• Filling the disk with 70× AAB/IPA intermediate artifacts

We did not escape flavors. We industrialized them.

The solution: three layers

1. flutter_flavorizr
   Declarative flavor defs → native projects + Dart enum

2. FlavorConfig (Dart)
   Per-flavor seed: title, splash, logo, brandColor, tenant ID
   + optional runtime color overlay from tenant profile

3. Batch CI scripts
   flavor_list_*.json → build only enabled → upload to stores

flavorizr owns native packaging. FlavorConfig owns first-paint branding in Dart. Scripts own release fan-out so humans do not click “build” seventy times.

Layer 1: managing flavors with flutter_flavorizr

We use flutter_flavorizr (with local customizations so we can extend processors). Flavors live as declarative config under pubspec.yaml:

flavorizr:
  ide: "vscode"
  app:
    android:
      flavorDimensions: "app"
  flavors:
    acme_w1:
      app:
        name: "Acme Studios"
      ios:
        bundleId: com.example.app.1
        icon: assets/images/acme/logo.png
        firebase:
          config: config/acme/GoogleService-Info.plist
      android:
        applicationId: com.example.app.w1
        icon: assets/images/acme/logo.png
        firebase:
          config: config/shared/google-services.json
        customConfig:
          manifestPlaceholders: '= [deepLinkHost: "1"]'
          versionCode: 15004
          versionName: '"1-3.0.6"'
          signingConfig: signingConfigs.release

Running flavorizr generates / refreshes:

• Android product flavors and flavorizr.gradle
• iOS schemes / build configs
• Per-flavor icons and Firebase plist/json wiring
• A Dart Flavor enum consumed at startup

Naming convention: {clientSlug}_w{tenantId} (for example acme_w1). The wN suffix maps to a white-label / tenant ID used by the backend and feature gates.

Why this works at scale

• New client: add a YAML block + assets + regenerate (instead of hand-editing Gradle and Xcode)
• Deep links: declare manifestPlaceholders per flavor
• Firebase: declare a config: path per OS
• Signing: keep signingConfig explicit in customConfig so Play uploads do not fail mysteriously

Adding a client becomes a checklist, not archaeology.

Layer 2: Dart-side FlavorConfig + runtime color overlay

Native flavor only gets you package identity and assets. UI still needs brand tokens. At boot:

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();

  // appFlavor comes from the native flavor / --flavor
  F.appFlavor = Flavor.values.firstWhere(
    (e) => e.name == appFlavor?.toLowerCase(),
  );

  flavorConfig = F.appFlavor.getFlavorConfig()!;
  // … init OAuth / Firebase for this flavor …
  runApp(const ProviderScope(child: MyApp()));
}

Each enum case maps to a seed config:

class FlavorConfig {
  String? appTitle;
  String splashImage;
  String? whiteLabelId;
  Color brandColor;
  Color? contentColor; // text/icons on brand surfaces
  String? logo;
  bool isLive;
  bool isPhoneRequiredOnSignup;
  bool isPhoneRequiredForProfileCompletion;

  bool get isWhiteLabel =>
      whiteLabelId != null && whiteLabelId != '0';
}

extension on Flavor {
  FlavorConfig? getFlavorConfig() {
    switch (this) {
      case Flavor.acme_w1:
        return FlavorConfig()
          ..appTitle = 'Acme Studios'
          ..splashImage = 'assets/images/acme/splash.png'
          ..logo = 'assets/images/acme/logo.png'
          ..whiteLabelId = '1'
          ..brandColor = const Color(0xFF3F51B5);
      // … one case per flavor …
    }
  }
}

Widgets do not hard-code one brand purple. Shared chrome reads helpers:

Color getBrandColor() =>
    whiteLabelModel?.brandColor ?? flavorConfig.brandColor;

Color getContentColor() =>
    whiteLabelModel?.effectiveContentColor ??
    flavorConfig.contentColor ??
    flavorConfig.brandColor;

Runtime overlay

After splash/welcome, we fetch the tenant profile. If the API returns a brandColor hex, we set a small in-memory model so AppBars, buttons, and loaders pick up the latest palette without rebuilding the store binary.

Logos, splash, and app title stay flavor-seeded (store identity). Accent color can still move with the photographer’s profile.

Derived surfaces keep the design coherent from one seed:

Color get subtleBackground => Color.alphaBlend(
      brandColor.withAlpha((255 * 0.02).round()),
      const Color(0xFFF5F5F5),
    );

Feature gates are mostly per white-label ID (for example, hide create-event for some tenants). Not elegant forever—but explicit and reviewable next to the flavor map.

Layer 3: CI scripts as the real alternative to manual releases

flavorizr solves definition. It does not solve “build and upload 40 AABs tonight.” That is where batch scripts matter.

Control plane: flavor_list_*.json

Instead of hard-coding the release set in bash, we keep a JSON registry:

{
  "flavors": [
    {
      "name": "main_w0",
      "enabled": false,
      "priority": 1,
      "package_name": "com.example.app"
    },
    {
      "name": "acme_w1",
      "enabled": true,
      "priority": 1,
      "package_name": "com.example.app.w1"
    }
  ]
}

• enabled — include in tonight’s batch (flip without editing the shell)
• package_name — Android applicationId for Fastlane version bumps / upload
• Separate lists for Android and iOS

Only enabled flavors run. If one flavor fails, the script continues and prints a summary at the end.

Android batch script

./scripts/cicd/build_and_upload_android.sh \
  --version-name "3.0.1" \
  --version-code 15020 \
  --track internal

Per enabled flavor, sequentially:

1. Bump version in flavorizr.gradle via Fastlane (update_version + package_name)
2. Clean build/, android/app/build/, and android/.gradle/ (disk fills fast at N flavors)
3. Run flutter build appbundle --release --flavor <name>
4. Upload the AAB with Fastlane + a Play service account JSON
5. Clean again after upload (success or failure)

Optional: pass --flavor acme_w1 to smoke-test one client before enabling the full set.

iOS batch script

Same idea, different store plumbing:

1. Bump pubspec.yaml version (name+code)
2. Clean Flutter / iOS build dirs
3. Run flutter build ipa --release --flavor <name> --build-number <code>
4. Extract dSYMs to a versioned folder before wipe (Crashlytics needs them)
5. Upload via xcrun altool using per-flavor App Store Connect API keys

./scripts/cicd/build_and_upload_ios.sh \
  --version-name "3.0.1" \
  --version-code 15020

Why scripts beat hand-rolled CI jobs for every flavor

• Selective releases: toggle enabled in JSON
• Per-flavor signing: honor signingConfig already in flavorizr output
• Disk pressure: aggressive clean before/after each flavor
• Debuggability: timestamped logs under build_logs/
• Partial failure: continue the matrix; summarize failures
• Local / CI agnostic: same bash on a release Mac or a runner

This is our practical alternative to maintaining seventy separate CI jobs by hand: one pipeline shape, data-driven flavor set.

End-to-end release flow

New client
  → assets/ + Firebase config/
  → flavorizr YAML entry
  → regenerate native + Flavor enum
  → FlavorConfig case (seed colors, splash, whiteLabelId)
  → row in flavor_list_android.json / flavor_list_ios.json (enabled: false)
  → first manual / --flavor smoke build
  → enable in JSON
  → batch script with shared version-name + version-code
  → Play / App Store Connect
  → runtime profile may still refresh brandColor later

Humans decide which tenants ship. Machines do the repetitive build/sign/upload loop.

What we learned

1. Flavors are a distribution boundary, not a theming API. Use them for store identity; keep UI tokens thin (FlavorConfig + optional runtime overlay).
2. Declarative generation (flavorizr) beats hand-edited native projects once you pass roughly ten clients.
3. A JSON enable-list is the release feature flag for white-label CI. Do not bury the release set inside the shell script.
4. Sequential builds + aggressive cleaning are boring and necessary. Parallelizing 70 Flutter release builds without a disk strategy fails noisily.
5. Per-flavor signing and ASC API keys must be first-class in the checklist. Most “batch upload” failures are identity/signing, not Dart.
6. Runtime branding still helps—photographers can change brand colors without waiting for another store review—while splash/icon/package stay flavor-owned.

Conclusion

We did not pretend seventy store apps are “one binary.” At Kamero, we accepted flavors, then made them operable:

• flutter_flavorizr for consistent native + Dart flavor scaffolding
• FlavorConfig for seed branding and tenant ID wiring
• Batch CI scripts + flavor_list JSON so releases are toggles and version args, not tribal knowledge

If your white-label story requires separate listings, invest in generation + batching early. The cost of flavors is not the YAML—it is the release matrix. Scripts are how we keep that matrix boring.

Building something similar for photographers or event platforms? Check out kamero.ai—happy to compare notes on white-label Flutter delivery.

Discussion

Do you generate flavors (flavorizr / custom codegen) or maintain native projects by hand? And for releases: one mega CI matrix, or a data-driven enable-list like ours?

War stories welcome—especially signing mismatches and “disk filled on flavor #37.” Drop a comment, or find us at kamero.ai.