Domenic Denicola — known for his work on web standards and stints at both Google and Microsoft — published a detailed account of trying to build native Windows applications in 2026, and the picture is bleak.
The core problem isn't that Windows lacks UI frameworks. It's that it has too many, none of them complete, and Microsoft keeps launching new ones before finishing the old ones. WinForms, WPF, UWP, WinUI 2, WinUI 3, MAUI, Reunion — each was supposed to be The Answer. Each was partially abandoned in favor of the next shiny thing.
WinUI 3, the current official recommendation, still has significant gaps years after its initial release. MAUI, Microsoft's cross-platform play, has its own set of well-documented stability issues. Meanwhile, WPF — the framework many production apps still depend on — receives maintenance-level updates at best. The developer who needs to ship a Windows desktop app today faces a genuinely difficult choice where every option comes with serious trade-offs.
This resonated hard on Hacker News (198 points), and for good reason. The Windows developer experience has been deteriorating relative to other platforms for years. macOS has SwiftUI with a clear migration path from AppKit/UIKit. Linux has GTK and Qt with decades of stability. Windows has a graveyard of half-finished frameworks and a recommendation matrix that reads like a choose-your-own-adventure book written by a committee.
The deeper issue is strategic. Microsoft's attention — and its best engineering talent — has shifted decisively toward cloud (Azure), AI (Copilot), and developer tools (VS Code, GitHub). Windows-the-platform gets features that serve those priorities: WSL for cloud developers, Copilot integration for AI demos, Terminal for the CLI crowd. What it doesn't get is a coherent story for people building native desktop software.
This matters beyond Windows enthusiasts. Enterprise software, internal tools, creative applications, and scientific instruments still need native desktop UIs. When the platform owner can't commit to a single framework for more than three years, it pushes developers toward Electron, Tauri, or web apps — which then get criticized for not being 'native enough.'
The take is straightforward: Microsoft needs to pick one framework, fund it properly, and stop the cycle of announce-underdeliver-abandon. Until they do, Windows native development will remain a tax that developers pay, not a capability they choose.
I'm an embedded programmer who occassionally needs to write various windows programs to interface with embedded devices (usually via serial port or usb), and I find it a breeze to write native gui programs in pure win32 and c++.Recently had to add a new feature to and old program that was last
Again, unless you have existing Windows 8/10 applications that were written against WinRT, UAP or UWP[0], that make use of WinUI 2.0, forget about touching anything related to WinUI 3.0 or WinAppSDK, stay away from the marketing.Exception being the few APIs that have been introduced in Win32 th
The author is right, it's really such a mess.The lessons I've learnt building and shipping a few a Windows apps at scale are basically:(1) Learn Win32 and use those ancient APIs if possible, they're extraordinarily stable and you'll probably need to reach for them anyway. They&#x
Let me chime in and say that plain Win32 API is a perfectly viable option if you are using C++ (or another "OO" language) and if you are willing to sink a couple of weeks into writing your own MFC-like wrapper.Clearly this is not an option for those who are just starting up with Windows GU
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid.Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable