Domenic Denicola — a name you might recognize from TC39 and web standards work — published a detailed teardown of the current state of Windows native application development, and the picture is bleak.
The core problem: Microsoft has spent decades layering new UI frameworks on top of old ones without ever finishing or fully committing to any of them. Win32, WinForms, WPF, UWP, WinUI 2, WinUI 3, MAUI, Reunion — the graveyard of half-shipped frameworks is long, and each one was supposed to be The Answer.
For developers trying to build a native Windows app today, the decision tree is genuinely painful. WinUI 3, the current official recommendation, still has gaps that send you back to Win32 interop. MAUI promised cross-platform native UI but shipped with enough rough edges that many teams gave up and went back to Electron or web-based approaches. UWP is effectively abandoned but still the only path to certain Windows APIs. And WPF, released in 2006, remains the most complete option for many use cases — which tells you everything about the rate of progress.
The contrast with Apple's platform story is damning. SwiftUI has its problems, but Apple made a clear bet: here's the new thing, the old thing (UIKit/AppKit) still works, and we're steadily migrating APIs to the new thing. There's one IDE (Xcode), one language pushing forward (Swift), one UI framework getting investment (SwiftUI). Developers can disagree with Apple's choices, but at least there's a coherent direction to disagree with.
Microsoft's problem isn't technical capability — it's organizational. Different teams ship competing frameworks, none gets enough resources to reach parity with what came before, and the developer is left to assemble a working stack from the wreckage. The Windows App SDK was supposed to unify things, but it's been slow to absorb the full surface area developers need.
This matters beyond Windows enthusiasts. Every time native Windows dev gets harder, Electron wins another convert. Every abandoned framework trains developers to distrust the next one Microsoft announces. The 253-point Hacker News discussion suggests this frustration runs deep in the community.
The practical takeaway for teams choosing a Windows stack today: if you need native, WPF is boring but battle-tested. If you're starting fresh, the web stack inside a lightweight wrapper (Tauri, Electron) gives you a framework that won't be deprecated in three years. WinUI 3 is a bet on Microsoft following through — and the historical odds on that aren't great.
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