Is MAUI another Silverlight? A retrospective on every Microsoft UI framework, and why developers are tired

The question shows up in every .NET forum at least once a quarter. Someone is starting a new project, or maintaining one, or interviewing for a role that uses Multi-platform App UI (MAUI), and they want to know whether they are about to make the same bet a previous generation made on Silverlight. The honest answer is no, not in the way Silverlight died. The Silverlight story was specific to its category. But the pattern that produced the question rhymes with the pattern that killed Silverlight, and that rhyme is the actual story.

Microsoft has shipped more developer-facing User Interface (UI) frameworks than any other vendor in the history of personal computing. Win32, the Microsoft Foundation Classes (MFC), Visual Basic 6 (VB6) forms, WinForms, Windows Presentation Foundation (WPF), Silverlight, Silverlight for Phone, Windows Runtime (WinRT, later Metro), Universal Windows Platform (UWP), WinUI 2, WinUI 3, Xamarin.Forms, MAUI, Blazor Hybrid. Some are still here. Most are not. Every one of them launched with a deck full of reasons why this was the future of Windows development. The reason a developer in 2026 asks "is MAUI another Silverlight" is not paranoia. It is pattern recognition.

This post is the long answer. The retrospective first, then the specifics of why MAUI is not the next Silverlight, then the three plausible futures for MAUI, then a working developer's read on what to actually pick in 2026.

The graveyard, chronologically

What follows is every UI framework Microsoft has put in front of working developers since the start of Windows. Not the failed prototypes or research projects. The ones that shipped with marketing, documentation, and a "this is the future" pitch.

The visual version of the graveyard first, so the prose has somewhere to anchor:

timeline
    title Microsoft UI frameworks, 1985 to 2026
    1985 : Windows 1.0 / Win16
    1991 : Visual Basic 1.0
    1992 : MFC 1.0
    1993 : Win32 (Windows NT 3.1)
    1998 : Visual Basic 6.0
    2002 : WinForms (.NET 1.0)
    2006 : WPF (.NET 3.0)
    2007 : Silverlight 1.0
    2008 : VB6 IDE end of life
    2010 : Windows Phone 7
         : Silverlight strategy shift
    2011 : Silverlight 5 (last major)
    2012 : WinRT / Metro (Windows 8)
    2014 : Xamarin.Forms
    2015 : UWP (Windows 10)
    2016 : Microsoft acquires Xamarin
    2018 : WinUI 2
         : WPF open-sourced
    2019 : Windows 10 Mobile end of life
    2021 : WinUI 3 / Windows App SDK 1.0
         : Silverlight end of life
         : Blazor Hybrid (.NET 6)
         : UWP deprecated
    2022 : .NET MAUI general availability
    2024 : Xamarin.Forms end of life

Win32 (Windows 1.0 in 1985, Win32 API proper with Windows NT 3.1 in 1993, still here). The bedrock. Every Microsoft UI framework since has either wrapped it, replaced it, or compiled down to it. WinForms is Win32 controls with .NET bindings on top. WPF talks to the display through DirectX but still lives inside a Win32 process and uses Win32 windowing. WinUI 3 is the modern-controls layer on top of the modern wrapper around Win32. Win32 has outlived every framework written to retire it, and there is no scenario in 2026 where it stops shipping. I have a separate piece on the case for using Win32 directly in 2026, so I will not re-argue it here.

MFC (1992). The C++ wrapper around Win32, shipped with Visual C++ 1.0. Still in Visual Studio 2026. The install base in industrial control software and Computer-Aided Design (CAD) tooling has never had a reason to migrate, and Microsoft has never had a reason to make them.

Visual Basic forms (Visual Basic 1.0 in May 1991, Visual Basic 6.0 in 1998, VB6 IDE end-of-life April 2008, runtime still ships in Windows 11). Alan Cooper's drawing of a form designer, turned into Visual Basic by Microsoft, turned into the most successful Line of Business (LOB) UI toolkit of the 1990s. I covered the form-designer continuity argument in the WinForms post, so I will only say here: the design metaphor Visual Basic invented in 1991 is the same metaphor the .NET 10 WinForms designer uses today. The IDE died. The runtime did not. The metaphor never did.

WinForms (.NET Framework 1.0 in February 2002, still here). The .NET port of the Visual Basic forms model. Microsoft has been "replacing" it for twenty-four years and it is still the path of least resistance for a working LOB application. The designer is current, the controls are current, and the apps written against it in 2003 still build and run on .NET 10 in 2026 with very little work. The framework that was supposed to retire it (WPF) is in maintenance; the framework after that (UWP) is dead; the framework after that (WinUI 3) is now an internal rendering layer more than a target. WinForms outlasted them all.

