Em meados da década de 2010, uma abordagem impôs-se no desenvolvimento móvel: o híbrido. Um site encapsulado numa camada nativa, via Cordova, Ionic ou PhoneGap. Era rápido de produzir, corria em iOS e Android com uma só base de código, e para muitas empresas fez muito bem o trabalho.
Dez anos depois, estas aplicações envelheceram muitas vezes bem no plano funcional — e mal no plano técnico. Se reconhece a sua app, eis como sair dela sem estragos.
Os sintomas de uma app híbrida em fim de vida
- O deslocamento das listas não tem a fluidez de uma aplicação nativa — parece «lento» face à concorrência.
- Cada atualização do iOS ou do Android passa a ser um risco: a camada de encapsulamento depende de componentes que já não são verdadeiramente mantidos.
- Os plugins do ecossistema vão sendo abandonados uns atrás dos outros.
- Encontrar um programador que ainda aceite trabalhar nela torna-se difícil.
Nenhum destes sintomas é bloqueante isoladamente. Juntos, anunciam o dia em que uma simples atualização do sistema operativo parte a aplicação — e é preciso refazê-la à pressa, sem orçamento previsto.
As duas más respostas
Não fazer nada, na esperança de que aguente. Aguenta — até ao dia em que deixa de aguentar, no pior momento possível.
Recomeçar do zero, com uma nova aplicação e um novo identificador nas lojas. É a armadilha mais cara: perde todo o histórico — as avaliações, o posicionamento, o número de instalações. Os seus utilizadores têm de descarregar uma nova app. Muitos nunca o farão. Não está a migrar a sua aplicação: está a afundá-la e a lançar outra.
A resposta certa: reescrever sem que o utilizador dê por isso
O verdadeiro objetivo de uma migração não é «reescrever a aplicação». É reescrever a aplicação mantendo a sua identidade. Concretamente:
- Mesmo identificador, mesma app nas lojas. Não se cria uma nova ficha: publica-se uma atualização da existente. O histórico, as avaliações e o parque instalado são preservados.
- Continuidade de versão. Numa migração de uma aplicação de programação televisiva que conduzimos, a última versão híbrida tinha o número 3.1.8; a primeira versão Flutter saiu como 3.2.0. Do ponto de vista do utilizador, é mais uma atualização — não uma rutura.
- Paridade funcional primeiro, melhorias depois. Reconstrói-se o que existe de forma idêntica, entrega-se, e só depois se capitaliza no nativo para melhorar o que o merece.
A parte difícil de uma migração técnica quase nunca é técnica. O que exige método é não fazer os utilizadores pagar a transição.
Porquê Flutter
O Flutter impôs-se como o alvo natural destas migrações, por boas razões:
- Uma só base de código para iOS e Android, como o híbrido — mas com desempenho nativo real, não uma webview disfarçada.
- Uma renderização fluida: a interface é desenhada diretamente, sem depender do navegador embutido.
- Um ecossistema vivo e mantido, apoiado pela Google, com uma comunidade ativa — o exato oposto da situação de que foge.
Não é a única escolha possível (o nativo puro continua pertinente em alguns casos), e é precisamente o papel de uma fase de consultoria e arquitetura: decidir com base no seu contexto real e não na moda.
Quando migrar?
O momento certo é antes da avaria, não depois. Enquanto a aplicação funciona, a migração pode fazer-se com serenidade, por etapas, sem pressão. Depois de uma atualização do sistema a ter partido, já não tem o luxo da calma nem o do orçamento controlado.
Se a sua aplicação móvel assenta em Cordova, Ionic ou PhoneGap e começa a sentir estes sinais, é a altura de falar — não daqui a seis meses.
É exatamente o tipo de projeto que conduzimos em desenvolvimento de aplicações móveis. Vamos falar da sua aplicação: primeira conversa gratuita, e um diagnóstico claro sobre o que uma migração implicaria para si.