CommunityToolkit.Maui: What the toolkit adds to a plain .NET MAUI app

What the toolkit is for, and who it is written for

The README describes the project as "a collection of common elements for development with .NET MAUI that developers tend to replicate across multiple apps." That sentence is the whole pitch. If you have built more than one MAUI app, you have probably written the same popup host, the same value converters, the same snackbar, the same folder picker wrapper, twice. The toolkit exists so that work happens once and lives in a NuGet package instead of in your repository.

The audience is narrower than "anyone using .NET MAUI". It is aimed at developers already inside the MAUI project system, with a MauiProgram.cs and a XAML or C# UI. It is not a framework that replaces MAUI, and it does not abstract platform differences away for you. Version 15.0.0 is titled "Prevent Breaking Changes in .NET 11", which tells you the library tracks upstream MAUI releases closely and expects you to do the same. If you are pinned to an older MAUI band, that coupling is a cost, not a feature.

How the pieces are split across four NuGet packages

The installation section of the README lists four packages: CommunityToolkit.Maui, CommunityToolkit.Maui.MediaElement, CommunityToolkit.Maui.Maps and CommunityToolkit.Maui.Camera. That split is the most useful architectural fact about the project. The core package carries the extensions, behaviors and UI controls. Media playback, maps and camera capture sit in their own packages, so an app that needs a snackbar does not drag in a video player.

The repository layout matches this: src/ holds the package sources, samples/ holds CommunityToolkit.Maui.Sample.slnx, and the sample app under samples/CommunityToolkit.Maui.Sample/ is the working reference for how each feature is wired. If a control's documentation is thin, the sample project is the place to look for the actual property names.

One structural point deserves attention. The README states that features added to the toolkit "may one day be included into the official .NET MAUI library", and that the team works with the MAUI engineering team to nominate features for promotion. That is a real benefit (a feature you adopt may later become first-party) and a real risk (an API you depend on can change shape or move when it is promoted).

Installing CommunityToolkit.Maui and calling it from MauiProgram.cs

Packages come from NuGet. The README gives these commands, which you run in a terminal against the project you want to modify:

dotnet add package CommunityToolkit.Maui
dotnet add package CommunityToolkit.Maui.MediaElement
dotnet add package CommunityToolkit.Maui.Maps
dotnet add package CommunityToolkit.Maui.Camera

You do not need all four. Add CommunityToolkit.Maui first and bring in the others only when you use the corresponding feature.

Registration happens in MauiProgram.cs. The README's getting-started example chains UseMauiCommunityToolkit() onto the builder, next to UseMauiApp<App>():

using CommunityToolkit.Maui;

public static class MauiProgram
{
	public static MauiApp CreateMauiApp()
	{
		var builder = MauiApp.CreateBuilder();
		builder
			.UseMauiApp<App>()
			.UseMauiCommunityToolkit();

		return builder.Build();
	}
}

After that call, the toolkit's controls and behaviors are available. To use them from XAML, declare the toolkit namespace the README documents:

xmlns:toolkit="http://schemas.microsoft.com/dotnet/2022/maui/toolkit"

With the namespace in place you can reference toolkit types by the toolkit: prefix in the same file. The README stops there; the Microsoft Learn documentation linked from it, at learn.microsoft.com/dotnet/communitytoolkit/maui/get-started, is where per-control usage lives.

If you want to try unreleased code, the README describes a prerelease feed on GitHub Packages. It requires a personal access token (classic) with the read:packages scope, added as a NuGet source:

dotnet nuget add source https://nuget.pkg.github.com/CommunityToolkit/index.json -n CommunityToolkitGitHubNuget -u YOUR_GITHUB_USERNAME -p YOUR_GITHUB_PERSONAL_ACCESS_TOKEN

Prerelease versions are then installed with an explicit version, for example --version 99.0.0-preview980 as shown in the README. Treat this path as a way to test a fix, not as a default for production builds.

