MauiReactor: an MVU component model bolted onto .NET MAUI

A state object and a Render method replace the XAML page

The pitch of MauiReactor is that a screen becomes a class instead of a markup document. A page derives from Component<CounterPageState>, holds its mutable data in a plain state class, and returns a VisualNode tree from an overridden Render method. The README shows the whole thing in a dozen lines, which is the fastest way to see what the abstraction actually is:

class CounterPageState
{
    public int Counter { get; set; }
}

class CounterPage : Component<CounterPageState>
{
    public override VisualNode Render()
        => ContentPage("Counter Sample",
            VStack(
                Label($"Counter: {State.Counter}"),

                Button("Click To Increment", () =>
                    SetState(s => s.Counter++))
            )
            .Spacing(10)
            .Center()
        );
    
}

Nothing in that example mentions MAUI types such as ContentView or StackLayout directly, even though the resulting tree is MAUI underneath. The fluent helpers VStack, Label and Button build the visual tree, the extension calls .Spacing(10) and .Center() configure it, and SetState is the only mutation entry point on display. That single funnel is what makes the model useful: because all writes go through one method, the framework has a single place to decide that a re-render is needed. The sample does not document that decision, so the exact re-render timing is left to the reader.

The trade-off is that you lose XAML entirely. A team that has live XAML tooling, designers editing markup, or a large existing .resx and style asset pipeline is now maintaining a C# layout tree by hand.

Setup is four CLI steps: templates, hot reload tool, project, build

Installation is driven from the dotnet CLI rather than from a package reference you add by hand. The template pack gives you a project skeleton, and the hot reload console is installed as a separate global tool. The README flags one thing explicitly: the hot reload console package changed name between version 3 and version 4, so an existing install from the older line needs an update rather than a fresh install.

The template pack is a one line install:

dotnet new install Reactor.Maui.TemplatePack

The hot reload console is a separate global tool, and the README notes the rename from Reactor.Maui.HotReload to Reactor.Maui.HotReloadConsole between version 3 and version 4:

dotnet tool install -g Reactor.Maui.HotReloadConsole

If you already have the old tool installed, the update path is separate:

dotnet tool update -g Reactor.Maui.HotReloadConsole

Then you create the project and move into it:

dotnet new maui-reactor-startup -o my-new-project

cd .\my-new-project\

The Windows style path syntax is what the README prints, and the same idea applies on a Unix shell with forward slashes. Nothing here pulls a specific .NET MAUI workload, so the SDK and workload installation stays a prerequisite you own.

Building and reloading: the console runs in a second shell

The run loop has two halves that must be alive at the same time, and this is the part of the setup that trips people up. The application is built and launched with a target framework switch, and the hot reload console is started separately in another shell so it can attach to the running process and push edits.

On Android the build command names the framework explicitly, and the README states that an emulator or device must be running and configured first:

dotnet build -t:Run -f net10.0-android

On a Mac targeting an iOS device or simulator, the device identifier has to be passed through as a property, and the README points at a specific command to list candidates:

dotnet build -t:Run /p:_DeviceName=:v2:udid=<device_id> -f net10.0-ios

xcrun simctl list

The console itself takes a framework filter:

dotnet-maui-reactor -f [net10.0-android|net10.0-ios|...]

Note the target frameworks throughout: net10.0-android and net10.0-ios. The commands are written against a specific .NET version, so an older SDK on your machine will not accept them, and the -f filter on the console has to match the framework you actually built. Once both are running, edits to code are reloaded into the live application without a rebuild.

The samples directory shows the breadth the library is aiming at

The repository layout says more about the project's ambitions than the README does. The top level holds src/ and templates/ alongside a samples/ directory that contains Calculator, ChartApp, Contentics, IntegrationTest, MauiReactor.Calendar, MauiReactor.MapsDemo, MauiReactor.TestAot, MauiReactor.TestApp, MauiReactor.TestAppWindow, MauiReactor.WeatherTwentyOne, SlidingPuzzle and UnitTests.

Several of those names carry design intent. Contentics points at content-driven screens, ChartApp and MauiReactor.Calendar at charting, and IntegrationTest plus UnitTests at a testing story that a UI framework usually lacks. There is also a separate docs repository referenced from the README, and a maui-reactor-ai-prompt.md file at the top level, which suggests the project has been positioned for use by AI coding assistants as well as by people reading the documentation site.

External sample applications live in their own repositories: a main samples repository, a Rive app, and a KeeMind app. These matter for evaluating adoption because they show the library outside its own test harness. What the repository does not contain is a compatibility statement between those samples and the current release, so a reader has to work out which sample tracks which version.

Release tags lag behind the commits, and the hot reload rename shows the cost

The repository is not archived, and the last push was on 2026-08-28. The published tags tell a different story: v3.0.16 from 2025-01-27, v2.0.16 from 2024-01-18, and v1.0.104 from 2023-02-07. There is no tag for the version 4 hot reload console that the README tells you to install, so a new user following the setup steps today is pulling a tool whose major version does not correspond to any published release of the library itself.

That gap has a practical consequence. If your organisation pins package versions in a lock file or an internal feed, you cannot assume that the version 4 hot reload console behaves like the version 3 tool that shipped with the 3.0.x line. The README documents the rename and offers an update command, but it does not document a compatibility matrix between the two console majors and the library versions.

The licence is MIT, which is about as permissive as a project can get for a library that sits underneath an application. There is no copyleft obligation on code you write against MauiReactor, and the README gives no warranty or support commitment beyond the issue tracker and pull request route described in the contribution notes.

Where the framework is the wrong tool

MauiReactor is a poor choice for a codebase whose UI is maintained by designers through XAML. The value of the model comes from the tree being code, and code layout trees are not what a design tool edits. It is also the wrong choice for a team that wants a MAUI feature the library has not wrapped, because an unexposed MAUI control means dropping out of the abstraction for that part of the screen and mixing paradigms in one file.

There is a second wrong-tool case that has nothing to do with preferences: the hot reload workflow depends on the console and the app running side by side, which is a developer loop rather than a shipping configuration. The README does not describe a hot reload fallback for a device that is not attached to a Mac, so anyone planning to iterate on physical hardware away from a workstation will find the inner loop much slower than the documentation's happy path.

Finally, the release cadence makes it awkward to plan against. Commit activity continued into 2026, but the newest published tag is from January 2025. If your process requires a versioned, auditable upgrade path, you should find out how the maintainers intend to version the version 4 tooling line before committing a team to it.

Editorial conclusion

MauiReactor is worth a try for C# teams that already ship MAUI and want state driven UI with hot reload, and it is a poor fit for XAML shops or for anyone who needs a versioned release trail, because the newest published tag is v3.0.16 from 2025-01-27 while the last push was on 2026-08-28. Check the tool version mismatch between Reactor.Maui.HotReload and Reactor.Maui.HotReloadConsole before you start, and confirm that the net10.0-android and net10.0-ios targets in the build commands match the SDK on your machine.

Frequently asked questions

Official sources

1. adospace/reactorui-maui on GitHub
2. Issues
3. License: MIT
4. README
5. Releases