Flutter vs React Native vs Nativo em 2026: como escolher

Se você está escolhendo uma stack mobile em 2026, a resposta curta é: use React Native com Expo se o seu time já escreve TypeScript e o app precisa parecer nativo; use Flutter se quer um único motor de renderização em mobile, web e desktop ou se o time vem de Dart, Java ou C#; use Kotlin Multiplatform se tem engenheiros Android e quer UIs nativas com lógica compartilhada; e vá totalmente nativo, em Swift e Kotlin, quando o produto depende de integração profunda com o sistema operacional. O resto deste artigo explica como descobrir em qual desses quatro casos você está.

As quatro opções realistas em 2026

O debate "Flutter vs React Native" ficou datado como escolha binária. Hoje existem quatro caminhos sérios, e eles diferem em um eixo fundamental: quem desenha os pixels e onde a lógica de negócio roda.

Flutter compila Dart antecipadamente (AOT) para código nativo e desenha cada pixel por conta própria com seu próprio motor (o Impeller é o renderizador padrão em iOS e Android). O sistema operacional fornece uma superfície; o Flutter faz o resto. É por isso que um app Flutter fica igual em qualquer dispositivo e se estende naturalmente para web, Windows, macOS e Linux.

React Native roda JavaScript ou TypeScript no motor Hermes e renderiza widgets reais da plataforma. Com a New Architecture, o JavaScript chama código nativo de forma síncrona pela JSI, o layout passa pelo Fabric e os módulos nativos são TurboModules tipados. A antiga bridge assíncrona, origem da maioria das reclamações históricas de performance, não existe mais. O Expo é hoje a forma padrão de criar e publicar um projeto: oferece o serviço de build (EAS), atualizações over-the-air, roteamento baseado em arquivos com o Expo Router e um conjunto curado de módulos nativos. Config plugins permitem adicionar código nativo sem sair do Expo.

Kotlin Multiplatform (KMP) é a terceira opção em ascensão. Você escreve rede, persistência, regras de domínio e view models uma vez em Kotlin e compila para uma biblioteca JVM no Android e um framework nativo no iOS. A UI pode continuar totalmente nativa (Jetpack Compose no Android, SwiftUI no iOS) ou ser compartilhada com o Compose Multiplatform, que é estável no iOS. O Google recomenda o KMP para compartilhar lógica entre Android e iOS, e a JetBrains mantém o ferramental.

Nativo significa Swift com SwiftUI no iOS e Kotlin com Jetpack Compose no Android. Duas bases de código, dois times ou um time com dois conjuntos de habilidades, e nenhuma abstração entre você e a plataforma.

Flutter vs React Native vs KMP vs nativo: tabela comparativa

Critério	Flutter	React Native (Expo)	Kotlin Multiplatform	Nativo (Swift / Kotlin)
Linguagem	Dart	TypeScript / JavaScript	Kotlin (+ Swift para a UI iOS)	Swift, Kotlin
Renderização	Motor próprio (Impeller); desenha cada pixel	Widgets nativos da plataforma via Fabric	UI nativa, ou Compose Multiplatform (baseado em Skia)	Toolkits de UI nativos
Aparência nativa	Consistente entre plataformas; o estilo da plataforma precisa ser emulado (Material / Cupertino)	Alta; views reais de UIKit / Android	Alta com UI nativa; média com UI Compose compartilhada	Máxima
Perfil de performance	Código AOT previsível e renderização via GPU; binário grande	Próximo do nativo na UI; a thread JS pode virar gargalo em computação pesada	Nativo na lógica; performance da UI igual à do toolkit usado	Melhor teto, mais previsível
Acesso às APIs da plataforma	Via plugins e platform channels	Via TurboModules / módulos Expo; config plugins para configuração nativa	Direto em cada plataforma (expect/actual)	Direto, desde o primeiro dia de cada versão do SO
Alcance web / desktop	Forte: web, Windows, macOS e Linux de uma única base	Web via React Native Web / Expo; desktop mantido pela comunidade	Desktop via Compose; web ainda experimental	Nenhum sem um projeto separado
Mercado de contratação	Médio; Dart raramente é a primeira linguagem	O maior; todo time web conhece React	Médio; forte em equipes Android	Médio; especialistas custam mais, dois conjuntos de habilidades
Maturidade do ferramental	Madura: hot reload, DevTools, suporte oficial em IDEs	Madura: Expo CLI, EAS, Metro, React DevTools	Amadurecendo rápido; o lado iOS ainda depende de Xcode mais ferramental Kotlin	A mais madura: Xcode, Android Studio
Tamanho do app (ordem de grandeza)	Dezenas de MB de base (motor embutido)	Dezenas de MB de base (Hermes + runtime)	Próximo do nativo; a biblioteca compartilhada adiciona alguns MB	O menor; poucos MB em apps simples

