Em menos de um mês, a Microsoft encerrará o suporte para a primeira grande ferramenta de UI multiplataforma do .NET, o Xamarin Forms. Em vez de os desenvolvedores terem que criar interfaces de usuário separadas para Windows, iOS e Android, o Xamarin Forms nos forneceu um conjunto de controles de interface de usuário de plataforma cruzada que poderíamos usar para criar uma base de código compilada para todas as plataformas de destino, sem nenhum código específico do dispositivo. Foi um grande sucesso, mas agora está desaparecendo.
A Microsoft está desenvolvendo uma continuação do Xamarin Forms na forma de MAUI, a UI de aplicativo multiplataforma. MAUI oferece suporte a Windows, macOS, iOS e Android, permitindo novamente que você continue a desenvolver código usando as mesmas ferramentas e técnicas do Xamarin, trabalhando com as versões .NET mais recentes. MAUI ainda está em desenvolvimento, com algumas diferenças que tornam difícil simplesmente trocar um conjunto de controles por outro.
Você pode ver a comparação atual entre as duas plataformas no GitHub. Provavelmente, as diferenças mais importantes são a necessidade de mover o código para a plataforma .NET mais recente, com suporte do .NET 6 e superior, bem como a gama de diferentes modelos de aplicativos que são expandidos para incluir suporte para MVU e Blazor. O objetivo é fornecer um conjunto comum de recursos entre o MAUI e o Windows App SDK, para que você possa mover rapidamente o código somente do Windows para várias plataformas.
Um ponto importante a ser observado é que, mesmo que não haja suporte, você ainda precisará do Xamarin Forms para criar aplicativos para dispositivos iOS e Android mais antigos. Se dispositivos mais antigos não forem um alvo para você, considere mover seu código para MAUI ou para uma das estruturas alternativas de UI .NET de plataforma cruzada que estão agora disponíveis. Tanto a plataforma Uno quanto a Avalonia são ferramentas maduras que oferecem controles compatíveis com WinUI 3 e suportam muitos sistemas operacionais diferentes, incluindo Linux.
Mais opções que MAUI
A escolha é boa. A natureza de código aberto do .NET tornou-o uma plataforma atraente para extensões como Uno e Avalonia, ambas oferecendo diferentes abordagens para fornecer UIs multiplataforma, suportando diferentes modelos de aplicativos e fornecendo uma gama diferente de controles. Você pode escolher a ferramenta adequada à sua equipe e, se quiser experimentar uma nova, tudo o que você precisa fazer é configurar um novo branch em seu repositório e testá-lo.
A Microsoft fornece um guia para atualização do Xamarin para o MAUI. Embora a maioria dos cenários comuns sejam suportados, outros, como o watchOS, exigem que você crie novos aplicativos Swift nativos. Na prática, isso pode não ser necessário, pois as notificações avançadas do watchOS podem ser uma alternativa melhor para gerenciar uma estrutura de aplicativo totalmente nova.
Embora você possa mover projetos para o formato de projeto MAUI SDK manualmente, existe a opção de usar o próprio .NET Upgrade Assistant da Microsoft para iniciar o processo para você. É importante observar que, na maioria dos casos, isso não fornecerá um aplicativo pronto para ser compilado. Você terá que gastar tempo finalizando layouts e certificando-se de ter as bibliotecas certas.
Lançamentos recentes do MAUI abordaram muitos dos problemas anteriores, e a Microsoft está mantendo um roteiro aberto, bem como uma lista de correções no repositório MAUI GitHub. É certamente um projeto muito ativo e que está amadurecendo rapidamente.
Se você planeja usar uma das plataformas de UI alternativas, tanto o Uno quanto o Avalona oferecem seus próprios guias de migração, bem como estudos de caso mostrando como grandes clientes gerenciaram suas transições.
Escolhendo sua plataforma de UI
A maior diferença entre as plataformas Uno e Avalonia UI e MAUI é que MAUI é um wrapper para controles nativos. MAUI permite que você crie aplicativos nativos de aparência enquanto ainda usa o mesmo código, enquanto Avalonia e Uno também têm sua própria renderização. Essa abordagem garante um nível de consistência entre aplicativos em diferentes dispositivos de destino e facilita a portabilidade de controles para diferentes dispositivos e plataformas. Baseando-se no modelo WinUI do Windows, as plataformas Avalonia e Uno têm mais opções para estilizar controles.
Se você olhar a documentação de migração do Uno, há muitas coisas a considerar ao migrar, desde animações, controles, navegação e muito mais. No entanto, há semelhança suficiente entre como o Uno e o Xamarin Forms implementam o XAML para que você possa trabalhar em uma migração. No entanto, você não deve esperar que seja um processo que possa ser facilmente automatizado.
Por exemplo, se você estiver animando controles ou objetos, precisará migrar da classe de animação do Xamarin Forms para os Storyboards do WinUI 3. Os storyboards são baseados nas abordagens de animação introduzidas com o WPF nos primórdios do .NET e podem parecer familiares, pois têm sido usados na maioria das ferramentas de desenvolvimento de UI do Windows há mais de uma década. Vale a pena entender os equivalentes do Storyboard das operações de animação do Xamarin Forms e usá-los como parte de uma migração, enquanto trabalha em uma linha do tempo do Storyboard.
Uma diferença importante é como o WinUI 3 oferece suporte à navegação. O Xamarin Forms possui um modelo de página, com uma pilha que gerencia a navegação entre as páginas. Isso é substituído por um controle Frame que gerencia a navegação para frente e para trás em uma pilha de páginas. Embora esta seja uma abordagem mais flexível, existem alguns problemas decorrentes da herança do Windows do WinUI 3. Por um lado, não há suporte direto para botões de navegação de hardware, então você precisará adicionar seu próprio código para entregá-lo quando necessário. Você também precisa adicionar seus próprios controles de barra de navegação, embora, diferentemente do Xamarin Forms, uma navegação WinUI possa passar parâmetros para a nova página.
Existem pequenos problemas como esse que você deve gastar algum tempo trabalhando na documentação e nos tutoriais antes de tentar uma migração. No entanto, não existem obstáculos reais e existem soluções alternativas para a maioria dos problemas. Claro, há um outro lado da história, onde a migração simplifica algumas operações, permitindo reduzir a complexidade do código, facilitando a depuração.
Atualizações significam tudo
Na prática, qualquer abordagem escolhida para substituir o Xamarin Forms exigirá um trabalho significativo. Muito disso, porém, será devido à evolução da plataforma .NET além do Xamarin. A Microsoft trabalhou muito para garantir que o .NET tenha um bom desempenho em todas as plataformas de destino e, se você estiver criando aplicativos voltados para o usuário, vai querer aproveitar essas mudanças. Xamarin Forms agora é uma tecnologia legada e, como tal, irá atrasar você e seus usuários.
Ao migrar para uma estrutura de UI moderna, você está dando um passo em direção à preparação de seus aplicativos para o futuro. Isso significa oferecer aos usuários suporte para dispositivos mais recentes e, com o Wasm, suporte para aplicativos da web avançados que possuem muitos dos mesmos recursos dos aplicativos nativos de desktop e móveis. Tanto o Avalonia quanto o Uno possuem grandes bibliotecas de controles que vão além do que o Xamarin Forms poderia fazer, permitindo que você faça mais com seu código e com mais rapidez.
Se você adotar essa abordagem, poderá ver o fim da vida útil do Xamarin Forms como uma oportunidade de atualizar e reestruturar seu código, aproveitando os recursos mais recentes do .NET e os padrões de design mais recentes que podem ser mais adequados para seus aplicativos. Você pode até adicionar ferramentas de design modernas, como o Figma, ao seu conjunto de ferramentas, permitindo preencher as lacunas entre o design e o desenvolvimento, reduzindo atritos e garantindo um ambiente mais colaborativo.
O fim do suporte para Xamarin Forms não é uma coisa ruim para o .NET móvel e multiplataforma. Na verdade, isso mostra que o .NET moderno oferece muitas opções. E suas bases de código aberto permitem que você adicione seu próprio código para preencher quaisquer lacunas.
