Microsoft.UI.Reactor Preview: Try Microsoft’s Experimental C# Framework for WinUI Apps

What Reactor is, and what it isn't​

Reactor draws no pixels of its own. Every control you render is a real WinUI control, such as Button, TextBox, NavigationView or TreeView, just authored differently. Layout panels, theme resources and inspection tools all stay the same. A few pieces are Reactor's own, such as a flex layout panel, but Microsoft says those are built on the same primitives a XAML app uses.

The change is in how you describe the UI. XAML apps typically use MVVM (Model-View-ViewModel). State sits on a view model, which announces changes, and bindings carry those changes into controls. Reactor uses MVU (Model-View-Update). State lives in one place, an update produces the next state, and the view is a plain function of that state. The Microsoft post is careful to call these two established patterns with different trade-offs. Neither is a successor to the other.

Mechanically, a component's Render() method returns the element tree that becomes the native control tree. State lives in UseState and similar hooks. Every setter call re-runs Render(), and the reconciler diffs the new tree against the previous one and patches the WinUI controls in place. The repository's agent guidance adds that the UI is described as immutable C# records, not WinUI controls.

The whole counter app, in one file​

Microsoft's headline demo is a complete counter app in a single .cs file. It uses .NET 10's file-based app directives:

• #:package [email][email protected][/email]
• #:property OutputType=WinExe
• #:property TargetFramework=net10.0-windows10.0.22621.0
• #:property UseWinUI=true

The component calls UseState(0). It renders a title bar, a "Count" heading and minus and plus buttons, with a Mica backdrop. ReactorApp.Run<MyApp> opens the window. Save the file as counter.cs and run winapp run counter.cs.

How to try it​

Prerequisites

• The .NET 10 SDK.
• The winapp CLI at v0.7 or later. Microsoft says that release is where running a .cs file directly arrived. Install it with winget install Microsoft.WinAppCli.

Option 1: single-file scratch app

1. Save the counter as counter.cs.
2. Run winapp run counter.cs.
3. Success looks like this. Microsoft says it builds the file, generates a package manifest from the #:property lines, and launches the app with real package identity, not a loose .exe.

Option 2: plain dotnet, unpackaged

• Microsoft gives dotnet run counter.cs -a x64 -p:WindowsAppSDKSelfContained=true. This runs the app unpackaged. Adding a #:package Microsoft.Windows.SDK.BuildTools.WinApp@* line gets you the packaged launch under dotnet run too.
• If you leave out the explicit platform, expect an architecture complaint from the WindowsAppSDKSelfContained setting. That is why the -a x64 flag is there.

Option 3: a real project

1. Run winapp new -t reactor -n MyApp.
2. Run cd MyApp.
3. Run winapp run.

This scaffolds a packaged app with a manifest, assets and publish profiles. It also installs the WinUI template pack if you don't already have it. There are four starting points: reactor (blank), reactor-mvu (Model-View-Update via UseReducer), reactor-navview (a NavigationView shell) and reactor-tabview (a TabView shell). winapp new --list shows the rest, including XAML templates. The project's docs also say the project templates ship in the Windows App SDK dotnet new pack, so dotnet new reactor works from a plain .NET SDK install. The repository README notes that the scaffolded app is a single-project MSIX and needs Developer Mode on.

Treat these as separate workflows. The single-file path, the dotnet flags and the project template package differently, so don't mix their flags.

Reactor versus XAML plus MVVM​

Microsoft compares the counter against what it calls a good 2026 XAML version, using x:Bind and the MVVM Toolkit's source generators. That version needs markup, code-behind, a view model, App.xaml and App.xaml.cs, and a project file. The Reactor counter is one class.

The claimed upsides:

• Compile-time everything. Renaming a property updates every usage, because every usage is C#. There are no runtime binding failures in the output window.
• State next to the UI. There is no view model class and no PropertyChanged plumbing.
• Analyzers. Microsoft says there are 60+ Reactor-specific Roslyn analyzers. They cover hooks, accessibility, theming, commanding and performance. Examples include a missing list key, a hook called inside an if, a hard-coded brush that breaks in dark mode, and an icon-only button a screen reader would announce as just "button".
• Built-ins. Flexbox layout via a C# port of Meta's Yoga engine, commanding, navigation, theming tokens, localization, a DataGrid and docking.

Here is the caveat. This compares code structure in a 12-line example. It is not a benchmark, and it doesn't show that Reactor is faster or simpler across a large app. Microsoft itself asks the obvious question of whether the syntax still reads well at 400 lines. The analyzer count and coverage are Microsoft's claims, not independent measurements. The agent-friendliness argument is also a design rationale, not a measured result.

Interop and the XAML question​

Microsoft insists XAML isn't being deprecated and is still receiving active investment. It describes interop as running in both directions, in the same process and visual tree. Reactor content can be hosted in XAML apps and XAML content in Reactor apps. Any other WinUI control, third-party or your own, can be wrapped as a Reactor element. This is Microsoft's description, not a tested compatibility matrix. Interop is one of the questions the team explicitly asks developers to stress-test.

The post also says some Reactor building blocks are candidates to land in WinUI itself, where XAML apps could use them. That is a stated direction, not a commitment for any particular feature.

For production evidence, Microsoft says OpenClaw's Windows companion app uses Reactor for its chat, on by default. That app is open source. This is a single data point, and it doesn't change the experimental label.

Status, packaging and caveats​

• Experimental. The post says the label stays on for the next few months. The DSL syntax, controls and layering may all change. The repository labels the API pre-1.0.
• Current build. The repository's latest listed release is 0.1.0-preview.16, a prerelease dated September 22. The docs say that version is on NuGet.org.
• Package set. The release lists the core framework package, optional Advanced and Devtools packages, an agent skill bundle, and a Visual Studio 2022 extension. NuGet's listing for an earlier preview describes the Advanced package as Win2D canvas, charting, docking, markdown and data grid components.
• Visual Studio extension. Release notes call the embedded preview very rough in spirit: the project's own notes say to expect install friction, solution-load races and HWND/DPI edge cases. It requires Windows 11 23H2 or later and Windows App SDK 1.6 or later, and may be unsigned. That warning applies to the extension, not necessarily to every Reactor app.
• License. The code is MIT-licensed on GitHub.

There's also a Rust cousin​

Microsoft says the same experiment is running in Rust. The windows-reactor library in windows-rs is built around components and typed messages, and is available on crates.io. The controls underneath are the same native WinUI ones.

Should you care?​

If you already think in React, SwiftUI or Compose terms, Reactor is a cheap weekend experiment. It is one file and two commands. If your team ships XAML and MVVM happily, nothing here forces a move, and Microsoft says so.

The real test is not the counter. It is whether a large screen stays readable, whether the interop holds in an existing app, and whether the API stops shifting. Until the experimental label comes off, build prototypes, not product commitments. Microsoft says it will tour the real sample apps in the repo next month, which is the better test than a counter.