App nativo, React Native ou PWA: como decidir sem errar

A pergunta chega sempre no mesmo formato: "vamos fazer nativo ou React Native?". E ela quase sempre é a segunda pergunta, feita antes da primeira.

A resposta curta, em ordem de importância: a maioria dos produtos que pede um app precisa mesmo é de uma web bem feita. Dos que precisam de app, a maioria resolve com uma base de código compartilhada. E nativo puro se justifica por requisito específico, não por preferência.

O erro caro aqui não é escolher a tecnologia errada — é escolher a categoria errada. Fazer app quando bastava web significa pagar duas lojas, dois ciclos de revisão e uma manutenção permanente para resolver o que um site responsivo resolveria.

Antes da tecnologia: você precisa mesmo de um app?

Existem cinco motivos legítimos para um aplicativo existir. Se o seu caso não está entre eles, provavelmente você quer um app pelo motivo errado:

1. Uso recorrente e frequente. Ícone na tela inicial vale muito para o que se usa todo dia, e quase nada para o que se usa uma vez por trimestre.
2. Recurso de hardware. Câmera com processamento, sensores, bluetooth, leitura de código em série, biometria, uso intenso de localização em segundo plano.
3. Funcionamento offline de verdade. Equipe em campo, área sem sinal, operação que não pode parar quando a conexão cai.
4. Notificação como parte do produto. Não notificação de marketing — notificação que é o próprio valor, como alerta operacional ou mensagem em tempo real.
5. Presença na loja como canal. Quando as pessoas realmente procuram pela sua categoria na App Store ou na Play Store.

O motivo que não está na lista, e que responde por boa parte dos pedidos: "nossos concorrentes têm". App existindo não é app sendo usado. Antes de construir, vale olhar quantas instalações ativas o concorrente realmente tem — costuma ser um banho de realidade produtivo.

Aplicativo com uso esporádico é um ícone morto na tela do usuário, competindo por espaço com o que ele abre todo dia.

As quatro opções, sem torcida

	Nativo (Swift/Kotlin)	React Native	Flutter	PWA
Bases de código	Duas	Uma	Uma	Uma (a mesma da web)
Acesso a hardware	Total e imediato	Amplo, via bibliotecas	Amplo, via bibliotecas	Limitado, varia por sistema
Desempenho gráfico pesado	Melhor	Bom	Muito bom	Limitado
Está nas lojas	Sim	Sim	Sim	Não
Atualização sem revisão da loja	Não	Parcial	Parcial	Sim, imediata
Time necessário	Especialistas por plataforma	Base web reaproveitada	Especialistas em Dart	Time web existente
Recurso novo do sistema no lançamento	Imediato	Espera a biblioteca	Espera a biblioteca	Depende do navegador

Nativo entrega o teto de qualidade e o acesso mais direto ao sistema, ao custo de manter dois produtos paralelos para sempre — duas implementações, dois testes, duas correções para cada bug de regra de negócio.

React Native costuma ser a escolha mais racional quando já existe um time web. A regra de negócio fica em um lugar só, e a parte específica de cada plataforma continua possível quando necessário. É a opção que a gente mais usa, e o motivo é organizacional antes de ser técnico: uma base de código que o time existente consegue manter.

Flutter entrega desempenho excelente e controle fino da interface, com o custo de exigir um ecossistema próprio — outra linguagem, outro conjunto de bibliotecas, outro perfil de contratação. Ótima escolha quando existe time para isso.

PWA é a opção mais subestimada. É o seu site funcionando como aplicativo: instalável, com ícone, com tela cheia e com funcionamento offline através de cache. Atualiza na hora, sem revisão de loja, sem duas bases. A limitação é real e precisa ser dita: acesso a hardware é mais restrito e varia bastante entre sistemas, e ele não aparece nas lojas — o que remove um canal de descoberta.

Os critérios que decidem de verdade

Ignore comparações genéricas de desempenho. Na prática, a decisão sai de cinco perguntas:

1. Qual hardware o produto realmente usa? Câmera para tirar uma foto simples: qualquer opção serve. Leitura contínua de código de barras, processamento de imagem ao vivo, comunicação com dispositivo bluetooth específico: aí a conversa muda e nativo ou uma base compartilhada com módulo nativo entram em cena.

2. O que precisa funcionar sem internet? "Seria bom ter offline" e "a operação para sem offline" são requisitos completamente diferentes. O segundo exige sincronização, resolução de conflito e estratégia de dados — e isso é mais trabalhoso que a escolha de framework. Muita gente escolhe a tecnologia e descobre que o difícil era a sincronização.

3. Quem vai manter isso daqui a um ano? É o critério mais decisivo e o menos discutido. Escolher uma tecnologia que ninguém do time domina, porque ela ganha benchmark, é criar dependência externa permanente. Base de código que o seu time consegue evoluir vale mais que benchmark.

4. Com que frequência você precisa publicar? Ciclo de revisão das lojas impõe um ritmo. Produto que muda muito ou que precisa corrigir rápido sofre com isso — e é um argumento forte para manter na web o que puder ficar na web.

5. Como o produto é monetizado? Conteúdo ou assinatura digital consumidos dentro do app geralmente caem nas regras de compra da loja, com comissão e restrições que variam por país e tipo de produto. Isso afeta margem e precisa ser considerado antes de escolher a plataforma, não depois de o app estar pronto.

