What it means in practice
One codebase, many published apps. Each brand gets its own store listing, app name, icon, palette and content, and every one of them is built from the same source. The economics are the point: the twentieth app costs a fraction of the first, because the first paid for the platform.
The buyers are consistent in shape. Agencies reselling apps to their own clients. Franchise networks where each region needs its own store presence. Multi-brand operators with a portfolio to serve. Course and community platforms shipping an app per creator. The common sentence is "I need ten, or fifty, and I cannot fund ten build projects."
Four words people use interchangeably
| What varies per customer | Codebases to maintain | |
|---|---|---|
| Reskin | Logo, colours, app name | One — but the apps are the same product |
| Fork | Anything at all | One per customer, diverging from day one |
| Multi-tenant | Data and content, one deployment | One, one app |
| White-label | Identity at build time, content and features at runtime | One, many apps |
A fork is the honest answer for two customers with genuinely different products. Multi-tenancy is what a SaaS does when everyone shares one app and only the data differs. White-label is the case where each customer needs their own app in their own store listing, and that store listing is exactly where it gets difficult.
What separates it from a reskin
App Store Review Guideline 4.2.6 exists to remove apps generated from a template, and a set of apps that show the same screens with the same data under different logos is precisely what it describes. Rejections here are not gentle: apps pulled after months live, whole fleets held in review, developer accounts flagged.
The lesson most people take from that is the wrong one — that you cannot ship many apps from one codebase. You can. The problem is never the shared codebase; it is apps that are the same product wearing different hats.
There are two layers of differentiation, and almost everyone does only the first.
Visual theming gives each app its own colours, typography, logo, splash, name, bundle identifier and icon. This is necessary and it is table stakes. On its own it is exactly what 4.2.6 rejects.
The client-to-server layer is what actually differentiates. Each app authenticates to the backend as its own tenant and pulls down its own world: its own content, its own catalogue, its own data, its own feature set behind per-tenant flags, its own remote configuration. Two apps built from the same binary blueprint become genuinely different products the moment they boot and talk to the server.
Theming makes an app look different. The server layer makes it be different — and a reviewer opening two of them sees two products rather than one app twice.
What to ask a vendor
- What varies at runtime, not just at build time? If the answer is only theme and app name, you are buying a reskin and 4.2.6 is coming for it.
- Whose developer accounts do the apps ship under? Brands often need to publish under their own publisher account rather than yours.
- What does app number twenty cost? If it is close to app number one, there is no platform underneath — only a build script.
- How does a brand get created? A form in an admin panel means it scales. An engineer editing build configuration per client means it does not.
When it is the wrong answer
When you have two customers, not twenty. The platform work — the tenant model, the build pipeline, the per-tenant configuration — is an investment that only pays back across a fleet, and two forks would have shipped sooner and cost less.
It is also wrong when each client wants features the others will never use. A shared codebase absorbing genuinely divergent products becomes a pile of conditionals nobody can safely change, and at that point the fork you avoided is the fork you need.
If the fleet is real, though, the leverage is unusual: a new brand goes from a form submission to a signed binary in the right store account without an engineer in the loop.
The long version — the architecture, the build pipeline, and the submission strategy — is in how we ship 20+ branded apps from one Flutter codebase, and the service page is white-label app development.