A Microsoft encerrou o suporte ao Xamarin e ao Xamarin.Forms em 1º de maio de 2024. O caminho com suporte daqui para frente é o .NET MAUI (Multi-platform App UI), que é, de modo geral, o sucessor arquitetônico do Xamarin.Forms, com um tempo de execução .NET unificado e uma única estrutura de projeto. O discurso de marketing é "migração fácil". A realidade é mais sutil. Depois de várias migrações reais, este é o guia que usamos.
O que “migrar” realmente significa
A primeira decisão é definir o escopo com honestidade. Existem três projetos possíveis sobre uma base de código Xamarin.Forms existente, e de fora eles parecem quase idênticos:
- Migração mecânica. Converter os arquivos do projeto, trocar os namespaces, atualizar a sintaxe de binding e publicar. No melhor cenário: de 2 a 4 semanas para um app de porte médio.
- Migração com limpeza. O mesmo que acima, mais aposentar as partes que você já sabia que estavam frágeis (renderizadores personalizados que agora deveriam ser handlers do MAUI, navegação sob medida que agora deveria usar Shell, código assíncrono que vem rangendo). De 6 a 10 semanas.
- Migração como reescrita. A base de código acumulou mais de 5 anos de remendos, o arquiteto original saiu e a estratégia de testes é "a gente clica por tudo manualmente antes de cada versão". O MAUI é a sua desculpa para entregar uma base de código sustentável. De 12 a 24 semanas.
O erro que vemos com mais frequência é supor que o projeto é do primeiro tipo quando na verdade é do terceiro. Os sprints de descoberta existem por um motivo.
O que migra sem problemas
- Páginas XAML com controles padrão. Se suas views são em sua maioria Label, Button, Entry, ListView etc., o XAML é atualizado sem problemas. Alguns nomes de propriedades mudaram em certos pontos (a hierarquia FormattedText → FormattedString é a mesma; alguns caminhos de propriedades anexadas foram movidos). O .NET Upgrade Assistant detecta a maioria desses casos.
- ViewModels e serviços. C# puro: sua lógica de negócio, os bindings MVVM e o registro de DI geralmente passam sem alterações.
- Chamadas ao HttpClient e serialização JSON. Sem mudanças. (Se você ainda usa o Newtonsoft.Json, este é um bom momento para considerar o System.Text.Json, mas isso é um projeto à parte.)
O que não migra sem problemas
- Renderizadores personalizados. O modelo de renderizadores do Xamarin foi substituído pelos handlers do MAUI. O conceito é parecido, mas a superfície da API é diferente e o ciclo de vida é diferente. Planeje reescrever cada renderizador em vez de esperar uma troca de uma única linha.
- Effects. A mesma história: normalmente reconstruídos como personalização de handlers específica por plataforma.
- Controles de UI de terceiros. Se migram ou não depende do fornecedor. Telerik e Syncfusion lançaram versões para MAUI; fornecedores menores muitas vezes não lançaram. Faça o inventário das suas dependências com antecedência.
- Configuração de notificações push. A configuração nativa de iOS/Android mudou (especialmente com as mudanças do SDK do Firebase para iOS). Não presuma que o seu código de push existente "simplesmente funciona".
- Telas de abertura e ícones do app. O MAUI tem um modelo de recursos unificado (MauiSplashScreen, MauiIcon), bem melhor, mas é uma conversão única que pega as equipes de surpresa.
Decisões de arquitetura para tomar cedo
Shell vs. NavigationPage
Se o seu app Xamarin usa NavigationPage em todo lugar, você pode manter esse padrão no MAUI, mas o Shell é o padrão recomendado para apps novos e te dá muita coisa de graça (roteamento baseado em URL, flyout, busca). Para a maioria dos apps que migramos, a escolha certa é "fique no NavigationPage na v1 e planeje a mudança para o Shell na v2". Misturar os dois é confuso.
Projeto único vs. projetos cabeça
A estrutura de projeto único do MAUI (um só .csproj para iOS+Android+Windows+macOS) é o novo padrão. O Xamarin usava projetos cabeça separados por plataforma. A conversão é em sua maior parte mecânica, mas se você tem código específico de plataforma que ficava nos projetos cabeça, vai precisar realocá-lo nas pastas Platforms/. As equipes subestimam isso quando têm muita personalização nativa de AppDelegate ou MainActivity.
Versão mínima do iOS
A versão mínima de iOS no MAUI varia conforme a versão do .NET e o tipo de app, então confira a matriz atual de plataformas com suporte da Microsoft antes de se comprometer (as versões recentes de .NET MAUI / MAUI Blazor elevaram os mínimos para iOS 12.2 e iOS 16.4 respectivamente, e esse piso continua subindo). Se o seu app Xamarin dava suporte a versões mais antigas de iOS porque alguma base de clientes precisava, você terá uma conversa real sobre cortar esse suporte durante a migração.
Desempenho e inicialização
A inicialização do MAUI geralmente é mais rápida que a do Xamarin.Forms, especialmente no iOS. Mas há um ganho real a ser obtido com a compilação AOT adequada no iOS e as novas opções $(MtouchInterpreter). Não aceite o padrão; faça profiling e ajuste. Já vimos melhorias de inicialização de 30% a 50% só com o ajuste de flags de compilação que ninguém se deu ao trabalho de mexer.
Testes durante a migração
Se o seu app Xamarin tem poucos ou nenhum teste automatizado, esse é o problema maior que você vai trazer à tona. O MAUI não tem uma estratégia de testes dramaticamente melhor que a do Xamarin. Nós usamos:
- xUnit/NUnit para testes de ViewModel e de serviços (estes migram sem alterações)
- Appium ou os testes de UI com Hot Reload da versão de prévia do MAUI para ponta a ponta
- QA manual em uma matriz de dispositivos reais durante a virada da migração. A regra prática do Calvin: pelo menos um dispositivo por versão principal de sistema operacional com suporte
Estratégia de virada
Para apps de consumo, você publicará uma única build do MAUI que substitui a do Xamarin nas lojas. Para apps corporativos/B2B com uma frota de dispositivos conhecida (apps de representantes de vendas, ferramentas de armazém), já fizemos lançamentos paralelos por TestFlight / canal interno: você mantém o app Xamarin instalado enquanto um pequeno grupo piloto exercita a versão MAUI. Encontrou um bug? Corrige no MAUI sem atrapalhar os usuários em produção que ainda estão na build estável do Xamarin.
O custo oculto: as dependências de terceiros
O que estoura os orçamentos é a longa lista de bibliotecas de terceiros que você esqueceu que usava. O Xamarin teve mais de 10 anos de ecossistema de plugins; nem tudo tem sucessores compatíveis com MAUI. Antes de assinar uma migração por preço fechado, audite cada referência do NuGet. Qualquer coisa que não seja atualizada desde 2022 é um sinal de alerta.
A conclusão
Para a maioria dos apps, a migração é trabalho de verdade, não uma refatoração de uma semana: algo entre uma migração simples e uma reescrita parcial. A boa notícia: uma vez no MAUI, você está em uma plataforma com suporte, em desenvolvimento ativo e com futuro. A má notícia: ninguém mais está produzindo trabalho novo em Xamarin, então, mesmo que o seu app esteja "ok", o mercado de talentos para mantê-lo encolhe a cada trimestre.
Se você tem um app Xamarin e está tentando dimensionar a migração, mande um recado. Faremos uma auditoria real antes de orçar: é assim que evitamos a armadilha da “migração mecânica que virou reescrita”.