Windows native app development in 2026 resembles a graveyard of abandoned frameworks. Microsoft’s “recommended” WinUI 3 forces developers to drop down to 1990s Win32 APIs for features that WPF had built-in 20 years ago. Global keyboard shortcuts require Win32 RegisterHotKey(). Display monitoring needs ChangeDisplaySettings(). Tray icons demand Shell_NotifyIcon(). Even window auto-sizing to content—trivial in WPF—requires Win32 interop. Add in hostile deployment (Windows 11 ships .NET Framework 4.8.1 but not modern .NET 10), expensive code signing ($129-300/year), and Microsoft Store rejections for vague “unique lasting value” criteria, and the question isn’t “why do developers choose Electron?” It’s “why would anyone still choose Windows native development?”
This isn’t temporary transition pain. It’s a strategic failure where Microsoft has broken developer trust across six framework generations since 2000. Each promised modernity, each delivered gaps. Consequently, developers abandon native frameworks for Electron and web technologies, while third-party frameworks like Avalonia and Uno Platform flourish by delivering the stability Microsoft won’t.
“Modern” Frameworks Require Legacy APIs
WinUI 3—Microsoft’s recommended framework for new Windows apps—lacks APIs that force developers to use Win32 P/Invoke interop for functionality WPF provided two decades ago. A simple utility app needs P/Invoke for global hotkeys, display monitoring, non-activating windows, and tray icons. The promise of modern frameworks is abstracting platform complexity. When half your code is Win32 interop, that promise has failed.
Domenic Denicola documented this paradox after building a utility that required extensive Win32 calls: “What is the point of using Microsoft’s latest and greatest, if half your code is” legacy interop? Microsoft’s CsWin32 project—a source generator for P/Invoke bindings—can’t even correctly wrap strings inside structs. It remains perpetually pre-1.0, with fundamental limitations tracing back to C# language gaps.
// Global keyboard shortcut - should be built-in, requires Win32
[DllImport("user32.dll")]
static extern bool RegisterHotKey(IntPtr hWnd, int id, uint fsModifiers, uint vk);
// Display change monitoring - no WinUI API
[DllImport("user32.dll")]
static extern int ChangeDisplaySettings(ref DEVMODE devMode, int flags);
// Tray icon - inconsistent across frameworks
[DllImport("shell32.dll")]
static extern bool Shell_NotifyIcon(int dwMessage, ref NOTIFYICONDATA pnid);The moment you realize “modern” means “more complex than legacy,” the Electron exodus makes perfect sense.
Twenty Years of Broken Promises
Windows development has cycled through six major frameworks since 2000: Win32 → MFC → Windows Forms → WPF → UWP → WinUI 3. Each promised to be “the future.” None successfully replaced predecessors due to missing features and broken migration paths. WPF launched in 2006. Twenty years later, observable property boilerplate remains virtually unchanged in WinUI 3. Meanwhile, UWP sits in “maintenance mode” receiving only security fixes.
Microsoft’s own documentation (updated February 2026) lists WinUI 3 as “recommended” while documenting critical gaps: no UI designer years into development, missing WPF controls (DockPanel, AdornerDecorator), and performance regressions versus UWP. Despite upgrading from DirectX 9 to DirectX 12, WinUI 3 has slower launch speeds, higher RAM usage, and larger installation sizes than UWP. The graphics improvements don’t offset the performance penalties.
Framework churn without feature parity erodes trust. Enterprises with 15-year WPF codebases see WinUI 3 migration as high risk with zero reward. Independent developers hit missing features that block completion. The pattern is clear: Microsoft launches frameworks with incomplete APIs, positions them as “the future,” then repeats the cycle before delivering on promises. This isn’t evolution. It’s abandonment disguised as innovation.
Windows 11 Ships Legacy Runtime, Rejects Modern Apps
Windows 11 preinstalls .NET Framework 4.8.1—a legacy runtime from .NET’s 2002 era—but NOT modern .NET 10. The first app needing modern .NET triggers a dialog prompting runtime download, despite the OS launching in 2021 when .NET 5 was already current. For distribution, developers face a three-way trap: pay $129-300/year for code signing, accept undiscoverability via PowerShell sideloading, or risk Microsoft Store rejection.
Code signing certificates from traditional Certificate Authorities cost $129-300 annually, with new 2026 requirements capping validity at one year (February) and 460 days (March). Microsoft’s January 2026 Azure Artifact Signing service offers a cheaper alternative at $9.99/month (5,000 signatures) or $99.99/month (100,000 signatures). Unsigned MSIX packages require cryptic PowerShell commands—Add-AppxPackage -Register .\AppxManifest.xml—that users will never discover.
The Microsoft Store adds another barrier. Domenic’s utility app was rejected for “lacking unique lasting value”—a tool that monitors displays and manages hotkeys, functionality Windows itself provides poorly. The rejection criteria are subjective with no clear remediation guidance. Deployment friction kills adoption. When your “modern” app triggers runtime downloads, requires annual signing fees, or faces Store rejection, Electron’s self-contained model becomes rational despite 120-150MB overhead.
When “Bloated” Becomes “Rational”
Electron powers VS Code, Slack, Discord, Figma, and Notion. Each bundles an entire Chromium browser and Node.js runtime—120-150MB minimum. Multiple Electron apps multiply memory exponentially. Yet developers increasingly choose Electron not despite these costs but because Windows native development has become more hostile than bundling a browser.
Hacker News discussion (161 points, 152 comments) reveals divided sentiment. Some defend Microsoft’s tooling as misunderstood, citing LTSC Visual Studio Build Tools as lightweight alternatives. Others validate the critique: “Modern VS versions are awful and bloated compared to VC++ 6.0.” The trend is clear: new projects increasingly choose alternatives (Electron, Tauri, Avalonia) over Microsoft’s frameworks. Tauri—a Rust-based alternative—captures new projects from Electron with smaller footprints and native webviews.
Electron isn’t winning because it’s better technology. It’s winning because Microsoft made native development deliberately painful. When framework instability, missing features, and deployment complexity exceed Electron’s overhead, the calculus shifts. Microsoft created their own competition by failing to deliver stable, feature-complete frameworks. The punchline: VS Code—Microsoft’s flagship developer tool—is built on Electron, not WinUI 3.
Third-Party Frameworks Flourish Where Microsoft Fails
Avalonia and Uno Platform thrive by delivering what Microsoft won’t: stable, feature-complete frameworks with clear migration paths. Avalonia provides near-identical WPF API with cross-platform support (Windows, macOS, Linux, mobile, WebAssembly). Avalonia XPF runs existing WPF apps on non-Windows platforms with minimal changes. Uno Platform uses WinUI/UWP XAML dialect across platforms. Both outpace Microsoft’s frameworks in developer trust.
Uno Platform’s 2026 article “5 Best Frameworks for WPF Modernization” doesn’t even list WinUI 3 as a top choice—instead recommending Avalonia, Uno, .NET MAUI, and Blazor Hybrid. Community consensus: Avalonia is simpler to start with than Microsoft’s frameworks for most WPF developers. Third-party frameworks wouldn’t flourish if Microsoft delivered on promises. Developers are voting with their projects: choose frameworks maintained by people who remember what made WPF successful, or bet on Microsoft’s next framework abandonment.
Microsoft’s “Solution”: Organizing Chaos
Microsoft’s January 2026 response to developer complaints is winapp CLI, a command-line tool to “unify configuration across Windows frameworks and toolchains.” The goal: simplify development by consolidating configuration tasks. The problem: configuration complexity is a symptom, not the root cause.
Framework fragmentation, missing features, and broken migration paths remain unaddressed. Organizing chaos produces organized chaos. Until Microsoft commits to feature parity and migration paths, a CLI tool won’t fix strategic failures spanning 20 years. The problem isn’t configuring frameworks—it’s trusting frameworks that will be abandoned in favor of the next “modern” iteration.
Key Takeaways
- WinUI 3 forces Win32 P/Invoke interop for features WPF provided 20 years ago—global hotkeys, display monitoring, tray icons—defeating the entire purpose of modern frameworks
- Six framework iterations since 2000 (Win32 → MFC → WinForms → WPF → UWP → WinUI 3) have created a graveyard of broken migration paths and missing features, with observable property boilerplate unchanged across 20 years
- Windows 11 preinstalls legacy .NET Framework 4.8.1 but not modern .NET 10, while code signing costs $129-300/year and Microsoft Store rejections for “unique lasting value” create deliberate barriers to distribution
- Electron’s 120-150MB overhead becomes rational when Windows native development requires Win32 interop, runtime downloads, signing fees, and Store approval—Microsoft created their own competition by making native hostile
- Third-party frameworks (Avalonia, Uno Platform) flourish by delivering WPF-level stability and feature completeness Microsoft won’t commit to, with community-maintained alternatives outperforming official frameworks in developer trust
