Meine Erfahrung mit .NET MAUI und warum ich mich bei Nebenprojekten letztendlich für PWA entschieden habe

Was mich an .NET MAUI gereizt hat

Was mir an .NET MAUI gefällt, ist die Vertrautheit mit Visual Studio, C# und .NET. Außerdem kann ich Entitäten, Validierungen und praktisch die gesamte Backend-Logik wiederverwenden, was die Entwicklung erheblich beschleunigt.

Aus diesem Grund habe ich mich für MAUI entschieden. Das Erste, was ich tat, war, ein sehr einfaches API-Backend zu erstellen.

Nach Abschluss der API habe ich Claude Code (Opus 4.5) gebeten, die gesamte Oberfläche zu erstellen und die API basierend auf Layoutspezifikationen zu konsumieren, die ich in .md-Dateien geschrieben habe.

Das Ergebnis war beeindruckend: In weniger als einem Tag hatte ich ein funktionierendes Projekt.

Die Herausforderungen der Entwicklung

Nachdem das Projekt generiert war, begann ich mit Tests unter Windows und stieß schnell auf zahlreiche Fehler.

Es waren mehrere Iterationen mit der KI erforderlich, bei denen ich spezifische Probleme aufzeigte, sowie mehrere manuelle Korrekturen von mir.

Am Ende gelang es mir, das Projekt sowohl unter Windows als auch unter Android durch manuelle Tests zum Laufen zu bringen.

Das größte Problem, auf das ich stieß, waren die Unterschiede zwischen den Plattformen.

• Code, der unter Android einwandfrei funktionierte, verursachte unter Windows Probleme.
• In einigen Fällen musste ich spezifische Komponenten nur für Windows erstellen.
• Es gab Situationen, in denen selbst die KI keine Lösung finden konnte.

Das war die größte Herausforderung während der Entwicklung.

Veröffentlichung der App im Play Store

Nachdem das Projekt funktioniert hatte, wollte ich es im Google Play Store veröffentlichen.

In diesem Moment bekam ich den größten Schrecken.

Neben der Zahlung einer Gebühr von etwa 25 US-Dollar (ca. 100 R$) musste ich mehrere bürokratische Prozesse durchlaufen:

• Screenshots erstellen.
• Mehrere Formulare ausfüllen.
• Richtlinien und App-Informationen konfigurieren.
• Einen Closed Testing erstellen.

Der Closed Testing war der komplizierteste Teil.

Es war notwendig, 12 Tester zu finden, die die App etwa 12 Tage lang nutzten, bevor ich die öffentliche Veröffentlichung beantragen konnte.

Da ich nicht so viele Personen zur Verfügung hatte, musste ich für diese Tests bezahlen.

Ich habe sogar eine E-Mail an Google geschickt und erklärt, dass die App nur ein Nebenprojekt zu Studienzwecken sei, mit nur zwei Bildschirmen zum Lesen von Artikeln, und bereits manuell getestet wurde.

Ich fragte, ob es eine Möglichkeit gäbe, diese Anforderung zu reduzieren oder eine Ausnahme zu erhalten.

Die Antwort war einfach: nein.

Wartung des MAUI-Projekts

Ein weiterer Punkt, der mich störte, war die Wartung.

Jedes Update erforderte einen neuen Veröffentlichungsprozess für Windows und Android.

Das verursacht ziemlich viel Arbeit für ein persönliches Projekt, das:

• Keine Einnahmen generiert.
• Nur zum Lernen existiert.
• Im Grunde nur Kontakte von anderen Entwicklern erhält, die um Hilfe bitten, oder von Leuten, die Dienstleistungen anbieten.

In diesem Moment begann ich, nach Alternativen zu suchen.

Entscheidung, PWA zu testen

Ich beschloss, eine Progressive Web App (PWA) auszuprobieren.

Die Implementierung war extrem einfach.

Im Grunde musste ich nur:

• Einige Icons hinzufügen.
• Eine worker.js konfigurieren.

Claude Code hat praktisch die gesamte Implementierung übernommen.

Was mir an PWA am besten gefallen hat

PWA ist praktisch die Website selbst, die als App funktioniert.

Das bedeutet, dass ich keine plattformspezifische Version erstellen und nicht die ganze Bürokratie der Stores durchlaufen muss.

Die Verteilung erfolgt direkt über die Website.

Obwohl es sich um eine Webanwendung handelt, bietet der durch den Service Worker implementierte Cache in vielen Szenarien ein sehr naturnahes App-Erlebnis.

Vorteile von PWA

• Extrem schnelle Implementierung.
• Kann offline funktionieren.
• Hervorragendes Caching-System durch den Service Worker.
• Updates erfolgen automatisch, wenn die Website aktualisiert wird.
• Erfordert keine Veröffentlichung in Stores für die Verteilung.
• Muss nicht bei jedem Update bürokratische Prozesse wiederholen.
• Ein einziges Projekt bedient alle Plattformen.
• Ideal für Informationssysteme, ERP, Dashboards und administrative Anwendungen.

Nachteile von PWA

• Viele Führungskräfte kennen die Technologie noch nicht und zögern daher, sie einzusetzen.
• Hat Einschränkungen beim Zugriff auf das Betriebssystem.
• Kann nicht direkt mit Treibern arbeiten.
• Kein Zugriff auf USB-, serielle Schnittstellen, Prozesse, Systemdienste und andere Low-Level-Ressourcen.
• Erreicht noch nicht in allen Szenarien die gleiche Leistung wie eine wirklich native App.

Abschließende Überlegungen

Meine Schlussfolgerung ist relativ einfach.

Wenn ich eine App entwickeln müsste, die auf spezifische Betriebssystemressourcen angewiesen ist, wie z.B. industrielle Automatisierung, Kommunikation mit Geräten, Treiber oder tiefe OS-Integration, würde ich Flutter, .NET MAUI oder sogar native Entwicklung wählen.

Andererseits würde ich für Anwendungen wie:

• ERP.
• Interne Systeme.
• Portale.
• Unternehmensanwendungen.
• Informationssysteme.
• Artikel lesen.

heute wahrscheinlich ein PWA wählen.

Die Entwicklung ist extrem schnell, die Wartung verschwindet praktisch, Updates sind sofort verfügbar und es gibt die ganze Bürokratie bei der Veröffentlichung in Stores nicht.

Die einzige Herausforderung, die ich noch sehe, ist die Akzeptanz der Technologie, da viele Führungskräfte einfach nicht genug über PWA wissen und daher traditionellere Lösungen bevorzugen.