Lösung

Whitelabel Apps ohne Fork für jede Marke

Erscheint ein Produkt unter mehreren Marken, entstehen ohne Struktur Kopien und Store-Einträge von Hand. Die Plattform behandelt Marken als Konfiguration und übernimmt Build, Deployment und Release.

Eine Codebasis, mehrere Marken mit eigenem Branding
Eigene Domains und eigene Store-Einträge pro Variante
Build, Deployment und Store-Release automatisiert je Marke

Kostenlos registrieren Funktionen ansehen

Kostenlos starten. Keine Kreditkarte nötig.

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

Varianten legst du im Projekt fest, Build und Veröffentlichung laufen pro Marke.

Kurz gesagt

Varianten sind Konfiguration, keine Kopien des Projekts.

Eine Codebasis: Features werden einmal entwickelt und stehen allen Marken zur Verfügung.
Eigenes Erscheinungsbild: Branding, Domains und Store-Einträge unterscheiden sich pro Variante.

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 vorgesehen: 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 vorgesehen: Ä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 vorgesehen: 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 vorgesehen: 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 vorgesehen: 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: 10. August 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen.

Was Whitelabel-Projekte einfacher macht

Die Punkte, die den Aufwand pro zusätzlicher Marke klein halten.

Varianten statt Forks

Marken werden im Projekt konfiguriert. Es gibt keine Kopie der Codebasis, die eigenständig altert.

Eigene Domains und SSL

Jede Variante bekommt ihre Domain samt Zertifikat. Reverse-Proxy und SSL sind Teil des Server-Setups.

Store-Einträge pro Marke

Metadaten, Screenshots und Changelogs werden je Variante gepflegt und über Fastlane veröffentlicht.

Ein Release-Weg

Organisationen, Rollen und Projekt-Credentials regeln, wer welche Marke sehen und ausrollen darf.

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?

Dir. Repositories, Pipeline- und GitOps-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.

Kostenlos registrieren Mit uns sprechen