MewUI: a C# GUI framework that leaves the platform choices to you

The application picks the host and the backend

The most surprising thing about MewUI is what it refuses to do. The README states plainly that an app registers a platform host and a rendering backend before Application.Run, and that MewUI does not pick them for you. The example shows what that looks like in practice, with the Windows host and the Direct2D backend registered explicitly while Linux and macOS register their own:

    // Windows here; Linux and macOS register their own host and backend.
    Win32Platform.Register();
    Direct2DBackend.Register();

    var window = new Window()
        .Title("Hello MewUI")
        .Resizable(520, 360)
        .Padding(12)
        .Content(
            new StackPanel()
                .Spacing(8)
                .Children(
                    new Label()
                        .Text("Hello, Aprillz.MewUI")
                        .FontSize(18)
                        .Bold(),
                    new Button()
                        .Content("Exit")
                        .OnClick(Application.Shutdown)
                )
        );

    Application.Run(window);

That choice is the design. Instead of a framework that ships one rendering path for every platform, MewUI ships a thin core and platform-specific hosts and backends, and the developer makes the decision in code where it is visible and testable. The framework is described as cross-platform and lightweight, aimed at NativeAOT and trimming, and it is published as NuGet packages with a website at mewui.aprillz.net. The topic list names the platforms the project cares about: Windows, Linux, macOS, Avalonia, WPF and WinForms, which is a good hint that interoperability with the existing .NET desktop world is a goal even though the framework itself is separate from all of them.

Fluent markup, and the binding style that comes with it

There is no XAML. The UI tree is built in C# with a fluent API, as the window example shows, with a chain of calls on each element and a Children method taking the child widgets. The stated highlights are NativeAOT and trimming first, lightweight by design with a small executable, a low memory footprint and a fast first frame, and fluent C# markup for building UI trees. Binding is described as AOT-friendly explicit binding, including nested paths, and reflection-based path binding is listed as a non-goal. That is the crux of the framework's opinion. A reflection-based binding system is convenient and it is also one of the things that makes trimming and ahead-of-time compilation difficult, so MewUI trades that convenience for a binding model the compiler can see. The result is a UI code base that is a program rather than a document, which means the usual XAML tooling, live preview and designer workflows do not apply, and the project is explicit that designer-first development is a non-goal.

NativeAOT and trimming are constraints, not features

Everything in the concept section is framed around one requirement, and the README is unusually direct about the implications. The library aims to be trimming-safe by default through explicit code paths and no reflection-based binding. Windows interop uses source-generated P/Invoke through LibraryImport for NativeAOT compatibility. On Linux, building with NativeAOT requires the AOT workload in addition to the regular .NET SDK, and the README is cut off mid-sentence on the exact package name for that. The payoff is a small executable with no separate .NET runtime installation on the target machine, and that is the reason a developer would accept a young framework with an unstable API. It also explains the design of the core: a small, explicit core with optional extensions, because anything heavy in the core is something every consumer pays for in binary size. The repository layout supports that split, with a src directory, a separate extensions directory, and a samples directory that contains one sample project per feature area.

Installing from NuGet or running a single file

The NuGet route is a metapackage. Aprillz.MewUI bundles Core, all platform hosts and all rendering backends, and platform-specific packages are also available as Aprillz.MewUI.Windows, .Linux and .MacOS, with the install command given as dotnet add package Aprillz.MewUI and the Installation and Packages document linked for detail. The second route is a file-based app, and the minimal header for one looks like this:

    #:sdk Microsoft.NET.Sdk
    #:property OutputType=Exe
    #:property TargetFramework=net10.0

    #:package [email protected]

    // ...

The file-based app form needs the .NET 10 SDK and is described as VS Code friendly, and the run command is dotnet run your_app.cs. The README also points to a working sample at samples/FBASample/fba_calculator.cs. That last detail is worth pausing on, because the file-based app header pins a specific package version at 0.21.1 while the current release tags are v0.22.1 and v0.22.0, so the sample is not tracking the newest tag. The examples directory also contains a browser gallery running on WebAssembly, and the MewUI.Gallery.Browser sample directory backs the claim that the framework can target a browser as well as a desktop.

One command to run the gallery, and the warning attached to it

The fastest way to see the framework is a pipeline that fetches a sample and runs it, with no clone and no project setup, and it works on Windows, Linux and macOS given a .NET 10 SDK:

curl -sL https://raw.githubusercontent.com/aprillz/MewUI/refs/heads/main/samples/FBASample/fba_gallery.cs -o - | dotnet run -

The README puts a warning directly under it, and the warning deserves to be read rather than skimmed: the command downloads and executes code directly from GitHub. It is a convenient way to see a framework you have never used, and it is also a pattern that will get you in trouble if you copy it into a script that runs unattended, because the content of that URL can change without notice. The browser gallery is the safer way to take a first look, since it needs nothing installed at all, and the light and dark screenshots in the README give a reasonable idea of the visual result before you run anything.

The non-goals are the most useful part of the README

A short list under the concept section tells you what MewUI is not, and it reads like a design brief. Full XAML and WPF compatibility is out. A drop-in replacement for WPF or Avalonia with identical APIs and behaviour is out. Designer-first development workflows are out, as is reflection-based path binding, and so is an exhaustive, all-in-one control catalog. In their place, the core covers common desktop UI patterns, and specialised features such as charts and docking ship as extension packages. That last sentence is the honest summary of the architecture: the core is deliberately incomplete, and the missing pieces are separate packages you opt into. The sample directories show how wide the surface is in practice, with separate projects for charts, docking, markdown, SVG, video, geometry, a task manager, a skia sample, a WinForms host for Win32, a WebView2 sample, a windowless sample and a writeable bitmap sample.

An API that is still moving, on a fast release line

The project status section is the one to read before committing. MewUI is described as actively developed with published NuGet packages, cross-platform hosts, multiple rendering backends and optional extension packages, but the public API surface is still being stabilized, so breaking changes can happen between minor releases, and the README advises pinning package versions and reviewing release notes before upgrading for production apps. The release history supports that reading: v0.22.1 on 2026-09-30, v0.22.0 on 2026-09-28 and v0.21.1 on 2026-09-07, three releases in under a month, and the last push to the repository was on 2026-10-20. The licence is MIT, with a THIRD_PARTY_NOTICES.md file at the root recording third-party terms. One more thing the README is upfront about, and that a reader should weigh, is how the code was produced: the project states it was developed using an AI prompt-driven workflow, with design and implementation performed through iterative prompting without direct manual code edits, and each step reviewed and refined by the developer. That is a statement about provenance, and it is a fact a team adopting a young framework may want to raise internally.

Editorial conclusion

MewUI suits a .NET developer who wants to ship a small, self-contained desktop binary without a runtime installer, and who is comfortable choosing a platform host and a rendering backend in code rather than having a framework decide. It is the wrong tool for an application that depends on WPF behaviour, XAML tooling or a designer-first workflow, since the project lists all of those as non-goals, and it is the wrong tool for a team that cannot absorb API churn, because the README states the public API surface is still being stabilized and breaking changes can happen between minor releases. Verify first which version of the packages you will pin and read the release notes before upgrading, and note that the samples directories show the framework covers far more than the core, with separate packages for charts, docking, charts, markdown, SVG, video and WinForms hosting.

Frequently asked questions

Official sources

1. aprillz/MewUI on GitHub
2. License: MIT
3. Project website
4. README
5. Releases