Em fevereiro de 2026, três frameworks cross-platform disputam a atenção de quem precisa entregar um app mobile sem manter dois codebases nativos. Flutter lidera em market share. React Native largou a bridge legada e entregou a New Architecture de verdade. Kotlin Multiplatform deixou de ser experimento e colocou apps em produção na Netflix, no McDonald's e no Cash App.

A pergunta que chega na mesa do arquiteto não mudou: qual escolher? Mas os dados para responder, esses sim mudaram. E o que me incomoda é que a maioria das comparações para na contagem de FPS. Como se performance de renderização fosse o único fator que define se um projeto vai dar certo ou virar um pesadelo de manutenção daqui a dois anos.

Os números de 2026: quem lidera o quê

Segundo a Statista, Flutter tem 46% de market share entre desenvolvedores cross-platform. React Native fica com 35%. Kotlin Multiplatform, que em 2024 marcava 7% de adoção, saltou para algo entre 18% e 23% dependendo da pesquisa que você consultar.

Os números brutos contam parte da história. Flutter tem 2 milhões de desenvolvedores ativos e 93% de satisfação. Mas React Native se beneficia de um pool de talentos JavaScript que é 3 a 5 vezes maior. Contratar um dev React Native em Toronto ou São Paulo leva semanas; encontrar alguém com experiência em Dart pode levar meses.

KMP é o caso mais interessante. A pesquisa State of Kotlin Multiplatform mostra que 60% dos respondentes já usaram ou experimentaram KMP em produção. E 23,8% começaram nos últimos seis meses. Não é mais adoção de early adopter. É migração real.

Flutter e o Impeller: onde o Dart voa

A substituição do Skia pelo Impeller é o divisor de águas do Flutter em 2026. Desde a versão 3.27, o Impeller é o motor de renderização padrão para iOS (via Metal) e Android API 29+ (via Vulkan).

O que isso significa na prática: testes mostram redução de 50% no tempo médio de rasterização em cenas complexas. Frames com jank caíram entre 30% e 50% em animações pesadas. O shader compilation jank, aquele engasgo na primeira execução de uma animação que atormentou o Flutter por anos, deixou de existir. Shaders são pré-compilados.

Em dispositivos com tela de 120Hz, o Flutter mantém frame rate estável sem quedas perceptíveis. Para apps com UI customizada, animações elaboradas ou transições que fogem do padrão Material, o Flutter simplesmente não tem concorrente cross-platform nesse quesito.

O ecossistema também amadureceu: mais de 50.000 pacotes no pub.dev, hot reload que funciona de verdade e uma comunidade que responde rápido. O ponto fraco continua sendo o mesmo: Dart. A linguagem é boa, bem desenhada, com null safety e bom ferramental. Mas não é JavaScript e não é Kotlin. Cada dev contratado precisa aprender Dart do zero, e isso tem custo.

React Native depois da bridge: a New Architecture entregou?

A resposta curta: sim. A New Architecture (Fabric + TurboModules + JSI) está habilitada por padrão desde a versão 0.76 e estável em produção.

O que foi embora: a bridge assíncrona que serializava tudo em JSON para comunicar JavaScript com o lado nativo. O que entrou no lugar: JSI (JavaScript Interface) permite chamadas síncronas e diretas entre JS e código nativo. Fabric traz renderização concorrente alinhada com React 18. TurboModules carregam módulos nativos sob demanda, não todos no startup.

Os benchmarks refletem a mudança. Apps com a New Architecture atingem 60 FPS consistentes em scroll e animações. O cold start ficou entre 15% e 20% mais lento que nativo, contra 40% a 50% da arquitetura legada. Com Hermes e bytecode pré-compilado, o startup cai mais 30% a 50%.

O ecossistema Expo turbinou a experiência de desenvolvimento. Builds na nuvem, atualizações OTA, configuração simplificada. Para quem vem do mundo web, a curva de entrada é a mais suave entre os três frameworks.

O que me pega no React Native é a fragmentação histórica. Mesmo com a New Architecture resolvendo problemas reais, a quantidade de bibliotecas desatualizadas, wrappers abandonados e tutoriais de 2021 que aparecem no Google ainda gera confusão. O framework melhorou. O ecossistema ao redor precisa de mais tempo para alcançá-lo.

Kotlin Multiplatform: o intruso que virou opção séria

KMP não é um framework de UI. Essa distinção importa. A proposta é compartilhar lógica de negócio, networking, persistência e validação entre plataformas, mantendo a UI nativa em cada uma.

