dotnet/maui: a C# and XAML framework for Android, iOS, macOS and Windows from one codebase

What dotnet/maui is for and who ends up using it

The README states the project is a cross-platform framework for creating mobile and desktop apps with C# and XAML, and that a single shared codebase can target Android, iOS, iPadOS, macOS and Windows. That target list is the whole pitch. If you need an app on phones and on a desktop OS and you do not want to maintain separate UI layers, this is the problem dotnet/maui addresses.

The audience is narrower than the target list suggests. It is teams that already have C# skills and a .NET toolchain, because the framework sits inside the .NET SDK rather than beside it. A JavaScript or Dart team gains nothing here. The README also points to Visual Studio productivity tools and emulators as part of the development process, which tells you the intended workflow assumes an IDE on Windows or macOS rather than a terminal-only environment.

The workload, the template and what a new project actually contains

The mechanism is a .NET workload plus a project template. The README notes that if the maui template is not available, you first install the workload with dotnet workload install maui. After that, dotnet new maui -n NewApp produces a project. There is a second variant, dotnet new maui -n NewApp -sc, which the README describes as a sample app that also pulls in the open-source Syncfusion Toolkit for .NET MAUI with over 30 additional controls, plus the .NET MAUI Community Toolkit and MVVM Toolkit.

That is the visible architecture from the repository side. The top-level entries show separate solution filters for mac, windows and vscode, a Microsoft.Maui.sln, build scripts in Cake, PowerShell and shell, and a src/ directory holding the framework itself. The repository is the framework source, not a starter kit. Cloning it gives you the code that ships in the workload, and the README routes anyone who wants to build from source to the Development Guide rather than describing that path inline.

The template choice matters more than it looks. The plain template gives you a minimal app. The -sc variant gives you a working sample with third-party and community libraries already wired up, which is useful when you are evaluating whether the ecosystem covers the controls you need. Neither template is a scaffold you keep; you are expected to restructure as the app grows.

Installing dotnet/maui and creating a first project

The README gives the install in two places: the Install .NET MAUI link and the note about the workload. Start by confirming the template exists, and install the workload if it does not.

dotnet workload install maui

That command is the one the README names for the case where the maui template is not available. It needs an SDK that matches the release line you intend to use, so check your SDK version before running it.

dotnet new maui -n NewApp

This creates a project named NewApp. If you want the sample that includes the extra toolkits, the README gives the same command with a flag:

dotnet new maui -n NewApp -sc

After either command you have a project you can open in Visual Studio or build from the command line. The README does not walk through the generated file layout, so read the .NET MAUI documentation linked from the README for the platform-specific setup each target requires. Expect the first build to take a while, since the workload pulls in platform SDKs.

Linux desktop is not a target, and the README is silent about it

The README lists Android, iOS, iPadOS, macOS and Windows. Linux is absent from that list, and nothing in the README describes a Linux desktop target or a community-supported path to one. Searches for dotnet maui linux are common enough that this is clearly a recurring question, but the repository does not answer it. If Linux desktop is a requirement, this framework does not meet it, and no amount of tooling around the edges changes that.

The second limitation is structural. The workload model means your SDK version and your MAUI version are coupled. The recent releases show a 10.0.101 stable line and an 11.0.100 release candidate, and the repository carries separate merge-flow configuration files for net11 and release-11. Teams that pin an SDK for other reasons may find themselves unable to move to the MAUI line they want without moving the SDK. That is a real cost, and the README does not discuss it.

A third gap: the README does not document rollback. If a workload update breaks a build, the README offers no procedure for returning to a previous state. That is the kind of thing you discover at the wrong moment.

How dotnet/maui differs from Avalonia and Flutter in approach

Avalonia is the closest comparison for C# teams, and the difference is in the abstraction. Avalonia renders its own UI across platforms, so a Linux desktop target is part of the design rather than an exception. dotnet/maui instead maps onto the native controls of each platform and leans on the platform SDKs through the workload. The practical consequence: dotnet/maui gives you platform-native behaviour on the five targets it lists, and nothing at all on the ones it does not.

Flutter takes the opposite route from Avalonia in language and the same route in rendering. You write Dart, and Flutter draws its own widgets. Choosing between Flutter and dotnet/maui is mostly a question of which language your team already has and whether you want the UI to look identical everywhere or to inherit platform conventions. The README's framing, with Visual Studio and emulators named as part of the process, points at teams inside the Microsoft toolchain rather than teams picking a UI stack from scratch.

Maintenance, releases and the licence

The repository is not archived, and the last push was on 2026-09-20. The release history shows a steady cadence: 10.0.100 on 2026-08-20, 10.0.101 on 2026-09-07, and 11.0.100-rc.1 on 2026-09-08. A release candidate for the next major line alongside a patched stable line is the normal shape for a project tied to the .NET release train.

The upgrade cost is the workload. Moving between MAUI versions is not a package bump you can isolate in one project file; it is an SDK-level change that affects every project on the machine. Plan upgrades as environment changes, and check the What's new pages the README links for each .NET version before you move.

The licence is MIT, stated in the repository. That is permissive and permits commercial use, modification and redistribution with the licence and copyright notice retained. The repository also carries a THIRD-PARTY-NOTICES.TXT, which matters because the -sc template pulls in the Syncfusion toolkit and community toolkits under their own terms. Check those separately if you use that template; MIT on the framework does not extend to every dependency in the sample. This is a description of the licence text, not legal advice.

Editorial conclusion

Adopt dotnet/maui if your team already writes C# and you need one codebase for Android, iOS, macOS and Windows, and confirm the maui workload resolves before you plan any work. Skip it if Linux desktop is a hard requirement, since the README lists only Android, iOS, iPadOS, macOS and Windows as targets. Verify first that your installed SDK matches the release line you intend to pin (10.0.101 or the 11.0.100 release candidate), and check the .NET MAUI FAQ wiki for the question you cannot answer from the README.

Frequently asked questions

Official sources

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