How We Ship 20+ Branded Apps From One Flutter Codebase — and Survive Apple 4.2.6

TL;DR. Yes — you can ship many branded apps from one codebase and pass App Store review, but only if each app is genuinely differentiated in content and behavior, not just skinned with a new logo. The decision rule: if two of your apps show the same screens with the same data and only the branding changes, Apple will treat them as duplicates and reject them under guideline 4.2.6; if each app authenticates as its own tenant and pulls its own content, catalog, features, and config from the server, they are functionally distinct products that pass. The trap that catches template mills is treating white-label as a reskin. The thing that makes it work is a client-to-server layer that makes each app substantively different at runtime. Everything below is how we build that — the architecture, the submission strategy, and the economics of app number twenty costing a fraction of app number one.

We run a Flutter-first agency, and one of the platforms we built runs 15+ live branded apps from a single codebase (cashback & loyalty platform). This is the honest version of how that works, including the part where a lazy version of it gets you pulled from the store.

Who this is for

You're not buying an app. You're buying apps — plural, and you need a lot of them.

• Agencies reselling mobile apps to their own clients — you want to onboard a new client and hand them a branded app without running a fresh build project each time.
• Franchise networks where every location or region needs its own store presence under its own brand, but the product underneath is one product.
• Multi-brand operators running a portfolio of brands that each need a customer-facing app.
• Course, coaching, and community platforms shipping a per-creator or per-cohort app.
• Event organizers who spin up an app per event or per venue and retire it after.

The common shape is "I need 10, or 50, or 500 apps, and I can't afford to build and maintain each one from scratch." If that's you, you've probably been pitched "white-label" before — and if you've been burned, it was almost certainly because someone sold you a reskin and Apple noticed.

Why most white-label apps get rejected: the 4.2.6 trap

App Store Review Guideline 4.2.6 is the rule Apple uses to remove apps "created from a commercialized template or app generation service" unless they're submitted by the business the app is for, and it's the rule they lean on to reject apps that are duplicates or reskins of each other. The intent is simple: the store shouldn't fill up with hundreds of near-identical apps that add no standalone value. Apple wants each app on the store to be a real product, not spam generated from a factory.

Here's why the typical white-label pitch walks straight into it. A template mill takes one binary, swaps the logo, changes the color palette, changes the app name, and submits forty copies. Every one of those apps:

• shows the same screens in the same order,
• displays the same content and data,
• exposes the same features,
• and often ships with near-identical screenshots and metadata.

To a reviewer — and increasingly to Apple's automated tooling — that's forty copies of one app. The differentiation is cosmetic. Guideline 4.2.6 exists precisely to reject that, and the rejections are brutal: apps pulled after months live, developer accounts flagged, whole fleets held in review. The scar most buyers arrive with is exactly this — "we shipped six branded apps, Apple approved four, then retroactively rejected the batch as duplicates."

The lesson people take from that is usually wrong. They conclude "you can't ship many apps from one codebase." You can. The problem was never the shared codebase. The problem was that the apps were the same product wearing different hats.

The differentiation that actually passes review

This is the whole point, so let me be precise about it.

There are two layers of differentiation. Almost everyone does the first. The second is what separates a real platform from a template mill.

Layer 1 — visual white-labeling (necessary, not sufficient). Each app gets its own theme (colors, typography, logo, splash, light/dark brightness), its own app name, its own bundle identifier / application ID, its own icon, and its own store listing. This is table stakes. It makes the apps look different. On its own, it is exactly what 4.2.6 rejects.

Layer 2 — the client-to-server layer (the actual moat). This is where we don't just white-label the presentation — we differentiate the content and behavior. Every branded app, at runtime, authenticates to the backend as its own tenant and pulls its own world down from the server:

