Thirty Years of Framework Churn: Tracing Microsoft's Windows UI Problem

Jeffrey Snover, the architect of PowerShell, published a post making a pointed claim: Microsoft has not had a coherent GUI strategy since the Charles Petzold era. The Hacker News thread that followed drew 276 comments and 453 points, which tells you something about how much pent-up frustration exists around this topic. Steven Sinofsky, who ran the Windows division through the Windows 8 pivot and left Microsoft shortly after it shipped, weighed in on the discussion as well.

The Snover framing is provocative but accurate in a specific way. The Win32 era was coherent not because Win32 is a good API, it is famously verbose and unpleasant, but because it was stable, authoritative, and fully documented by one book. Petzold’s Programming Windows went through five editions between 1988 and 1998 and was effectively the complete reference for Windows GUI development. You could write a Windows app, put it on a shelf for fifteen years, come back, and it would still compile and run. That durability was not accidental; it was the result of Microsoft’s famous obsession with backward compatibility in the Win32 layer. If you understand CreateWindow, WndProc, WM_PAINT, and HWND handles, that knowledge is still valid today, more than thirty years later.

Every framework since has followed a different pattern: announce, push hard, abandon or supersede within a decade, repeat.

The Anatomy of the Pattern

MFC shipped with Visual C++ 1.0 in 1992 as a C++ wrapper over Win32. It never fully abstracted the underlying API; heavy MFC apps still required Win32 knowledge to build correctly, which made it the worst of both worlds. Visual Basic, launched in 1991, took the opposite approach and hid Win32 almost entirely behind a drag-and-drop form designer. VB6, released in 1998, was enormously popular for line-of-business apps. Then VB.NET arrived in 2002 as a near-complete language break from VB6, alienating an enormous developer community. This is the first clean instance of the pattern: Microsoft declared a new thing the future before the ecosystem was ready to migrate.

WinForms shipped with .NET Framework 1.0 in February 2002, providing a thin managed wrapper over Win32 controls. It works; it is still maintained in .NET 9. WPF followed in November 2006 with .NET 3.0, and it was a genuine leap forward: DirectX-based hardware-accelerated rendering, resolution independence, XAML markup, data binding, and a vector-based layout model. WPF is the most capable native Windows desktop UI framework Microsoft has ever shipped. Its DependencyProperty system is overly complex but solves real problems around binding and animation. If Microsoft had stayed the course on WPF for a decade, the story might be different.

Instead, Silverlight appeared in 2007 as a browser plugin competing with Flash. It borrowed WPF’s XAML but ran in a sandboxed browser environment. Microsoft briefly pushed it as the future of rich internet applications and even as a Windows Phone development platform. By 2011 it was clear that HTML5 had won the browser and iOS had killed the plugin model. Silverlight’s end-of-support came in October 2021, but it was effectively abandoned by 2012. The WPF team lost significant talent to Silverlight; those developers then scattered again when Silverlight was wound down.

Windows 8, which launched in October 2012, introduced WinRT and the Metro app model. This is the inflection point that the Snover article and the Sinofsky context both circle around. WinRT was COM-based, language-projected to C++, C#, and JavaScript, with full-screen sandboxed apps distributed through the Windows Store. The XAML dialect looked like WPF XAML but was not compatible with it in any meaningful way. Microsoft’s message to developers was clear: Win32 and WPF are legacy, Metro is the future. Sinofsky left Microsoft in November 2012, weeks after Windows 8 shipped, and the Windows 8 backlash has been documented extensively. Windows 8.1 in 2013 quietly walked back the full-screen-only model by admitting that windowed apps mattered.

UWP followed in 2015 with Windows 10, promising that a single codebase would run on desktop, Xbox, HoloLens, Windows Phone, and Surface Hub. The promise was real; the execution was not. UWP’s sandboxing model (AppContainer) made it genuinely difficult to do things that desktop apps needed to do: write to arbitrary file paths, call Win32 APIs, integrate with system utilities. Windows Phone was discontinued in 2019. Microsoft’s own flagship applications, Visual Studio and Office, never moved to UWP. The framework Microsoft was telling developers to adopt was not the framework Microsoft was using internally.

WinUI 2 arrived in 2018 as a NuGet package that decoupled Fluent Design controls from the OS release cycle; it was an add-on for UWP, not a new framework. WinUI 3, the current recommended approach for new native Windows apps, is the UI layer of the Windows App SDK, which launched in stable form in November 2021. It runs on Windows 10 1809 and later, supports both packaged (MSIX) and unpackaged deployment, and represents another evolution of the XAML dialect. Migration from WPF or UWP to WinUI 3 is non-trivial. The frameworks share a surface-level XAML resemblance but differ in enough specifics that significant rewriting is involved.

.NET MAUI entered general availability in May 2022 as the successor to Xamarin.Forms. On Windows it renders through WinUI 3, adding an abstraction layer on top of the already-new WinUI 3. MAUI’s early releases had quality problems that were widely documented. The .NET 8 and 9 versions represent genuine improvements, but the framework still carries the perception damage from a rocky launch. When Microsoft laid off portions of the MAUI team in mid-2023, the community noticed immediately.

What Apple and Google Did Differently

SwiftUI launched at WWDC in June 2019 and shipped with macOS Catalina and iOS 13. It is a declarative, reactive UI framework built on Swift, and it represents a complete paradigm shift from AppKit and UIKit. The critical difference is what Apple did not do: it never deprecated AppKit or UIKit. SwiftUI is explicitly additive. NSHostingView embeds SwiftUI views inside AppKit hierarchies; NSViewRepresentable goes the other direction. Apple’s message has been consistent: SwiftUI is where new development should go, but you can migrate at your own pace, your existing code remains supported indefinitely, and interop between old and new is a first-class concern.

Jetpack Compose reached stable 1.0 on Android in July 2021 with a nearly identical philosophy. The Android Views system was not deprecated. AndroidView embeds legacy Views inside Compose; ComposeView does the reverse. Google’s recommendation was “Compose for new code, Views for existing code.” Compose Multiplatform, developed by JetBrains, has since extended this to Desktop and iOS. The migration story is gradual, explicit, and backed by maintained interop.

Microsoft’s pattern has been the opposite: declare the new thing the only path, push developers toward it before it matures, and allow the predecessor to enter a kind of half-life state where it still technically works but receives no meaningful investment. Developers who rewrote VB6 applications to VB.NET, then WinForms applications to WPF, then were told to adopt UWP, and are now being asked to consider WinUI 3 or MAUI, have every rational reason to be skeptical of the current recommendations.

The Coherence Question

The word coherent in Snover’s title is doing specific work. A coherent strategy does not mean a single framework that never changes; it means a framework with a clear upgrade path, maintained interop with predecessors, an authoritative documentation story, and credibility signals from the vendor’s own products. Win32 had all of these. WPF had most of them until the Silverlight diversion and then the Windows 8 pivot removed any sense that Microsoft was committed to it.

WinUI 3 and the Windows App SDK may represent a genuine break from the pattern, or may not. The framework is actively developed and Microsoft has been more forthcoming about its roadmap than in previous cycles. But Visual Studio still runs on WPF. Office still runs on Win32. Until Microsoft migrates its own highest-profile Windows applications to the framework it recommends for everyone else, the credibility gap remains open. That is not a technical argument; it is an organizational one. Petzold’s era was coherent partly because there was only one answer and partly because Microsoft used that answer everywhere. Neither condition has been true since.