Flutter's UI framework, written in C#
Plumix brings Flutter's Widget → Element → RenderObject architecture to .NET. Build desktop and mobile apps in C#, and port Flutter widgets with minimal conceptual translation.
dotnet add package Plumix --prerelease
If you know Flutter, you already know Plumix.
Compose UIs from immutable widgets. The framework manages an element tree and a render tree under the hood — exactly the way Flutter does. Same lifecycle, same layout protocol, same paint phase. Just C#.
- Immutable widgets, mutable elements, render objects do the work
- BuildContext, State<T>, InheritedWidget — they all behave as expected
- Layout protocol: parent passes constraints, child returns a size
- Hot reload preserves State while you edit — dotnet watch, no restart
public sealed class MyApp : StatelessWidget
{
public override Widget Build(BuildContext context)
{
return new Container(
color: Colors.White,
padding: EdgeInsets.All(24),
child: new Column(
children:
[
new Text("Hello, Plumix"),
new SizedBox(height: 12),
new Text("Render tree is driven by Flutter-like widgets.")
]
)
);
}
}Built for parity
Four principles that keep Plumix faithful to Flutter — and predictable for C# developers.
Widget · Element · RenderObject
The same three-tree architecture as Flutter — not a thin wrapper around an existing UI toolkit.
Port Dart to C# directly
Translate Flutter widgets line-by-line. Familiar names, familiar lifecycle, familiar layout protocol.
Avalonia as infrastructure
Avalonia handles the window, input, and drawing surface. All layout and paint logic lives in Plumix.
Parity by default
When behavior diverges from Flutter, it is explicitly documented — never silently skipped.
Why Plumix exists
Plumix is not "Flutter inspired." It is a deliberate translation of Flutter's architecture into the .NET runtime.
Flutter-faithful architecture
Widget, Element, RenderObject — the same mental model as Flutter, not a thin wrapper around another toolkit.
Dart → C# without friction
Porting a Flutter control should feel like translation, not rewriting. APIs and lifecycle mirror Flutter intentionally.
Avalonia as infrastructure, not UI
Avalonia provides the host, platform lifecycle, and rendering surface. All layout and paint behavior is framework-owned.
Parity by default
When behavior diverges from Flutter, it is explicitly documented in the changelog and reference — not silently skipped.
Packages for every layer
Install only what you need. Material, Cupertino and the hosts sit on top of Plumix core.
Plumix
Core framework — widgets, elements, render objects, layout & paint pipeline.
Plumix.Material
Every widget in Flutter's Material library, Material 2 and 3 theming, the 8,825-icon Icons catalog and localizations for 119 locales.
Plumix.Cupertino
Flutter's Cupertino library — CupertinoApp, navigation and tab bars, pickers, text fields, sheets, context menus and iOS-style routes.
Plumix.Android
Android host — PlumixMainActivity runs your widget tree as a native Android app, system back button included.
Also on NuGet: Plumix.FSharp (F# widget DSL) · Plumix.Elmish (Elmish (MVU) host) · Plumix.Provider (port of provider) · Plumix.Bloc (port of bloc) · Plumix.Slang (port of slang i18n)
Current status
The public roadmap from core parity to a v1.0 release candidate.
- M1Core Parity Hardening Shipped
- M2Input / Focus / Accessibility Shipped
- M3Port-first Widget Set Expansion Shipped
- M4Material Library Rewrite Shipped
- M5Cross-host Sample Parity & Stability In progress
- M6Cupertino Library Port In progress
- RCv1.0 Release Candidate — API freeze Planned
Common questions
How is Plumix different from Avalonia?
Plumix is not a wrapper over Avalonia's control set. Avalonia supplies the window, platform lifecycle, input plumbing and drawing surface; every layout, paint and hit-test decision above that surface is made by Plumix's own render tree. You write Flutter-style widgets, not XAML.
Do I need to know Flutter to use Plumix?
No. Plumix is a normal C# UI framework you can learn on its own. But if you already know Flutter, the API surface, lifecycle and layout protocol are deliberately the same, so most of your existing knowledge transfers directly.
Can I port an existing Flutter widget to C#?
That is the primary design goal. Widget, Element and RenderObject exist with the same responsibilities and mostly the same names, so porting a Dart widget is closer to translation than to a rewrite. Where behaviour intentionally diverges from Flutter, it is documented in the changelog.
Which platforms does Plumix support?
Windows, macOS and Linux through the Avalonia desktop host, which is the most mature. Android (the Plumix.Android package), iOS and the browser (WebAssembly) hosts run the same widget tree; cross-host stability is the current milestone. The framework targets .NET 10.
Is Plumix production ready?
Not yet. Plumix is in beta (v0.4). The framework core, rendering, gestures, navigation, scrolling and the Material library are strict ports of Flutter 3.47; the Cupertino port and cross-host stability are in progress, and the next step is a v1.0 release candidate with an API freeze.
Does Plumix support hot reload?
Yes. Running under dotnet watch preserves State across edits, so you keep your counter values and scroll positions while the widget tree rebuilds — the same workflow Flutter developers expect.
Start porting Flutter widgets today
Read the architecture guide, browse the controls catalog, or jump straight into the source.