MvvmCross in 2026: What Happens to Apps Built on It

If you inherited an enterprise Xamarin.Native app of any real complexity, there is a good chance it uses MvvmCross. For years it was the standard answer to MVVM on native iOS and Android in C# — dependency injection, ViewModel-first navigation, data binding directly in Android layout XML, and a plugin system for platform services.

Almost nothing current has been written about where those apps go now. What little exists tends to assume the project is dead.

It is not. That framing is wrong, and getting it right changes the decision.

The actual state of the project

Checked directly against the repository and the NuGet API on 6 August 2026:

Target frameworks shipped in 10.1.2 include net10.0-ios26.0, net10.0-android36.0, net9.0-ios18.0 and net9.0-android35.0. That is current — more current than a lot of the ecosystem. .NET 8 mobile workloads were deliberately dropped in the 10.0 release, following the MAUI support policy.

So: actively maintained, modern target frameworks, released within the last eight months.

The qualification is who “actively maintained” means. Of the commits to the default branch since January 2026, the large majority are from dependency bots. Human commits number in the low double digits, and around 85% of them come from a single maintainer — Tomasz Cielecki. June and July 2026 saw no human commits at all; August resumed.

That is not a criticism of anyone. Maintaining a framework of this size largely alone, for years, unpaid, is a considerable thing to do. But if you are making a multi-year platform decision for an enterprise application, bus factor one is a fact you have to price. We wrote about the general version of this problem in The Bus Factor Is Zero; here it applies to a dependency rather than to your own codebase, which makes it harder to mitigate, not easier.

One thing to be clear about: there is no official statement from the maintainers about end of life, funding, or the project’s future. No pinned issue, no deprecation notice, no roadmap post. Anyone telling you MvvmCross has announced its end is making it up.

The thing that actually changes the decision

MvvmCross 11 is in development on the develop branch, and it is not an incremental release. The project’s own upgrade guide opens with this:

MvvmCross 11 replaces the custom IoC container (IMvxIoCProvider) with Microsoft.Extensions.DependencyInjection (MEDI) and introduces a new MvxHostBuilder / MvxHost startup model that replaces the old App.cs + Setup.cs pattern. This is the largest breaking change in MvvmCross history, but the new model is significantly simpler and aligns with the standard .NET hosting patterns you already know.

The commit that implements it deletes, among other things:

• the entire MvvmCross/IoC/ folder — IMvxIoCProvider, MvxIoCProvider and the rest
• Mvx.cs, the static service locator
• MvxSetup.cs and every platform variant
• the whole plugin infrastructure — IMvxPlugin, MvxPluginManager, and every Plugin.cs in MvvmCross.Plugins/
• MvxApplication and IMvxApplication

Those are not obscure internals. They are the APIs your Setup.cs and your service registration are written against. Version 11 is unreleased as of August 2026 — the version file still reads 10.1.2, and develop sits well ahead of main — but the direction is committed and public.

So here is the decision as it actually stands, rather than as it is usually framed:

You are not choosing between “stay on MvvmCross and change nothing” and “migrate and rewrite everything.” You are choosing between two rewrites. Staying means adopting MvvmCross 11 and rewriting your IoC registration, startup and plugins onto Microsoft.Extensions.DependencyInjection. Leaving for MAUI means rewriting your IoC registration, startup and plugins onto Microsoft.Extensions.DependencyInjection — plus the UI.

The container work is common to both paths. That is genuinely useful to know when sequencing.

What is hard to leave, in order

Not all of MvvmCross costs the same to replace. Ranked by difficulty, based on what the framework actually does:

1. Native data binding — the hardest by a distance

MvvmCross binds directly in Android layout XML:

local:MvxBind="Text Name"
local:MvxBind="Visible Favorite"
local:MvxBind="TextColor NativeColor(FavoriteColor)"

These are strings, parsed at runtime by a reflection-based binding engine that hooks layout inflation. The MvvmCross/Binding/ tree contains dozens of reflection call sites and is heavily annotated as trim-unsafe.

There is no converter, no codemod, and no partial path. A move to MAUI discards the AXML files entirely and every binding is rewritten in XAML. The custom converter and combiner syntax — NativeColor(FavoriteColor) above — has no analogue in MAUI at all.

If you want one number to size an MvvmCross exit, count your MvxBind occurrences.

2. ViewModel-first navigation

MvvmCross navigates by ViewModel type with typed parameters:

await NavigationService.Navigate<DetailViewModel, MyParam>(param);

MAUI Shell navigates by route string with query parameters:

