App nativo vs multiplataforma: React Native/Expo vs Swift/Kotlin vs Flutter

Se você está planejando um aplicativo, logo alguém vai perguntar: nativo ou multiplataforma? (Muita gente ainda chama de "app híbrido".) A pergunta parece técnica, mas a resposta depende principalmente de orçamento, prazo e do que o seu app faz o dia inteiro. Veja como eu decidiria em 2026, com os prós e contras sem rodeios.

Nativo vs multiplataforma: o que cada termo significa

Desenvolvimento nativo significa construir cada plataforma com as próprias ferramentas: Swift (normalmente com SwiftUI) para iOS e Kotlin (normalmente com Jetpack Compose) para Android. O resultado são dois códigos-fonte, muitas vezes mantidos por duas pessoas ou duas equipes.

Desenvolvimento multiplataforma (ou cross-platform) significa escrever um único código que é publicado nas duas lojas. As duas opções sérias hoje são:

• React Native, geralmente com Expo: você escreve TypeScript e React, e o app renderiza componentes nativos de verdade (um botão real do iOS, uma lista real do Android).
• Flutter: você escreve Dart, e o Flutter desenha cada pixel com o próprio motor de renderização, em vez de usar os componentes da plataforma.

Um caminho intermediário mais recente é o Kotlin Multiplatform, que compartilha a lógica de negócio (e, se você quiser, a interface via Compose Multiplatform) mantendo código nativo onde fizer sentido. É uma opção sólida, mas o ecossistema e o mercado de profissionais ainda são menores que os das outras três, então não vou me aprofundar nele aqui.

Comparação lado a lado

A linha de custo é a que mais importa para quem está empreendendo. Com um único código, você desenha, desenvolve, testa e corrige cada funcionalidade uma vez, não duas. Na nossa experiência, um projeto multiplataforma costuma custar bem menos que dois apps nativos de mesmo escopo, embora a diferença exata dependa de quanto trabalho específico de cada plataforma o app exige. Para valores concretos, veja quanto custa criar um aplicativo.

React Native e Expo em 2026

O React Native é mantido pela Meta e usado em grandes apps em produção no mundo todo. O Expo é o framework e o conjunto de ferramentas em nuvem construído sobre ele, e o próprio time do React Native hoje recomenda começar novos apps com um framework como o Expo. Algumas mudanças dos últimos anos alteraram bastante o cenário:

A Nova Arquitetura

A Nova Arquitetura do React Native (o renderizador Fabric, os TurboModules e a JSI) substituiu a antiga "ponte" (bridge) assíncrona entre JavaScript e código nativo. Agora o JavaScript pode chamar código nativo de forma direta e síncrona quando precisa, a renderização ficou mais previsível e os recursos concorrentes do React funcionam. Ela virou o padrão para novos projetos no fim de 2024, e as versões recentes do React Native e do Expo abandonaram a arquitetura antiga. A maior parte das reclamações de desempenho que você encontra em posts antigos era sobre a ponte.

EAS Build, Submit e Update

• EAS Build compila os binários de iOS e Android na nuvem, então a equipe não precisa manter um Mac configurado com todo cuidado para cada desenvolvedor.
• EAS Submit envia esses builds para o App Store Connect e o Google Play.
• EAS Update entrega atualizações over-the-air (OTA): mudanças no JavaScript e nos assets chegam ao celular do usuário na próxima abertura do app, sem esperar a revisão da loja.

Some a isso o Expo Router (navegação baseada em arquivos que também roda na web), os config plugins que alteram configurações do projeto nativo sem editar o Xcode na mão e uma grande biblioteca de módulos mantidos para câmera, notificações, localização, pagamentos e muito mais. Na maioria dos apps, raramente é preciso escrever código nativo.

Flutter: Dart e motor de renderização próprio

O Flutter, do Google, segue outro caminho. Em vez de pedir ao iOS e ao Android que desenhem os componentes, ele traz o próprio motor de renderização (Impeller) e pinta a interface inteira sozinho. Isso tem vantagens reais:

• Interface idêntica pixel a pixel em qualquer aparelho, ótimo para interfaces muito personalizadas e com identidade visual forte.
• Animações fluidas e uma biblioteca de widgets madura.
• Hot reload rápido e um conjunto de ferramentas bem integrado.

As desvantagens: você escreve em Dart, uma linguagem que poucos desenvolvedores usam fora do Flutter, então é mais difícil contratar. Como o Flutter desenha os próprios widgets, acompanhar exatamente cada atualização visual do iOS ou do Android depende de o time do Flutter correr atrás. E o Flutter na web renderiza em um canvas, o que funciona para dashboards com cara de app, mas não serve bem para conteúdo que você quer ver indexado no Google.

Flutter é uma boa escolha, e eu nunca diria a uma equipe com experiência forte em Flutter para trocar. O principal motivo de não ser o meu padrão é o compartilhamento de código com a web, que explico mais abaixo.

Nativo: Swift/SwiftUI e Kotlin/Jetpack Compose

Desenvolver nativo hoje é bem mais agradável do que há dez anos. SwiftUI e Jetpack Compose são frameworks de interface declarativos, parecidos em espírito com o React. Você tem acesso no primeiro dia a cada novo recurso que a Apple e o Google anunciam, as melhores ferramentas de depuração e profiling e nenhuma camada de abstração para atrapalhar.