WPF (.NET Framework 3.0 in November 2006, open-sourced 2018). The "real" successor to WinForms. Extensible Application Markup Language (XAML), hardware-accelerated rendering, retained-mode display, the Model-View-ViewModel (MVVM) pattern as a first-class story, data binding that actually worked. WPF was technically excellent and culturally important. It taught a generation of Windows developers what declarative UI felt like, and almost every framework on this list since has carried some piece of XAML's DNA. It also got a lukewarm Microsoft reception after about 2010, went into a long quiet period, and was eventually open-sourced in 2018 as part of the .NET Core push. It still ships, still has users, was never the future Microsoft promised it would be. The community kept it alive after Microsoft visibly stopped caring, and that is the part of the WPF story that matters for this post.

Silverlight (1.0 in 2007, last major version 5.0 in December 2011, end-of-life October 12, 2021). Browser plugin for cross-platform .NET in the browser. The pitch was Flash but with .NET. For about three years, Silverlight looked like the future of business apps on the web. Microsoft pushed it hard at LOB developers. Bob Muglia's "our strategy has shifted" comment in October 2010 was the moment the category started dying in public, even though the framework itself was supported for another decade. Silverlight died because its category died: browser plugins as a delivery vector were over. Flash, Java applets, and Silverlight all went down together, and the platform decision was made above Microsoft's pay grade. Not strictly Microsoft's fault. Still felt like a betrayal because Microsoft had spent years telling LOB developers it was where to invest.

Silverlight for Phone, then Windows Phone (Windows Phone 7 in October 2010, Windows Phone 8.1 end-of-life July 2017, Windows 10 Mobile end-of-life December 10, 2019). The phone version of Silverlight, then the XAML stack for Windows Phone 8, then a parallel app model in Windows 10 Mobile. A generation of mobile developers wrote shipped, paid, in-store production code for a platform that no longer boots. The Windows Phone story is its own essay, but it belongs in this graveyard because the developer-impact pattern is the same: a Microsoft strategic bet, sold as a future, walked away from inside a release cycle.

WinRT, then Metro, Modern UI, Windows Store apps (Windows 8, October 2012). The touch-first UI rebrand for Windows 8. The XAML dialect that eventually became UWP. The most reviled rebrand in Microsoft's UI history, and the only one where the developer community, the enterprise customers, and the consumer reviewers all hated the same thing for the same reason. The lesson Microsoft took was "do not call it Metro again." The lesson the lesson should have been was something else.

UWP (Windows 10 in July 2015, deprecated October 2021). Universal Windows Platform. Pitched as the future of Windows. A single sandboxed app model that would run on phones, tablets, desktops, Xbox, and HoloLens. Required apps go through the Microsoft Store. Failed because no working developer wanted the sandbox, no enterprise wanted the Store deployment story, and the platform never matched the surface area of Win32. UWP shipped just after Windows Phone died, and the cross-device promise died with the phone. By 2018 Microsoft was quietly walking it back. In October 2021 it was officially deprecated in favour of the Windows App SDK.

Xamarin.Forms (May 2014, Microsoft acquired Xamarin February 24, 2016, end-of-life May 1, 2024). Cross-platform mobile UI from a third party (Xamarin) that Microsoft bought. The most successful cross-platform .NET UI ever shipped. By 2020 Xamarin.Forms had a stable Developer Experience (DX), a mature ecosystem, and a working iOS and Android story. Microsoft killed it in favour of MAUI. The migration was painful, the timing was contested, and the community has not entirely forgiven it.

WinUI 2 (October 2018). UWP controls back-ported and shipped as a NuGet package. A bridge release for developers who wanted the modern Fluent controls without being trapped fully inside the UWP sandbox. Mostly a stepping stone to WinUI 3.

WinUI 3, shipped in Windows App SDK 1.0 (November 2021). The UI half of Project Reunion, renamed the Windows App SDK before launch. The "we are sorry about UWP" framework. Modern XAML controls running in a normal Win32 process, no sandbox required, no Store deployment required. WinUI 3 still ships, but in 2026 it is mostly the rendering layer underneath MAUI on Windows rather than a developer-facing target most teams reach for directly. It exists, it is supported, and the number of greenfield WinUI 3 apps being written is not large.

.NET MAUI (general availability May 23, 2022). Multi-platform App UI. The successor to Xamarin.Forms. Originally planned to ship with .NET 6 in November 2021, slipped six months, finally hit general availability at Build 2022. Launched buggy, stabilised slowly, finally usable around the 9.0 and 10.0 releases. iOS DX still lags Xamarin.Forms at its peak. Currently shipping, currently officially supported, currently the answer Microsoft gives to "I am a .NET shop and I need iOS and Android from a shared codebase." If you are reading this post because you have to make a decision about MAUI, the rest of this post is for you.

