Windows native app development is a mess

Original Article ↗ Hacker News Discussion ↗

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.