Windows Native Dev Is a Mess, and Microsoft Keeps Making It Worse

Domenic Denicola — a name you might recognize from TC39 and web standards work — published a detailed teardown of the current state of Windows native app development, and it's not pretty. The post resonated immediately, pulling 246 points on Hacker News.

The core thesis: if you want to build a native Windows desktop app in 2026, Microsoft offers you a bewildering array of overlapping, half-supported frameworks — and none of them are good enough. Win32, WinForms, WPF, UWP, WinUI 2, WinUI 3, MAUI, the Windows App SDK — each one arrived with promises, each one carries baggage or gaps that make it hard to recommend without caveats.

This isn't a new complaint, but what makes Denicola's piece land is the specificity. He's not hand-waving about developer experience in the abstract. He's cataloging real friction: APIs that exist in UWP but not WinUI 3, packaging models that don't compose, documentation that assumes you already know which of Microsoft's seven UI stacks you're targeting. The situation is worse than fragmentation — it's fragmentation where each fragment is incomplete.

The contrast with Apple is hard to ignore. SwiftUI has its own rough edges, but Apple ships one framework, iterates on it annually, and deprecates the old stuff on a clear timeline. Microsoft, by comparison, seems unable to either commit to a single path forward or properly maintain the paths they've already laid.

WinUI 3 was supposed to be the answer — the modern, decoupled-from-OS-releases framework that would unify everything. In practice, it launched missing features that WinUI 2 (tied to UWP) already had, and adoption has been sluggish. MAUI, the cross-platform play, has its own reliability problems and doesn't cover the full Windows API surface. Developers who need deep OS integration are often pushed back to Win32 and C++, which works but isn't exactly a pitch that attracts new talent to the platform.

For the working developer, the practical takeaway is bleak: there is no obvious right choice for a new Windows desktop project. If you need broad API access, you're looking at Win32 or WPF. If you want the 'modern' stack, you accept gaps and instability. If you want cross-platform, you probably reach for Electron or Tauri before MAUI.

Microsoft has the resources to fix this. The question is whether Windows client development is still a priority in a company increasingly oriented around cloud, AI, and services. The silence from the developer tools org — relative to the noise coming out of Azure and Copilot — suggests the answer.

This is a story about institutional focus. Microsoft isn't failing at native dev because the problems are hard. They're failing because they keep starting new frameworks instead of finishing the ones they have.