.NET MAUI migra para o CoreCLR no .NET 11
O CoreCLR no .NET MAUI passa a ser o runtime padrão a partir do .NET 11 Preview 4 para aplicações Android, iOS, Mac Catalyst e tvOS. Essa é uma das mudanças mais significativas da plataforma desde a sua criação, porque unifica o ambiente de execução em toda a stack .NET.
Neste artigo, explico de onde veio o Mono, por que a Microsoft decidiu trocar de runtime e o que você precisa medir antes de levar essa mudança para produção.
O legado do Mono
Por mais de 15 anos, o Mono foi o runtime que levou o .NET a plataformas para as quais ele não foi projetado originalmente. Miguel de Icaza iniciou o projeto em 2001 para levar o .NET ao Linux. A partir daí, o Mono cresceu de formas que ninguém previu completamente.
O MonoTouch chegou ao iPhone em 2009. Em seguida, o MonoDroid levou a mesma ideia ao Android em 2011.
A Xamarin transformou esses experimentos em uma plataforma que milhões de desenvolvedores usaram para entregar aplicativos móveis em produção. Quando a Microsoft adquiriu a Xamarin em 2016 e iniciou a jornada em direção ao .NET MAUI, o Mono sustentava toda a operação.
O impacto do Mono vai muito além dos produtos da Microsoft.
O Unity construiu seu runtime de scripting sobre o Mono. Já o Avalonia e o Uno Platform usam o Mono no WebAssembly para entregar aplicações no navegador.
Além disso, o MonoGame carrega o legado do XNA para o desenvolvimento de jogos em todas as plataformas. O Godot também oferece um backend de scripting em C# alimentado pelo Mono.
Esse é um ecossistema vasto, e tudo remonta à mesma fundação.
O que muda com o CoreCLR no .NET MAUI
Quando você compila uma aplicação .NET MAUI para o .NET 11, o CoreCLR passa a ser o runtime padrão para builds de Release e Debug no Android, iOS e Mac Catalyst. O anúncio saiu no blog oficial do .NET em maio de 2026, assinado por David Ortinau.
No entanto, essa transição não acontece em terreno completamente novo. O CoreCLR já roda no Windows, no Linux e no macOS, e o .NET 10 já permitia testar o CoreCLR no Android como recurso experimental.
O que há de novo no .NET 11 é a extensão desse runtime para as últimas plataformas do .NET MAUI que ainda rodavam sobre o Mono. Por isso, a mudança tem um peso simbólico grande.
Alguns pontos precisam de esclarecimento:
- A mudança vale para Android, iOS, Mac Catalyst e tvOS.
- O Blazor WebAssembly continua usando o Mono, e isso não muda no .NET 11.
- No Preview 4, ainda era possível voltar para o Mono caso surgissem problemas durante a transição.
Por que a Microsoft escolheu o CoreCLR
Três razões motivaram essa mudança, e todas giram em torno de simplificar a plataforma.
Unificação do runtime com o CoreCLR no .NET MAUI
Até agora, aplicações móveis .NET rodavam sobre o Mono, enquanto servidor, desktop e nuvem rodavam sobre o CoreCLR. Essa divisão significava comportamentos distintos de JIT, características diferentes do garbage collector e ferramentas de diagnóstico separadas.
Com o CoreCLR no .NET MAUI, uma aplicação móvel passa a rodar no mesmo runtime que o backend. Na prática, um bug de runtime deixa de ter duas superfícies diferentes para investigar.
Base para melhor desempenho
O CoreCLR no .NET MAUI traz para o ambiente móvel a compilação JIT em camadas (tiered JIT), a pré-compilação ReadyToRun (R2R) e a otimização guiada por perfil (PGO). Isso inclui R2R parcial por padrão e perfis PGO empacotados, que melhoram o tempo de inicialização sem nenhuma alteração no código.
NativeAOT em todas as plataformas
Além disso, o CoreCLR no .NET MAUI também é a fundação da compilação NativeAOT, que produz binários nativos completamente compilados antes da execução. Com ele como padrão, o caminho para o NativeAOT no Android se abre como um próximo passo natural.
No iOS e no Mac Catalyst, o NativeAOT se apoia na compilação antecipada que as plataformas Apple sempre exigiram. Agora, porém, com uma cadeia de ferramentas mais unificada.
As estratégias de compilação do CoreCLR no .NET MAUI
Para compreender o impacto do CoreCLR no .NET MAUI, é preciso entender as estratégias de compilação disponíveis no ecossistema. A página de runtimes e compilação no .NET MAUI detalha cada uma delas.
JIT e Mono AOT
A compilação JIT (Just-In-Time) converte o MSIL em código nativo em tempo de execução, conforme o app chama cada método pela primeira vez. Ela favorece ciclos rápidos de build, deploy e debug, incluindo o Hot Reload.
Antes do CoreCLR no .NET MAUI, o Mono AOT pré-compilava o MSIL em código nativo durante o build, usando o compilador AOT do Mono. Esse era o modo padrão para builds de Release do .NET MAUI no iOS, no Mac Catalyst e no Android.
Vale notar que Mono AOT não é o mesmo que NativeAOT. Com o Mono AOT, a aplicação ainda inclui o runtime Mono e pode recorrer ao interpretador para código que não passou pela compilação antecipada.
ReadyToRun e PGO
O ReadyToRun é uma forma de compilação AOT do CoreCLR que gera assemblies com o MSIL original e uma representação em código nativo. Na inicialização, o runtime usa o código pré-compilado em vez de compilar o MSIL com o JIT, o que reduz o tempo de startup.
No Android, o CoreCLR no .NET MAUI usa por padrão o ReadyToRun parcial composto nos builds de Release. Segundo a documentação do .NET 11, a propriedade MauiEnableFullReadyToRun ativa o modo completo, embora isso aumente o tamanho do pacote.
A PGO, por sua vez, usa dados de perfil para orientar o compilador. O .NET MAUI distribui arquivos .mibc com os métodos mais chamados durante uma inicialização típica, e o compilador R2R usa esses perfis para decidir o que pré-compilar.
No iOS e no Mac Catalyst, as regras da Apple proíbem gerar código dinamicamente. Por isso, o CoreCLR no .NET MAUI usa ali um interpretador para executar o código que não foi pré-compilado.
NativeAOT
O NativeAOT compila toda a aplicação, suas dependências e um runtime mínimo em um único binário nativo durante o build. Não existe compilador JIT nem interpretador em tempo de execução.
Por isso, esse modelo produz os menores pacotes e os tempos de inicialização mais rápidos. Em contrapartida, ele impõe restrições sobre os padrões de código, já que tudo precisa ser compatível com trimming e AOT.
Desempenho do CoreCLR no .NET MAUI na prática
A equipe do .NET foi direta sobre o que esperar. O CoreCLR no .NET MAUI com R2R e PGO mostra melhorias significativas para muitas aplicações, especialmente no tempo de inicialização, e um app criado com dotnet new maui inicia de forma visivelmente mais rápida.
No entanto, a comunidade já reportou regressões em aplicações maiores e mais complexas no Android. Há casos documentados em que o tempo de startup ou o tamanho do aplicativo aumentou.
No iOS, a equipe validou o CoreCLR no .NET MAUI com submissões bem-sucedidas na App Store. Mesmo assim, a recomendação continua sendo medir o comportamento de cada aplicação individualmente.
A orientação oficial é clara: meça a sua aplicação. Compile com o Preview 4 em modo Release, teste em dispositivos físicos e compare startup e tamanho do pacote contra o baseline do .NET 10.
Para referência, a documentação do .NET MAUI 10 traz benchmarks de um app dotnet new maui, com tempos de inicialização em milissegundos:
| Runtime | Android | iOS | macOS |
|---|---|---|---|
| Mono (padrão) | ~642 | ~275 | ~311 |
| NativeAOT | ~274 | ~130 | ~255 |
Esses números ilustram diferenças relativas entre runtimes e não representam garantias, porque dependem do hardware. Ainda assim, eles mostram o potencial de ganho quando o NativeAOT estiver maduro em todas as plataformas.
O conteúdo de um APK com CoreCLR
A estrutura interna de um pacote Android muda conforme o runtime escolhido. Entender essa diferença ajuda a investigar variações de tamanho.
Com o Mono, o APK contém libmonosgen-2.0.so como runtime e libmonodroid.so como código de inicialização. Além disso, ele carrega os assemblies MSIL compactados e as imagens nativas do Mono AOT nos builds de Release.
Com o CoreCLR no .NET MAUI, a estrutura inclui libcoreclr.so como runtime, libclrjit.so como compilador JIT e libmonodroid.so para a inicialização. Os assemblies MSIL seguem empacotados junto com as imagens ReadyToRun.
Com o NativeAOT, o APK contém apenas o classes.dex e uma única biblioteca nativa com o nome do app. Essa biblioteca reúne o runtime, o código gerenciado e o código de inicialização.
Como reverter para o Mono no Preview 4
Caso um problema bloqueante surgisse no Preview 4, a equipe permitia voltar temporariamente para o Mono enquanto as correções avançavam. Bastava adicionar a seguinte propriedade ao arquivo de projeto:
<!-- Volta temporariamente para o runtime Mono (válido no .NET 11 Preview 4) -->
<PropertyGroup>
<UseMonoRuntime>true</UseMonoRuntime>
</PropertyGroup>
Essa opção funcionava para Android, iOS e Mac Catalyst. Ao usá-la, a equipe pedia uma issue em dotnet/android ou dotnet/macios.
Na issue, informe o tipo de aplicação, o tamanho do pacote, os tempos de startup e, se possível, uma amostra reproduzível.
Atenção a um detalhe importante: a documentação mais recente do .NET MAUI 11 informa que o Mono não tem suporte no .NET 11.
Além disso, definir UseMonoRuntime como true passa a gerar erro de build.
Portanto, trate esse escape como algo restrito ao período de preview. Se o seu app depende dele, o momento de investigar o problema e reportar é agora.
Checklist de validação do CoreCLR no .NET MAUI
Para garantir que o CoreCLR no .NET MAUI não introduza regressões inesperadas, a equipe do .NET recomenda o seguinte processo:
- Compilar e publicar a aplicação em modo Release com alvo no .NET 11.
- Medir o startup em dispositivos físicos, tanto cold start quanto warm start.
- Comparar o tamanho do pacote (APK ou AAB no Android e IPA no iOS) com o build do .NET 10.
- Testar o fluxo completo da aplicação, incluindo navegação, carregamento de dados e integrações de plataforma.
- Verificar o funcionamento do Hot Reload no fluxo de desenvolvimento.
- Validar bibliotecas de terceiros que usam reflexão, geração dinâmica de código ou APIs específicas do Mono.
Os comandos abaixo ajudam a preparar o ambiente e gerar os pacotes de Release para comparação:
# Instala a workload do .NET MAUI no SDK do .NET 11 Preview 4
dotnet workload install maui
# Gera o pacote Android em Release para medir tamanho e startup
dotnet publish -f net11.0-android -c Release
# Gera o pacote iOS em Release para comparar com o build do .NET 10
dotnet publish -f net11.0-ios -c Release
Algumas plataformas, porém, ficaram de fora do suporte do CoreCLR no .NET MAUI 11. Android x86, Android API 23 e anteriores, além das APIs de embedding, não entram, e a equipe ainda avaliava o suporte para Android arm32.
Diagnósticos do CoreCLR no .NET MAUI
Um dos benefícios imediatos do CoreCLR no .NET MAUI é o acesso às ferramentas de diagnóstico do .NET em dispositivos móveis. As mesmas ferramentas dotnet-trace e dotnet-counters usadas em servidores e desktops passam a funcionar no Android e nos fluxos de iOS e Mac Catalyst.
# Instala as ferramentas globais de diagnóstico do .NET
dotnet tool install --global dotnet-trace
dotnet tool install --global dotnet-counters
Isso representa uma mudança significativa para quem antes precisava recorrer a ferramentas específicas de cada plataforma. Além disso, a equipe citou o dotnet-dump como próxima ferramenta em avaliação.
Propriedades MSBuild de runtime e compilação
A tabela abaixo resume as propriedades MSBuild que controlavam o comportamento de runtime e compilação no período do Preview 4:
| Propriedade | Descrição | Padrão |
|---|---|---|
PublishAot |
Habilita a compilação NativeAOT | false |
PublishReadyToRun |
Habilita a pré-compilação R2R para CoreCLR | true (Release em plataformas CoreCLR) |
PublishTrimmed |
Habilita o trimming com ILLink | true (Release) |
TrimMode |
Define o nível do trimming (partial ou full) |
partial |
UseInterpreter |
Habilita o interpretador Mono | true (Debug no iOS e Mac Catalyst com Mono) |
UseMonoRuntime |
Usa o Mono em vez do CoreCLR | true no .NET 10, false no .NET 11 |
Por exemplo, para testar o NativeAOT e o trimming completo em um projeto, você combinaria as propriedades assim:
<!-- NativeAOT só tem efeito no dotnet publish e já aplica trimming completo -->
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<PublishAot>true</PublishAot>
</PropertyGroup>
Se você trabalha com listas grandes, vale revisar também o artigo sobre CollectionView no .NET MAUI, já que o desempenho de rolagem costuma revelar regressões de runtime.
O caminho do CoreCLR no .NET MAUI até o GA
Para o CoreCLR no .NET MAUI, o Preview 4 marca o início da validação ampla, não o fim do refinamento. Nos previews seguintes, a equipe prometeu fechar as lacunas de startup e tamanho em aplicações complexas e expandir a cobertura de R2R e PGO.
Além disso, o plano inclui resolver problemas de compatibilidade levantados pela comunidade e avançar o NativeAOT no Android, que segue experimental. O trabalho acontece nos repositórios dotnet/android e dotnet/macios.
O lançamento GA do .NET 11 está previsto para novembro de 2026. Até lá, o feedback durante os previews define o que a equipe vai priorizar.
Para acompanhar o restante das novidades dessa versão, confira o artigo sobre o lançamento do .NET 11 Preview 4.
Conclusão
A adoção do CoreCLR no .NET MAUI com o .NET 11 é uma mudança estrutural que elimina uma das últimas divisões do ecossistema .NET. Aplicações móveis passam a compartilhar o mesmo runtime de servidores, desktops e serviços de nuvem.
Na prática, isso significa comportamentos previsíveis, ferramentas unificadas e uma base sólida para avanços como o NativeAOT no Android. Ainda assim, a recomendação continua a mesma: meça, compare e reporte.
Afinal, o Mono provou que o .NET poderia ir a qualquer lugar. O CoreCLR é o capítulo seguinte dessa história, agora com uma base mais robusta e unificada para o futuro.
FAQ
O que é o CoreCLR e por que ele importa para o .NET MAUI?
O CoreCLR é o Common Language Runtime do .NET usado em servidor e desktop. No .NET MAUI, ele unifica o runtime da stack, traz diagnósticos completos e prepara o terreno para o NativeAOT.
O Blazor WebAssembly também vai migrar para o CoreCLR?
Não no .NET 11. O Blazor WebAssembly continua usando o Mono, e a migração do WASM segue em andamento fora deste ciclo de release.
Minhas bibliotecas de terceiros vão continuar funcionando?
Na maioria dos casos, sim. Bibliotecas que dependem de APIs específicas do Mono, geração dinâmica de código ou comportamentos do Mono AOT podem precisar de ajustes.
Meu aplicativo vai ficar maior com o CoreCLR?
Depende da estratégia de compilação, porque o ReadyToRun inclui MSIL e código nativo. Com NativeAOT, o pacote tende a ficar bem menor, então meça e compare com o .NET 10.
Como instalo o .NET 11 Preview 4 para testar?
Instale o SDK do .NET 11 Preview 4 e rode dotnet workload install maui. Em seguida, compile contra net11.0-android, net11.0-ios ou net11.0-maccatalyst.
O tvOS também usa o CoreCLR no .NET 11?
Sim. O tvOS entra na migração junto com Android, iOS e Mac Catalyst.
O Hot Reload continua funcionando com o CoreCLR?
Sim. O CoreCLR suporta Hot Reload via Edit and Continue sem o interpretador Mono, mas a implementação nas novas plataformas ainda é jovem e pode ter problemas conhecidos.