Hoe we 20+ merkapps uit één Flutter-codebase uitbrengen — en Apple 4.2.6 overleven

Kort samengevat. Ja — je kunt veel merkapps uit één codebase uitbrengen en door de App Store-beoordeling komen, maar alleen als elke app werkelijk onderscheiden is in content en gedrag, en niet slechts van een nieuw logo is voorzien. De beslisregel: tonen twee van je apps dezelfde schermen met dezelfde data en verandert alleen het merk, dan behandelt Apple ze als duplicaten en wijst ze onder richtlijn 4.2.6 af; authenticeert elke app zich als eigen tenant en haalt hij zijn eigen content, catalogus, functies en configuratie van de server, dan zijn het functioneel verschillende producten die er wel doorkomen. De val waar sjabloonfabrieken in lopen is white-label als een nieuw jasje behandelen. Wat het laat werken is een laag tussen client en server die elke app tijdens het draaien wezenlijk anders maakt. Alles hieronder gaat over hoe we die bouwen — de architectuur, de indieningsstrategie, en de economie waarin app nummer twintig een fractie van app nummer één kost.

Wij runnen een Flutter-eerst bureau, en een van de platforms die we bouwden draait 15+ live merkapps uit één codebase (cashback- en loyaliteitsplatform). Dit is de eerlijke versie van hoe dat werkt, inclusief het deel waarin een luie versie ervan je uit de winkel laat halen.

Voor wie dit is

Je koopt niet een app. Je koopt apps — meervoud, en je hebt er veel nodig.

• Bureaus die mobiele apps aan hun eigen klanten doorverkopen — je wilt een nieuwe klant aansluiten en hem een merkapp overhandigen zonder elke keer een vers bouwproject te draaien.
• Franchiseketens waar elke vestiging of regio een eigen winkelaanwezigheid onder een eigen merk nodig heeft, terwijl het product eronder één product is.
• Multimerkbedrijven met een portfolio merken die elk een app voor eindklanten nodig hebben.
• Cursus-, coaching- en communityplatforms die een app per maker of per groep uitbrengen.
• Evenementenorganisatoren die per evenement of per locatie een app opzetten en daarna weer uitzetten.

De gedeelde vorm is "ik heb er 10, of 50, of 500 nodig, en ik kan het me niet veroorloven ze stuk voor stuk te bouwen en te onderhouden." Ben jij dat, dan is je waarschijnlijk eerder "white-label" verkocht — en heb je je gebrand, dan kwam dat vrijwel zeker doordat iemand je een nieuw jasje verkocht en Apple het merkte.

Waarom de meeste white-label apps worden afgewezen: de 4.2.6-val

App Store Review Guideline 4.2.6 is de regel waarmee Apple apps verwijdert die "uit een gecommercialiseerd sjabloon of een appgeneratiedienst" zijn gemaakt, tenzij ze worden ingediend door het bedrijf waarvoor de app bedoeld is, en het is de regel waarop ze leunen om apps af te wijzen die duplicaten of hergebruikte jasjes van elkaar zijn. De bedoeling is eenvoudig: de winkel hoort niet vol te lopen met honderden bijna identieke apps die geen zelfstandige waarde toevoegen. Apple wil dat elke app in de winkel een echt product is, geen spam uit een fabriek.

Dit is waarom het gangbare white-labelvoorstel er recht in loopt. Een sjabloonfabriek neemt één binary, wisselt het logo, wijzigt het kleurenpalet, wijzigt de appnaam, en dient veertig kopieën in. Elk van die apps:

• toont dezelfde schermen in dezelfde volgorde,
• toont dezelfde content en data,
• biedt dezelfde functies,
• en komt vaak met vrijwel identieke schermafbeeldingen en metadata.

Voor een beoordelaar — en steeds vaker voor het geautomatiseerde gereedschap van Apple — zijn dat veertig kopieën van één app. Het onderscheid is cosmetisch. Richtlijn 4.2.6 bestaat juist om dat af te wijzen, en de afwijzingen zijn hard: apps die na maanden live worden teruggetrokken, ontwikkelaarsaccounts die gemarkeerd worden, hele vloten die in beoordeling blijven hangen. Het litteken waarmee de meeste kopers aankomen is precies dit — "we brachten zes merkapps uit, Apple keurde er vier goed, en wees daarna de hele partij alsnog af als duplicaten."

