MAUI переходит на CoreCLR по умолчанию на Android, iOS и Mac Catalyst в .NET 11 Preview 4

Microsoft переключила среду выполнения MAUI по умолчанию на CoreCLR в .NET 11 Preview 4, выпущенном 13 мая 2026 года. Новые проекты MAUI, нацеленные на Android, iOS, Mac Catalyst и tvOS, теперь работают на той же среде выполнения, которая обеспечивает работу ASP.NET Core и консольных приложений на десктопе. Mono больше не является неявным выбором для мобильных платформ. Это самое крупное единичное архитектурное изменение в MAUI со времён слияния с Xamarin, и оно тихо приходит за флагом по умолчанию.

Если вы следите за мобильной историей .NET 11, это опирается на появление dotnet watch для MAUI на Android и iOS в той же предварительной версии.

Почему CoreCLR на телефоне имеет значение

Около десятилетия Xamarin, а затем MAUI работали на Mono на мобильных платформах, потому что у CoreCLR не было рабочей AOT-истории для мобильных целей ARM. Mono поставлял собственный AOT-компилятор, GC, JIT, профилировщик и отладчик. Каждое вложение Microsoft в инструменты CoreCLR (многоуровневая компиляция, динамический PGO, движок регионов Server GC, ReadyToRun) приходилось переделывать заново или пропускать на мобильных платформах.

Переход на CoreCLR схлопывает это. Мобильный MAUI теперь получает тот же JIT, GC и поверхность диагностики, что и Linux-контейнер, выполняющий ASP.NET Core. Цифры запуска от Microsoft положительны для базовых шаблонов с ReadyToRun и PGO, но анонс честно говорит о регрессиях в более крупных приложениях на Android и просит команды измерять в режиме Release на реальных устройствах, прежде чем считать выигрыш бесплатным.

Другая причина, почему это важно: CoreCLR на Android разблокирует NativeAOT для MAUI, что в публикации называется “естественным следующим шагом”.

Что отключается по умолчанию

CoreCLR на мобильных платформах сбрасывает некоторые платформы, которые тащил Mono:

• Android x86 ушёл.
• Android API 23 и ниже ушёл.
• Embedding-API Android (путь, которым пользовалось большинство авторов библиотек Xamarin.Android) ушли.
• Android arm32 “всё ещё на рассмотрении”.
• Blazor WebAssembly не затронут. WASM остаётся на Mono, потому что у CoreCLR нет цели WebAssembly.

Если ваше приложение или любая транзитивная зависимость NuGet полагается на embedding-API или поставляемые бинарники для x86, обновление сломается на этапе сборки или загрузки, а не во время выполнения в продакшене.

Как отключить

Одно свойство MSBuild возвращает затронутые target frameworks на Mono:

<PropertyGroup Condition="'$(TargetFramework)' == 'net11.0-android'">
  <UseMonoRuntime>true</UseMonoRuntime>
</PropertyGroup>

Уберите Condition, чтобы откатить все платформы. Относитесь к этому как к временному запасному выходу. Microsoft не обязалась поставлять Mono для мобильного MAUI за пределами жизненного цикла .NET 11, а анонс представляет это свойство как способ разблокировать релиз, пока вы заводите issue о регрессии, а не как долгосрочный вариант конфигурации.

Что действительно стоит сделать на этой неделе

Три вещи стоит сделать сейчас, пока это всё ещё предварительная версия:

1. Соберите приложение на .NET 11 Preview 4 и проверьте сбои из-за выпавших платформ.
2. Запустите Release-сборку на репрезентативном Android-устройстве начального уровня и сравните холодный старт, тёплый старт и размер APK с тем же приложением, собранным на .NET 10. Сообщения сообщества включают как выигрыши, так и регрессии, поэтому общие цифры не предскажут поведение вашего приложения.
3. Если вы зависите от библиотеки Xamarin.Android, к которой годами не прикасались, проверьте, использует ли она embedding-API. Если да, она не загрузится на CoreCLR, и вам нужна замена до того, как поезд GA уйдёт.

Это такое изменение, которое выглядит хорошо в бенчмарках и тихо ломает продакшен через шесть месяцев, когда транзитивная зависимость оказывается только на Mono. Лучше узнать об этом во время предварительной версии.