Projeto experimental não é base de app em produção: o caso do Mobile Blazor Bindings

O app de agendamento da clínica veterinária foi fechado em 2020 em cima do Mobile Blazor Bindings: componentes Razor gerando telas nativas, a equipe já sabia Blazor, o protótipo ficou pronto em duas semanas. Hoje, ninguém consegue atualizar o projeto sem quebrar a compilação, a base Xamarin por baixo perdeu o suporte e a loja de aplicativos exige um SDK mais novo. A palavra "experimental" estava no título da documentação desde o primeiro dia.

A resposta curta: experimental quer dizer que o autor não promete manutenção, compatibilidade nem continuidade. Use para aprender e para protótipo descartável. Para entregar a um cliente, escolha a tecnologia que o fornecedor declara suportada hoje e, se você já depende de algo experimental, planeje a migração agora, enquanto ainda escolhe o momento.

O que aconteceu com o Mobile Blazor Bindings

O Mobile Blazor Bindings foi um projeto da Microsoft para escrever apps móveis com a sintaxe do Blazor, usando o Xamarin.Forms por baixo. A própria documentação o apresentava como experimental, para coletar feedback, sem compromisso de virar produto suportado. As ideias que ele testou seguiram para o .NET MAUI, em especial o modelo Blazor Hybrid, em que componentes Razor rodam dentro de um BlazorWebView num app nativo.

O caminho foi o esperado para um experimento: ele cumpriu o papel e outro produto ficou com o lugar. O Xamarin, base do projeto, também chegou ao fim do suporte em 2024, substituído pelo .NET MAUI. Quem construiu produto em cima do experimento ficou com duas camadas sem futuro.

O ponto não é que a Microsoft errou. O aviso existia. O problema é a equipe tratar "compilou e funcionou" como sinal de que a tecnologia está pronta para o ciclo de vida de um app de cliente, que dura anos.

Como reconhecer que a base é instável

Os sinais costumam estar à vista, e quase sempre na primeira página:

• Rótulos explícitos: "experimental", "preview", "alpha", "sem suporte" na documentação ou no README.
• Versão de pacote com sufixo de pré-lançamento, como -preview ou -beta, ou versão abaixo de 1.0.
• Repositório arquivado no GitHub, ou sem commits relevantes há muito tempo.
• Pacote marcado como obsoleto no NuGet, muitas vezes com a indicação do substituto.
• Documentação apontando para outro produto como "o caminho recomendado".

Como sair de uma base experimental, passo a passo

1. Inventarie as dependências do projeto e o estado de cada uma: suportada, obsoleta, experimental.
2. Leia a página oficial de migração, se existir. Ela diz o que tem equivalente direto e o que precisa ser reescrito.
3. Separe o que é portátil do que é preso ao framework. Regras de negócio, acesso a API e validação geralmente migram quase sem mudança; telas, nem sempre.
4. Mova a lógica portátil para uma biblioteca de classes independente de interface, ainda no projeto antigo. Isso já reduz o tamanho da migração.
5. Crie o projeto novo na tecnologia suportada e traga uma tela de cada vez, começando pela mais usada.
6. Registre a decisão num documento curto, com data, alternativa escolhida e o motivo.
7. Agende uma revisão periódica das dependências para não repetir a história.

O inventário com a CLI do .NET

Na pasta da solução, três comandos dão o retrato das dependências NuGet:

# pacotes que o autor marcou como obsoletos, com o substituto quando informado
dotnet list package --deprecated

# pacotes com versão mais nova disponível
dotnet list package --outdated

# vulnerabilidades conhecidas, incluindo dependências indiretas
dotnet list package --vulnerable --include-transitive

# SDKs instalados na máquina
dotnet --list-sdks

Em projetos antigos baseados em Xamarin, parte desses comandos pode nem rodar com o SDK atual, o que já é uma resposta. Anote o resultado e a data; esse retrato é o ponto de partida do plano.

O que migra e o que reescreve

No app da clínica, a divisão ficou assim:

• Migra quase sem mudança: o cliente da API de agendamentos, os modelos, as validações de horário, a lógica de lembretes. Estavam em classes C# comuns.
• Reescreve: as telas. No Mobile Blazor Bindings, os componentes Razor usavam elementos que viravam controles nativos do Xamarin.Forms. No .NET MAUI Blazor Hybrid, os componentes Razor renderizam HTML dentro do BlazorWebView; a outra opção é escrever as telas em XAML do MAUI. Nenhum dos dois aceita o markup antigo como está.
• Revisa com cuidado: login, armazenamento seguro de token e notificações, que dependem de APIs da plataforma. O post sobre login no app MAUI pelo navegador do sistema e o sobre identidade no Blazor Hybrid cobrem essas partes.

Separar a lógica numa biblioteca antes de migrar é o que torna o trabalho previsível: a equipe reescreve só a camada de interface, e os testes das regras continuam passando dos dois lados.

O registro da decisão

Um arquivo curto no repositório evita que a próxima equipe repita a escolha sem saber do risco:

# docs/decisoes/2026-10-app-mobile.md
Data: 2026-10-17
Contexto: o app usa Mobile Blazor Bindings (experimental) sobre Xamarin.Forms,
sem suporte. Atualização de SDK exigida pela loja não compila.
Decisão: migrar para .NET MAUI com Blazor Hybrid, reaproveitando os componentes
de regra já extraídos para a biblioteca Clinica.Core.
Alternativas avaliadas: telas em XAML do MAUI; app web responsivo.
Consequências: telas reescritas; lógica e testes preservados.
Revisão das dependências: a cada seis meses.

Quando experimental é a escolha certa

Experimento tem lugar: aprender um conceito novo, validar uma ideia com usuários em poucas semanas, produzir um protótipo que será jogado fora. O cuidado é combinar isso por escrito. Se o protótipo vai para a loja, ele deixou de ser protótipo, e a base precisa ser revista antes. E não prometa ao cliente manutenção de uma tecnologia que o próprio autor não promete. Vale lembrar que a mesma lógica serve para tutoriais: um exemplo que dependia de um projeto descontinuado não é receita de hoje, como discute o post sobre resposta de fórum antigo não ser manual.

Erros comuns

• Ignorar o rótulo "experimental" porque compilou: o projeto para de evoluir e o app do cliente fica preso numa versão que não atualiza.
• Misturar regra de negócio com a camada de interface: na hora de migrar, tudo precisa ser reescrito em vez de só as telas.
• Adiar a migração até a loja exigir: o prazo passa a ser do outro, e a migração vira emergência.
• Trocar um experimento por outro: o próximo framework promissor sem suporte declarado repete o problema.
• Não registrar a decisão: a equipe seguinte não sabe do risco e amplia a dependência.
• Prometer manutenção de longo prazo sobre base experimental: o contrato fica com um compromisso que nenhum fornecedor sustenta.

Checklist

• Toda dependência principal tem o status conferido na documentação oficial.
• dotnet list package --deprecated foi rodado e o resultado está anotado.
• Regras de negócio estão numa biblioteca separada da interface.
• Existe uma página de migração lida e um plano com a ordem das telas.
• A decisão de tecnologia está registrada no repositório, com data.
• Há uma data marcada para revisar as dependências de novo.
• Contrato e proposta não prometem suporte que o fornecedor não oferece.

Abra a documentação da biblioteca mais importante do seu app agora. Ela ainda é chamada de experimental ou de preview, ou você parou de olhar desde o dia em que compilou?