De les die mensen daaruit trekken is meestal de verkeerde. Ze concluderen "je kunt niet veel apps uit één codebase uitbrengen." Dat kan wel. Het probleem was nooit de gedeelde codebase. Het probleem was dat de apps hetzelfde product waren met een andere hoed op.

Het onderscheid dat de beoordeling werkelijk doorstaat

Dit is het hele punt, dus laat me precies zijn.

Er zijn twee lagen van onderscheid. Vrijwel iedereen doet de eerste. De tweede is wat een echt platform van een sjabloonfabriek scheidt.

Laag 1 — visueel white-labelen (noodzakelijk, niet voldoende). Elke app krijgt een eigen thema (kleuren, typografie, logo, splash, licht of donker), een eigen appnaam, een eigen bundle-identifier of applicatie-ID, een eigen icoon, en een eigen winkelvermelding. Dat is het minimum. Het maakt dat de apps er anders uitzien. Op zichzelf is het precies wat 4.2.6 afwijst.

Laag 2 — de laag tussen client en server (de werkelijke gracht). Hier white-labelen we niet alleen de presentatie — we onderscheiden de content en het gedrag. Elke merkapp authenticeert zich tijdens het draaien bij de backend als eigen tenant en haalt zijn eigen wereld van de server:

• eigen content (de data, teksten, media en feed van de schermen zelf),
• eigen catalogus (producten, aanbiedingen, cursussen — waar de app ook over gaat),
• eigen data (een klant in de app van merk A ziet nooit de data van merk B; merkcontext wordt per verzoek bepaald),
• eigen functieset (functieschakelaars per tenant zetten hele modules aan of uit), en
• eigen configuratie op afstand (gedrag, campagnes, uitrol — allemaal vanaf de server gestuurd).

Het concrete verschil:

Een nieuw jasje toont dezelfde catalogus, dezelfde feed, dezelfde functies, met een nieuw logo erop.

Onze apps halen een andere catalogus, een andere feed, en kunnen per klant andere functies tonen — twee apps uit dezelfde blauwdruk zijn werkelijk verschillende producten zodra ze starten en met de server praten.

Dat wezenlijke, door de server gestuurde onderscheid is de reden dat elke app in de ogen van Apple een echte zelfstandige app is. Een beoordelaar die twee van onze apps opent ziet niet twee keer dezelfde app — hij ziet twee producten met andere content en, vaak, andere mogelijkheden. Dat is wat 4.2.6 vraagt, en het is wat een puur nieuw jasje niet kan veinzen, want een nieuw jasje heeft niets anders te tonen.

De architectuur

Dit is de pijplijn van begin tot eind, fase voor fase — van een manager die een merk aanmaakt tot een ondertekende app die in het juiste winkelaccount landt.

1. Beheerpaneel (Nuxt). Een manager maakt een nieuw merk aan — naam, assets, thema en helderheid, functiekeuze, winkelmetadata — en het formulier versturen genereert de configuratie van dat merk. Geen engineer in de lus.
2. Backend en multi-tenant-API. De configuratie landt in de backend als nieuwe tenant: zijn themakleuren, zijn catalogus, content en data, zijn functieschakelaars, en zijn eigen inloggegevens per tenant. Dat is de "wereld" van de tenant, en dat is wat de app later ophaalt.
3. Buildpijplijn (tijdens het bouwen). De configuratie genereren start een build. Eigen Dart-tooling past de identiteit van het merk op de Flutter-binary toe — thema, appnaam, bundle-identifier, iconen — door de Android- en iOS-buildconfiguratie deterministisch uit de configuratie te herschrijven (geen build.gradle of Info.plist met de hand bewerken per app). Fastlane ondertekent daarna de iOS- en Android-binaries.
4. De merkapp (tijdens het draaien). Elke app is dezelfde Flutter-blauwdruk. Bij het starten authenticeert hij zich bij de backend als eigen tenant en haalt hij zijn eigen content, catalogus, data, functieset en configuratie op — zodat app 17 een andere wereld toont dan app 3, ook al is het dezelfde code.
5. Uitrol naar meerdere uitgevers. Fastlane brengt elke ondertekende app naar het juiste winkeldoel — App Store-account A, App Store-account B, Google Play, enzovoort — zodat merken onder aparte uitgeversaccounts kunnen leven in plaats van onder één.