await Shell.Current.GoToAsync("details?id=42");

These are structurally opposed. Every typed call becomes a route registration, a string URI, and an IQueryAttributable.ApplyQueryAttributes implementation — losing compile-time type safety at every navigation boundary.

Worse, MvvmCross’s result-returning navigation — Navigate<TViewModel, TResult>, awaiting a value back from a pushed screen — has no Shell equivalent at all. Any workflow built on it needs redesigning, not translating.

Worth noting for anyone planning trimming or AOT: Microsoft’s own guidance is that “receiving navigation data using the QueryPropertyAttribute isn’t trim safe and shouldn’t be used with full trimming or NativeAOT” — use IQueryAttributable instead. If you are rewriting navigation anyway, write it the trim-safe way the first time.

3. The IoC container

The mapping looks mechanical — RegisterType becomes AddTransient, RegisterSingleton becomes AddSingleton — until you hit convention scanning. MvvmCross’s own guide:

The CreatableTypes().EndingWith("Service").AsInterfaces().RegisterAsLazySingleton() pattern no longer exists. Register your services explicitly, or use the community library Scrutor

In a large application that single line may register hundreds of services. Unwinding it means enumerating every one by hand, or taking on a third-party dependency to keep the convention.

Two semantics also have no direct MEDI equivalent: MvvmCross’s lazy singletons, and property injection via IMvxPropertyInjector. Both are usually fixable, but both are code changes rather than configuration changes.

4. The plugin system

Auto-discovery is gone in v11; each plugin becomes an explicit IServiceCollection extension method — services.AddMvxMessenger(), services.AddMvxJson(), and platform-specific variants. Mechanical for first-party plugins.

The real risk is third-party: community plugins implementing IMvxPlugin will stop loading, because the interface no longer exists. Inventory those now. Some will have no maintained successor.

5. Platform adapters

MvxRecyclerView, MvxTableViewSource, MvxCollectionViewSource and friends are all still present and are not going away in v11 — the DI rewrite does not touch them. Two honest observations: they are the least urgent thing on this list if you stay, and they are dead weight if you go, since MvxRecyclerView maps to CollectionView and every item template and template selector has to be rebuilt.

The runtime question nobody has answered yet

This is the item to watch rather than to act on today.

Microsoft moved .NET MAUI mobile to CoreCLR in .NET 11, with general availability in November 2026. Their guidance to library consumers is to “validate third-party libraries that use reflection, dynamic code generation, or Mono-specific APIs.”

MvvmCross is a reflection-heavy framework by design — that is how ViewModel-first navigation and string-expression binding work at all. The project has done substantial trimming-annotation work: hundreds of [RequiresUnreferencedCode] and [DynamicallyAccessedMembers] attributes across the codebase, with the trim analyzer enabled. But the 10.0 release notes are candid about where that has reached:

Trimming annotations across a lot of the MvvmCross code surface. Some platform specific code is still missing and will come in a later version. MvvmCross libraries are still not marked trimmable, but this brings us closer to be able to enable this

The annotations exist; the trimmable switch has not been flipped. The platform-adapter layer — precisely the Android and iOS code you depend on — is the part still unannotated.

There is also an open issue from August 2024 noting that LinkerPleaseInclude, the long-standing preservation workaround, uses a deprecated attribute and should move to DynamicDependency. The reporter’s concern, in their words: it “will cause a lot of MvvmCross apps to crash with release mode at runtime.” The issue has had no comments in two years.

No public .NET 11 or CoreCLR work is visible in the repository, and the target matrix stops at .NET 10. That is a statement about what we could see, not proof that nothing is planned. But if your plan involves MvvmCross on .NET 11, that assumption needs validating rather than assuming — ideally by building a spike against a preview, not by waiting. Our post on what .NET 11 does to migrated Xamarin apps covers the runtime change itself.

What the alternatives actually give you

The most common mistake here is assuming CommunityToolkit.Mvvm is a drop-in replacement. It is a good library. It is not that.

CommunityToolkit.Mvvm covers roughly the ViewModel layer — call it a third of what MvvmCross does for a native app. It also ships no mobile target frameworks at all, by design; it is deliberately UI-framework-agnostic. Version 8.4.2 was published in March 2026 and the repository has been quiet since; it is best described as stable and low-churn rather than actively developed.

A staged strategy that works

The sequencing matters more than the destination, and one order is clearly better than the others.