A tabela mostra o padrão: cada camada que você coloca entre o seu código e o SO compra alcance e velocidade de entrega e cobra em fidelidade e acesso. A pergunta nunca é "qual é o melhor", e sim "qual trade-off este produto tolera".

Performance na prática, não em benchmarks

A maioria dos artigos de benchmark mede rolagem de listas ou tempo de inicialização em um celular topo de linha e conclui que as diferenças são pequenas. Em um Android intermediário, que é o que a maioria dos seus usuários fora da Europa Ocidental e dos EUA tem na mão, o quadro é mais sutil.

Inicialização: apps nativos abrem mais rápido. Flutter e React Native adicionam uma etapa de inicialização do runtime que custa centenas de milissegundos em hardware modesto; o bytecode do Hermes e os builds AOT do Flutter mantêm essa penalidade sob controle.

Renderização: o Flutter controla o pipeline inteiro, então as animações são consistentes, mas a compilação de shaders costumava causar travadas na primeira execução; o Impeller foi criado justamente para eliminar isso. O React Native renderiza views nativas, então uma FlatList ou FlashList é tão fluida quanto a plataforma permite, mas qualquer trabalho na thread JavaScript compete com as atualizações de UI. Mova trabalho pesado para módulos nativos ou worklets (o Reanimated roda animações na thread de UI exatamente por isso).

Trabalho pesado de CPU: processamento de imagem, criptografia, inferência de ML no dispositivo. O Flutter pode usar isolates e FFI para C; o React Native precisa de um módulo nativo ou de uma biblioteca C++ ligada via JSI; KMP e nativo simplesmente chamam a plataforma. Se o seu loop central é limitado por CPU, conte isso como ponto para KMP ou nativo.

Meça antes de decidir: construa a sua tela real mais pesada nas duas stacks candidatas e rode no dispositivo mais barato que o seu analytics mostrar.

Quando o nativo é inegociável

Frameworks multiplataforma alcançam qualquer API do SO por meio de um módulo nativo. A pergunta honesta é: quanto do seu app será módulo nativo? Quando a resposta é "a maioria das funcionalidades que diferenciam o produto", você deveria ser nativo desde o início.

• Pipelines de câmera e AR. ARKit e ARCore, controles de câmera customizados, filtros em tempo real, sensor de profundidade. Existem plugins, mas eles ficam atrás das versões do SO e expõem um subconjunto da API.
• Widgets de tela inicial e tela de bloqueio, Live Activities, App Intents. Rodam fora do processo do app, em frameworks específicos da plataforma (WidgetKit, Glance). São código nativo independentemente da stack principal.
• Wearables. Apps para watchOS e Wear OS são targets separados, com frameworks de UI próprios e limites de recursos rígidos.
• CarPlay e Android Auto, plataformas de TV. Frameworks nativos baseados em templates, com restrições de revisão.
• Execução em segundo plano. Reprodução de áudio, VoIP, rastreamento de localização, periféricos Bluetooth, sincronização de dados de saúde. Viável em multiplataforma, mas o debug acontece em código nativo e as regras do SO mudam todo ano.
• Recursos sensíveis de segurança. Secure Enclave, StrongBox, passkeys, atestação de hardware. Primeiro as APIs nativas, depois os wrappers.
• Adoção imediata de novos recursos do SO. Se o seu marketing depende de lançar o novo recurso do iOS na semana em que ele sai, você não pode esperar por um plugin.

