# Microsoft.UI.Reactor: a declarative C# way to build WinUI 3 apps

> Microsoft.UI.Reactor is an experimental C# framework that describes WinUI 3 desktop apps through a virtual element tree, hooks-style state and a typed DSL instead of XAML markup. It suits teams that want React or Compose style composition without leaving the WinUI runtime, and it is still a preview package.

**microsoft/microsoft-ui-reactor** — Reactor is an experimental set of extensions to WinUI

- Repository: https://github.com/microsoft/microsoft-ui-reactor
- Stars: 749 · Forks: 57
- Language: C#
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-microsoft-ui-reactor

## Reactor is not a new platform, it is a new way to write WinUI

Microsoft.UI.Reactor is described as a declarative, component-based C# framework for building WinUI 3 desktop apps, and the README is unusually clear about the negative case. Reactor is not a new UI platform. It is a new way to describe WinUI content. Every control it renders is a real WinUI control such as Button, TextBox, NavigationView or TreeView, only authored differently, and apps built with it interop with XAML, MVVM, existing controls and the rest of the WinUI ecosystem.

That framing is the whole pitch, and it is aimed at a specific audience. Developers arriving from React, SwiftUI or Jetpack Compose expect co-located state, declarative composition and type-safe UI construction, and WinUI's XAML plus MVVM model does not offer those. Reactor adds them on the same runtime, with the same controls, in the same process.

The status line in the README reads Experimental, dated April 2026, and the repository is not archived, with the last push on 2026-10-20. The release tags are previews in the 0.1.0 line, with preview.14, preview.15 and preview.16 landing on 2026-09-01, 2026-09-11 and 2026-09-22 respectively.

What the framework adds on top of WinUI is four things according to the README: a virtual element tree with a reconciler that diffs old against new descriptions and patches only what changed on real WinUI controls, hooks-based state such as UseState, UseEffect and UseReducer co-located with render logic, a C# DSL that replaces XAML markup with typed factory methods and fluent modifiers, and higher-level building blocks including flex layout, charting, commanding, navigation, data grid, theming and localization.

## The reconciler patches real controls, which is why it can be incremental

The mechanism that makes Reactor more than a wrapper is the virtual element tree. The README describes a reconciler that diffs old versus new descriptions and patches only what changed on real WinUI controls. So the output of a component is not a description that gets thrown away, it is a tree that is compared against the previous render, and the difference is applied to the underlying WinUI object graph.

This matters because it is the only way a declarative model can sit on top of a platform that was not designed for one. A native WinUI app has real controls with real state, and a naive declarative layer would either rebuild the tree on every render or require a binding layer to mirror state. Patching means the platform keeps its own object model and the framework acts as the thing that decides what to update.

The DSL is the other half of that mechanism. Where XAML is markup parsed by a tool, Reactor uses typed factory methods with fluent modifiers, and the README's selling point is that this yields full IntelliSense, refactoring and compile-time type safety with no App.xaml, no MainWindow.xaml, no code-behind and no ViewModels.

The higher-level building blocks sit on top of the same tree. Flex layout, charting, commanding, navigation, data grid, theming and localization are described in the README as candidates to migrate back into WinUI itself, which is a candid admission that some of this belongs in the platform rather than the framework. The repository layout supports that reading, with sample projects for charting, navigation, commanding, styling, a todo app, interop and a transition comparison between the Reactor and XAML approaches.

## Hooks and a Component base class in C#

The smallest complete example in the README shows the shape of an application. You derive from Component, override Render, and return an element built from factory methods:

```csharp
using Microsoft.UI.Reactor;
using Microsoft.UI.Reactor.Core;
using static Microsoft.UI.Reactor.Factories;

ReactorApp.Run<MyApp>("Hello Reactor");

class MyApp : Component
{
    public override Element Render()
    {
        var (count, setCount) = UseState(0);

        return VStack(
            Heading($"Count: {count}"),
            HStack(8,
                Button("-", () => setCount(count - 1)),
                Button("+", () => setCount(count + 1))
            )
        );
    }
}
```

The state mechanism is a tuple returned from a hook. UseState(0) gives back the current value and a setter, and the setter is captured in the click handlers of the two buttons. The render function is a pure description of what should be on screen, and the reconciler works out the minimum change needed to make the real controls match.