Isso mudou em parte com o Compose Multiplatform 1.10.0, lançado em janeiro de 2026. O CMP para iOS atingiu estabilidade total. Navigation 3 permite manipular a stack de navegação como uma lista comum, sem métodos opacos. O Compose Hot Reload saiu como stable 1.0.0 e já vem embutido no plugin Gradle.

O Swift Export experimental da JetBrains faz código Kotlin parecer Swift idiomático no lado iOS. A fricção de consumir módulos compartilhados caiu para quase zero. E o garbage collector Native 2.0 eliminou as restrições de frozen objects que tornavam a interoperabilidade com Swift um exercício de paciência.

Empresas como Netflix, Cash App (usando KMP em produção desde 2018), McDonald's, Duolingo (mais de 40 milhões de usuários ativos com KMP) e Google Docs no iOS validam a abordagem. Não são provas de conceito. São apps em escala.

O trade-off: complexidade organizacional. KMP funciona melhor com times que já conhecem Kotlin e que têm disposição para manter módulos compartilhados com disciplina. Para uma startup de 5 pessoas que precisa de MVP em 12 semanas, KMP provavelmente adiciona mais overhead do que resolve.

O custo que ninguém coloca na planilha

O custo de desenvolvimento inicial é só 50% a 70% do TCO de um app mobile. Manutenção consome entre 15% e 25% do custo inicial por ano. E aqui que as diferenças entre frameworks ficam reais.

Contratação é o primeiro ponto. Devs React Native custam entre $60 e $120/hora, com salário médio de $135K/ano. Flutter fica entre $80 e $150/hora. KMP herda o pool de desenvolvedores Kotlin/Android, que é grande, mas devs com experiência real em compartilhamento cross-platform ainda são raros.

O segundo ponto é menos óbvio: atualizações de plataforma. Quando o Android 17 lança uma API nova ou a Apple muda algo no iOS, cada framework reage em velocidades diferentes. Flutter e React Native dependem da equipe core e da comunidade para criar bindings. KMP, por usar código nativo diretamente, absorve mudanças de plataforma com menos atrito.

O terceiro ponto é o custo de migrar. Se o time decide trocar de framework daqui a três anos, quanto do código sobrevive? Com KMP, a lógica de negócio compartilhada pode ser reutilizada mesmo que a camada de UI mude completamente. Com Flutter ou React Native, a migração é geralmente um rewrite.

Empresas que operam em escala estão adotando estratégias mistas: KMP para lógica de negócio crítica, React Native para prototipagem rápida, Flutter para apps consumer-facing com UI diferenciada. Não é contraditório. É pragmatismo.

Quando escolher cada um

Flutter funciona quando a UI customizada é o diferencial do produto. Apps de fintech com gráficos interativos, apps de saúde com visualizações de dados, qualquer coisa onde a identidade visual precisa fugir dos componentes nativos padrão. O time precisa aprender Dart, mas se a empresa está disposta a investir nessa curva, o retorno em consistência visual e produtividade de UI é real.

React Native faz sentido quando o time já vive no ecossistema JavaScript/TypeScript. Startups que precisam de MVP rápido, apps content-driven, e-commerce e qualquer cenário onde time-to-market importa mais que a última gota de performance. A maior vantagem é pragmática: você contrata JavaScript devs, e eles são muitos.

Kotlin Multiplatform é a escolha quando o time tem desenvolvedores Android/Kotlin experientes e a aplicação tem lógica de negócio complexa que não pode divergir entre plataformas. Finanças, saúde, logística. Apps onde um cálculo errado numa plataforma é um bug crítico. A opção de manter UI nativa com SwiftUI e Jetpack Compose garante a melhor experiência possível em cada plataforma.

Nenhum dos três está errado para todos os cenários. Todos os três estão errados para algum cenário.

Conclusão

A conversa sobre frameworks cross-platform amadureceu. Não estamos mais debatendo se cross-platform é viável. Estamos debatendo qual sabor de viável encaixa melhor em cada situação.

Flutter lidera em adoção e entregou o Impeller. React Native finalmente completou a transição arquitetural que prometeu por anos. KMP transformou a ideia de shared business logic em realidade de produção, com Compose Multiplatform tornando o compartilhamento de UI uma opção, não uma obrigação.

O que me preocupa é a tendência de tratar essa escolha como torcida de futebol. Vi times gastarem mais energia defendendo sua escolha de framework do que analisando se ela fazia sentido para o produto. A resposta certa quase sempre começa com duas perguntas que não têm nada a ver com FPS: que time eu tenho hoje? E que problema estou tentando resolver?

Referências pesquisadas nesta publicação