Windows native app development is a mess

Original Article ↗ Hacker News Discussion ↗

Windows desktop development is portrayed as fragmented and exhausting, with decades of overlapping UI frameworks (Win32, MFC, WinForms, WPF, UWP, WinUI, MAUI and more) that Microsoft rarely consolidates or clearly deprecates. Commenters contrast Windows’ remarkable backward compatibility with the difficulty of choosing a modern, well-supported toolkit, the push toward web-based stacks like Electron, and the appeal of third‑party options such as Qt, Avalonia, Lazarus, or even game engines for UI. Many see this incoherence—plus code signing and deployment hurdles—as a key reason native Windows apps are stagnating while resource‑heavy web technologies proliferate.

Ecosystem fragmentation and churn

  • Commenters broadly agree Windows native UI is fragmented: Win32, MFC, ATL/WTL, WinForms, WPF, WinRT/UWP, WinUI 2/3, MAUI, WinJS, etc.
  • Microsoft keeps adding frameworks without clearly sunsetting old ones or providing a single obvious “current” choice.
  • Some see this as driven by internal politics/“impact” metrics rather than a coherent platform vision.

Win32 and older stacks: stability vs modernity

  • Many praise raw Win32, MFC, WinForms, and WPF as stable, well-understood, and astonishingly backward compatible (e.g., VC6-era apps compiling in VS 2022 and running on Win11).
  • Win32-based apps can be tiny, single-EXE, and run from Windows 95 through 11 (often under Wine too).
  • Downsides noted: dated visuals, limited HiDPI and dark-mode support, and lots of boilerplate / low-level ceremony.

Newer Microsoft stacks: UWP, WinUI, WinAppSDK

  • UWP/Metro is widely regarded as a failure: originally extremely restricted (no multi-monitor, admin, sideloading, etc.), then slowly relaxed, now effectively in maintenance.
  • WinUI 3 and Windows App SDK are seen as immature and risky for third‑party developers; some advise avoiding them unless forced to by Microsoft employment or legacy WinRT/UWP code.
  • Confusion persists over which stack maps to which “modern” Windows 10/11 visuals.

Web tech, Electron, and React Native

  • Many lament Microsoft itself using Electron or React Native for core apps (Teams, Outlook, parts of Settings, Start menu), seeing it as an admission native is too painful internally.
  • Critics argue Electron apps are bloated, slow, memory‑heavy, and hard to make feel properly native.
  • A minority defend web stacks (Electron, Tauri, React Native) as pragmatic and standards-based, especially given Windows’ native mess.

Alternative toolkits and cross‑platform angles

  • Strong interest in non‑Microsoft toolkits: Qt (often called “best in class”), wxWidgets, Lazarus/Delphi, JUCE, ImGui, FLTK, Avalonia, Uno, Fyne, Tk/Tcl, even game engines (Godot, Unity) for non-game UIs.
  • Debate over what “native” means: system widgets only vs. “non‑webview, compiled, well‑integrated”.

Deployment, .NET, and code signing

  • Friction around deployment: .NET Core/“modern .NET” not bundled with Windows; versions not fully backwards compatible; choice between bundling runtimes (larger EXEs) or forcing installs.
  • Some want Windows to ship multiple .NET versions side‑by‑side; others warn about bloat and compatibility guarantees.
  • Code signing on Windows (certs, hardware keys, Smart App Control) is described as a major barrier for indie devs; Azure Artifact Signing helps but is region/business‑limited.

Languages and safety

  • Disagreement over “crime to use C++”: some say safe modern C++ is fine for simple tools; others find going back from memory‑safe languages to C/C++ painful and error‑prone.
  • Rust + Win32 bindings are mentioned as a promising way to combine native APIs with memory safety.