Blazor Hybrid, Blazor Desktop, Blazor MAUI (.NET 6 in November 2021). Web UI in a webview, hosted in a native container. Shipped via the BlazorWebView component in .NET 6, available inside MAUI, WPF, and WinForms hosts. Initially a curiosity, has grown into a serious option. Internal Microsoft enthusiasm for Blazor is visibly higher than enthusiasm for MAUI, and the cross-platform story is much simpler when the UI is HTML and the rendering surface is the same webview on every platform. Blazor Hybrid is the most likely contender to eclipse MAUI in the next three years.

That is the graveyard. Fifteen frameworks if you count generously, ten if you only count the ones that got a real marketing push. The remarkable thing is not that some of them died. The remarkable thing is the rate. Microsoft has shipped a new strategic UI direction about every three years for the last twenty, and the working developer is the one who pays the migration cost every time.

The pattern

Why this keeps happening. Three forces overlap, and they explain almost every framework on the list.

The first force is strategy footballs. Each new regime in the Windows org re-pitches the UI story to justify its own existence. The Sinofsky era killed WPF's momentum to ship Metro. The Nadella era killed UWP's momentum to ship Project Reunion. Each regime arrives with a deck. The deck is always sincere. The deck is always partial. The previous regime's commitments are footnotes in the new one's slides, and the developers who built against the previous deck are the ones discovering, post-Build, that they are now legacy.

The second force is platform shifts the framework cannot survive. Browser plugins died as a delivery vector, and Silverlight went with them. Touch-first computing reset the desktop, and WPF's momentum did not survive the reset. Mobile became the centre of computing for most people, and everything in the .NET ecosystem that was not Xamarin had to reinvent itself or be replaced. The framework is downstream of the platform's relevance. When the platform shifts, the framework's options narrow, and Microsoft tends to pick rewrite over rescue.

The third force is the unkillable middle. WinForms and Win32 outlasted every successor because they solved a problem the successors made harder. The successors aimed at a new platform (web, phone, touch, sandbox), and the customer's problem was almost always still the old one (data entry, configuration, reporting, internal tooling on a Windows desktop). The successors wanted the developer to come to them. The unkillable middle stayed where the developer already was.

Put those three together and the pattern is clear. Microsoft generates strategic UI frameworks faster than the platforms underneath them stabilise. Win32 survived because there is always a Windows desktop. WinForms survived because there is always a line-of-business form to draw. Silverlight died because there are no more browser plugins, and UWP died because there was never a sandboxed-Windows-Store world that customers actually wanted to live in. Category first, framework second, every time.

The Silverlight specifics, and why MAUI is not in the same situation

Silverlight died because its category died. Browser plugins as a delivery model were over by 2012, and there was no path forward for any plugin-based UI technology, no matter how good. It was not a Silverlight code problem. It was not even, in the strict sense, Microsoft's decision. Silverlight is the framework on this list whose death is least Microsoft's fault.

The question "is MAUI another Silverlight" usually maps onto the wrong dimension of risk. The category Silverlight occupied went extinct. The category MAUI occupies (cross-platform mobile and desktop from a shared codebase) is permanent. As long as Microsoft wants .NET to be on phones and tablets at all, something has to occupy the MAUI shape. There is no plausible 2030 in which a .NET shop targeting iOS and Android is told "actually, please use the C# bindings to React Native that we are about to ship," and there is no plausible 2030 in which Microsoft abandons cross-platform .NET UI entirely. The category lives.

So MAUI does not die the way Silverlight died. If MAUI dies, it dies by being eclipsed.

Three plausible futures for MAUI

There are three reasonable scenarios for where MAUI is in three years, and I will rank them by what I would actually bet on.

The first scenario, and the most likely one, is that MAUI keeps muddling along. Microsoft has now invested five years in it, has a maintenance team, has a small but real ecosystem of paid customers, and it would be embarrassing to kill the framework again after the Xamarin.Forms migration was as painful as it was. The path of least resistance is incremental improvement, no marketing push, and a quiet "MAUI is fine, keep using it" line at Build for the next several years. This is what I expect.

The second scenario, possible but less likely, is that MAUI gets quietly de-emphasised in favour of Blazor Hybrid. Internal enthusiasm at Microsoft for Blazor is visibly higher than for MAUI, and "just use Blazor in a webview" solves cross-platform UI without the native-control overhead. This lines up with Microsoft's web-first instincts and with the broader industry trend toward rendering everything in Chromium. MAUI does not get killed in this scenario. It gets to be the legacy option while Blazor Hybrid becomes the recommended one. Existing MAUI apps stay maintainable. New apps drift to Blazor.

