Mono Is Gone: What .NET 11 Does to Your MAUI App

Most .NET MAUI upgrades are uneventful. You bump a target framework, resolve a handful of package versions, run the test suite, and ship. .NET 11 is not that upgrade, and the reason has nothing to do with the UI framework.

As of .NET 11 Preview 6, CoreCLR is the only runtime for .NET MAUI mobile apps. Mono is no longer selectable for Android, iOS, or Mac Catalyst, and the build property that previously allowed you to pick it has been removed. CoreCLR had already become the default across all MAUI platforms in Preview 4; Preview 6 removed the alternative.

If your codebase started as Xamarin.Forms, this deserves more attention than it is getting. Mono carried .NET onto mobile for more than fifteen years. Every Xamarin.Forms app ever shipped ran on it. Your app was written against Mono, tuned against Mono, and — if anyone ever profiled it — profiled against Mono.

Swapping the runtime under an application is a different class of change from swapping a UI layer.

Why this lands now

.NET 11 reaches general availability in November 2026. Preview 6 is available today. That gap is the entire opportunity: you can find out what breaks during a preview you chose to install, or during an upgrade you are already committed to.

There is a second change in the same preview that most teams have not connected to the first. The optional Microsoft.Maui.Controls.Compatibility NuGet package is no longer built or shipped in .NET 11. Microsoft’s guidance is direct:

Projects that explicitly referenced this package for Xamarin.Forms migration compatibility should migrate off it before moving to .NET 11.

For a large population of migrated apps, these two changes are the same event. The teams still leaning on the compatibility package are, by definition, the teams that migrated by preserving Xamarin-era code rather than rewriting it. They are now blocked on .NET 11 for the same reason their app has been carrying overhead since the migration. We wrote about the performance half of that problem separately in You Migrated Xamarin.Forms to .NET MAUI and the App Got Slower.

Related, and easy to miss: starting in Preview 6, Android Shell apps use the handler-based Shell architecture by default. The legacy ShellRenderer path still works, but only if you explicitly register it. If your navigation behaves differently after the upgrade and you never touched navigation, that is the first place to look.

What the numbers actually say

Microsoft’s position on performance is that iOS and Mac Catalyst are generally faster than Mono, and Android lands within roughly 10% of Mono on startup and app size.

That is a reasonable claim and we have no reason to dispute it. It is also measured on a template app.

Meanwhile, dotnet/android issue #10914 — “[Android][CoreCLR] Severe startup regression (~5s delay) and APK size increase (~80%) compared to Mono in .NET 11 Preview” — reports startup moving from roughly 1.0s to 6.0s and an APK growing from 21 MB to 38 MB. The issue is open.

Both of these can be true at once, and understanding why is the useful part:

Microsoft’s figures come from a freshly generated dotnet new maui project — minimal dependencies, no native bindings, no reflection-heavy libraries, nothing carried over from a previous framework.
The issue is a real application on an earlier preview, with a real dependency graph.
Preview-era numbers move. Microsoft is actively working size and startup down, and the gap between an early preview and GA is usually significant.

The honest conclusion is not “CoreCLR is 80% bigger.” It is that the template number does not predict your number, and the distance between them is a function of what your app drags along. That distance is exactly what a migrated Xamarin codebase tends to have a lot of.

So do not take our word for it, or Microsoft’s. Take the measurement.

What to measure, in order

This is a half-day of work for one engineer, and it converts an unknown into a number you can plan against.

1. Install the .NET 11 Preview 6 SDK and build against CoreCLR. Do not change anything else yet. You want to know whether it compiles and launches before you know whether it is fast.

2. Measure cold start on real hardware. Not the simulator, not the newest device in the office. The cheapest Android device your user base actually runs, in a Release build. Cold start is where runtime changes surface first and where users notice them.

3. Measure package size. IPA and APK/AAB, Release configuration. Compare against your current .NET 10 build on the same machine, same day. If the delta is large, you have found something specific rather than a general property of CoreCLR.

4. Inventory your reflection-dependent dependencies. This is the step that matters most and the one teams skip. Anything doing runtime type inspection, dynamic proxies, expression compilation, or reflective serialization is a candidate. In apps that came from Xamarin, this list is typically longer than anyone expects and includes at least one package that has not shipped a release in three years.

