PWA ou app nativo: o que muda na prática

A resposta curta: PWA quando a distribuição pela loja não é o ponto; nativo quando o produto depende de recurso profundo do aparelho ou de estar na loja. A escolha quase nunca é sobre qualidade da tecnologia — é sobre quem controla a distribuição e a atualização.

O que é PWA, sem jargão

PWA é um site que o navegador deixa instalar como aplicativo. A pessoa acessa um endereço, escolhe "adicionar à tela inicial", e ele ganha ícone, abre em tela cheia sem barra de endereço e continua abrindo mesmo com a internet oscilando.

Por baixo é web. Por cima, para quem usa, se parece com aplicativo.

App nativo é um programa construído para cada sistema, distribuído pela App Store e pelo Google Play, instalado pelo mecanismo do próprio aparelho.

As quatro diferenças que decidem

O resto é detalhe. Estas quatro são as que mudam a decisão.

1. Quem controla a atualização

No PWA, você publica e a próxima abertura já traz a versão nova. Corrigiu um erro às 14h, está corrigido às 14h01 para todo mundo.

No nativo, cada versão passa por revisão da loja antes de chegar a alguém. Depois de aprovada, ainda depende de a pessoa atualizar — e uma parte do público simplesmente não atualiza, o que significa manter versões antigas funcionando.

Para produto que muda com frequência, isso é a diferença entre corrigir e esperar.

2. Quem controla a distribuição

Estar na loja tem valor real: as pessoas procuram lá, confiam no que está lá, e em alguns setores o cliente pergunta "vocês têm app?" querendo dizer "está na loja?".

O preço disso é depender de aprovação. As lojas têm regras próprias, mudam essas regras, e podem recusar ou remover. Não é hostilidade — é que a decisão não é sua.

O PWA não tem essa dependência, e também não tem essa vitrine. Ele é encontrado como um site é encontrado.

3. O que o aparelho deixa fazer

Aqui o nativo ainda está na frente, mas a distância é menor do que a fama sugere. Câmera, geolocalização, notificação, armazenamento local e leitura de arquivo funcionam bem em PWA.

O que continua sendo território do nativo: Bluetooth de baixa energia com dispositivo específico, NFC para pagamento, sensor do aparelho em taxa alta, processamento pesado em segundo plano, e integração profunda com o sistema (widget, contato, atalho de sistema).

Se a sua lista de requisitos não tem nada disso, o argumento técnico a favor do nativo é mais fraco do que parece.

4. O iPhone tem uma regra que muda a conta

Vale destacar porque é o detalhe que mais pega gente de surpresa: no iPhone, um PWA só envia notificação push se a pessoa tiver instalado o app na tela inicial. Sem a instalação, não há push.

Se o seu produto depende de notificação para funcionar — lembrete de agendamento, alerta de operação, aviso de pedido — e boa parte do seu público usa iPhone, essa restrição pesa muito. Ou você trabalha para conseguir a instalação, ou considera nativo.

Onde os dois se parecem mais do que se diz

Alguns argumentos comuns não sobrevivem ao contato com a realidade:

"App nativo é mais rápido." Depende inteiramente de como foi feito. Um PWA bem construído é mais rápido que um app nativo malfeito, e vice-versa. Velocidade é resultado de decisão de engenharia, não de plataforma.

"PWA não funciona offline." Funciona parcialmente, e é isso que a maioria dos casos precisa: continuar abrindo e mostrar o que já foi carregado. O que exige projeto específico — em PWA ou em nativo — é operação que grava horas de dado sem conexão e sincroniza depois. Nesse caso a complexidade está na sincronização, não na plataforma.

"App na loja passa mais confiança." Passa, para uma parte do público. Para outra, instalar aplicativo é atrito e a pessoa desiste. Qual pesa mais depende de quem é o seu usuário, e essa é uma pergunta que só você responde.

Quando a opção mais barata é a certa

Com frequência.

Se o seu app é para uso interno da equipe, o PWA costuma ser a escolha certa e não só a mais barata: você distribui por link, atualiza na hora, e ninguém precisa passar por loja para usar a ferramenta de trabalho.

Se é para cliente que já está no seu WhatsApp ou no seu site, o PWA aproveita esse caminho: a pessoa clica e usa, sem baixar nada.

O nativo se justifica quando a loja é canal de aquisição — as pessoas vão procurar você lá — ou quando um dos recursos profundos da lista acima é requisito, não desejo.

O que ninguém pode prometer

Publicação em loja não depende de quem desenvolve. Depende de conta de desenvolvedor, taxas anuais cobradas pela Apple e pelo Google, e da aprovação de cada uma delas. Uma agência que garante publicação está prometendo uma decisão que não é dela.

O que dá para garantir é o app pronto, testado e submetido em conformidade com as regras vigentes — e o acompanhamento se houver exigência na revisão.

O que o cliente precisa fornecer

Nos dois casos: as regras do processo que o app automatiza, com as exceções. As exceções são o que mais muda escopo, e são também o que o cliente mais esquece de contar, porque para quem convive com elas todo dia elas parecem óbvias.

No caso do nativo, também: contas de desenvolvedor Apple e Google no nome da sua empresa. Elas precisam ser suas, não de quem desenvolve — senão o app fica preso a um terceiro.

Como o preço se comporta

Na SrZuim, os apps da Fase 1 são PWA, e isso está dito na categoria: aplicativos PWA. Os produtos publicados — app institucional, app de agendamento, app de equipe externa — trazem cada um o que está incluído e quando não servem.

Empacotamento para loja não está incluído em nenhum deles, e aparece separado como custo de terceiro, porque taxa de loja é cobrança da Apple e do Google, não nossa. Misturar isso no preço esconderia um custo recorrente que é seu.

O próximo passo

Se a decisão travou em "mas e se depois eu precisar da loja?", esse é um bom sinal de que a conversa precisa ser sobre o produto, não sobre a plataforma. O diagnóstico tem uma etapa só para requisitos — inclusive integração com máquina e com sistema existente — e é ali que essa dúvida se resolve com informação em vez de suposição.