• its own content (the actual screens' data, copy, media, feed),
• its own catalog (products, listings, courses, offers — whatever the app is about),
• its own data (a customer in brand A's app never sees brand B's data; brand context is resolved per request),
• its own feature set (per-tenant feature flags turn whole modules on or off), and
• its own remote configuration (behavior, campaigns, rollout — all server-driven).

The concrete before/after:

A reskin shows the same catalog, the same feed, the same features, with a new logo on top.

Our apps pull a different catalog, a different feed, and can expose different features per client — two apps built from the same binary blueprint are genuinely different products the moment they boot and talk to the server.

That substantive, server-driven differentiation is the reason each app is a real standalone app in Apple's eyes. A reviewer opening two of our apps doesn't see the same app twice — they see two products with different content and, often, different capabilities. That is what 4.2.6 asks for, and it's what pure reskins can't fake, because a reskin has nothing different to show.

The architecture

Here's the pipeline end to end, stage by stage — from a manager creating a brand to a signed app landing in the right store account.

1. Admin panel (Nuxt). A manager creates a new brand — name, assets, theme and brightness, feature selection, store metadata — and submitting the form generates that brand's configuration. No engineer in the loop.
2. Backend / multi-tenant API. The configuration lands in the backend as a new tenant: its theme tokens, its catalog and content and data, its feature flags, and its own per-tenant credentials. This is the tenant's "world," and it's the thing the app will pull down later.
3. Build pipeline (build time). Generating the config triggers a build. Custom Dart tooling applies the brand's identity to the Flutter binary — theme, app name, bundle identifier, icons — by rewriting the Android and iOS build configuration deterministically from the config (no hand-editing build.gradle or Info.plist per app). Fastlane then signs the iOS and Android binaries.
4. The branded app (runtime). Every app is the same Flutter binary blueprint. On launch, it authenticates to the backend as its own tenant and pulls its own content, catalog, data, feature set, and remote config — so app #17 shows a different world than app #3, even though they're the same code.
5. Multi-publisher deployment. Fastlane ships each signed app to the right store target — App Store account A, App Store account B, Google Play, and so on — so brands can live under separate publisher accounts rather than one.

Read that as two flows meeting at the app. At build time (stages 1–3), the pipeline bakes the brand's identity into the binary and signs it — that's what makes it a distinct store listing. At runtime (stage 4), the app authenticates as its tenant and pulls its content and behavior from the backend — that's what makes it a distinct product. Build time makes it a distinct listing; runtime makes it a distinct product.

The split between what's fixed at build time and what's resolved at runtime is the whole design, so here it is as a table:

Flutter is what makes this economical. Building this fleet natively would mean maintaining Swift and Kotlin codebases multiplied by every brand — an impossible burden. Flutter collapses it to one Dart codebase, one team, every platform and brand, which is the same foundation as our Flutter app development work, scaled from one app to a fleet. Because it renders every pixel itself, a brand theme applies identically across devices, and a fix shipped once lands in all N apps on the next release.

Publisher accounts and submission strategy

Passing 4.2.6 isn't only about the code. The submission has to look like N real products too, because that's the surface a reviewer actually sees.

The single biggest red flag you can wave at Apple is one developer account publishing forty visually similar apps. That pattern is the signature of a template mill, and it invites exactly the duplicate-app scrutiny you're trying to avoid. So the account strategy is part of the architecture, not an afterthought:

• Separate publisher accounts per brand or client is the safest model, and often the correct one anyway — when the app is for your client (an agency reselling to them, a franchisee, an independent partner brand), it should be published under their account. Guideline 4.2.6 explicitly favors this: template-derived apps are acceptable when submitted by the business the app serves.
• Single account with genuine differentiation can work for one company's own sub-brands, but the bar on content and metadata differentiation is higher, because everything sits under one publisher.
• Metadata and screenshots must differ per app — real, brand-specific descriptions and screenshots taken from that brand's actual content, not one screenshot set with the logo swapped. Duplicated marketing assets get flagged even when the app itself is differentiated.

Our pipeline supports all three publishing models and mixes them per brand, because the right answer depends on your partner agreements and who the app is legally for — we walk through the tradeoffs in detail on the white-label app development service page.

Build vs buy vs license

You have three honest options, and we'll tell you which one fits even when it isn't us.

Build it yourself. You own everything and it's tuned to your exact model. But you're funding the platform — the config layer, the admin panel, the multi-tenant backend, the Dart build tooling, the Fastlane pipeline — before app number one ships, and you're taking on the 4.2.6 risk with no scar tissue. This makes sense when a mobile platform is your business and you'll run an engineering team around it for years. If you want to build it but need Flutter horsepower to do it, that's what team augmentation is for — our engineers in your repo, the platform stays yours.

Buy a template mill. Cheapest sticker price, fastest demo, and the highest chance of a 4.2.6 rejection, because reskins are the exact thing the guideline targets. If the pitch is "we change your logo and colors and submit it," you're buying the rejection, not avoiding it. There's a place for template builders — internal tools, enterprise distribution, prototypes — but not a public multi-brand fleet on the App Store.

License or partner with a team that's shipped this. You get the platform architecture and the submission playbook without funding the R&D or absorbing the rejection risk first-hand. The tradeoff is a partner in the loop. This is the model most agencies and multi-brand operators should want — you're buying a proven pipeline, not discovering the failure modes yourself.

There's no universally right answer. There is a wrong one: buying a reskin and finding out about 4.2.6 from a rejection email.

The economics: why app 2…N is cheap

The reason this model exists is the cost curve, so here's the honest shape of it.

App number one carries the platform. The first app isn't really "an app" — it's the codebase, the theming and feature-flag system, the multi-tenant backend, the admin panel, and the automated build-and-publish pipeline. That's the investment, and it's front-loaded. As a rough anchor, a white-label platform build lands roughly in the range of a serious custom app project and scales with fleet size and feature depth — the tiers are on the service page, and the general cost mechanics are in Flutter App Development Cost in 2026.

Apps 2 through N are dramatically cheaper, because they share everything that cost money. A new branded app is, mechanically, a configuration: brand assets, a theme, a feature selection, store metadata, and a publisher account. No new build project, no forked codebase, no second round of architecture. The marginal cost of app N approaches the cost of filling in a form and preparing store assets — hours, not a rebuild.

A rough model, without inventing your numbers:

• Total cost of N apps ≈ platform cost + (N × per-brand config cost).
• The platform cost is fixed and paid once. The per-brand cost is small and roughly flat.
• So your average cost per app falls as N grows — the more brands you ship, the closer the average gets to the marginal config cost.

On top of that curve sits Flutter's structural saving: one codebase for iOS and Android is ~30–40% cheaper than building two separate native apps, and that saving compounds across the fleet — you're not paying it once, you're avoiding it N times.

For our own numbers: we've shipped 20+ branded apps from our white-label codebases, and on one platform alone the fleet passed 15+ live apps from a single codebase, where launching the next brand is close to free.

FAQ

Talk to us about a white-label build

If you need many apps and not one, the interesting question isn't "can Flutter do it" — it's "will these apps survive review, and what does the pipeline actually take." We've built the architecture, hit the 4.2.6 edge cases, and shipped fleets that stayed live.

• Book a platform demo — see the admin panel spin up a new branded app and the pipeline sign and publish it: talk to us.
• Go deeper on the offering — architecture, publishing models, and pricing tiers on the white-label app development service page.
• Building it yourself? We'll put Flutter engineers in your repo via team augmentation and leave the platform in your hands.

Tell us how many brands you're planning and who the apps are for, and we'll give you a straight read on the model, the submission strategy, and the cost curve — not a template-mill pitch.

Ilya Nixan is Founder & Lead Developer at Nerdy Production, a Flutter-first agency that builds white-label platforms and ships branded app fleets across fintech, retail, and loyalty.