Wat het in de praktijk betekent
Eén codebase, veel gepubliceerde apps. Elk merk krijgt een eigen winkelvermelding, appnaam, icoon, kleurenpalet en content, en ze worden allemaal uit dezelfde bron gebouwd. De economie is het hele punt: de twintigste app kost een fractie van de eerste, omdat de eerste het platform heeft betaald.
De kopers hebben steeds dezelfde vorm. Bureaus die apps doorverkopen aan hun eigen klanten. Franchiseketens waar elke regio een eigen aanwezigheid in de winkel nodig heeft. Multimerkbedrijven met een portfolio om te bedienen. Cursus- en communityplatforms die een app per maker uitbrengen. De gedeelde zin is "ik heb er tien nodig, of vijftig, en ik kan geen tien bouwprojecten financieren."
Vier woorden die door elkaar worden gebruikt
| Wat per klant verschilt | Codebases te onderhouden | |
|---|---|---|
| Reskin | Logo, kleuren, appnaam | Eén — maar de apps zijn hetzelfde product |
| Fork | Werkelijk alles | Eén per klant, vanaf dag één uit elkaar lopend |
| Multi-tenant | Data en content, één deployment | Eén, één app |
| White-label | Identiteit bij het bouwen, content en functies tijdens gebruik | Eén, veel apps |
Een fork is het eerlijke antwoord voor twee klanten met werkelijk verschillende producten. Multi-tenancy is wat een SaaS doet wanneer iedereen één app deelt en alleen de data verschilt. White-label is het geval waarin elke klant een eigen app in een eigen winkelvermelding nodig heeft, en juist die winkelvermelding is waar het lastig wordt.
Wat het onderscheidt van een reskin
App Store Review Guideline 4.2.6 bestaat om apps te verwijderen die uit een sjabloon zijn gegenereerd, en een reeks apps die dezelfde schermen met dezelfde data onder verschillende logo's toont is precies wat daar beschreven staat. Afwijzingen zijn hier niet mild: apps die na maanden live gaan worden teruggetrokken, hele vloten die in review blijven hangen, ontwikkelaarsaccounts die gemarkeerd worden.
De les die de meeste mensen daaruit trekken is de verkeerde — dat je niet veel apps uit één codebase kunt uitbrengen. Dat kan wel. Het probleem is nooit de gedeelde codebase; het zijn apps die hetzelfde product zijn met een andere hoed op.
Er zijn twee lagen van differentiatie, en vrijwel iedereen doet alleen de eerste.
Visuele theming geeft elke app eigen kleuren, typografie, logo, splash, naam, bundle-identifier en icoon. Dat is noodzakelijk en het is het minimum. Op zichzelf is het precies wat 4.2.6 afwijst.
De laag tussen client en server is wat werkelijk onderscheidt. Elke app authenticeert zich bij de backend als eigen tenant en haalt zijn eigen wereld op: eigen content, eigen catalogus, eigen data, een eigen functieset achter tenant-specifieke flags, eigen configuratie op afstand. Twee apps die uit dezelfde blauwdruk zijn gebouwd worden werkelijk verschillende producten zodra ze starten en met de server praten.
Theming laat een app er anders uitzien. De serverlaag laat hem werkelijk anders zijn — en een reviewer die er twee opent ziet twee producten in plaats van één app twee keer.
Wat je een leverancier moet vragen
- Wat verschilt tijdens gebruik en niet alleen tijdens het bouwen? Is het antwoord alleen thema en appnaam, dan koop je een reskin en komt 4.2.6 eraan.
- Onder wiens ontwikkelaarsaccounts verschijnen de apps? Merken moeten vaak onder hun eigen uitgeversaccount publiceren en niet onder dat van jou.
- Wat kost app nummer twintig? Ligt dat dicht bij app nummer één, dan zit er geen platform onder — alleen een buildscript.
- Hoe wordt een merk aangemaakt? Een formulier in een beheerpaneel betekent dat het schaalt. Een engineer die per klant buildconfiguratie aanpast betekent van niet.
Wanneer het het verkeerde antwoord is
Wanneer je twee klanten hebt en geen twintig. Het platformwerk — het tenantmodel, de buildpijplijn, de configuratie per tenant — is een investering die zich alleen over een vloot terugbetaalt, en twee forks waren sneller klaar geweest en goedkoper.
Het is ook verkeerd wanneer elke klant functies wil die de anderen nooit gebruiken. Een gedeelde codebase die werkelijk uiteenlopende producten absorbeert wordt een stapel voorwaarden die niemand veilig kan wijzigen, en op dat punt is de fork die je vermeed de fork die je nodig hebt.
Is de vloot echt, dan is de hefboom ongewoon: een nieuw merk gaat van een ingediend formulier naar een ondertekende binary in het juiste winkelaccount zonder dat er een engineer aan te pas komt.
De lange versie — de architectuur, de buildpijplijn en de indieningsstrategie — staat in hoe we 20+ merkapps uit één Flutter-codebase uitbrengen, en de dienstpagina is white-label appontwikkeling.