The rest of the hook family in the README is UseState, UseEffect and UseReducer, with the state hooks co-located with the render logic rather than separated into a ViewModel. That is the design target stated in the README: a functional MVU model with no XAML and no ViewModels, on the same runtime and with the same controls.

Composition is visible in the example as well. VStack and HStack are layout elements, Heading renders text, Button takes a label and a callback, and the spacing argument to HStack shows the fluent modifier style. The static import of Microsoft.UI.Reactor.Factories is what keeps the call sites short.

## Scaffolding a first app with the Windows App SDK CLI

The quick start path deliberately avoids a source checkout. The public preview package Microsoft.UI.Reactor is on NuGet.org, and the project templates ship in the official Windows App SDK dotnet new pack, so the README shows the whole flow as three commands:

```powershell
winget install Microsoft.WinAppCli
winapp new -t reactor -n MyApp
cd MyApp
dotnet run
```

The comment in the README explains why the CLI is used: winapp new installs the template pack on demand, so there is no separate install step and no version to pin. The templates are reactor, plus richer shells named reactor-mvu, reactor-navview and reactor-tabview, and winapp new --list prints them all.

What you get is a scaffolded app that is packaged as a single-project MSIX, so dotnet run launches it with full package identity, which the README describes as the F5 equivalent. Developer Mode has to be enabled in the Windows settings under System and then For developers.

There is a plain .NET path for people who would rather not install the CLI. The README gives dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates::<version> followed by dotnet new reactor -n MyApp, and explains the catch: the pack is prerelease-only today, and dotnet new install resolves stable versions unless you pin one explicitly, which is exactly the step that winapp new removes.

Contributors take a different route, cloning the repository and running the bootstrap script before scaffolding:

## Reactor and XAML sharing one visual tree

The README spends a section on what it does not replace, and the argument is worth taking seriously. XAML and MVVM are described as a powerful native platform model with tooling, designer support, templating, data binding, years of guidance, samples and third-party controls built around it, and Reactor does not try to replace any of that. If you ship XAML and MVVM today, the recommendation in the README is to keep doing so, on the grounds that the investment going into Reactor, meaning improved accessibility APIs, richer theming, better commanding and a stronger data stack, is designed to flow back into WinUI where it helps XAML and MVVM users as well.

The practical consequence is that the two models can be mixed. You can host Reactor content inside a XAML app, or drop XAML content inside a Reactor app, and they share the visual tree. That is the difference between a framework that wants to replace your architecture and one that wants to sit next to it.

The sample projects in the repository show how concrete that is. There is an InteropFirst sample, a WinFormsInterop sample that puts a Windows Forms host inside the mix, and a TransitionComparison project with both a Reactor and a XAML variant side by side, which is exactly the kind of thing you would build to argue that the two approaches produce comparable visual results. CommandingDemo, NavigationDemo, StylingGallery, ReactorGallery, ReactorCharting.Gallery and TodoApp cover the feature areas the README lists as building blocks.

The direction of travel stated in the README is that WinUI is the foundation, with the experiments in the repository landing in WinUI directly where they can, and others continuing to ship through Reactor.

## The two build traps: long paths and the missing platform flag

Two build issues are documented with enough detail to save you an afternoon, and both are the kind of thing that looks like an unrelated failure.

The first is path length. The Windows App SDK XAML and resource compilers are 32-bit tools with no long-path support, so a deep or OneDrive-synced checkout can push generated obj and bin output past the Windows 260-character MAX_PATH limit and break the build with MSB3073 or PRI210 errors. The README says this happens most often on ARM64 development boxes, where those tools run under emulation. The instruction is to clone into a short root directory such as C:\src, and the issue is referenced as number 678.

The second is the platform flag. The README is unambiguous: always build with an explicit platform, dotnet build -p:Platform=x64 or ARM64, and omitting -p:Platform causes WindowsAppSDKSelfContained errors. This applies to dotnet build, to dotnet run and to mur check invocations alike.

The contributor path in the README follows from this. You clone the repository, then call the bootstrap script under the PowerShell version you are on:

```powershell
git clone https://github.com/microsoft/microsoft-ui-reactor.git
cd microsoft-ui-reactor

& (Get-Process -Id $PID).Path -ExecutionPolicy Bypass -File .\bootstrap.ps1

dotnet new reactor -n MyApp
cd MyApp
dotnet run -p:Platform=x64
```

