Warum die Entwicklung nativer Windows-Apps ein Desaster ist

• Das Ökosystem für die Entwicklung nativer Windows-Apps liefert selbst im Jahr 2025 keine echte Produktivität, weil es seit Jahrzehnten von Brüchen zwischen Frameworks und wiederholten Neuentwürfen geprägt ist
• Von Win32 über MFC, WinForms, WPF, WinRT und UWP bis zu WinUI 3 gab es zwar sieben Entwicklungsstufen bei UI-Frameworks, dennoch gibt es viele Fälle, in denen sich nicht einmal grundlegende Funktionen allein mit den neuesten APIs umsetzen lassen
• Alltägliche Funktionen wie Tray-Icons oder das Abfangen globaler Tastenkürzel sind weiterhin auf Win32-Aufrufe per P/Invoke angewiesen, was den Sinn der Einführung moderner Frameworks untergräbt
• Selbst wenn mit .NET AOT-Kompilierung eine einfache Utility-App gebaut wird, entsteht ein Binärpaket von mehr als 9 MiB, und für die Verteilung per MSIX gibt es mit jährlich $200–300 für ein Code-Signing-Zertifikat eine reale Hürde
• Die Tatsache, dass Microsofts eigene zentrale Apps wie VS Code, Outlook und das Startmenü mit Web-Technologien umgesetzt sind, zeigt, dass native Windows-Entwicklung selbst innerhalb von Microsoft keine Priorität mehr hat

---

Hintergrund: Was wurde gebaut

• Bei der Entwicklung der Windows-exklusiven Utility-App „Display Blackout“ wurden die Probleme der heutigen nativen App-Entwicklungsumgebung sichtbar
  • Die App bietet in Multi-Monitor-Umgebungen beim Spielen die Funktion, die linken und rechten Bildschirme mit einem schwarzen Overlay auszuschalten
  • Benötigt werden Funktionen wie Display-Auflistung, Grenzberechnung, Verarbeitung globaler Tastenkürzel, Anzeige eines Tray-Icons, Autostart beim Systemstart und Speichern von Einstellungen
• Zwar gibt es bestehende AutoHotkey-Skripte und Microsoft-Store-Apps, doch aus Lernzwecken und zur Verbesserung der UI wurde eine Eigenentwicklung versucht
• Das Ergebnis: Die native Windows-App-Entwicklungsumgebung ist extrem komplex und ineffizient

Die Geschichte der Windows-Programmierung

• Anfangs war die C-basierte Win32 API die einzige Wahl, und diese API ist bis heute gültig
• Das C++-basierte MFC ergänzte Win32 um objektorientierte Abstraktionen wie Klassen und Templates
• Mit .NET 1.0 (2002) kamen die Sprache C#, eine JIT-Bytecode-VM und automatische Speicherverwaltung; Windows Forms war ein Wrapper um die Fenster- und Control-APIs von Win32
• WPF in .NET 3.0 (2006) führte die Markup-Sprache XAML ein und war mit GPU-basiertem Rendering von Controls der erste Versuch, sich von der Win32-Abhängigkeit zu lösen
• WinRT in Windows 8 (2012) führte ein Sandbox-App-Modell ein und zielte auf die Vereinheitlichung von Desktop, Tablet und Smartphone, sorgte aber für Verwirrung, weil sich die XAML-Struktur subtil von WPF unterschied
• UWP in Windows 10 (2015) lockerte einige Sandbox-Beschränkungen, erreichte aber nicht die Desktop-Rechte von WPF; zudem blieben einige OS-Funktionen wie Push-Benachrichtigungen, Live Tiles und die Verteilung über den Microsoft Store auf WinRT/UWP beschränkt
  • Das führte dazu, dass bestehende Apps wie Chrome und Microsoft Office eine unbeholfene Architektur mit per IPC verbundenen WinRT/UWP-Bridge-Apps übernehmen mussten
• Das Windows App SDK in Windows 11 (2021) öffnete exklusive WinRT/UWP-Funktionen auch für Standard-Apps in C++ und .NET und enthält mit WinUI 3 eine neue XAML-basierte Control-Bibliothek
• Zusammenfassung der UI-Framework-Entwicklung:
  > Win32 C APIs → MFC → WinForms → WPF → WinRT XAML → UWP XAML → WinUI 3

Das Dilemma bei der Wahl des Entwicklungswegs

• Für die Entwicklung von WinUI-3-Apps gibt es drei Wege:
  • C++: schlanke Binärdateien, einfache Interoperabilität mit der Win32-C-API — aber ohne Speichersicherheit
  • C#/XAML + frameworkabhängige Verteilung: Selbst auf aktuellem Windows 11 ist nur .NET 4.8.1 vorinstalliert, sodass bei der ersten Installation ein Dialog zum Herunterladen von .NET-Bibliotheken erscheint — eine miserable User Experience
  • C#/XAML + .NET AOT: Die komplette .NET-Runtime (VM, GC, Standardbibliothek) wird in die Binärdatei eingebettet — selbst einfache Apps erzeugen so Binärdateien von mehr als 9 MiB
