Ein generisches Projektmodell
Viele Unternehmen möchten eine einzige Codebase pflegen und daraus mehrere Marken-Apps ableiten – jede mit eigenem Branding, eigenem Bundle-Identifier und gelegentlich abweichender Business-Logik. Im Folgenden zeige ich ein schlankes, bewusst generisch gehaltenes Struktur- und Build-Konzept, das sich flexibel auf jede multibrand-Situation übertragen lässt. Eine Multibrand App mit .NET MAUI
Grundidee der Multibrand App mit .NET MAUI
Shared Core
Alle plattform- und markenunabhängigen Funktionen liegen in einem gemeinsamen Projekt.Brand Projects
Für jede Marke gibt es ein separates .NET-MAUI-Projekt, das den Shared Core referenziert und nur die Ressourcen überschreibt, die wirklich anders sein müssen (Farben, Texte, Logos, evtl. zusätzliche Services).One Build per Brand
Jedes Brand-Project generiert exakt eine iOS- und eine Android-App – mit eigenem Bundle-Identifier, separatem Store-Listing und eigener CI/CD-Pipeline.
Ordner- und Projektstruktur (Overview)
Multibrand Apps mit .NET MAUI - Solution
│
├─ SharedCore/ # Gemeinsamer Code & Ressourcen
│ ├─ Resources/
│ │ ├─ Fonts/
│ │ └─ Images/
│ ├─ Services/ # Business-Logik für alle Marken
│ ├─ Views/ # Wiederverwendbare UI-Komponenten
│ └─ Tests/ # Unit-Tests für SharedCore
│
├─ Brand.Generic/ # Marke 1
│ ├─ Resources/
│ │ └─ Texts/ # markenspezifische Strings
│ └─ Generic.csproj
│
├─ Brand.Pride/ # Marke 2
│ └─ ...
│
└─ Brand.XYZ/ # weitere Marken
.NET MAUI arbeitet mit einem Multi-Target-Projekt – iOS, Android, Windows, macOS sind nur unterschiedliche Targets. Markenunterschiede lösen wir deshalb nicht über Platform-Projects, sondern über eigene Brand-Projects mit gezielter MSBuild-Konfiguration.
Shared vs. Brand-spezifisch
| Ebene | Inhalt (Beispiele) |
|---|---|
| Shared Core | MVVM-Framework, REST-Clients, Logging, Theme-Grundfarben, Basis-Views |
| Brand Project | eigenes Resources/Texts/strings.resx, Logo, Farb-Akzent, evtl. Payment-SDK |
| Platform Hooks | iOS-/Android-Differenzen via #if IOS / Partial Classes |
Build- und Release-Pipelines
CI kompiliert Shared Core und führt Unit-Tests aus.
CD baut pro Brand zwei Artefakte (APK + IPA) mit individuellem Bundle-Identifier.
Jede Brand verfügt über einen separaten Play-Console- bzw. App-Store-Connect-Workflow (Fastlane, Azure DevOps …).
Lessons Learned
Ressourcen strikt trennen – alles, was sich potenziell unterscheidet, gehört in die Brand-Ressourcen.
Shared Core bleibt neutral – Markenlogik via Decorator oder Feature Flag drüberlegen.
MSBuild-Properties sauber halten – pro Brand genau eine
$(ApplicationId)-Definition.Lean Duplication – erst duplizieren, wenn wirklich notwendig; so bleibt die Codebase schlank.
Fazit
Mit einem Shared Core + Brand Projects nutzt man .NET MAUI optimal: eine zentrale Codebase, klare Trennung der Markenbelange und übersichtliche Deployments – perfekt für Unternehmen, die ein Produkt unter mehreren Marken ausrollen möchten.