Lees dat als twee stromen die bij de app samenkomen. Tijdens het bouwen (fase 1–3) bakt de pijplijn de identiteit van het merk in de binary en ondertekent hem — dat maakt er een aparte winkelvermelding van. Tijdens het draaien (fase 4) authenticeert de app zich als tenant en haalt hij zijn content en gedrag van de backend — dat maakt er een apart product van. Bouwen maakt er een aparte vermelding van; draaien maakt er een apart product van.

De scheiding tussen wat tijdens het bouwen vastligt en wat tijdens het draaien wordt bepaald is het hele ontwerp, dus hier is ze als tabel:

Flutter is wat dit betaalbaar maakt. Deze vloot native bouwen zou betekenen dat je Swift én Kotlin onderhoudt, vermenigvuldigd met elk merk — een onmogelijke last. Flutter vouwt dat samen tot één Dart-codebase, één team, elk platform en elk merk, hetzelfde fundament als ons werk aan Flutter-appontwikkeling, opgeschaald van één app naar een vloot. Doordat het elke pixel zelf tekent, valt een merkthema op alle toestellen identiek uit, en landt een fix die één keer wordt opgeleverd bij de volgende release in alle N apps.

Uitgeversaccounts en indieningsstrategie

4.2.6 doorstaan gaat niet alleen over de code. De indiening moet er ook uitzien als N echte producten, want dat is het oppervlak dat een beoordelaar werkelijk ziet.

Het grootste rode vlaggetje dat je naar Apple kunt zwaaien is één ontwikkelaarsaccount dat veertig visueel vergelijkbare apps publiceert. Dat patroon is de handtekening van een sjabloonfabriek, en het nodigt precies uit tot de duplicaatcontrole die je wilt vermijden. De accountstrategie hoort dus bij de architectuur en is geen bijzaak:

• Aparte uitgeversaccounts per merk of klant is het veiligste model, en vaak sowieso het juiste — is de app voor je klant (een bureau dat aan hem doorverkoopt, een franchisenemer, een zelfstandig partnermerk), dan hoort hij onder diens account gepubliceerd te worden. Richtlijn 4.2.6 geeft daar uitdrukkelijk de voorkeur aan: uit sjablonen afgeleide apps zijn aanvaardbaar wanneer ze worden ingediend door het bedrijf dat de app bedient.
• Eén account met werkelijk onderscheid kan werken voor de eigen submerken van één bedrijf, maar de lat voor onderscheid in content en metadata ligt hoger, omdat alles onder één uitgever staat.
• Metadata en schermafbeeldingen moeten per app verschillen — echte, merkspecifieke beschrijvingen en schermafbeeldingen uit de werkelijke content van dat merk, geen set schermafbeeldingen met een gewisseld logo. Gedupliceerd marketingmateriaal wordt gemarkeerd, ook wanneer de app zelf wel onderscheiden is.

Onze pijplijn ondersteunt alle drie de publicatiemodellen en mengt ze per merk, want het juiste antwoord hangt af van je partnerafspraken en van voor wie de app juridisch bedoeld is — de afwegingen lopen we in detail door op de dienstpagina white-label appontwikkeling.

Zelf bouwen, kopen of licentiëren

Je hebt drie eerlijke opties, en we zeggen welke past ook wanneer dat wij niet zijn.

Zelf bouwen. Je bezit alles en het is op jouw model afgestemd. Maar je financiert het platform — de configuratielaag, het beheerpaneel, de multi-tenantbackend, de Dart-buildtooling, de Fastlane-pijplijn — voordat app nummer één uitkomt, en je neemt het 4.2.6-risico zonder littekenweefsel. Dat is zinnig wanneer een mobiel platform je zaak is en je er jarenlang een engineeringteam omheen zult draaien. Wil je het bouwen maar mis je Flutter-slagkracht, dan is daar teamuitbreiding voor — onze engineers in jouw repo, het platform blijft van jou.