Where the toolkit is the wrong tool

The toolkit is a grab bag, and grab bags have edges. The README is explicit that there is no delivery plan: "All work carried out on the toolkit is done so by the community and the core maintainers in our spare time on nights and weekends. Due to this reason we do not have a concrete plan on when features will be added and delivered." If your roadmap depends on a toolkit feature that does not exist yet, you are waiting on volunteer time. The project board lists proposals and their states; it is not a commitment.

There is also an API-stability cost. The 15.0.1 release notes mention removing remaining .NET MAUI internal API usage, and 15.0.0 is framed around preventing breaking changes in .NET 11. Both are signs of a library that reaches into MAUI internals and has to react when those internals shift. That is normal for a companion library, but it means a MAUI upgrade is often a toolkit upgrade too, and skipping one can leave you on a version that no longer compiles.

Finally, the toolkit is not a substitute for an MVVM framework or a navigation library. The README's own scope is extensions, controls and behaviors. If what you actually need is source-generated observable properties and commands, the toolkit's core package is not where that lives, and reaching for it there will leave you with a dependency you do not use.

CommunityToolkit.Maui compared with the CommunityToolkit.Mvvm package

The comparison users ask about most is between this project and CommunityToolkit.Mvvm. They share a name and a GitHub organization, and that is roughly where the overlap ends. CommunityToolkit.Mvvm is an MVVM library: it supplies the observable-property and command infrastructure that view models are built on. CommunityToolkit.Maui is a UI library: it supplies controls, behaviors and platform extensions that sit on top of .NET MAUI itself.

The practical difference shows up in what breaks when you remove them. Drop the MVVM package and your view models stop notifying the UI; you would have to implement INotifyPropertyChanged by hand. Drop CommunityToolkit.Maui and your app still runs, minus the popup, the snackbar, the converter or the media element you were using. One is load-bearing for your architecture, the other is load-bearing for individual screens.

That makes them complements rather than alternatives, and the repository's own framing supports it: the toolkit's stated purpose is to "simplify and demonstrate common developer tasks when building apps with .NET MAUI", not to define how you structure an app. If you are choosing between them, you are asking the wrong question. If you are choosing whether to add CommunityToolkit.Maui at all, the question is whether the specific controls in its documentation replace code you would otherwise write and maintain yourself.

Maintenance, releases and what the MIT licence means for you

The repository is not archived, and the last push was on 2026-09-17. The release cadence visible in the notes is steady: 14.2.2 on 2026-07-16, 15.0.0 on 2026-07-24, and 15.0.1 on 2026-08-21, with the patch releases doing compatibility work rather than adding features. A patch arriving a month after a major version, specifically to fix WindowsAppSDK compatibility, is the pattern to expect from this project.

Upgrade cost is dominated by that coupling to MAUI itself. Because the library uses MAUI APIs and, per the 15.0.1 notes, has been removing internal API usage, a MAUI band change is the moment to check the toolkit's release notes before bumping. Budget for reading them; the titles alone ("Prevent Breaking Changes in .NET 11", "Fix WindowsAppSDK Compatibility") tell you which surfaces moved.

The licence is MIT, which is permissive and permits commercial and closed-source use. That is a statement about the licence text, not legal advice; if your organization has rules about third-party dependencies, the LICENSE file at the repository root is the document to hand to whoever reviews those.

Editorial conclusion

Adopt CommunityToolkit.Maui if you are building a .NET MAUI app and would otherwise hand-write popups, converters, alerts, animations or a media player. Do not adopt it as a substitute for MVVM plumbing, and do not expect a delivery schedule: the maintainers state that work happens in their spare time on nights and weekends. Before adding it to a shipping app, check the release notes of the version you pick for the WindowsAppSDK and internal-API changes, since 15.0.1 and 15.0.0 exist precisely to address those, and read the .NET MAUI version each package targets.

Frequently asked questions

Official sources

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