.NET 11, CoreCLR and Google Play’s DEX Optimization: What .NET MAUI Developers Need to Know

Google Play is introducing more visibility around Android application quality, including 16 KB page-size support and DEX code optimization. For .NET MAUI developers, this raises an interesting question: Does moving to .NET 11 and CoreCLR automatically improve the DEX optimization score reported by Google Play?

The short answer is: Not directly. .NET 11 brings important improvements to .NET MAUI Android applications, including CoreCLR, ReadyToRun, and improved trimming. However, Google Play's DEX optimization metric is primarily related to the Android DEX pipeline and should be considered separately from .NET runtime optimization. Let's break this down.

What is changing in .NET MAUI with .NET 11?

One of the significant changes in .NET 11 is the move toward CoreCLR as the default runtime for .NET MAUI applications. Microsoft's official documentation states that CoreCLR is the default runtime for .NET MAUI applications in .NET 11.

For Android Release builds, CoreCLR also uses composite partial ReadyToRun by default. This changes the runtime and compilation model compared with previous MAUI releases.

The relevant technologies include:

• CoreCLR
• ReadyToRun
• IL trimming
• Android-specific trimming improvements
• NativeAOT as an optional deployment model

These changes can affect startup performance, application size, and runtime behavior. However, they should not be confused with Google's DEX optimization metrics.

CoreCLR and DEX are different layers

A useful way to understand the architecture is:

.NET MAUI Application
│
├── C# / .NET code
│   │
│   ├── CoreCLR
│   ├── ILLink / Trimming
│   └── ReadyToRun
│
└── Android platform integration
    └── Java/Kotlin / Android code
        └── DEX
            └── R8

CoreCLR operates primarily on the .NET runtime side. R8 operates on the Android/DEX side.

Therefore: .NET 11 + CoreCLR ≠ automatic R8 optimization

Upgrading a MAUI application from an older .NET version to .NET 11 does not automatically mean that Google Play will report a high DEX optimization percentage.

What exactly is Google Play measuring?

Google has introduced a DEX code optimization metric in Play Console. According to Google's Android documentation, the metric applies to applications with at least 10 MB of uncompressed DEX code.

Google evaluates aspects including:

• DEX optimization
• Code shrinking
• Code obfuscation

Google currently specifies a 25% minimum threshold for the relevant optimization metrics.

This is separate from:

• Target SDK
• 64-bit support
• 16 KB page-size support
• .NET trimming
• CoreCLR
• ReadyToRun

These are related to Android application quality, but they are not the same measurement.

What about 16 KB page-size support?

This is another area that can easily become confused with DEX optimization. Android's 16 KB page-size requirement primarily concerns native libraries.

For example: lib*.so

Native libraries must be compatible with devices using 16 KB memory pages.

DEX optimization, on the other hand, concerns:

• classes.dex
• classes2.dex
• classes3.dex
• ...

So an application can simultaneously have:

• 16 KB page-size support ✅
• Target SDK 36 ✅
• 64-bit architectures ✅
• DEX optimization ⚠️ Low

There is no contradiction. They represent different parts of the Android build.

Does .NET 11 improve application size?

Potentially, yes. This is where .NET 11 becomes interesting.

Microsoft has made improvements to Android trimming in .NET 11. The Android trimmer can remove unused code more effectively, including improvements around Android-related managed types. This can reduce the amount of code included in an application.

However, application size and DEX optimization are not interchangeable measurements.

For example:

.NET trimming ↓
Remove unused .NET code
↓ Smaller managed application

while:

R8 ↓
Analyze Android bytecode
↓ Shrink / optimize / obfuscate DEX

Both are valuable, but they operate at different stages.

ReadyToRun is another separate concept. .NET 11 Android Release builds use composite partial ReadyToRun with CoreCLR by default. ReadyToRun precompiles portions of .NET code to improve startup performance.

But ReadyToRun should not be interpreted as a DEX optimization mechanism. In fact, precompiled code can introduce a size trade-off because additional native code may be included.

Therefore: ReadyToRun is primarily a runtime/startup optimization, not a Google Play DEX optimization mechanism.

This distinction becomes important when analyzing application size and Play Console metrics.

What should MAUI developers do about "DEX optimization: Low"?

Don't immediately change your entire MAUI build configuration. First, determine what Google Play is actually measuring.

If your Play Console reports:

DEX Code Optimization: Low

start by inspecting the actual Android App Bundle.

For example:

unzip -l MyApp.aab | grep -E '\.dex$'

You can also calculate the total DEX size:

unzip -l MyApp.aab \
| grep -E '\.dex$' \

By Niladri