CrossFly vs Flutter

O núcleo do Flutter desenha widgets, mas na hora em que você precisa de notificações, câmera, localização em segundo plano, Bluetooth, pagamentos ou um editor avançado, você recorre a um pacote do pub.dev que o Google não mantém. Mantenedores se esgotam acompanhando duas plataformas nativas, e pacotes são abandonados — até alguns que o próprio time do Flutter recomendou, como o flutter_adaptive_scaffold. Quando um pacote para de atualizar, uma futura mudança de Flutter ou Gradle pode quebrar o seu build sem ninguém para consertar.

O Flutter lança mudanças que quebram em cadência regular — a reescrita da API de Color, mudanças de edge-to-edge e Gradle, entre outras. O dart fix automatiza parte, não tudo. A dor real se acumula: quando o SDK quebra uma API, você ainda espera cada pacote de terceiros se atualizar antes de conseguir subir de versão.

O Dart é usado quase que exclusivamente dentro do Flutter. O pool de talentos é uma fração das linguagens mainstream, então contratar é mais lento e mais caro, e há menos bibliotecas testadas em batalha e menos respostas quando você bate num caso extremo.

O Flutter não chama código Java ou JVM diretamente. Para reaproveitar seus modelos de backend, validações ou SDKs, você escreve e mantém “platform channels” assíncronos por plataforma — código numa linguagem que o time não usa em outro lugar, que exige testes de integração com o app rodando para permanecer seguro.

Flutter e Dart são conduzidos por uma única empresa. As demissões do Google em 2024 atingiram os times de Flutter e Dart, e um grupo da comunidade forkou o Flutter no “Flock” citando comunicação lenta — um sinal real de risco de governança e de velocidade para uma stack em que você apostaria um produto.