With.NET 11, that drastically changes.
The only runtime available for.NET MAUI mobile apps aimed at Mac Catalyst, iOS, and Android as of .NET 11 Preview 6 is CoreCLR. The CoreCLR runtime, which powers desktop programs, cloud services, ASP.NET Core, and other.NET workloads, is being leveraged by Microsoft for mobile workloads.
This goes beyond a simple implementation detail.
Changing the runtime can affect:
Application startup
Memory behavior
Package size
JIT and AOT behavior
Diagnostics
Debugging
Reflection-heavy libraries
Third-party dependencies
Platform integrations
Microsoft's own guidance is clear that developers should measure their applications rather than assume that every application will improve equally. The .NET MAUI team specifically recommends comparing startup and package size against a .NET 10 baseline using real devices and Release builds.
This makes CoreCLR migration an excellent opportunity for a controlled benchmark.
What Changed in .NET MAUI?
Previously, the runtime architecture for mobile applications was different from the server and desktop .NET ecosystem.
The simplified model was:
while many other .NET workloads used:
.NET 11 brings the mobile platforms onto CoreCLR.
The current .NET 11 Preview 6 architecture is:
Microsoft also clarifies that Blazor WebAssembly is not affected by this change and continues to use Mono.
Why CoreCLR Matters
Runtime unification provides several potential benefits.
CoreCLR brings technologies such as:
Tiered JIT
ReadyToRun
Profile-Guided Optimization
Shared runtime implementation
Common .NET diagnostics tooling
Microsoft describes CoreCLR as providing a stronger foundation for runtime performance and future NativeAOT work on mobile platforms.
However, these capabilities do not guarantee that every application will automatically become faster.
Application startup depends on much more than the runtime:
That is why measurement is essential.
Define the Benchmark Before Migrating
A useful benchmark compares the existing application with the migrated version.
For example:
Do not change several unrelated application components at the same time.
If you simultaneously:
Upgrade .NET
Replace the database
Rewrite startup logic
Upgrade every NuGet package
Change image libraries
then you will not know which change caused a performance difference.
Benchmark Environment
A reproducible benchmark should document:
For mobile benchmarks, real devices are especially important.
An emulator can be useful for development, but it should not be the only source of production-performance conclusions.
Microsoft explicitly recommends measuring .NET 11 MAUI applications on target devices and comparing them with the .NET 10 baseline.
Create a .NET 10 Baseline
Before migrating, build the existing application in Release mode.
For example:
The exact target framework depends on the project and installed SDK.
Record at least:
Do not rely only on stopwatch measurements.
Automated instrumentation provides more consistent results.
Measure Cold Startup
Cold startup means the application is not already running.
A simplified test looks like:
Measure the interval between launch and a clearly defined application-ready event.
For example:
The exact location of the timer matters.
If you stop the timer too early, you may measure only framework initialization rather than the time users actually experience.
Define "Startup Complete"
This needs to be explicit.
Possible definitions include:
For a user-facing benchmark, the last meaningful event is often more useful than process creation.
However, the definition should remain consistent between the baseline and migrated builds.
Measure Warm Startup
Warm startup is different.
The operating system may retain application-related resources after the first launch.
A benchmark should therefore distinguish:
Run each test multiple times rather than relying on one measurement.
For example:
Then report the distribution.
Avoid publishing a single number without explaining how it was obtained.
Measure Package Size
Runtime changes can also affect application size.
For Android, measure the resulting APK or AAB.
For iOS, measure the resulting IPA or relevant packaged application artifact.
Microsoft specifically recommends comparing package size between the .NET 10 baseline and .NET 11 CoreCLR builds.
Record:
Be consistent between builds.
Do not compare an Android APK from one configuration with an Android AAB from another and treat the difference as a runtime effect.
Measure Memory Usage
Startup time is only one part of the benchmark.
Measure memory after defined application states.
For example:
This helps detect memory growth caused by application behavior rather than startup alone.
Useful measurements include:
Working set
Managed heap
Allocation rate
GC collections
Native memory where available
Use .NET Diagnostics
One advantage of CoreCLR on mobile is the availability of familiar .NET diagnostics.
Microsoft states that tools such as dotnet-trace and dotnet-counters can now be used with .NET MAUI mobile applications running on CoreCLR.
That makes it easier for teams already familiar with server-side .NET diagnostics to investigate mobile runtime behavior.
Conceptually:
The exact connection and collection workflow varies by platform and development environment.
Monitor Runtime Counters
Runtime counters can help identify whether an observed slowdown is related to:
CPU utilization
GC
Allocation
Threading
Exceptions
The important point is correlation.
For example:
A benchmark result becomes much more useful when you can explain why it changed.
Benchmark Memory After Navigation
A mobile application may appear efficient during startup but accumulate memory as users navigate.
Create a repeatable workflow:
Repeat the workflow several times.
Measure memory after each cycle.
If memory continuously increases, investigate whether the application has:
Event-handler leaks
Unreleased subscriptions
Cached images
Retained pages
Native resource leaks
Long-lived references
Do not automatically attribute memory growth to CoreCLR.
The runtime is only one part of the application.
Compare Equivalent Builds
The baseline and candidate should be as similar as possible.
For example:
| Variable | .NET 10 Baseline | .NET 11 Candidate |
|---|---|---|
| Application source | Same | Same |
| Device | Same | Same |
| OS | Same | Same |
| Build mode | Release | Release |
| Data | Same | Same |
| Network | Same | Same |
| Test workflow | Same | Same |
| Runtime | Baseline | CoreCLR |
This makes the runtime migration the primary experimental variable.
Test Real Application Flows
A benchmark based only on:
is not enough for a complex application.
Microsoft recommends exercising the complete application flow, including navigation, data loading, and platform-specific integrations.
A realistic workflow might be:
This exposes issues that a startup-only benchmark cannot detect.
Test Platform-Specific Integrations
.NET MAUI applications frequently use platform-specific capabilities.
Examples include:
Camera
Location
Notifications
Bluetooth
Files
Sensors
Media
Native SDKs
Test them separately.
For example:
A runtime migration can expose compatibility problems in libraries that depend on reflection, dynamic code generation, or runtime-specific behavior.
Microsoft specifically calls out third-party libraries using reflection, dynamic code generation, or Mono-specific APIs as areas that should be validated during the transition.
Review Reflection-Heavy Libraries
Reflection can be important for:
Dependency injection
Serialization
ORMs
Plugin systems
Dependency discovery
Native bindings
Audit libraries that dynamically inspect types.
For example:
The code may work under one runtime configuration but behave differently when trimming, AOT, or runtime assumptions change.
Do not assume a successful startup proves that all dynamically discovered types remain available.
Test the actual feature.
Review Dynamic Code Generation
Some libraries rely on:
These areas deserve additional testing when moving between runtime and compilation configurations.
If a third-party component documents runtime-specific requirements, follow the vendor's compatibility guidance.
CoreCLR and ReadyToRun
CoreCLR can use ReadyToRun (R2R) images to reduce some runtime compilation work.
Microsoft describes partial R2R and packaged PGO profiles as part of the .NET 11 mobile performance work.
Conceptually:
This can affect startup behavior, but the actual result depends on the application.
Therefore, measure startup rather than assuming R2R will produce a specific percentage improvement.
CoreCLR and PGO
Profile-Guided Optimization can use runtime behavior to improve generated code.
The simplified concept is:
Again, the correct engineering approach is measurement.
If your application has a different execution profile from the workload used to produce an optimization profile, the results may differ.
Compare Memory Under Load
Do not only measure memory immediately after launch.
Create defined checkpoints:
Then compare:
The resulting graph or table can reveal whether memory stabilizes or continually increases.
Do not claim a memory improvement unless the measurements support it.
Example Benchmark Table
A final article or engineering report can use a table such as:
| Metric | .NET 10 | .NET 11 CoreCLR | Difference |
|---|---|---|---|
| Cold startup | Measure | Measure | Calculate |
| Warm startup | Measure | Measure | Calculate |
| Package size | Measure | Measure | Calculate |
| Initial memory | Measure | Measure | Calculate |
| Memory after workflow | Measure | Measure | Calculate |
| Allocation rate | Measure | Measure | Calculate |
The numbers should come from your actual test environment.
For example, if baseline startup is 1,000 ms and the candidate is 900 ms:
Do not substitute hypothetical values into a production benchmark.
Automate the Benchmark
Manual measurements are useful for initial validation, but automation improves repeatability.
A benchmark harness can record:
The actual values should be populated by the measurement system.
Then compare baseline and candidate builds automatically.
Test on Multiple Devices
Mobile hardware varies significantly.
A single device cannot represent every target.
Where practical, test representative device classes:
For iOS, similarly test the device generations relevant to the application's supported deployment range.
The objective is not to benchmark every device.
It is to identify whether runtime behavior changes significantly across the supported hardware range.
Test Android and iOS Separately
Do not combine platform results.
Use:
Microsoft reports different performance characteristics across platforms during the CoreCLR transition. Its Preview 6 update states that iOS and Mac Catalyst are generally faster than Mono, while Android was within 10 percent of Mono for startup and app size in Microsoft's reported validation. These are Microsoft's observations, not a universal benchmark for every application.
Your application's results can differ.
Common Migration Problems
Startup Gets Worse
Do not immediately revert the migration.
Profile startup first.
Look at:
Microsoft has acknowledged reports of startup and package-size regressions in some larger Android applications during the preview transition.
Package Size Increases
Compare the complete packaged artifact.
Then inspect:
Determine whether the increase comes from the runtime or another dependency.
A Third-Party Library Stops Working
Check whether the library depends on:
Mono-specific APIs
Reflection
Dynamic code generation
Native bindings
Runtime assumptions
Then check the library's compatibility information.
Hot Reload Behaves Differently
Hot Reload and debugging have been actively evolving during the CoreCLR mobile transition.
Microsoft reports substantial progress in Preview 6 while noting that some scenarios remain in progress.
Do not use development-time tooling behavior as the only reason to reject a Release build migration.
Common Benchmarking Mistakes
Comparing Different Devices
Always use the same device when comparing two builds.
Comparing Debug With Release
Use Release builds for production-oriented performance measurements.
Measuring Only Startup
Startup is important, but it is only one part of mobile performance.
Measuring Only Memory
Memory should be evaluated alongside allocations, GC behavior, application state, and native resources.
Using One Run
One measurement can be affected by background processes, caches, thermal conditions, and other variables.
Changing Application Code During the Experiment
If you optimize the application between baseline and candidate measurements, the runtime is no longer the only variable.
Publishing Microsoft's Numbers as Your Own
Microsoft's published observations are useful context, but they should not be presented as a benchmark of your application.
A Practical Migration Benchmark Workflow
Use this sequence:
This approach produces evidence rather than assumptions.
Best Practices
Create a .NET 10 baseline before migration.
Use .NET 11 Release builds for comparison.
Test on real target devices.
Keep the test workload identical.
Measure cold and warm startup separately.
Measure package size.
Measure memory at multiple application states.
Use runtime diagnostics when investigating differences.
Test third-party libraries explicitly.
Test complete application flows.
Separate Android, iOS, and Mac Catalyst results.
Do not assume CoreCLR produces the same improvement for every application.
Record the exact SDK, runtime, device, and build configuration.
Do not publish benchmark numbers that you did not actually measure.
Frequently Asked Questions
Is CoreCLR now the default for .NET MAUI in .NET 11?
More precisely, as of .NET 11 Preview 6, CoreCLR is the only runtime for .NET MAUI mobile apps targeting Android, iOS, and Mac Catalyst. The previous Mono selection path has been removed for those targets in that preview.
Does this affect Blazor WebAssembly?
No.
Microsoft explicitly states that Blazor WebAssembly continues to use Mono and is not affected by this .NET 11 MAUI runtime transition.
Will CoreCLR automatically make my MAUI application faster?
No universal guarantee should be made.
Microsoft reports positive results in its validation, but also acknowledges application-specific regressions, particularly in some Android scenarios. The recommended approach is to measure your own application against its .NET 10 baseline.
What should I benchmark first?
Start with:
Cold startup
Warm startup
Package size
Initial memory
Memory after a representative workflow
Then investigate any meaningful differences with runtime diagnostics.
Should I benchmark an emulator?
An emulator can be useful for development and repeatable functional tests.
For production performance conclusions, prioritize real devices that represent your supported hardware.
Can I continue using Mono with .NET 11 Preview 6?
Microsoft's Preview 6 announcement states that CoreCLR is now the only runtime for .NET MAUI mobile applications on Android, iOS, and Mac Catalyst and that the previous Mono selection path has been removed.
Conclusion
The move from Mono to CoreCLR is one of the most significant runtime changes for .NET MAUI mobile applications.
As of .NET 11 Preview 6, CoreCLR is the only runtime for .NET MAUI Android, iOS, and Mac Catalyst applications. Microsoft has positioned the change around runtime unification, performance foundations, diagnostics, and the longer-term NativeAOT direction.
But the correct migration strategy is not:
It should be:
The most important metrics are not limited to startup time.
A meaningful CoreCLR migration benchmark should examine:
The key principle is simple:
Do not migrate to CoreCLR because a benchmark says mobile applications are faster. Migrate with evidence that CoreCLR works correctly and delivers acceptable behavior for your application, devices, and production workload.
The .NET 11 preview window provides an opportunity to establish that evidence before the final release. Microsoft is explicitly asking developers to test their applications now and report reproducible results, making application-specific benchmarking particularly valuable during this transition.
Windows Hosting Recommendation
