- 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
3 Kommentare
Danke für die Normalisierung mit Electron …
Ich frage mich, wann endlich ein WYSIWYG für WinUI 3 kommt.
Hacker-News-Meinungen
Ich denke wie andere auch, dass es richtig ist, bei Win32 zu bleiben
Aus der Perspektive von jemandem, der seit langem mit Win32 entwickelt, lassen sich die nötigen Funktionen problemlos in einer eigenständigen ausführbaren Datei von unter 8 KB umsetzen
Display-Auflistung, Fenstererstellung, Hotkey-Hooking, Registrierung im Autostart, Speichern von Einstellungen, Anzeige von Tray-Icons – all das ist mit API-Aufrufen im Umfang von nur ein paar hundert Byte möglich
Aber im Jahr 2026 ein neues Projekt in einer nicht speichersicheren Sprache (C++) zu schreiben, ist nicht mehr zeitgemäß
Wenn es sich allerdings um eine App mit kaum unvertrauenswürdigen Eingaben handelt, muss man sich nicht unbedingt von Propaganda beeinflussen lassen
_UNICODE-Probleme vermeiden will, kann man dasselbe mit .NET Framework in der halben Zeit bauenIch finde, die Bewegung „NoFramework“ sollte zurückkommen und wir sollten wieder in die RAD-Ära zurückkehren
Bei neuen Projekten sollte man die Wahl von C++ aber sorgfältig abwägen
Man kann Win32 auch aus speichersicheren Sprachen heraus nutzen — zum Beispiel windows-rs
Damals war Borland Delphi das populärste Werkzeug
Wenn es sich nicht um bestehende WinRT-, UAP- oder UWP-Apps handelt, sollte man WinUI 3.0 oder das WinAppSDK vermeiden
Es ist besser, weiter auf bewährte Technologien wie Win32, MFC, WinForms oder WPF zu setzen,
und außerhalb des Microsoft-Ökosystems kommen Qt, VCL, Firemonkey, Avalonia, Uno, ImGUI usw. infrage
WinUI 3.0 ist so chaotisch, dass sogar Microsoft versucht, es als Open Source an die Community zu übergeben
Später wurde WinJS zu einem Open-Source-Web-Framework umgewandelt, woraufhin der offizielle Support eingestellt wurde
Zugehöriger Blogbeitrag
Ich bin Embedded-Entwickler, und es ist immer noch einfach, Win32-GUI-Programme zu bauen, die mit Geräten kommunizieren
Code aus der XP-Zeit lief unverändert auch unter Windows 11, und selbst wenn man ein VC6-Projekt in Visual Studio 2022 öffnet, lässt es sich problemlos bauen
Solche Abwärtskompatibilität ist auf anderen Plattformen kaum zu finden
Apples Cocoa wirkt strukturell zwar „elegant“, ist in der Praxis aber komplex und schlecht dokumentiert
Die reine Win32-API ist weiterhin eine praktische Wahl
Wenn man sich in C++ selbst einen MFC-ähnlichen Wrapper baut, ist der in 2 bis 3 Wochen fertig, und danach hat man vollständige Kontrolle
Dank Microsofts starker Abwärtskompatibilität sind Win32-basierte Apps langfristig stabil
Ein Beispiel, das über mehr als 10 Jahre hinweg aktualisiert wurde, gibt es hier
Systemfarben und Controls sind hart kodiert und kollidieren deshalb mit dunklen Themes
Nur ein Teil der UI – etwa Menüs, Message-Boxen oder Dateidialoge – unterstützt Dark Mode, wodurch die Konsistenz verloren geht
Eine entsprechende Diskussion findet sich in diesem Beitrag
Heute wird es als Open Source gepflegt und ist inzwischen bei Version 10 angekommen
Aus meiner Erfahrung mit mehreren Windows-Apps gilt:
(1) Die Win32-API ist alt, aber sehr stabil, und
(2) UI-Toolkits von Microsoft sollte man meiden — am Ende braucht man doch Kontrolle auf Win32-Ebene
Die meisten UI-Technologien, die Microsoft in den letzten 20 Jahren entwickelt hat, waren Variationen von WPF
Hätte man WPF konsequent weiterentwickelt, wäre es heute vermutlich der Standard für UI-Entwicklung
Aus Nutzersicht sind native Apps schnell und gut, aber die Entwicklung ist wirklich ein kompliziertes Chaos
Das ist auch der Grund, warum Apps wie Outlook und Teams immer schlechter werden
Dinge wie Fokus oder Tastaturnavigation lassen sich nur schwer mit echtem nativen Gefühl nachbilden
Siehe das Electrobun-Projekt
Ich stimme der Aussage nicht zu, dass „ein neues Projekt in C++ zu bauen ein Verbrechen“ sei
Bei GUIs sind Performance und Kontrolle wichtiger als Sicherheit, und C++ ist nach wie vor eine bewährte Sprache
Qt ist auch 2026 noch eines der besten GUI-Frameworks und bringt Funktionen für Speichersicherheit mit
Ich frage mich, warum die aktuelle .NET-Runtime nicht standardmäßig in Windows 11 enthalten ist
Das wirkt wie ein weiteres Beispiel dafür, dass Microsoft eine konsistente Nutzererfahrung aufgegeben hat
deshalb ist es unrealistisch, sie alle über Windows Update auszurollen
Stattdessen kann man AOT-kompilierte eigenständige ausführbare Dateien verteilen (etwa 9 MiB)
Das ist viel kleiner und effizienter als Electron
Heute ist es besser, die DLLs direkt mit zu paketieren
wodurch eine Integration ins OS schwierig geworden ist
Um den schnellen Release-Zyklus beizubehalten, wurde es von OS-Updates entkoppelt
während .NET Core separat installiert werden muss
Nach langer Zeit habe ich wieder einmal mit Tauri Apps für Windows und Mac gebaut,
Entwicklung und Build waren einfach, aber wegen Code-Signing konnten Kollegen sie nicht installieren
Auf dem Mac ließ sich das per Terminalbefehl lösen, unter Windows musste jedoch Smart App Control deaktiviert werden
Diese Funktion lässt sich ohne Neuinstallation nicht wieder aktivieren
Ich verstehe den Sicherheitszweck, aber ich hätte nicht gedacht, dass die Installation so schwierig sein würde
Die Antwort auf die Frage „Warum nicht einfach Electron?“ ist simpel —
Electron-Apps bieten eine schlechte Nutzererfahrung
Die Entwicklung ist einfach, aber auf Kosten von Performance und Qualität
Wenn man ein gutes Produkt bauen will, muss man trotz aller Schwierigkeiten nativ entwickeln
Persönlich finde ich C# viel besser als TypeScript