Stage 1 — Platform first, framework second. Move the app from Xamarin.Native to .NET for iOS and .NET for Android without touching MvvmCross. Version 10.1.2 already targets net10.0-ios26.0 and net10.0-android36.0, so this is possible today. You get off an unsupported, store-blocked stack — see Keeping a Xamarin.Native App Shippable for why that is more urgent than it looks — while changing exactly one variable. The mechanics are in Xamarin.Native to .NET for iOS and .NET for Android.

Stage 2 — Container and startup. Move service registration and startup to Microsoft.Extensions.DependencyInjection. This is required for MvvmCross 11 and for MAUI, which means you can do it before deciding between them. Enumerate what CreatableTypes() was registering; that inventory is valuable on its own.

Stage 3 — Decide, with real information. By now you know your MvxBind count, your plugin inventory, and how the app behaves on current .NET. Only then is the stay-or-leave question answerable with numbers rather than opinions.

What not to do: platform migration and framework replacement simultaneously. Two moving foundations under one app means no failure can be attributed, and these projects stall in exactly that state.

How MaboaSoft helps

MvvmCross apps are among the more complex legacy .NET mobile codebases in circulation — native UI, a reflection-heavy framework layer, an unsupported platform underneath, and usually nobody left who remembers why the plugin was written that way. That combination is squarely what we work on.

If you are holding one and want an outside read on the staging, book a 20-minute call. Bring your Setup.cs — it tells us more in five minutes than a written brief does in an hour.

FAQ

Is MvvmCross still maintained in 2026?

Yes. The latest stable release is 10.1.2, published 11 December 2025, and there was maintainer activity on the default branch in August 2026. It targets current monikers including net10.0-ios26.0 and net10.0-android36.0. The qualification worth knowing is that substantive engineering comes from essentially one maintainer, and that human commit activity in mid-2026 was intermittent. It is maintained, with a bus factor of one.

Does MvvmCross support .NET MAUI?

No, and it never has. There is no MvvmCross MAUI integration package on NuGet, no MAUI code in the repository, and no mention of MAUI in the documentation. The nearest historical analogue is MvvmCross.Forms for Xamarin.Forms, which has been frozen at version 8.0.2 since July 2021. Moving an MvvmCross app to MAUI means leaving MvvmCross, not integrating the two.

Does MvvmCross support .NET 11?

Not as of August 2026. The repository’s target matrix covers net8.0, net9.0 and net10.0 with no net11.0 entry, and no public .NET 11 tracking work is visible in the repository. Given that CoreCLR becomes the runtime for .NET mobile in .NET 11 and that MvvmCross libraries are not yet marked trimmable, this is worth monitoring rather than assuming.

Can CommunityToolkit.Mvvm replace MvvmCross?

Only partially. CommunityToolkit.Mvvm covers the ViewModel layer well — ObservableObject, RelayCommand, and a messenger. It provides no ViewModel-first navigation, no plugin system, no data binding engine for native Android or iOS, and no platform adapters. It also ships no mobile target frameworks by design. For a native MvvmCross app it replaces perhaps a third of what you are using.

What is the hardest part of leaving MvvmCross?

The native data binding. MvxBind expressions in Android AXML layouts are strings resolved at runtime by a reflection-based binding engine, with a custom value converter and combiner syntax that has no equivalent anywhere else. There is no converter and no partial migration path — moving to MAUI means discarding the AXML and rewriting every binding in XAML. ViewModel-first navigation is a close second, particularly the result-returning navigation pattern, which MAUI Shell has no equivalent for.

Related reading

• Xamarin.Native to .NET for iOS and .NET for Android — stage 1 of the strategy above
• Xamarin.Forms or Xamarin.Native? Which Migration You Are Actually Facing
• You Cannot Migrate This Year: Keeping a Xamarin.Native App Shippable
• The Bus Factor Is Zero: Recovering Product Knowledge from a Legacy Repository

Resources

• MvvmCross on GitHub — check the commit history yourself before making a platform decision
• MvvmCross on NuGet — the target framework list in the current package
• MvvmCross documentation
• MvvmCross releases — the 10.0 notes contain the trimming status quoted above
• CommunityToolkit.Mvvm — Microsoft Learn — the full API surface, for an honest comparison
• .NET MAUI Shell navigation — Microsoft Learn
• Dependency injection in .NET MAUI — Microsoft Learn
• .NET MAUI moves to CoreCLR in .NET 11 — .NET Blog

Repository state, release dates, target frameworks and download figures verified directly against GitHub and the NuGet API on 6 August 2026. MvvmCross 11 was unreleased at the time of writing; verify its status before planning around it.