Nativo ou Flutter: o que decidiu em dois aplicativos que lançamos

Procure “Flutter ou nativo” em português e você encontra duas coisas: textos de desenvolvedor decidindo carreira, e listas de critérios de agência — orçamento, prazo de lançamento, experiência do usuário, prioridades. Tudo verdadeiro e nada acionável. Ninguém diz qual aplicativo construiu, de que jeito, e o que de fato decidiu.

O problema dessas listas é que elas tratam a escolha como um trade-off contínuo, em que se paga um pouco mais por um pouco mais de desempenho. Na prática, quase nunca é assim. Na maioria dos projetos a decisão é óbvia em dez minutos de conversa, e o que a torna óbvia não é o orçamento: é o que o produto precisa pedir ao sistema operacional.

Lançamos dois aplicativos em caminhos opostos — um em Flutter, um em Swift nativo — e em nenhum dos dois casos o custo foi o fator decisivo. Abaixo está o que foi.

O Livrify é uma rede de leitura. Feed, biblioteca em três listas, detalhe do livro, atualização de progresso, conversas, notificações. Descrito em termos de interface: listas, cartões, formulários e navegação por abas.

Nada disso se comporta de forma diferente entre iOS e Android. Uma lista rolável é uma lista rolável. Um formulário de cadastro é um formulário de cadastro. Quando esse é o produto inteiro, escrever duas vezes o mesmo aplicativo não compra qualidade nenhuma — compra dois lugares onde o mesmo bug pode aparecer com comportamentos ligeiramente diferentes.

O aplicativo roda em Flutter sobre Firebase: autenticação com e-mail, Google e Apple, Firestore para catálogo e feed, notificações, sincronização entre aparelhos. Uma base de código, duas lojas, e o mesmo comportamento nas duas — que num produto social importa mais do que parece, porque quem comenta no feed de iOS precisa ver exatamente o que quem publicou do Android enviou.

O Reset é um programa de recuperação de hábito compulsivo. Boa parte do valor está em uma função só: bloquear conteúdo e aplicativos nos momentos em que a pessoa decidiu, de antemão, que não quer acesso.

No iOS isso vive nas APIs de Tempo de Uso — FamilyControls, ManagedSettings, DeviceActivity. E elas não são uma biblioteca que se importa: são um conjunto de extensões de aplicativo, binários separados, com ciclo de vida próprio, que o sistema executa fora do processo do seu aplicativo. O Reset tem duas — uma que responde pelo bloqueio de conteúdo e outra que monitora atividade do aparelho — cada uma com o próprio Info.plist e as próprias permissões.

Flutter não roda ali. Não é uma questão de ser difícil ou de faltar um pacote: o motor do Flutter desenha a sua interface dentro do processo do aplicativo, e uma extensão de Tempo de Uso não é o seu aplicativo. Mesmo em um projeto Flutter, essa parte teria de ser escrita em Swift à parte — e quando o núcleo do produto é justamente essa parte, você tem um aplicativo nativo com uma casca multiplataforma em volta, que é o pior dos dois mundos.

Há ainda o pedaço que nenhum comparativo menciona: o direito de usar FamilyControls é concedido pela Apple mediante solicitação. Não basta marcar uma caixa no Xcode. É um processo com justificativa, análise e espera — e ele entra no cronograma do projeto como qualquer outra dependência externa.

Escrevemos o documento que permitiria a um time Android reconstruir o Reset do zero. Quase tudo mapeia sem drama: SwiftUI vira Jetpack Compose, Firebase Auth continua Firebase Auth, Firestore é o mesmo Firestore com o mesmo esquema, RevenueCat tem SDK dos dois lados, Remote Config idem. O backend é compartilhado, e usuários de iOS e Android conviveriam no mesmo banco sem nenhuma tradução.

Uma linha da tabela ficou diferente de todas as outras. Bloqueio de aplicativos e sites, no Android: sem equivalente direto. Não existe um análogo do Tempo de Uso que um aplicativo comum possa acionar. Dá para chegar perto com UsageStatsManager mais um serviço de acessibilidade, ou com uma VPN local que filtra tráfego — caminhos legítimos, com permissões diferentes, riscos de revisão diferentes e um comportamento que não é o mesmo.

Ou seja: o Reset em Android não é uma porta do Reset. É um segundo produto que compartilha backend e copy, com uma arquitetura própria para o único recurso que justifica o aplicativo existir. Isso é uma decisão de negócio, não de tecnologia — e é exatamente o tipo de coisa que precisa aparecer no escopo antes de alguém prometer “também para Android”.

O que o seu aplicativo precisa pedir ao sistema operacional?

Se a resposta for “basicamente nada” — mostrar conteúdo, aceitar entradas, sincronizar com um servidor, notificar — Flutter é uma escolha excelente e chegar às duas lojas ao mesmo tempo vale mais que qualquer ganho marginal de código nativo. É o caso da maioria dos produtos: comércio, conteúdo, cadastro, agendamento, comunidade.

Se a resposta envolver câmera em tempo real, áudio contínuo em segundo plano, sensores, widgets, extensões do sistema, integração com Saúde ou Carteira, ou qualquer API que rode fora do processo do seu aplicativo — a conversa muda. Nesses casos o nativo não é o caminho mais caro; é o único que existe, e descobrir isso no quarto mês custa um replanejamento inteiro.

Há um terceiro caso, o mais comum de todos na prática: o produto é 90% listas e 10% uma função que exige o sistema. Aí a pergunta certa não é “nativo ou Flutter”, é “essa função de 10% vale o dobro do custo de desenvolvimento?”. Às vezes vale. Muitas vezes, ao olhar de perto, ela pode esperar a segunda versão — e essa é uma conversa de escopo, não de tecnologia.

É comum ler que multiplataforma reduz o custo em até 40%. O número é plausível para a fase de construção, e engana quando lido como desconto no projeto inteiro.

Estratégia, pesquisa, design de fluxo, redação de interface, backend, publicação e a operação depois do lançamento não dobram porque existem duas plataformas — eles são feitos uma vez de qualquer jeito. O que dobra é a implementação da interface, que é uma parcela do total, não o total.

E há a conta do outro lado, que raramente aparece: cada plataforma tem sua revisão de loja, seu ciclo de versões do sistema operacional e seus aparelhos para testar. Duas lojas custam mais para manter mesmo com uma base de código só. Multiplataforma economiza escrita, não operação.