The bootstrap script is doing more than installing a template. According to the README it packs mur as a dotnet tool global install, packs local framework snapshots into local-nupkgs, installs the Windows App SDK dotnet new template pack through the Windows App SDK CLI, and installs the Reactor agent plugin under the user profile. Scaffolded apps reference the public Microsoft.UI.Reactor package from NuGet by default, and you pass --reactor-version 0.0.0-local when you deliberately want a scaffolded app to consume the local source-built package instead.

## Preview packages, the support surface and what the licence gives you

The packaging story is a set of three NuGet packages. The framework package is Microsoft.UI.Reactor, and the README mentions optional sibling packages Microsoft.UI.Reactor.Advanced and Microsoft.UI.Reactor.Devtools that are version-matched to the framework package when published. The template pack can be held at a known-good version with the bootstrap script parameter for the Windows App SDK templates version.

The repository is a full engineering project rather than a sample. Alongside src/, tests/, samples/, docs/ and tools/ there are build/, plugins/, skills/ and assets/ directories, a solution file in the new slnx format, Directory.Build.props and Directory.Packages.props for centralised build settings, a global.json for SDK pinning, a nuget.config, mkdocs.yml for the documentation site, and cgmanifest.json for component governance. There are also agent and skill instruction files, AGENTS.md and SKILL.md, and a TESTING.md, plus coverage settings in coverage.settings.xml, a CHANGELOG.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md and SUPPORT.md. ThirdPartyNoticeText.txt records the third-party notices.

The licence is MIT, with the LICENSE file at the root of the repository. This article does not interpret the licence, but for a Microsoft-published preview framework the relevant practical point is that you can read the source, keep a modified copy, and redistribute it under the terms, and that the preview status means you should expect the API surface to change between preview tags.

The final thing to weigh is the platform commitment stated in the README. WinUI is the foundation, and Reactor is the experimental layer above it, which means the sensible long-term posture is to treat the framework as a place where ideas can be tried quickly, and to expect a good number of them to end up in the platform itself.

## Conclusion

Adopt Microsoft.UI.Reactor if your team already ships on WinUI 3 and wants component composition and co-located state without giving up the platform, and you are prepared to track a preview package. Do not adopt it as a reason to abandon XAML and MVVM, since the project states that the two models coexist and that WinUI remains the foundation. Verify first that the template pack you install matches your Windows App SDK version, that you clone to a short path such as C:\src to stay clear of the MAX_PATH limit in the XAML compilers, and that you always pass an explicit -p:Platform value, because the last push was on 2026-10-20 and the newest tag is 0.1.0-preview.16 from 2026-09-22 under the MIT licence.

## FAQ

### What is Microsoft.UI.Reactor and is it a replacement for XAML?

It is an experimental declarative, component-based C# framework for WinUI 3 desktop apps, and the README states it is not a new UI platform but a new way to describe WinUI content with real WinUI controls. XAML and MVVM are not being replaced, and Reactor content can be hosted inside a XAML app and the other way round.

### How do I create a new Reactor app?

The README shows winget install Microsoft.WinAppCli, winapp new -t reactor -n MyApp, cd MyApp and dotnet run, since winapp new installs the template pack on demand. Templates also include reactor-mvu, reactor-navview and reactor-tabview, and Developer Mode has to be enabled.

### Which hooks does Reactor provide for state?

The README lists hooks-based state co-located with render logic, naming UseState, UseEffect and UseReducer, and the example shows UseState returning a value and a setter that is captured by button callbacks. A component derives from Component and overrides Render to return an element.

### What are the known build problems with Reactor?

The README warns that the 32-bit XAML and resource compilers have no long-path support, so a deep checkout can hit the 260-character MAX_PATH limit and fail with MSB3073 or PRI210, so it recommends a short path such as C:\src. It also requires an explicit -p:Platform=x64 or ARM64, since omitting it causes WindowsAppSDKSelfContained errors.

## Sources

- [Issues](https://github.com/microsoft/microsoft-ui-reactor/issues)
- [License: MIT](https://github.com/microsoft/microsoft-ui-reactor/blob/main/LICENSE)
- [microsoft/microsoft-ui-reactor on GitHub](https://github.com/microsoft/microsoft-ui-reactor)
- [README](https://github.com/microsoft/microsoft-ui-reactor/blob/main/README.md)
- [Releases](https://github.com/microsoft/microsoft-ui-reactor/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-microsoft-ui-reactor