5. Check whether you still reference Microsoft.Maui.Controls.Compatibility. If you do, that reference is now a hard blocker, not a preference. Note that the shimmed renderer base classes included with Microsoft.Maui.Controls are a separate thing and still present — it is the opt-in package that stopped shipping.

6. Exercise your native bindings and platform interop. Custom native libraries, BLE stacks, hardware SDKs, anything with a [DllImport] or a binding project. Runtime changes are exactly where these surface, and they rarely fail at build time.

7. File what breaks. Microsoft is asking for this, and preview-window issues get attention that post-GA issues do not.

The delivery consequence

The thing worth naming to whoever holds the budget: this work does not produce a feature. It produces the absence of a November problem. That is a genuinely hard thing to fund, which is why most teams will not do it and will instead discover their reflection-dependent package is broken during an upgrade sprint that was scoped at two days.

The asymmetry is what makes the case. Testing against Preview 6 costs a known, small amount of engineering time and is schedulable. Finding the same problems after GA costs an unknown amount, arrives with everything else that was deferred to the same upgrade, and lands on whichever engineer is unlucky enough to pick up the ticket.

A useful way to frame it internally: you are not upgrading to .NET 11 in July. You are buying the information about what .NET 11 will cost you in November, at July prices.

Where this leaves migrated apps

If your app came from Xamarin.Forms and you have been treating the migration as finished, .NET 11 is the release that reopens it. Not because MAUI changed, but because the runtime underneath it did, and because the compatibility scaffolding that made the original migration cheap has stopped shipping.

The destination is fine. iOS and Mac Catalyst come out ahead, Android is close, and CoreCLR brings genuine compatibility benefits with the rest of the .NET ecosystem. Nothing here argues against making the move.

It is the inventory you are dragging along that decides how expensive the trip is — and right now, for most migrated apps, nobody has counted it.

FAQ

Is Mono still supported in .NET 11?

Not for .NET MAUI mobile. As of .NET 11 Preview 6, Mono is no longer selectable for Android, iOS, or Mac Catalyst, and the build property that previously allowed you to choose it has been removed. Blazor WebAssembly is a separate case and continues to use Mono.

Can I switch back to Mono if CoreCLR causes problems?

No. The build property used to select the Mono runtime has been removed, so there is no supported opt-out in .NET 11. Your options are to fix the problem on CoreCLR or to stay on .NET 10 until you have.

Will my third-party libraries work on CoreCLR?

Most will. The libraries most likely to break are those that depend on reflection, on runtime code generation, or on native bindings. Microsoft explicitly asks teams to validate reflection-heavy dependencies against CoreCLR. In an app that came from Xamarin, that dependency list is usually long and only partly maintained, which is why this is the step worth doing first.

When does .NET 11 reach general availability?

.NET 11 is scheduled for general availability in November 2026. Preview 6 is available now, which means there is a working window to test against CoreCLR before the release rather than after it.

Do I have to move to .NET 11 immediately?

No, but the decision has a deadline attached because .NET releases follow a fixed support lifecycle. The useful framing is not whether to move but when you find out what breaks — during a preview you control, or during an upgrade you are already committed to.

You Migrated Xamarin.Forms to .NET MAUI and the App Got Slower — the other half of the Preview 6 story, and why the compatibility layer is usually the cause.
Flutter vs .NET MAUI in 2026: An Honest Engineering Comparison — where MAUI genuinely wins, and what it costs.
Upgrading Flutter Without Surprises: A Diagnostic for What Silently Breaks — the same problem in a different framework, with the same answer: measure before you commit.

Working through a .NET 11 upgrade?

We run Xamarin and .NET MAUI modernization for product teams that need the work done without pulling their own engineers off the roadmap. If you want a second opinion on what your upgrade actually costs, book a 20-minute call — bring your dependency list and we will tell you where we would look first.

Sources

Facts verified against the sources above on 31 July 2026. .NET 11 is in preview; version-specific details will move before November GA.

Mono Is Gone: What .NET 11 Does to Your Migrated Xamarin App