• Der Versuch, Rust-Bindings weiterzuführen (windows-app-rs), wurde archiviert
• Auch bei der Verteilung gibt es die Qual der Wahl:
  • Das MSIX-Format erfordert ein Code-Signing-Zertifikat und kostet für Personen außerhalb der USA jährlich $200–300
  • Unsigned Sideloading erfordert schwer verständliche PowerShell-Befehle, die nur in einem Administrator-Terminal nutzbar sind
  • Die Registrierung im Microsoft Store wurde mit der Begründung abgelehnt, es werde kein „einzigartiger und nachhaltiger Mehrwert“ geboten

Funktionen, die selbst mit dem aktuellen SDK nicht möglich sind

Funktion	Unterstützung im Windows App SDK
Display-Auflistung	Teilweise möglich (foreach-Schleife nicht möglich, Änderungserkennung erfordert P/Invoke)
Platzierung inaktiver schwarzer Fenster	Teilweise möglich (non-activating erfordert P/Invoke)
Abfangen globaler Tastaturkürzel	Nicht möglich — P/Invoke erforderlich
Autostart beim Systemstart	Möglich (API zur Anbindung an Systemeinstellungen vorhanden)
Persistentes Speichern von Einstellungen	Möglich
Tray-Icon + Menü	Nicht möglich — P/Invoke erforderlich, Menü-Stil nicht standardisiert

• Der Stil von Tray-Icon-Menüs unterscheidet sich von App zu App; im gesamten OS gibt es keinen konsistenten Standard
• Auf dem Weg von WPF zu WinUI 3 sind sogar grundlegende Funktionen wie die automatische Anpassung der Fenstergröße verloren gegangen

Strukturelle Grenzen von C# und Win32-Interop

• Das moderne P/Invoke-Tool CsWin32 hat einen Bug, durch den Strings innerhalb von Structs nicht korrekt gewrappt werden
• Die Dokumentation von CsWin32 erklärt, dass es in C# keine idiomatische Darstellung für den grundlegenden Win32-API-Parametertyp [optional, out] gibt und deshalb zwei Versionen derselben Methode generiert werden
• Selbst 20 Jahre nach der Veröffentlichung von WPF (2006) hat sich der Boilerplate-Code zum Schreiben von Klassen für UI-Binding kaum verbessert
  • Es ist weiterhin wiederholter Code nötig, um alle Properties in Getter/Setter-Paare zu verwandeln, Gleichheitsprüfungen einzubauen und Event-Aufrufe auszulösen
  • Eine sprachseitige Lösung, die JavaScript-Dekoratoren oder Proxys entspricht, wurde C# in 20 Jahren nicht hinzugefügt
• CsWin32 bietet magere Changelog-Inhalte und verharrt auf einer Version unter 1.0, sodass es durchaus möglich wirkt, dass das Projekt in wenigen Jahren aufgegeben wird

Fazit: Warum Electron die Antwort ist

• Aktuell priorisiert Microsoft die Entwicklung nativer Apps nicht
  • Die zugehörigen Issue-Tracker sind voll mit Bugs und Reports, aber es gibt kaum Antworten von Microsoft-Ingenieuren
  • Die Changelogs des Windows App SDK konzentrieren sich vor allem auf das Hinzufügen von Machine-Learning-APIs
• Dass Microsofts wichtigste eigenen Apps wie VS Code, Outlook und das Startmenü mit Web-Technologien umgesetzt sind, ist ein weiterer Beleg dafür
• Die Community bewegt sich zu Third-Party-UI-Frameworks wie Avalonia und Uno Platform
  • Diese führen die WPF-Philosophie fort und stärken zugleich die Cross-Platform-Unterstützung
• Derzeit sind webbasierte Frameworks wie Electron oder Tauri die realistischere Wahl
  • Die Kombination aus TypeScript/React/CSS ist produktiver als C#/XAML
  • Auch Zugriff auf die Win32 API ist möglich

  • Tauri** nutzt** die systemeigene WebView, sodass kein Chromium-Bundle nötig ist

    • Die WebView2-Runtime wird alle 4 Wochen aktualisiert, während das System-.NET auf 4.8.1 feststeht
    • Microsoft könnte eine Erholung ermöglichen, wenn das Unternehmen das Windows App SDK verbessert und das Verteilungssystem vereinfacht
    • Aktuell erwarten das jedoch die meisten Entwickler nicht
    • Das Fazit lautet daher: „Ich werde den Web-Stack wählen“
• Microsofts jüngste Ankündigung zum Fokus auf Windows-Qualität enthält zwar die Aussage, WinUI 3 systemweit stärker einzusetzen, ob das aber zu echten Verbesserungen führt, bleibt unklar