A estratégia que mais funciona: web primeiro, app depois

Para a maioria dos produtos, o caminho de menor risco é este:

Comece pela web responsiva. Ela funciona em qualquer aparelho, é indexável por busca, atualiza na hora e valida se alguém quer o produto — sem ciclo de loja no meio.

Transforme em PWA quando houver uso recorrente. É incremental: manifesto, service worker, cache do essencial. Os usuários frequentes instalam, e você descobre quantos realmente são frequentes sem ter construído um app.

Construa o app quando os dados justificarem. E aí você já sabe quais telas as pessoas usam, o que precisa estar offline e quais recursos de hardware fazem falta de verdade. A decisão deixa de ser aposta e vira consequência.

A inversão dessa ordem — app primeiro, para "chegar com força" — é como se queimam meses construindo telas que ninguém vai abrir.

O custo permanente que não aparece na proposta

Aplicativo tem obrigações recorrentes que a web não tem, e elas continuam existindo mesmo quando você não está evoluindo o produto:

• Atualização forçada pelos sistemas. Apple e Google exigem periodicamente versões mínimas de SDK e novos requisitos. Ignorar significa app removido da loja.
• Suporte a versões antigas do sistema operacional. Definir até onde você suporta é decisão de produto com efeito direto no custo de teste.
• Aparelhos reais para testar. Especialmente no Android, a variedade é enorme e o emulador não cobre tudo.
• Contas de desenvolvedor e certificados. Renovação, assinatura, provisionamento. Certificado expirado derruba a publicação no pior momento.
• Migração de versão do framework. Toda base compartilhada tem ciclos de atualização que exigem trabalho, mesmo sem nenhuma funcionalidade nova.

A conclusão prática: um app é um compromisso contínuo, não uma entrega. Se a empresa não tem apetite para manter isso, o PWA passa a ser uma decisão estratégica inteligente, e não um plano B.

Perguntas Frequentes

React Native ou nativo: qual escolher?

React Native costuma ser a escolha mais racional quando já existe um time web, porque mantém a regra de negócio em uma única base de código e permite módulos nativos onde for necessário. Nativo se justifica quando o produto depende intensamente de hardware, exige desempenho gráfico máximo ou precisa de recursos do sistema operacional assim que são lançados. O critério decisivo costuma ser quem vai manter o código daqui a um ano.

PWA substitui um aplicativo nativo?

Substitui em boa parte dos casos de uso, principalmente produtos de conteúdo, gestão e serviços, onde o valor está na informação e não no hardware. Um PWA instala com ícone, funciona em tela cheia, opera offline via cache e atualiza sem revisão de loja. Não substitui quando o produto depende de recursos de hardware avançados ou quando a presença nas lojas é um canal relevante de descoberta.

Preciso mesmo de um aplicativo ou um site responsivo resolve?

Um site responsivo resolve sempre que o uso não é diário, não depende de hardware específico, não precisa funcionar offline e não usa notificação como parte central do produto. Aplicativo se justifica por uso recorrente, hardware, operação offline, notificação essencial ou descoberta pelas lojas. Ter app apenas porque a concorrência tem costuma gerar um ícone que o usuário não abre.

Quanto custa manter um aplicativo depois de publicado?

Além da evolução do produto, existe um custo recorrente independente de novas funcionalidades: atualizações obrigatórias exigidas pelas lojas, suporte a novas versões dos sistemas operacionais, testes em aparelhos reais, renovação de contas e certificados, e migrações de versão do framework. Esse compromisso contínuo precisa entrar na decisão antes da escolha de plataforma.

Flutter é melhor que React Native?

Nenhum é universalmente melhor. Flutter entrega desempenho muito bom e controle fino da interface, mas exige um ecossistema próprio, com linguagem e perfil de contratação diferentes. React Native reaproveita conhecimento de times web e mantém uma base única com acesso a módulos nativos. A escolha certa é a que o time disponível consegue manter e evoluir com autonomia.

Qual a melhor estratégia para lançar um produto mobile do zero?

Começar pela web responsiva, que valida a demanda sem depender de ciclo de aprovação das lojas, transformá-la em PWA quando houver uso recorrente comprovado, e construir o aplicativo apenas quando os dados de uso indicarem quais telas importam, o que precisa funcionar offline e quais recursos de hardware fazem falta. Essa ordem transforma a decisão de plataforma em consequência de evidência, não em aposta.

A decisão certa depende do seu contexto, não do ranking

Não existe resposta universal para essa pergunta, e desconfie de quem der uma sem perguntar nada antes. A escolha depende de quais recursos do aparelho o produto usa, do que precisa funcionar sem conexão, de quem vai manter o código, da frequência com que você precisa publicar e de como o produto ganha dinheiro.

O que a gente vê com frequência: empresa que chegou pedindo aplicativo e saiu com uma web bem construída mais um PWA, gastando uma fração do previsto e chegando ao mercado meses antes. E o inverso também acontece — operação de campo que tentou resolver no navegador, sofreu com a instabilidade de conexão e precisava mesmo de app com sincronização de verdade.

Na Alienhub a gente começa pela pergunta de trás: o que o produto precisa fazer, onde e em que condição. A plataforma é consequência. Se você está nessa decisão agora, fala com a gente ou veja como trabalhamos em aplicativos mobile e arquitetura de software.