Windows native app development is a mess

A long-time Windows developer set out to create a simple utility and discovered the native app ecosystem is an absolute quagmire. The article details a convoluted history of UI frameworks, tricky deployment, and constant reliance on legacy Win32 APIs, leading to a strong argument for web-based solutions like Electron or Tauri. This deep dive into Microsoft's perceived neglect of its own platform struck a chord with Hacker News, sparking a vigorous debate on native vs. web apps and the enduring legacy of older frameworks.

100

Score

Comments

Highest Rank

on Front Page

First Seen

Mar 22, 1:00 PM

Last Seen

Mar 22, 7:00 PM

Rank Over Time

The Lowdown

Domenic Denicola, a self-proclaimed 'Windows guy' with a history stretching back to Visual C++ 6, embarked on a seemingly simple hobby project: a utility to black out secondary monitors during gaming. What began as a nostalgic endeavor quickly devolved into a frustrating exploration of the fragmented and underdeveloped state of native Windows application development.

The author needed basic functionalities like enumerating displays, placing borderless windows, global hotkeys, startup options, persistent settings, and a tray icon, finding even these simple tasks unexpectedly complex.
He chronicles Microsoft's bewildering journey through UI frameworks, from Win32 C APIs to WinUI 3, highlighting how each new iteration often introduces new gaps and limitations, forcing developers to revert to older APIs.
Deployment options are a 'painful choice': C++ is memory-unsafe, framework-dependent C# requires a modern .NET runtime not pre-installed (Windows 11 ships with .NET 4.8.1 while current is .NET 10), and .NET AOT results in unexpectedly large binaries.
Many required features, such as watching for display changes or creating non-activating windows, still necessitate "P/Invoke" to ancient Win32 C APIs, undermining the supposed benefits of modern frameworks like WinUI 3.
Fundamental C# issues, like the lack of an idiomatic way to handle optional, out parameters from Win32 or the persistent boilerplate for data binding (unchanged in 20 years), further compound the frustration.
Denicola concludes that native Windows app development is not a priority for Microsoft, pointing to stagnant issue trackers, a focus on ML APIs in the Windows App SDK, and the widespread use of web technologies in first-party Microsoft applications.

The author expresses little hope for a turnaround, suggesting that given the current "mess," developers are better off choosing web stacks like Electron or Tauri, which ironically benefit from a more consistently updated underlying webview than native .NET.

The Gossip

Legacy vs. Latest Layering

Many commenters echoed the sentiment that older Windows development methods, particularly Win32 and MFC, were surprisingly stable and backward-compatible. Some lauded the 'it just kept working' nature of decades-old apps, often preferring the directness of Win32 to the 'mess' of newer frameworks. However, others pointed out that these legacy approaches have their own challenges, such as handling high-DPI displays, 32-bit to 64-bit migrations, or the complexities of '12 different ways to define a string'. The debate often circled back to whether Microsoft's constant introduction of new frameworks without retiring old ones or ensuring full feature parity has led to an unmanageable developer experience.

Microsoft's Missed .NET Moment

A significant portion of the discussion revolved around Microsoft's perplexing strategy regarding .NET. Commenters questioned why the latest .NET runtime isn't distributed via Windows Update, making 'framework-dependent deployment' impractical. While some argued against tying .NET updates to OS updates due to potential breakage or size, the author and others highlighted the inconsistency with how evergreen components like WebView2 are handled. This reflects a broader concern that Microsoft's internal choices create unnecessary hurdles for developers trying to use its 'modern' development stack.

Electron's Embrace & Native App Erosion

The article's conclusion that Electron/Tauri are viable alternatives for Windows apps fueled a heated discussion. Many agreed that the native development landscape pushes developers towards web technologies, even pointing out that Microsoft itself uses Electron for prominent apps like Teams. However, this was often framed as a regrettable necessity, with users lamenting the performance, memory usage, and 'bloat' of Electron apps. Some even expressed disdain for 'web technologies' in desktop development, preferring the efficiency and 'native feel' that has become increasingly elusive.

Alternative UI Arsenal

Amidst the critiques of Microsoft's official frameworks, many developers offered and debated a wide array of alternative GUI toolkits. Suggestions ranged from established cross-platform options like Qt and wxWidgets, to rejuvenated classics like Delphi and Lazarus, and even game engines like Unity and Godot being repurposed for non-game applications. This variety underscored the author's point about the lack of a clear, universally accepted 'best path' for Windows GUI development, with each alternative presenting its own set of trade-offs regarding language, licensing, runtime size, and ease of deployment.