Microsoft versucht, das Windows-Anwendungsökosystem mithilfe von KI-Agenten rund um WinUI neu aufzubauen, statt sich auf herkömmliche Entwicklungs- und Migrationsprozesse zu stützen, die das manuelle Schreiben großer Code-Mengen erfordern. Das Unternehmen erklärt, ein neuer Schnellleitfaden ermögliche es, eine WinUI-3-Anwendung ausgehend von einem leeren Ordner zu erstellen, sie zu testen, im MSIX-Format zu paketieren und innerhalb von etwa 30 Minuten an den Microsoft Store zu senden.
Der vorgeschlagene Ablauf erfordert keine Installation von Visual Studio und stützt sich auf VS Code, .NET 10, die Windows App Development CLI, WinUI-Projektvorlagen und eine kostenlose Version von GitHub Copilot sowie die Erweiterung WinUI Agent. Dem Artikel zufolge sind die verwendeten Werkzeuge kostenlos, und der manuelle Eingriff in den Phasen der Anwendungserstellung, des Hinzufügens von Funktionen, des Testens und des Paketierens kann weitgehend begrenzt werden.
Was bringt das Tool WinUI Agent?
WinUI Agent sollte nicht mit Copilot als allgemeinem Konversationsassistenten verwechselt werden. Das Tool ist für Aufgaben im Zusammenhang mit der Entwicklung von WinUI-Anwendungen konzipiert, darunter das Entwerfen der Benutzeroberfläche, die Codeüberprüfung, das Testen der Benutzeroberfläche, das Paketieren von Anwendungen und die Migration von Projekten auf Basis älterer Frameworks. Microsoft empfiehlt außerdem, den Agenten mit dem Microsoft Learn MCP-Server zu verbinden, damit er bei der Ausführung von Abfragen und Aufgaben auf die aktuellste Dokumentation der WinUI-API zurückgreifen kann.
Dieser Punkt ist wichtig, weil WinUI 3 laut der Darstellung des Artikels nicht über denselben Umfang an verfügbaren Trainingsbeispielen für KI-Modelle verfügt wie WPF und UWP. Daher könnte der Agent automatisch alte Muster erzeugen, sofern er keine ausdrücklichen Anweisungen zu den erforderlichen modernen Alternativen erhält.
Migration ist kein Suchen und Ersetzen
Microsoft stellt außerdem eigene Anleitungen für die Migration von WPF- und UWP-Anwendungen zu WinUI bereit. Im Fall von WPF beschränkt sich der Prozess nicht auf das Ersetzen von Namespace-Namen. So erfordert beispielsweise der Wechsel von System.Windows.* zu Microsoft.UI.Xaml.* den Umgang mit Unterschieden bei Steuerelementen, Thread-Verarbeitung, Fensterverwaltung, der Unterstützung von DPI-Bildschirmen und der Datenbindung. Das Unternehmen stellt Vergleichstabellen und erste Anweisungen bereit, die den Agenten bei der Prüfung dieser Aspekte unterstützen.
Die UWP-Anleitungen erklären hingegen, dass die Plattform nicht mehr aktiv weiterentwickelt wird und WinUI 3 sowie das Windows App SDK den nachfolgenden Entwicklungspfad darstellen. Microsoft warnt davor, dass KI-Modelle aufgrund ihres Trainings mit einer großen Zahl über Jahre angesammelter UWP-Beispiele weiterhin herkömmliche UWP-Muster erzeugen könnten, wenn die Migrationsfähigkeiten nicht die zu verwendenden Alternativen festlegen.
Warum ist diese Nachricht wichtig?
Das übergeordnete Ziel besteht darin, die Kosten für die Einführung neuer nativer Anwendungen in Windows zu senken und zugleich den Aufwand für die Migration einer großen Basis von WPF- und UWP-Anwendungen zu verringern. Microsoft setzt damit auf die Behandlung eines der Gründe, aus denen Entwickler zu Webanwendungen und plattformübergreifenden Frameworks greifen: die Möglichkeit, Code über verschiedene Systeme hinweg wiederzuverwenden und dabei die Abhängigkeit von einem Windows-Framework zu vermeiden, das sich in Zukunft grundlegend verändern könnte.
Auf der Build 2026 bezeichnete Microsoft WinUI als „Produktionsplattform für Windows-Anwendungen“ und entfernte außerdem die Zahl „3“ aus dem Namen, um die Botschaft zu vermitteln, dass die Plattform künftig keiner umfassenden Neuimplementierung unterzogen werden soll. Zu den weiteren Versprechen gehören ein geringerer Speicherverbrauch, die Ergänzung von DataGrid und Diagrammen, eine bessere Kompatibilität mit WPF und eine stärkere Beteiligung an der Open-Source-Entwicklung, wobei darauf hingewiesen wird, dass WinUI vollständig quelloffen geworden ist.
Microsoft nutzt WinUI 3 laut dem Artikel außerdem, um einige ältere Komponenten der Windows-11-Oberfläche zu ersetzen, darunter Funktionen für die automatische Wiedergabe und die Druckverwaltung. Diese interne Nutzung liefert dem Unternehmen ein praktisches Argument, wenn es Entwickler zur Einführung der Technologie auffordert, offenbart zugleich aber einen Maßstab, an den sich Microsoft selbst halten muss.
Grenzen, die Codegenerierung nicht beseitigt
Eine geringere Zahl von Zeilen, die ein Entwickler schreibt, bedeutet nicht zwangsläufig eine höhere Qualität der Anwendung. Der Artikel weist darauf hin, dass Microsoft den WinUI Agent gerade deshalb mit Prüf- und Testfunktionen ausgestattet hat, weil der generierte Code einer Überprüfung bedarf. Außerdem wird es nicht ausreichen, Entwickler zu nativen Anwendungen zu bewegen, wenn dies zu speicherintensiven oder langsam reagierenden Anwendungen führt.
Hier zeigt sich ein Widerspruch in Microsofts Strategie: Das Unternehmen ermutigt Entwickler, leichtere native Anwendungen zu erstellen, verwendet aber WebView2 in einigen seiner Anwendungen und sogar in den Windows-Oberflächen selbst. Der Artikel nennt, dass die auf WebView2 basierende Wetter-App in Windows 11 im Leerlauf etwa 1,2 Gigabyte Speicher verbraucht, also nahezu fünfmal so viel wie die native Wetter-App in macOS, und dabei neun Chromium-Unterprozesse ausführt. Auch Anwendungen wie WhatsApp, Discord und Teams sehen sich den im Ausgangstext genannten Beispielen zufolge mit Kritik hinsichtlich Leistung oder Ressourcenverbrauch konfrontiert.
Lesart von certi.news: Die tatsächliche Veränderung besteht nicht lediglich in der Ergänzung eines Programmierassistenten, sondern in dem Versuch, den gesamten Entwicklungszyklus von Windows mit einem Agenten zu verknüpfen, der die Anwendung erstellen, migrieren, testen und paketieren kann. Der Erfolg des Plans wird von zwei Punkten abhängen, die die Werkzeuge bislang noch nicht bewiesen haben: der Genauigkeit der Migration in realen Projekten und der Frage, ob KI-generierte WinUI-Anwendungen bei Leistung und Ressourcenverbrauch tatsächlich besser abschneiden werden als die Webanwendungen, mit denen Microsoft konkurrieren möchte. Daher erscheint die Initiative für Windows-Entwickler vielversprechend, beseitigt jedoch nicht die Notwendigkeit technischer Überprüfungen und praktischer Tests.