Domenic Denicola's latest post lays out what most Windows developers already feel in their bones: building native apps on Windows in 2026 is an exercise in archaeology, politics, and guesswork.
The core problem isn't that there's no good framework — it's that there are too many, none of them complete, and Microsoft can't stop launching new ones before finishing the last. The graveyard is impressive: Win32, WPF, WinForms, UWP, WinUI 2, WinUI 3, MAUI, and whatever Reunion was supposed to become. Each was pitched as the future. Each was semi-abandoned for the next shiny thing.
WinUI 3, the current "recommended" path, still has gaps that would embarrass a beta release. Basic controls behave inconsistently. The designer story is nonexistent compared to what WPF had a decade ago. MAUI, which was supposed to unify cross-platform native development, shipped with enough rough edges that many teams quietly went back to Xamarin — or gave up on native entirely and shipped Electron.
The deeper issue is organizational. Windows dev tooling decisions appear driven by reorg cycles rather than developer needs. Each new leadership shuffle produces a new framework initiative, a new branding exercise, and a new set of conference talks promising this time it'll be different. Meanwhile, the WPF apps that actually run the enterprise world keep chugging along on a framework Microsoft clearly wishes would go away but can't kill because nothing has replaced it.
For practitioners, the calculus is bleak:
- If you need Windows-only native: WPF remains the most complete option, despite being "legacy." WinUI 3 is viable for greenfield if you can absorb the rough edges. - If you need cross-platform: Electron or Tauri. MAUI's cross-platform story hasn't delivered on its promise. - If you're starting fresh: Seriously evaluate whether you need native at all. PWAs and web-based approaches cover more ground than they did five years ago.
The HN discussion (370+ points) reflects genuine frustration from developers who've watched this cycle repeat for 15 years. The top comments consistently land on the same theme: Microsoft's problem isn't technical capability — it's institutional follow-through.
This matters beyond Windows enthusiasts. When the dominant desktop OS can't offer a coherent native development story, it pushes the entire ecosystem toward web technologies. That's not inherently bad, but it's a choice being made by default rather than by design.
The post is worth reading in full for anyone making platform decisions in 2026. The honest answer to "what should I use for Windows native dev?" remains "it depends, and none of the options are great" — which is exactly the problem.
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