O preço é a duplicação. Cada tela, cada correção e cada funcionalidade é feita duas vezes, em duas linguagens, e os dois apps tendem a se distanciar com o tempo, a menos que alguém trabalhe para mantê-los alinhados. Para um produto com investimento e equipes separadas de iOS e Android, dá para administrar. Para uma startup ou pequena empresa com um orçamento só, geralmente não dá. Se uma plataforma basta para o lançamento, um único app nativo pode fazer sentido: veja desenvolvimento de apps iOS e desenvolvimento de apps Android.

Quando o desenvolvimento nativo vence

Vá de nativo, ou pelo menos planeje bastante código nativo, quando o seu app gira em torno de algo que a própria plataforma faz:

• Gráficos pesados e mídia em tempo real: 3D, realidade aumentada, jogos, edição profissional de vídeo ou áudio, pipelines de câmera que processam cada frame.
• Integração profunda com o sistema: CarPlay ou Android Auto, lógica de áudio ou localização em segundo plano além dos módulos comuns, hardware Bluetooth com tempo crítico, serviços de acessibilidade, teclados personalizados.
• Produtos centrados em widgets e relógio: se o widget da tela inicial, a Live Activity ou o app do Apple Watch é o produto, você vai escrever Swift e Kotlin para essas partes de qualquer jeito.
• Recursos novos do sistema no primeiro dia, quando lançar antes de todo mundo é a vantagem competitiva.

Um detalhe importante: apps em React Native podem incluir código nativo. Widgets, extensões de relógio e módulos nativos personalizados podem conviver com um app React Native, e os config plugins do Expo adicionam esses targets ao projeto. Então a pergunta real muitas vezes é "quanto código nativo vamos precisar?", e não "nativo ou não?"

Quando multiplataforma vence (a maioria dos apps de negócio)

A maioria dos apps é feita de formulários, listas, feeds, chat, mapas, pagamentos, notificações, contas de usuário e um backend. Isso inclui marketplaces, apps de agendamento, ferramentas internas, apps para equipes de campo, comunidades, apps complementares de SaaS e a maior parte dos apps com IA. Para eles, multiplataforma é a melhor decisão de negócio:

• Você lança nas duas lojas ao mesmo tempo, em vez de escolher uma plataforma e deixar metade do mercado esperando.
• O orçamento rende mais, seja com um custo total menor ou com mais funcionalidades pelo mesmo valor.
• Cada correção é feita uma vez. Um bug encontrado no Android também fica corrigido no iOS.
• Uma única equipe cuida do produto inteiro, o que faz muita diferença quando você está no começo e mudando de direção toda semana.

Isso pesa ainda mais em um MVP, em que a velocidade de aprendizado é o objetivo. Nosso guia sobre quanto tempo leva para criar um aplicativo mostra como os prazos encolhem quando você não constrói tudo duas vezes.

Compartilhando código com um app web

Muitos produtos também precisam de uma versão web: um painel administrativo, um portal do cliente ou uma versão do próprio app no navegador. É aqui que o React Native tem uma vantagem estrutural. Seu app web muito provavelmente será feito em React, então uma equipe de React Native pode compartilhar:

• Tipos TypeScript, validações e regras de negócio.
• Clientes de API, busca de dados e gerenciamento de estado.
• Código de backend. Com um backend em tempo real como o Convex, as mesmas queries e mutations alimentam o celular e o navegador.
• Em alguns casos, a própria interface, via React Native for Web e Expo Router.

Também é uma só linguagem e um só modelo mental em toda a stack, então os mesmos desenvolvedores transitam entre mobile, web e backend. Nosso produto Star funciona assim: um app para tablet usado para conduzir setlists e apresentações, mais um app web em app.starapp.io, ambos construídos sobre a mesma base em TypeScript. Se um produto no navegador faz parte do seu plano, veja desenvolvimento de aplicações web.

Nosso padrão na Loha.dev, e por quê

Sendo transparente: na Loha.dev construímos apps mobile com React Native e Expo, e é isso que vamos recomendar na maioria dos projetos. Vale você saber desse viés. Este é o raciocínio por trás dele:

1. Um único código TypeScript para iOS, Android e muitas vezes web mantém custo e prazo razoáveis para fundadores e pequenas empresas.
2. Atualizações over-the-air permitem corrigir a maioria dos problemas no mesmo dia, sem esperar a revisão da loja.
3. O mercado de profissionais é o maior entre todas as opções, então você nunca fica preso a nós. Outro desenvolvedor React Native consegue assumir o código.
4. Existem saídas para o nativo. Quando uma funcionalidade exige Swift ou Kotlin, escrevemos aquela parte em nativo em vez de trocar o app inteiro.

Quando diríamos o contrário: se o seu app é uma experiência 3D ou de realidade aumentada, um jogo, uma ferramenta profissional de mídia ou principalmente um app de relógio, a resposta honesta é um projeto nativo (ou uma engine de jogos), e vamos dizer isso mesmo que signifique você trabalhar com outra empresa. Veja como trabalhamos com desenvolvimento de aplicativos mobile ou vá direto ao ponto e receba um plano gratuito para o seu app com base na sua ideia.

Um jeito rápido de decidir

Seja qual for a escolha, o framework importa menos do que um escopo claro, um bom backend e uma equipe que entrega. Escolher bem no começo evita reescrever tudo depois.