How do you architect several brands or white-label apps from one codebase: configuration, theming, build variants, release and the risk of forks?

The goal is many apps that differ only where they must, with the shared core staying one codebase. Separate what varies into layers. Identity: each brand that ships in its own App Store listing needs its own bundle identifier, signing identity and profile, push keys, associated domains, app icon and store metadata (Q478, Q479). Look: design tokens (colours, typography, spacing, icons) in a theme object injected through the environment, with brand assets in per-brand asset catalogs, so views never name a colour directly. Behaviour: a typed brand configuration (feature set, endpoints, legal text, default locale, flags) loaded at startup, so the core asks “is this feature enabled” instead of “which brand am I”. Code differences: prefer configuration and protocols; use compile-time flags only when a brand must not contain another brand’s code at all (a licensing or size reason). The check below builds the same source three ways with -D flags and gets three different brands, with the other brands’ code excluded from each binary. Structure the project as shared Swift packages for the core and features (Q362), one thin app target per brand (or one target with brand-specific schemes and .xcconfig files, Q369), and keep brand-specific code in its own module that the core never imports.

The costs are in the matrix and the process. A bug in the core ships to every brand, so tests run against a brand matrix (at least a representative subset in CI, all brands before release), snapshot and accessibility checks per brand (Q448, Q477), and the release train covers all apps with brand-level flags for staggered launches (Q487, Q486). Automate creating a brand (a script that generates the target, assets placeholder, bundle ID, CI job and store metadata skeleton) so that adding the fifth brand takes days, not weeks. Fight the fork: when a brand wants a one-off, ask whether it is configuration, a feature other brands might use, or a genuine extension point, and add that seam in the core rather than copying code; track brand-specific code as debt with owners. Choose a single binary with runtime theming only when all brands share one App Store listing; separate listings need separate binaries. The trade-off to state: compile-time separation gives smaller, cleaner binaries and harder isolation; runtime configuration gives faster builds and a smaller matrix but ships all brands’ code.