MvvmCross: an opinionated MVVM framework for .NET across Android, iOS, macOS, tvOS, WPF and WinUI

What MvvmCross solves, and for whom

A .NET team that ships the same product on Android and iOS, plus a desktop target such as WPF or WinUI, ends up writing the same screen logic several times. MvvmCross targets exactly that situation. The README describes it as an opinionated cross-platform MVVM framework that lets developers share behavior and business logic between platforms, and it lists Android, iOS, MacCatalyst, tvOS, macOS, WinUI and WPF as supported targets. The unit of reuse is the ViewModel and the behavior attached to it, not the UI layer. You still write a native view per platform; what you do not rewrite is the logic behind it. That makes the framework a fit for product teams with a shared core and several thin app heads, and a poor fit for a solo developer with one target, where the framework's conventions cost more than they return.

Bindings, navigation and IoC: the three mechanisms you actually use

The README names four features, and three of them define the day-to-day programming model. First, ViewModel to View bindings run through a binding engine that MvvmCross owns, and the README notes you can create your own binding definitions for your own custom views. That matters when a platform control has no built-in mapping: instead of abandoning the binding, you declare one. Second, ViewModel to ViewModel navigation, which the README says helps you share behavior on how and when to navigate. Navigation therefore becomes a shared concern rather than something each platform's view layer decides. Third, inversion of control through dependency injection and property injection. Services are resolved through the framework's container, and the README states the framework is extendable and configurable, with the stated goal of letting the developer decide how to use it. A plugin framework sits on top, described as a way to plug in things like GPS location, localization, sensors and binding extensions, alongside third-party community plug-ins. The repository layout matches this: MvvmCross/, MvvmCross.DroidX/, MvvmCross.Wpf/, MvvmCross.WinUI/, MvvmCross.Plugins/ and UnitTests/ sit at the top level.

Installing MvvmCross and wiring a first ViewModel

The README gives one installation instruction: take the MvvmCross NuGet package and install it in your solution. The package command it shows is the Package Manager Console form.

Install-Package MvvmCross

The README adds a constraint that is easy to miss: both the shared core project and your application projects must include the NuGet. Installing it in the core project alone is not enough. For anything beyond that, the README points to the Getting Started documentation on mvvmcross.com, which it says also offers Visual Studio and Xamarin Studio plugins to install and manage MvvmCross in a project. The README does not print a ViewModel or setup class, so the first real use is not shown here; the getting-started page is where the framework's own example lives. What the README does establish is the shape of the work: a shared core project holding ViewModels and services, and one application project per platform, each referencing the same package.

Where MvvmCross is the wrong choice

The README's platform list is the first boundary. Android, iOS, MacCatalyst, tvOS, macOS, WinUI and WPF are named; .NET MAUI and Avalonia are not, even though both appear in what people search for around this project. If your roadmap is MAUI, the framework's own README gives you no supported path. Second, MvvmCross calls itself opinionated, and that is a real cost. Binding definitions, navigation and service resolution all go through the framework's engine and container. A team that has already standardized on another container, or that wants navigation handled by a platform's own router, will be fighting conventions rather than using them. Third, the promises are deliberately open-ended: the README says the framework is extendable and that you decide how to use it, but it does not document a migration or rollback path, and the README does not document upgrade steps between major versions. Teams that need a documented deprecation policy before adopting a UI framework should treat that silence as a gap to close with the maintainers, not as a minor detail.

How it compares to a platform's built-in MVVM

The honest alternative is not another cross-platform framework; it is using each platform's own MVVM support and sharing only plain .NET libraries. On that approach you keep ViewModels as ordinary classes in a shared project, and each app head wires its own bindings and navigation. You give up the shared binding engine, so custom views need per-platform binding code, and you give up ViewModel-to-ViewModel navigation, so each platform decides when and how to move between screens. What you gain is fewer moving parts and no framework-specific conventions to learn. MvvmCross is worth its conventions when you have three or more targets and want one navigation model across all of them. With two targets and a small screen count, the built-in route is usually less work, and the README's own framing supports that reading: the framework exists to enable code sharing, and code sharing is only valuable when there is enough duplicated code to remove.

Release cadence, licensing and what upgrading costs

The repository is not archived, and the last push was on 2026-09-19. The release list shows v10.1.0 on 2025-12-09, v10.0.0 on 2025-11-11 and 9.4.0 on 2025-07-17, so the 10.x line is the current one and 9.4.0 is the previous major series. A major version boundary inside a year is the main upgrade cost to plan for: moving from 9.x to 10.x is a major-version move, and the README does not describe what changes between them, so the CHANGELOG.md at the repository root is the file to read before you start. The default branch is develop, which means the code you see on GitHub is ahead of the released packages; pin to released NuGet versions rather than tracking the branch. On licensing, MvvmCross is under the MS-PL, and the README lists components redistributed under other terms: MonoCross under MIT, small parts of MvvmLight under MIT, messenger ideas from XPlatUtils under Apache License 2.0 and from TinyMessenger under an as-is disclaimer, color codes under MIT, and parts of Mvvm.Async under MIT. If you redistribute the framework or embed it in a product, those notices travel with it. That is a description of the repository's own statements, not legal advice; have your own counsel review the MS-PL and the listed third-party notices.

Getting help and reporting a bug

The README splits the two channels deliberately. GitHub issues are reserved for bugs, features and project management; questions belong on StackOverflow under the mvvmcross tag or in the #mvvmcross channel on Discord. If you do file an issue, the README asks for a minimal git repository that reproduces the problem, a snippet of the broken code, a check that the problem reproduces in a brand new project, the exact steps, and the platform where it occurs. That list is worth reading before you file, because a report missing the reproduction repository is likely to stall. The repository also carries CONTRIBUTING.md and CODE_OF_CONDUCT.md at the root, and the project states it is supported by the .NET Foundation.

Editorial conclusion

Adopt MvvmCross if you are building a .NET app on two or more of the supported platforms and want ViewModel-to-View bindings, ViewModel-to-ViewModel navigation and dependency injection in one package, licensed under MS-PL. Do not adopt it if you are on a single platform where the platform's own MVVM support is enough, or if you need MAUI or Avalonia support, which the README does not list. Before committing, verify on mvvmcross.com that your target platform and .NET version are covered by the current 10.x line, and confirm that your team accepts the MS-PL redistribution terms.

Frequently asked questions

Official sources

1. License: MS-PL
2. MvvmCross/MvvmCross on GitHub
3. Project website
4. README
5. Releases