Letzten Herbst saß ich bei einem Metallverarbeiter mit 180 Mitarbeitenden. Die hatten eine interne Android-App für die Werkslogistik — gebaut von einem Dienstleister, der inzwischen nicht mehr existiert. Der Code lief auf Xamarin, die App sah aus wie 2018, und der Betriebsleiter fragte mich: „Müssen wir das jetzt komplett neu bauen?"
Antwort war Nein — aber nur knapp. Die Migration nach .NET MAUI war möglich, hat drei Monate gedauert, und am Ende sah die App immer noch aus wie 2018. Nicht weil der Entwickler schlechte Arbeit gemacht hat, sondern weil Material 2 nun mal so aussieht. Das Feedback der Mitarbeiter war entsprechend: „Warum sieht das nicht aus wie die anderen Apps auf meinem Handy?"
Genau dieser Punkt hat mich den aktuellen Post vom .NET Blog aufmerksam lesen lassen.
Was Microsoft gerade ankündigt
Der Beitrag beschreibt, wie .NET MAUI 10 eine opt-in-Unterstützung für Material 3 — Googles aktuelles Design-System für Android — einführt. Das Aktivieren läuft über eine einzige Property im .csproj:
<UseMaterial3>true</UseMaterial3>
Ab .NET MAUI 10.0.60 (SR6) bekommt man damit automatisch überarbeitetes Styling für die wichtigsten Controls: Entry, Button, DatePicker, Slider, SearchBar und mehr. Die alten Stile bleiben parallel nutzbar, eigene Farben und Handler überschreiben Material 3 weiterhin. iOS und Windows sind explizit nicht betroffen — die nutzen ihre eigenen nativen Design-Systeme, was richtig so ist. Der Autor liefert auch Screenshots, eine Demo-App und einen Link zum Tracking-Issue für noch fehlende Controls.
Technisch ist der Post sauber, korrekt und vollständig. Das ist keine Kritik, sondern ein Ausgangspunkt.
Wie das in einem KMU mit 30–300 Mitarbeitenden wirklich landet
Ich habe in den letzten drei Jahren bei acht Unternehmen .NET-basierte mobile Apps begleitet — interne Tools, Außendienstanwendungen, Lagerlogistik, Servicetechnikerbegleitung. Mein Eindruck: Die wenigsten dieser Apps werden von einem dedizierten Mobile-Entwickler betreut. Meistens teilt sich jemand die Aufgabe mit dem Backend, manchmal ist es der einzige .NET-Entwickler im Haus überhaupt.
Was das für Material 3 bedeutet:
Erstens: Die gute Nachricht ist wirklich gut. Eine einzige Property, kein XML-Gefrickel in Resources/values/styles.xml, kein Handler-Customizing — das ist der richtige Weg. Wer jetzt eine neue MAUI-App für Android baut, sollte <UseMaterial3>true</UseMaterial3> von Anfang an setzen. Der Migrations-Aufwand für Greenfield-Projekte ist nahe null, und der optische Unterschied ist erheblich. Mitarbeiter erkennen Material-3-Patterns von ihren privaten Handys — das reduziert Schulungsbedarf.
Zweitens: Für bestehende Apps ist das Risiko nicht null. Die Formulierung „Any colors or styles you have explicitly set still take precedence" klingt beruhigend, aber in der Praxis gibt es in gewachsenen MAUI-Apps eine Menge implizit gesetzter Styles. Ich habe schon erlebt, dass jemand <Application.Resources> mit einem ResourceDictionary gefüllt hat, das ursprünglich aus einem Xamarin.Forms-Projekt migriert wurde und jetzt stillen Material-2-Override-Code enthält, den keiner mehr kennt. Ein Schalter, der „nur das Aussehen ändert", kann in solchen Apps trotzdem für Überraschungen sorgen — besonders beim DatePicker, der von einem Spinner-Dialog zu einem vollflächigen Kalender wechselt. Das ist keine kleine Änderung in der UX, auch wenn sie technisch rückwärtskompatibel ist.
Drittens: Der Artikel sagt nicht, was das für automatisierte UI-Tests bedeutet. Wer Screenshot-basierte Tests oder Appium-Skripte hat, die auf Control-Koordinaten oder UI-Tree-Elemente angewiesen sind, wird nach dem Schalten von UseMaterial3 auf Fehler laufen. Das ist kein Showstopper, aber es ist Arbeit — Arbeit, die im Rollout-Plan fehlt, wenn niemand explizit darauf hinweist.
Viertens, und das fehlt im Artikel komplett: Was ist mit Device-Fragmentierung? Android läuft auf Geräten von 2019 bis heute. Material You (der dynamische Farb-Teil von Material 3) funktioniert nur ab Android 12. Auf Android 10 oder 11 — und in vielen KMU-Umgebungen laufen auf Industrie-Handhelds genau diese Versionen — bekommt man Material 3 ohne Dynamic Color. Das ist kein Bug, das ist dokumentiertes Verhalten. Aber wenn dein Außendienstmitarbeiter ein Zebra-Gerät mit Android 10 hat, sieht er eine etwas andere App als der Kollege mit einem Samsung Android 14. Das muss man wissen, bevor man den Schalter umlegt.
Meine konkrete Empfehlung
Neue Projekte: Direkt mit <UseMaterial3>true</UseMaterial3> starten. Kein Grund, das aufzuschieben. Material 3 wird laut Microsoft in einer späteren Version der Default — wer jetzt anfängt, ist schon auf der richtigen Seite.
Bestehende Projekte mit aktiver Entwicklung: Auf einem Feature-Branch testen, gezielt die UX-kritischen Controls (DatePicker, Entry, SearchBar) manuell prüfen, und das Test-Gerät sollte das älteste im Einsatz sein, nicht das neueste. Wenn automatisierte UI-Tests existieren, erst die anpassen, dann den Flag setzen.
Bestehende Projekte ohne aktive Entwicklung: Finger weg. Der optische Gewinn rechtfertigt keinen Regressions-Zyklus in einer App, die niemand anfassen will. Wenn die App irgendwann eh migriert oder neu gebaut wird, dann Material 3 einplanen — jetzt nicht.
Konkrete Zahl aus der Praxis: Bei einem meiner Kunden haben wir für eine bestehende MAUI-App mit ~40 Screens geschätzt, was ein sauberer Material-3-Rollout kosten würde — inklusive Prüfung aller Custom-Styles, manueller Smoke-Tests auf drei Geräte-Generationen, und Anpassung der zwei vorhandenen Screenshot-Tests. Ergebnis: 3–5 Entwicklertage. Kein Riesenprojekt, aber auch kein Nullaufwand. Das solltest du in deiner Planung haben, bevor jemand sagt „wir setzen einfach den Flag".
Der vollständige Original-Beitrag von .NET Blog (MS): Give Your .NET MAUI Android Apps a Material 3 Makeover
Wenn du gerade vor der Entscheidung stehst — neue App oder bestehende modernisieren, und du willst wissen, was in deinem konkreten Fall der richtige Schritt ist — dann buche dir 30 Minuten:
— Bernhard