XAML in 2026: Time to Move On

XAML in 2026: Time to Move On

The Uncomfortable Truth

I have been working with XAML since the early days of WPF. It has been the standard way to build UIs in the Microsoft ecosystem for nearly two decades. But here we are in 2026, and I think it is time to have an honest conversation about whether XAML still makes sense for new .NET MAUI projects.

The short answer: probably not.

A Technology Frozen in Time

XAML has not meaningfully evolved since its inception. The core syntax and capabilities are essentially the same as they were when it was introduced. Meanwhile, the rest of the development world has moved forward with declarative UI patterns that feel modern and productive.

Look at what Apple did with SwiftUI or what Google did with Jetpack Compose. These frameworks took a fresh look at declarative UI and built something that feels native to their respective languages. They embraced modern programming patterns like reactive programming and functional composition. XAML, by comparison, feels like it belongs to a different era entirely. When was the last time you started a new project where XML was touted as the future of development?

Verbosity for the Sake of Verbosity

XAML is verbose. There is no way around it. Setting up a simple binding requires multiple lines of markup, and even basic layouts can quickly become walls of angle brackets. The argument has always been that this verbosity provides clarity, but in practice it just means more code to read, write, and maintain.

Compare the experience of writing a XAML page to writing the equivalent in C# Markup or a reactive framework. The difference in line count and cognitive overhead is significant. When you are trying to iterate quickly on a UI, that overhead adds up fast.

Tooling That Never Quite Works

This might be my biggest frustration with XAML. The tooling situation is a mess.

Try using Go-to-Definition on a binding path. It does not work. Want to refactor a property name and have it update your XAML files? Good luck. The basic IDE features that we take for granted in C# code simply do not exist for XAML in any reliable way.

What makes it worse is the inconsistency across development environments. Visual Studio on Windows has one set of capabilities, VS Code has its own limited support, and JetBrains Rider does things differently again. You cannot build muscle memory or workflows when every environment behaves differently.

The Mythical XAML Designer

There is this persistent idea in the enterprise world that somewhere out there exists a designer who will craft beautiful XAML interfaces without developer involvement. I have been building apps for a long time, and I have never actually met this person. In reality, developers write the XAML, and designers provide mockups in Figma or Sketch that developers then translate into markup.

The actual visual designer that ships with Visual Studio is somehow even more frustrating. It rarely works reliably, especially for MAUI projects. When it does render something, it often does not accurately represent how the UI will appear on actual devices. Different platforms have different behaviors, and the designer struggles to account for this. Most experienced developers I know have disabled it entirely and work directly with the markup.

Shout out to Uno and their Hot Designer, which actually works pretty well and is probably the most fun experience I have had with a designer since writing WinForms apps in Visual Studio 2005.

A Fragmented Ecosystem

If you are working in the XAML space, you quickly realize that there is no such thing as just XAML. There is WPF XAML, UWP XAML, WinUI XAML, .NET MAUI XAML, Avalonia XAML, and Uno XAML. They are all similar but frustratingly different.

Properties that exist in one flavor do not exist in another. Behaviors vary across platforms. Code that works in WPF might not compile in MAUI. This fragmentation makes it difficult to transfer knowledge between projects and creates constant friction when working across different parts of the Microsoft ecosystem.

The Better Path Forward

If XAML is not the answer, what is? For .NET MAUI specifically, I believe the best alternative right now is writing your UIs in pure C# using the C# Markup extensions from the Community Toolkit.

C# Markup

With C# Markup, you get all the benefits of the C# language: strong typing, proper refactoring support, Go-to-Definition that actually works, and the ability to use your existing debugging skills. The fluent API is expressive and produces code that is arguably more readable than equivalent XAML.

Beyond the .NET ecosystem, frameworks like MVU (Model-View-Update) and reactive patterns have proven that there are better ways to think about UI construction. These patterns treat UI as a function of state, which leads to more predictable and testable code. Frameworks outside of Microsoft, like those using SwiftUI patterns, have shown what modern declarative UI can look like.

A Glimpse of What Could Be

Interestingly, there is movement happening within the MAUI team that suggests they recognize these problems. A recent proposal for XAML C# Expressions would allow embedding C# code directly in XAML markup, eliminating the need for many converters and reducing boilerplate significantly.

XAML C# Expressions Proposal

This proposal takes inspiration from Razor Pages, which have proven incredibly successful in the ASP.NET world. Imagine being able to write boolean expressions directly in your bindings instead of creating yet another BooleanToVisibilityConverter. It is a step in the right direction, and the community response seems to be overwhelmingly positive.

The MAUI team has also been working on reducing XAML verbosity with implicit and global XML namespaces in .NET 10.

Implicit and Global XML Namespaces

This feature lets you eliminate most of those xmlns declarations at the top of every XAML file. You can register your own namespaces globally and skip all the prefix clutter. It genuinely makes XAML files cleaner and easier to read. But while this reduces verbosity, it does not address the fundamental modernity issues. The underlying language and its limitations remain the same.

Outside of Microsoft, Matt Lacey has been doing interesting work exploring what a XAML replacement might look like. His proposal, called Enamel (Experimental Native Application Markup Extension Language), takes a different approach. Rather than replacing XAML outright, it sits on top of it. You write your UI in a simpler language, and it generates the XAML for you. The generated XAML is still what your project uses, so there is no risk if you decide to stop using it.

Matt Lacey’s MAUI Day Talk on Enamel

I am not sure Enamel is the solution, but I appreciate that someone is at least thinking critically about what comes next. Matt has spent years working on XAML tooling and has written extensively about how the language could be improved. His work sparks important conversations about the changes needed and proposes some genuinely modern approaches that the community should be considering.

The fact that these proposals exist tells you something: even Microsoft knows that XAML needs to evolve. Whether these changes come fast enough to matter is another question.

The Hot Reload Factor

One argument I hear in favor of XAML is Hot Reload support. The ability to make changes and see them instantly without rebuilding is genuinely valuable for UI development. But here is the thing: Hot Reload is getting better for C# code too.

When Hot Reload for C# code-based UIs reaches full maturity, the productivity advantage of XAML largely disappears. You will be able to iterate just as quickly on C# Markup as you can on XAML, but with all the added benefits of working in a real programming language with proper tooling support.

Where Do We Go From Here

I am not suggesting you immediately rewrite all your existing XAML. Migration is expensive and often not worth the effort. But for new projects, I think you owe it to yourself to seriously consider the alternatives.

Start with C# Markup. Evaluate whether the reactive patterns used by frameworks like ReactiveUI make sense for your architecture. Look at how other platforms have solved these problems and consider whether those patterns could work for you.

XAML had its time. It brought declarative UI to the Microsoft world and that was genuinely important. But we have learned a lot about UI development since then, and it is okay to acknowledge that there are better approaches available today.

The future of .NET MAUI UI development is not more XAML. It is code-first, strongly-typed, and reactive. The sooner we embrace that, the better our applications will be.