The third scenario is the one developers are afraid of. MAUI gets killed and replaced by a sixth cross-platform framework. I rate this least likely, because the community would not forgive it after the Xamarin.Forms transition, and the political cost inside Microsoft would be high. But it cannot be ruled out, because Microsoft has done exactly this on a roughly three-year cadence for twenty years, and the org chart that produces the decision has not changed.

Build 2026 is on June 2-3 this year. Watch the keynote for the relative airtime MAUI gets versus Blazor. The signal will be in the framing, not the wording. If MAUI gets the "still here, still supported, doing fine" treatment and Blazor gets the "and here is what we are excited about" treatment, scenario two is the bet. If MAUI gets a real headline announcement, scenario one is the bet.

Why Avalonia is winning mindshare

Avalonia's quietest superpower is that it is not Microsoft's strategic football. Community-led, predictable cadence, no rebrand history, no acquired-then-killed story, no "previous regime did this differently" overhang. Devolutions became Avalonia's lead sponsor in July 2025 with a three-million-dollar commitment over three years, which gave the project a paid maintenance team without putting it inside a vendor's strategy cycle.

When a developer who has been burned by Silverlight, Windows Phone, UWP, and Xamarin.Forms looks for cross-platform .NET UI in 2026, "Microsoft might do this again" is a real and rational risk. Avalonia removes that risk entirely. The framework is not subject to a Build keynote re-pitch. There is no internal Microsoft team that can decide tomorrow that Avalonia's category is now Blazor Hybrid's category. The roadmap is public, the maintainers are reachable, and the project's survival is not contingent on a Microsoft strategic decision.

That is the entire value proposition. Avalonia is technically capable, well-documented, and shipping; it is also outside the strategy-football game. The two facts are independent and additive. The first one makes it a serious option. The second one makes it the safest serious option.

I will cite my own work as an honest example. GlyphDeck.UI, the touchscreen kiosk shell I am building for an ARM Linux Single-Board Computer (SBC), is on Avalonia. MAUI does not target Linux, so it was disqualified for platform reasons. WPF does not target Linux either, so it was also disqualified for platform reasons. The choice was forced by the platform. But the second reason it felt comfortable was that Avalonia is not going to be repositioned at Build 2027. The platform decision and the strategic-risk decision were independent, and Avalonia was the answer to both.

What a working developer should actually do in 2026

The retrospective is the long way around to a fairly short set of recommendations. None of these are universal. All of them are conditional on the working developer's actual situation.

If you have MAUI code in production, keep maintaining it. Do not panic. Watch Build 2026. The most likely outcome is that MAUI keeps shipping and you keep maintaining. The second most likely outcome is that Blazor Hybrid gets the marketing push and MAUI gets the maintenance treatment. Both of those leave your code working for years.

WinForms shops in production can stop worrying. You are fine forever. The .NET 10 designer is the same designer your VB6-graduate hires already know how to use. The framework solves the problem your customers have, and that problem has been stable for thirty years. There is no successor in 2026 that meaningfully improves your situation, and there will not be one in 2030 either.

Greenfield cross-platform work is where the strategic-risk argument matters most. Look at Avalonia and Uno before you look at MAUI. Not because MAUI is dying, but because the cost of Microsoft pivoting is borne by you, not by Microsoft, and the alternatives have removed that risk by not being Microsoft. The Avalonia and Uno teams have a fundamentally different incentive structure, and it shows up in their roadmaps.

For greenfield Windows-only desktop work, the choice is WinForms or WPF, depending on whether you want the forms-and-events model or the MVVM-and-XAML model. WinUI 3 is acceptable if you are sure you will never need to ship outside the modern Windows world, and if you are comfortable being on a framework whose strategic position inside Microsoft is "the renderer underneath the cross-platform framework" rather than "the recommended desktop target."

Greenfield web UI is a different conversation entirely. React versus Blazor versus HTMX, not which Microsoft framework. That is a different post.

The honest meta-takeaway is the one the brief for this article opened with. Microsoft's UI strategy has been volatile for so long, across so many framework generations, that "is this another Silverlight" is now the default question every working developer asks every time Microsoft ships UI. The question is reasonable. The fact that it is reasonable is the story.

MAUI is probably not the next Silverlight. MAUI's category lives, the framework is improving, and Microsoft has too much invested to walk away inside the next two years. But the rational developer in 2026 has already noticed that the question keeps having to be asked, and has already adjusted the strategic-risk multiplier on Microsoft frameworks accordingly. That adjustment is the tax. The alternatives have made the tax visible. Avalonia and Uno are not winning mindshare because they are technically dominant. They are winning because they are not subject to the tax.