Een sjabloonfabriek kopen. De laagste prijskaart, de snelste demo, en de grootste kans op een 4.2.6-afwijzing, want hergebruikte jasjes zijn precies waar de richtlijn op mikt. Luidt het voorstel "we wisselen je logo en kleuren en dienen hem in", dan koop je de afwijzing, je vermijdt hem niet. Er is een plek voor sjabloonbouwers — interne tools, distributie binnen een bedrijf, prototypes — maar niet voor een openbare multimerkvloot in de App Store.

Licentiëren of samenwerken met een team dat dit heeft opgeleverd. Je krijgt de platformarchitectuur en het indieningsdraaiboek zonder het onderzoek te financieren of het afwijsrisico zelf op te vangen. De afweging is een partner in de lus. Dit is het model dat de meeste bureaus en multimerkbedrijven zouden moeten willen — je koopt een beproefde pijplijn, je ontdekt de faalwijzen niet zelf.

Er is geen universeel juist antwoord. Er is een fout antwoord: een nieuw jasje kopen en van 4.2.6 horen via een afwijsmail.

De economie: waarom app 2 tot en met N goedkoop is

De reden dat dit model bestaat is de kostencurve, dus hier is de eerlijke vorm ervan.

App nummer één draagt het platform. De eerste app is eigenlijk geen "app" — het is de codebase, het systeem voor thema's en functieschakelaars, de multi-tenantbackend, het beheerpaneel, en de geautomatiseerde build- en publicatiepijplijn. Dat is de investering, en die zit vooraan. Als ruwe verankering: een white-label platform bouwen ligt ruwweg in de orde van een serieus maatwerkproject en schaalt mee met de omvang van de vloot en de diepte van de functies — de niveaus staan op de dienstpagina, en de algemene kostenmechaniek in Wat een Flutter-app kost in 2026.

App 2 tot en met N zijn dramatisch goedkoper, want ze delen alles wat geld kostte. Een nieuwe merkapp is mechanisch gezien een configuratie: merkassets, een thema, een functiekeuze, winkelmetadata, en een uitgeversaccount. Geen nieuw bouwproject, geen geforkte codebase, geen tweede ronde architectuur. De marginale kosten van app N naderen die van een formulier invullen en winkelmateriaal voorbereiden — uren, geen herbouw.

Een ruw model, zonder je cijfers te verzinnen:

• Totale kosten van N apps ≈ platformkosten + (N × configuratiekosten per merk).
• De platformkosten liggen vast en betaal je één keer. De kosten per merk zijn klein en ruwweg constant.
• Dus je gemiddelde kosten per app dalen naarmate N groeit — hoe meer merken je uitbrengt, hoe dichter het gemiddelde bij de marginale configuratiekosten komt.

Boven op die curve zit de structurele besparing van Flutter: één codebase voor iOS en Android is ongeveer 30 tot 40% goedkoper dan twee aparte native apps bouwen, en die besparing stapelt zich over de vloot op — je betaalt hem niet één keer, je vermijdt hem N keer.

Onze eigen cijfers: we hebben 20+ merkapps uit onze white-label codebases uitgebracht, en op één platform alleen al passeerde de vloot 15+ live apps uit één codebase, waar het volgende merk lanceren bijna gratis is.

Veelgestelde vragen

Praat met ons over een white-label bouw

Heb je veel apps nodig en niet één, dan is de interessante vraag niet "kan Flutter dat" — het is "komen deze apps door de beoordeling, en wat vraagt de pijplijn werkelijk". Wij hebben de architectuur gebouwd, de randgevallen van 4.2.6 geraakt, en vloten opgeleverd die live bleven.

• Plan een platformdemo — zie het beheerpaneel een nieuwe merkapp opzetten en de pijplijn hem ondertekenen en publiceren: neem contact op.
• Ga dieper op het aanbod — architectuur, publicatiemodellen en tariefniveaus op de dienstpagina white-label appontwikkeling.
• Bouw je het zelf? We zetten Flutter-engineers in jouw repo via teamuitbreiding en laten het platform in jouw handen.

Vertel ons hoeveel merken je van plan bent en voor wie de apps bedoeld zijn, en we geven je een rechttoe rechtaan oordeel over het model, de indieningsstrategie en de kostencurve — geen praatje van een sjabloonfabriek.

Ilya Nixan is oprichter en lead developer bij Nerdy Production, een Flutter-eerst bureau dat white-label platforms bouwt en vloten merkapps uitbrengt in fintech, retail en loyaliteit.