Kopie pro Marke
- Neues Repo oder langer Branch. Stores von Hand.
Whitelabel: eine Codebasis, mehrere Store-Einträge
Forks pro Marke fühlen sich schnell an. Nach einem Jahr mergeest du Bugfixes dreimal. Marke als Konfiguration ist langsamer am ersten Tag und billiger ab der dritten Variante.
- Eigenes Branding, eigene Domain, eigener Store-Eintrag – ein Repo
- Build und Release pro Marke, ohne Copy-Paste der Pipeline
Fork oder Variante
Konfiguration
- Dieselbe Codebasis, der Assistent kennt die Marke.
Gemeinsame Codebasis
Live Fahrplan
Ein Flutter Projekt. Daraus entstehen viele eigenständige Apps.
-
KVB Live Fahrplan iOS Android -
MVG Live Fahrplan iOS Android -
RMV Live Fahrplan iOS Android -
HVV Live Fahrplan iOS Android -
VVS Live Fahrplan iOS Android
Whitelabel beginnt harmlos und endet in fünf fast gleichen Repos. Der Ausweg ist langweilig und richtig: Namen, Icons, Bundle-IDs als Daten, nicht als Git-Geschichte.
Varianten selbst verwalten oder über die Plattform
Die Gegenüberstellung zeigt, welche Arbeit bei mehreren Marken entsteht und wie die Application Platform sie bündelt.
| Aufgabe |
Mit der Application Platform
|
Manuell aufgesetzt
|
|---|---|---|
| Neue Marke aufnehmen | Vollständig abgedeckt: Variante im Projekt konfigurieren, Build und Deployment folgen automatisch | Nicht angeboten: Repository kopieren oder Branch abzweigen und anpassen |
| Feature für alle Marken ausrollen | Vollständig abgedeckt: Einmal entwickeln, die Pipeline liefert es an alle Varianten aus | Nicht angeboten: Änderung in jede Kopie zurückportieren, mit Konfliktrisiko |
| Branding pro Marke | Vollständig abgedeckt: Farben, Logos und Texte gehören zur Variantenkonfiguration | Teilweise abgedeckt: Assets manuell austauschen, oft direkt vor dem Release |
| Eigene Domain je Marke | Vollständig abgedeckt: Domain, DNS und SSL gehören zum Setup der jeweiligen Variante | Teilweise abgedeckt: Pro Marke einzeln einrichten und Zertifikate im Blick behalten |
| Store-Einträge je Marke | Vollständig abgedeckt: Metadaten, Screenshots und Changelogs werden pro Variante gepflegt | Nicht angeboten: Jede App einzeln in zwei bis drei Portalen pflegen |
| Signing für viele Apps | Vollständig abgedeckt: Android Keystore und Apple Credentials werden pro Variante verwaltet | Nicht angeboten: Wachsende Sammlung von Zertifikaten ohne gemeinsame Ablage |
| Backend und Datenhaltung | Vollständig abgedeckt: Umgebungen und Variablen liegen als Konfiguration im Projekt | Teilweise abgedeckt: Pro Marke eigene Server- und Konfigurationsstände, schwer vergleichbar |
| Fehler einer Marke zuordnen | Vollständig abgedeckt: Error-Tracking über Sentry, gefiltert nach Repository | Teilweise abgedeckt: Meldungen laufen zusammen oder fehlen für einzelne Varianten |
| Release-Stand überblicken | Vollständig abgedeckt: Deployments erscheinen als Release-Karten pro Repository | Nicht angeboten: Tabelle oder Gedächtnis, welche Marke auf welcher Version steht |
| Übergabe an den Kunden | Vollständig abgedeckt: Repositories und Konfiguration gehören dir, 100 Prozent Code-Ownership | Teilweise abgedeckt: Abhängig davon, wie sauber die Kopien dokumentiert wurden |
Grün bedeutet vollständig abgedeckt, gelb teilweise, grau nicht vorgesehen. Der Unterschied wächst mit jeder weiteren Marke.
Stand: 9. September 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen. Logos sind Marken der jeweiligen Rechteinhaber und dienen nur der Zuordnung.
Wann Forks bleiben
- Wirklich anderes Produkt Unterscheiden sich Logik und Roadmap stark, ist ein eigenes Projekt ehrlicher als Whitelabel.
Kostenmodell
Du zahlst nicht pro Fork, sondern Plattform und die Builds, die du wirklich auslöst.
-
App StoreApple-Releases mit vorbereiteten Metadaten und Assets.
-
Google PlayPlay-Store-Einträge automatisiert bespielt.
Powered by Fastlane
So setzt du ein Whitelabel-Projekt auf
Vier Schritte von der ersten Marke zur zehnten.
-
Basisprojekt anlegen
Wähle den Stack, etwa Flutter für Mobile oder Next.js für Web. Repository, Struktur und Pipeline entstehen mit.
-
Varianten definieren
Lege die Marken im Projekt an und hinterlege Branding, Domain und die Unterschiede in der Konfiguration.
-
Store-Zugänge hinterlegen
Signing-Material und Store-Credentials werden pro Variante verwaltet, damit Releases nicht an einer Person hängen.
-
Ausrollen und nachziehen
Ein Feature entwickelst du einmal. Die Pipeline liefert es an alle Marken aus, den Stand siehst du pro Repository.
Häufige Fragen
Worin unterscheidet sich das von einem Fork pro Kunde?
Ein Fork trennt die Codebasis dauerhaft, jede Fehlerbehebung muss danach in jede Kopie zurückwandern. Bei einem Whitelabel-Projekt bleiben Marken Varianten derselben Codebasis, die sich in Konfiguration, Branding und Store-Einträgen unterscheiden.
Können sich Marken funktional unterscheiden?
In gewissem Rahmen ja, über Variantenkonfiguration und zentrale Umgebungsvariablen, solange die Unterschiede Ausprägungen eines gemeinsamen Produkts bleiben. Werden zwei Marken zu unterschiedlichen Produkten, ist eine eigene Codebasis ehrlicher.
Bekommt jede Marke einen eigenen Store-Eintrag?
Ja. Pro Variante lassen sich eigene Einträge im App Store, Play Store und Microsoft Store pflegen. Der Metadaten-Editor führt durch die Felder, Screenshots lassen sich zuschneiden. Veröffentlichung läuft über Fastlane.
Für wen eignet sich das?
Vor allem für Agenturen, die ein Produkt mehrfach verkaufen, und für Franchise-Strukturen, bei denen viele Standorte dieselbe Anwendung unter eigenem Namen brauchen. Auch Softwareanbieter mit Partnerversionen im eigenen Erscheinungsbild arbeiten so.
Wem gehört der Code?
Dir. Repositories, Pipeline- und Deployment-Konfiguration liegen in deinem Projekt, die Plattform hält daran nichts zurück. Übergibst du ein Whitelabel-Produkt an einen Kunden, lässt sich der Stand ausliefern, ohne proprietäre Bausteine nachzubauen.
Bau die zweite Marke ohne zweites Projekt
Registriere dich kostenlos, lege ein Projekt an und sieh dir an, wie Varianten konfiguriert und ausgeliefert werden.