Regra prática: se mais de aproximadamente um terço do seu roadmap está na lista acima, o multiplataforma economiza pouco e adiciona uma camada para debugar. Vá de nativo, ou use KMP para compartilhar a lógica e manter a UI nativa.

Time e contratação

A stack que você consegue contratar vence a stack que vai melhor no benchmark.

Time web existente. React Native com Expo é o caminho de menor atrito. Modelo mental do React, TypeScript, npm, os mesmos padrões de gerenciamento de estado que você já usa. Espere uma curva de aprendizado no ferramental de build nativo, assinatura e publicação nas lojas, que o EAS esconde nos casos comuns. Se você já investiu em TypeScript, esse investimento é aproveitado por completo.

Time Android existente. KMP é a extensão natural. Engenheiros Kotlin mantêm a linguagem e compartilham o código que é chato de escrever duas vezes. O lado iOS ainda precisa de alguém confortável com Swift e Xcode, pelo menos para UI e integração com a plataforma.

Time novo, sem histórico forte. Flutter e React Native são igualmente razoáveis. A vantagem do Flutter é uma toolchain única e opinativa, sem dependência da rotatividade do ecossistema npm. A vantagem do React Native é o tamanho do mercado de contratação e a opção de compartilhar código com um app web.

Agências e times terceirizados. Pergunte qual stack eles mais entregam e confira nas lojas as avaliações dos apps publicados, procurando reclamações de performance ou de aparência não nativa.

Seja qual for a escolha, reserve orçamento para pelo menos um engenheiro por plataforma capaz de ler stack traces nativos, configurar assinatura e CI e escrever um módulo nativo. Todo projeto multiplataforma precisa dessa pessoa, normalmente antes do planejado. Nosso guia sobre como escolher a stack de tecnologia para uma startup cobre os trade-offs mais amplos de contratação.

Migração e coexistência: integração brownfield

Pouquíssimos times partem do zero. O cenário realista é um app nativo existente, ou dois, e a dúvida sobre se as próximas cem telas precisam ser escritas duas vezes.

As três opções multiplataforma suportam rodar dentro de um app nativo existente:

• Flutter add-to-app empacota o seu código Flutter como um AAR no Android ou um framework no iOS. O app hospedeiro cria um FlutterEngine, opcionalmente pré-aquecido, e apresenta um FlutterViewController ou FlutterFragment para uma determinada rota. Vários engines podem compartilhar recursos por meio de um engine group.
• React Native incorpora uma root view (RCTRootView no iOS, ReactRootView no Android) que o app hospedeiro empilha como qualquer outra tela. O Expo suporta esse caminho, então brownfield não significa abrir mão do ecossistema de módulos do Expo.
• KMP é brownfield por natureza. O módulo compartilhado é só uma biblioteca; o app Android existente depende dele como um módulo Gradle e o app iOS linka um XCFramework. Nada na UI muda no primeiro dia.

Uma migração que funciona segue o padrão strangler usado em sistemas legados: escolha um fluxo autocontido e de baixo risco (configurações, uma central de ajuda, uma pesquisa de onboarding), entregue na stack nova atrás de uma feature flag, meça taxa de crash e performance contra a versão nativa e então expanda. Mantenha a interface entre hospedeiro e módulo fina e tipada: navegação, token de autenticação, tema, analytics. Cada chamada adicional que cruza essa fronteira é manutenção que você vai pagar dos dois lados.

Dois custos são fáceis de subestimar: tamanho do app (a primeira tela incorporada traz consigo o runtime inteiro do framework) e navegação (duas pilhas geram casos de borda no botão voltar, em deep links e na restauração de estado). Decida cedo qual lado é dono da navegação.

Checklist de decisão por tipo de app

Use o perfil que corresponde ao seu produto. Se dois corresponderem, fique com o mais restritivo.

App de consumo (marketplace, mídia, fitness, social)

