TL;DR: Starting with .NET 11 Preview 6, CoreCLR is the only runtime for .NET MAUI apps targeting Android, iOS, tvOS, and Mac Catalyst, replacing the previous Mono runtime path for these affected MAUI mobile targets. This article compares Mono and CoreCLR, explains the key runtime and performance differences, and provides practical guidance for testing your app before upgrading to .NET 11.
Upgrading a .NET MAUI application to .NET 11 is no longer just a framework update. The runtime underneath those applications is changing from the previous Mono-based path to CoreCLR.
This transition can affect startup behavior, memory usage, diagnostics, application size, and third-party library compatibility, even though most applications will not require a source-code rewrite.
This raises important questions for existing MAUI applications:
- Is CoreCLR faster than Mono?
- Will my application behave differently after upgrading?
- Do I need to change my code?
- What should I validate before moving to .NET 11?
In this article, we’ll compare Mono and CoreCLR, explore the architectural and performance differences between the two runtimes, examine what changes in .NET 11, and provide a practical migration and validation checklist to help you upgrade with confidence.
Mono vs CoreCLR at a glance
| Dimension | Mono | CoreCLR (.NET 11 MAUI) |
| Execution/compilation model | Platform- and build-dependent, including JIT, interpreter, and AOT configurations | Tiered JIT with Tier 0 → Tier 1 optimization |
| GC | SGen / platform-specific Mono configuration | CoreCLR generational GC |
| AOT/deployment model | Mono AOT and, on some platforms/configurations, interpreter or full AOT | CoreCLR JIT-based execution by default; NativeAOT is a separate deployment and execution model where supported |
| Diagnostics | More limited depending on platform and scenario | Broader .NET diagnostics support on supported mobile scenarios |
What is CoreCLR on .NET MAUI?
CoreCLR is the runtime used by .NET across desktop and server workloads, including ASP.NET Core and other .NET applications. For .NET 11 MAUI applications, it is the runtime path for the affected Android, iOS, tvOS, and Mac Catalyst targets.
CoreCLR and NativeAOT should be treated as separate technologies.
- CoreCLR executes managed code using its JIT and related compilation technologies.
- NativeAOT uses a separate ahead-of-time deployment and execution model and does not run on Mono or CoreCLR at runtime.
Both Mono and CoreCLR execute IL, provide garbage collection and runtime services, and expose the .NET Base Class Library (BCL). However, their execution and compilation architectures differ and those differences matter for mobile workloads where startup time, application size, memory usage, and runtime performance are important.
Architecture differences: Mono vs CoreCLR
1. JIT compilation strategy
| Feature | Mono | CoreCLR |
| Execution/compilation model | Platform- and build-dependent: JIT, interpreter, and AOT configurations | Tiered compilation (Tier 0 → Tier 1) |
| Dynamic PGO | Mono-specific/runtime-dependent | Profile-guided optimization and runtime-driven optimization |
| Ahead-of-time compilation | Mono AOT for supported mobile configurations |
ReadyToRun and NativeAOT are separate compilation options |
| Startup pre-compilation | Mono’s AOT pipeline |
ReadyToRun (R2R), where enabled |
| Startup tiering | Not directly comparable as a single Mono mobile mode | Tier 0 → Tier 1 for hot methods |
What does this mean for MAUI developers?
- CoreCLR’s tiered compilation allows methods to begin with relatively fast Tier 0 compilation and receive more aggressive optimization as they become hot.
- Mono’s mobile execution model varies by platform and build configuration, including JIT, interpreter, and AOT-based execution.
Therefore, tiered compilation alone should not be treated as the explanation for startup differences between Mono and CoreCLR.
2. Garbage collection
| Feature | Mono | CoreCLR |
| GC implementation | SGen / platform-specific Mono configuration | CoreCLR generational GC |
| GC modes | Configuration- and workload-dependent | Configuration- and workload-dependent |
| Pause times | Workload-dependent | Workload-dependent |
| Arm64 optimizations | Available | CoreCLR Arm64 optimizations |
| Runtime configuration | Mono-specific behavior | CoreCLR runtime configuration |
Why does GC matter for MAUI?
GC activity can contribute to UI pauses and memory pressure, but it is only one factor affecting rendering performance.
When comparing Mono and CoreCLR, measure:
- GC activity
- Allocation rate
- Memory usage
- Frame rendering
- Startup time
- CPU utilization
This gives you a more complete picture of application performance than GC pause time alone.
3. Threading and concurrency
Both Mono and CoreCLR support the standard .NET threading and asynchronous programming APIs, including Task, async/await, and synchronization primitives.
For most MAUI applications, the practical differences are more likely to appear in runtime behavior, diagnostics, and workload-specific performance than in application-level threading APIs. The more significant change is the diagnostics experience. CoreCLR provides a more consistent .NET diagnostics story across server, desktop, and supported mobile workloads.
4. Diagnostics and tooling
One of the significant benefits of CoreCLR is improved access to the broader .NET diagnostics ecosystem.
| Tool | Mono | CoreCLR |
| dotnet-trace | More limited depending on platform and workflow | Broader support for mobile scenarios |
| dotnet-counters | More limited depending on platform and workflow | Broader support for mobile scenarios |
| dotnet-dump | More limited depending on platform and workflow | Scenario-dependent; verify support for the target platform and diagnostic workflow |
| Hot Reload | Supported with platform-specific limitations | Supported through IDE and dotnet watch workflows |
CoreCLR provides a more consistent .NET diagnostics experience for supported mobile scenarios, including tools such as dotnet-trace and dotnet-counters. Availability and workflow can still depend on the target platform and diagnostic scenario.
5. Code generation and optimizations
Beyond the JIT itself, CoreCLR brings several compilation and optimization technologies to MAUI.
ReadyToRun
-
ReadyToRuncan precompile assemblies to reduce the amount of work required at runtime. This can improve startup behavior in supported configurations. - Its applicability and benefit depend on the target platform and publishing configuration, so compare equivalent publishing configurations when benchmarking MAUI applications.
Profile-guided optimization
Profile-guided optimization uses runtime and profile information to optimize frequently executed code paths.
NativeAOT
NativeAOT is available as a separate ahead-of-time deployment and execution model for supported platforms and scenarios. If your application uses NativeAOT, evaluate its trimming, reflection, and native interoperability requirements separately from the standard CoreCLR execution path.
Performance: Mono vs CoreCLR on real devices
The .NET MAUI team has published performance comparisons between Mono and CoreCLR.
iOS and Mac Catalyst
CoreCLR has generally demonstrated:
- Faster cold startup
- Faster warm startup
- Improved execution on PGO-friendly workloads
NativeAOT can provide additional startup and application-size benefits where it is used, but those results should be evaluated separately because NativeAOT represents a different execution model.
Android
The .NET MAUI team reports that, in its baseline measurements, CoreCLR is within 10% of Mono for Android startup and app size.
Android results are more workload-dependent. Some complex applications have reported startup regressions or increases in APK/AAB size, so the reported baseline should not be treated as a guarantee for every .NET MAUI application.
What the community has found
These baseline measurements do not capture every workload. Discussions in the .NET Android repository provide examples of applications where CoreCLR has shown different startup, size, or runtime behavior:
- dotnet/android#10588: Startup time and application size increases in complex Android applications.
- dotnet/android#10914: Specific scenarios where CoreCLR underperforms Mono.
These issues provide examples for investigation rather than benchmarks that represent all .NET MAUI applications.
Read the full blog post on the Syncfusion Website
Top comments (0)