Multibrand App mit .NET MAUI

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 marken­unabhä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

EbeneInhalt (Beispiele)
Shared CoreMVVM-Framework, REST-Clients, Logging, Theme-Grundfarben, Basis-Views
Brand Projecteigenes Resources/Texts/strings.resx, Logo, Farb-Akzent, evtl. Payment-SDK
Platform HooksiOS-/Android-Differenzen via #if IOS / Partial Classes

Build- und Release-Pipelines

  1. CI kompiliert Shared Core und führt Unit-Tests aus.

  2. CD baut pro Brand zwei Artefakte (APK + IPA) mit individuellem Bundle-Identifier.

  3. 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über­legen.

  • 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.

Schreibe einen Kommentar