• Precisa seguir de perto as convenções da plataforma? React Native ou nativo.
• UI customizada, com marca forte, que deve ficar idêntica em todo lugar? Flutter.
• Versão web planejada a partir da mesma base de código? React Native (Expo) ou Flutter.
• Crescimento depende de widgets, Live Activities, app de relógio? Nativo, ou multiplataforma mais extensões nativas desde o início.

App interno de campo (inspeções, logística, manutenção)

• Majoritariamente formulários, listas, fotos, sincronização offline? Flutter ou React Native; os dois lidam bem com isso e a base única se paga de imediato.
• Dispositivos Android robustos, só Android? Kotlin nativo, ou KMP se o iOS pode vir depois.
• Código de barras, NFC, impressoras, sensores externos? Verifique a cobertura dos plugins para o seu hardware exato antes de se comprometer. Veja nossas notas sobre desenvolvimento de aplicativos IoT.

App complementar de SaaS B2B

• Produto web já em React? React Native com Expo; compartilhe tipos, clientes de API e muitas vezes componentes com o app web.
• O produto é um consumidor da sua API no estilo dashboard, com notificações ocasionais? Considere se uma PWA resolve antes de construir qualquer app nativo.
• Clientes enterprise exigem MDM, SSO, certificate pinning? Todas as stacks conseguem; verifique as bibliotecas específicas antes de assinar o contrato.

App ligado a hardware (dispositivos BLE, médico, automotivo, casa inteligente)

• Bluetooth Low Energy como interação central? Nativo ou KMP. As stacks BLE diferem o bastante entre iOS e Android para que os plugins escondam os detalhes errados.
• Setor regulado (médico, automotivo)? Nativo reduz a superfície de auditoria: menos dependências de terceiros para documentar.
• UI complementar simples e o dispositivo faz o trabalho? Multiplataforma serve, desde que a camada BLE seja um módulo nativo dedicado e seu.

Implicações de custo

As diferenças de custo vêm de três lugares: quantas bases de código você mantém, quantos especialistas precisa e quanto código nativo acaba escrevendo de qualquer forma.

Uma única base multiplataforma para um app com UI majoritariamente padrão é um build e uma frente de manutenção em vez de duas. Esse é todo o business case, e ele vale para a maioria dos apps de consumo e corporativos. A economia encolhe conforme o número de módulos nativos cresce, e no extremo um app multiplataforma com integração nativa pesada custa mais do que dois apps nativos: três bases de código mais a cola entre elas.

O KMP fica no meio. Você compartilha a lógica (normalmente a metade maior e mais propensa a bugs de um app) enquanto paga por duas UIs. Para times com competência forte em Android, costuma ser a forma mais barata de ter um app iOS com qualidade nativa.

Custos ocultos a orçar, independentemente da stack: testes em device farm entre versões de SO, ciclos de revisão das lojas, migrações anuais de SO (Apple e Google descontinuam APIs em cronograma) e manutenção de dependências. Para faixas concretas de composição de time e diárias na Europa, veja quanto custa desenvolver software sob medida na Europa. Um bom pipeline de CI/CD, com builds e assinatura automatizados, não é opcional em nenhuma stack; é a diferença entre uma release semanal e uma mensal.

Recomendação

Adote React Native com Expo por padrão quando a sua organização já constrói em TypeScript e o app deve parecer nativo. Adote Flutter por padrão quando UI customizada e consistente em mobile, web e desktop importa mais do que o idioma da plataforma, ou quando o time prefere uma toolchain única e opinativa. Escolha Kotlin Multiplatform quando tem engenheiros Android e quer UIs nativas com lógica de negócio compartilhada. Vá totalmente nativo quando o valor do produto está em câmera, AR, widgets, wearables, serviços em segundo plano ou hardware, ou quando recursos do SO no primeiro dia fazem parte da estratégia.

Antes de se comprometer, rode um spike de duas semanas na sua tela mais difícil com os dois candidatos mais fortes, no seu dispositivo-alvo mais barato, e decida com números do seu próprio app. Na Arvucore, costumamos recomendar esse spike acima de qualquer quantidade de leitura comparativa, incluindo este artigo.