Flutter ou React Native: o que usamos e por quê

A pergunta aparece sempre que alguém pergunta sobre a stack do Lima: por que Flutter e não React Native? O React Native melhorou de verdade. A nova arquitetura (JSI, Fabric) corrigiu a latência do bridge que costumava ser o principal argumento contra ele. O bridge JavaScript não é mais o gargalo que era em 2020. Então a escolha é menos óbvia do que parece.

Aqui está onde chegamos e por quê.

Flutter controla os pixels

Flutter renderiza tudo com seu próprio engine (Impeller, agora o padrão no iOS e Android). React Native renderiza componentes nativos, o que significa comportamento específico por plataforma, bugs específicos por plataforma e às vezes diferenças visuais entre iOS 17 e Android 14 que você não pediu.

Para a grade de hábitos do Lima: 84 quadrados por usuário, gap específico, border-radius específico, animação específica. O Impeller simplesmente desenha. Em todos os dispositivos, em todas as versões de OS. Não há negociação com o UIKit ou o sistema de Views do Android. O que você constrói é o que é entregue.

Essa propriedade se multiplica. Cada componente customizado, cada animação, cada transição: o resultado é previsível. Quando algo quebra, você está olhando para o seu próprio código, não para uma diferença de renderização de plataforma que existe numa versão de OS e não em outra.

Dart não é o problema que as pessoas pensam

A objeção padrão ao Flutter é Dart. Ninguém quer aprender outra linguagem. Isso é real. Mas Dart tem tipagem, é moderno e familiar para quem conhece TypeScript ou Kotlin. A curva de aprendizado é mais íngreme que JavaScript mas mais suave que Swift ou Kotlin completo com coroutines. Nossa experiência: produtivo em cerca de uma semana, confortável em um mês.

A vantagem de linguagem do React Native é genuína quando seu time já escreve TypeScript. O argumento “meus engenheiros de web podem contribuir com mobile” se sustenta. No Lima, estávamos construindo isso sozinhos, então a escolha de linguagem era puramente sobre o que seria mais rápido de acertar, e Dart com as ferramentas do Flutter foi a resposta.

Onde o React Native realmente vence

Integração brownfield. Se você está adicionando uma tela ou feature a um app iOS ou Android nativo existente, o React Native se integra de forma mais natural. Flutter consegue fazer, mas a configuração é mais invasiva e isso aparece.

Tamanho do ecossistema JavaScript. O RN tem mais pacotes para mais coisas específicas, e muitos deles são mais maduros. Se seu caso de uso específico tem uma biblioteca JS que não tem equivalente no Flutter, essa lacuna importa.

Produtividade do time quando o time é JS-nativo. Se você tem cinco engenheiros TypeScript e um prazo de um mês, o RN te leva à produção mais rápido do que pedir a esses engenheiros que aprendam Dart enquanto constroem. Entregar algo real é melhor que construir a stack certa.

A decisão prática

App mobile greenfield, visando iOS e Android (potencialmente web depois), time aberto a aprender: Flutter. O controle dos pixels, o hot reload que realmente funciona de forma confiável e o target web compensam a curva de aprendizado do Dart rapidamente.

Time de JS existente, integração brownfield, pressão de tempo: React Native. A nova arquitetura é sólida, o ecossistema é rico, e se seus engenheiros já estão lá, você vai entregar mais rápido.

Lima no Flutter significou um codebase para iOS, Android e web. 25.000 usuários entre plataformas, sem bugs de renderização que não introduzimos nós mesmos. Esse é o caso que ele fez para nós.

O mesmo raciocínio se aplica quando construímos para clientes. Produtos mobile greenfield construímos em Flutter. Projetos onde o cliente tem um time JS existente e precisa de cobertura mobile, avaliamos React Native seriamente. O framework segue o problema.

---

Mais da construção do Lima: o bug de cache ETag que levou três sessões para rastrear, e o nono dígito brasileiro que quebrava silenciosamente o matching de WhatsApp para alguns usuários.