PWA: seu negócio precisa de um app ou de um webapp?

O reflexo de pedir um app

Quando um cliente fala “preciso de um app”, na maioria das vezes o que ele precisa é de um sistema que funcione bem no celular. Não de um aplicativo publicado na App Store e Google Play.

A confusão é compreensível. “App” no imaginário popular é sinônimo de “coisa que funciona no celular”. Mas entre o que o cliente precisa e um app nativo publicado nas lojas, existe um caminho mais rápido e mais barato que entrega praticamente o mesmo resultado.

A diferença entre os caminhos é grande em custo e prazo. Já vi cliente gastar R$ 80k num app nativo que poderia ter sido um PWA de R$ 25k com a mesma experiência pro usuário final.

O problema vai além do custo inicial. App nativo cria uma dependência contínua: cada atualização de iOS ou Android pode exigir ajustes, a taxa anual da Apple Developer Account é US$ 99, e cada versão nova precisa passar pelo processo de review. Com PWA, você atualiza o site e todo mundo recebe a versão nova instantaneamente.

O que é PWA na prática

PWA é Progressive Web App. Na prática: um site que se comporta como aplicativo. O usuário acessa pelo navegador, adiciona à tela inicial do celular e usa como se fosse app nativo.

O que funciona:

• Ícone na tela inicial (parece app nativo quando o usuário olha pro celular)
• Tela cheia sem barra do navegador (abre como app, não como site)
• Funciona offline ou com conexão fraca (dados em cache ficam disponíveis)
• Notificações push no Android (iOS tem limitações mas tá melhorando)
• Acesso a câmera e GPS
• Atualização automática e transparente (sem o usuário ir na loja baixar update)

O que ainda não funciona bem:

• Bluetooth e NFC (limitado em alguns navegadores)
• Integração profunda com hardware específico (sensores avançados, AR nativo)
• Presença na App Store da Apple como app nativo (pode publicar, mas não é o caminho natural)

Pra 80% dos casos de uso que atendo, o que funciona é mais que suficiente.

Do ponto de vista técnico, PWA se resume a três componentes: um arquivo manifest.json que descreve o app (nome, ícone, cor de fundo, orientação da tela), um Service Worker que gerencia cache e funcionamento offline, e o próprio webapp responsivo. São menos de 100 linhas de configuração em cima de um site que já existe. Não é um framework novo — é uma camada sobre o que você já tem.

A conta real

Vou abrir os números porque essa é a comparação que importa na hora de decidir.

App nativo (iOS + Android)

• Precisa de dois desenvolvimentos separados. Swift/SwiftUI pra iOS, Kotlin pra Android. Ou React Native/Flutter, que é um codebase só mas ainda assim é desenvolvimento mobile com suas complexidades
• Submeter pra App Store da Apple pode levar dias ou semanas. E pode ser rejeitado por motivos que vão de interface até regras de negócio. Google Play é mais rápido mas tem regras próprias
• Cada nova versão precisa ser submetida, aprovada e baixada pelo usuário. Se o usuário não atualiza, roda versão antiga com bugs corrigidos na nova
• Atualizações de iOS e Android podem quebrar coisas. Novo iPhone com tela de tamanho diferente pode precisar de ajuste. Deprecação de APIs do sistema operacional exige atualização
• Custo: R$ 40.000 a R$ 150.000+ pra um app funcional nos dois sistemas. Com backend, design e integrações, pode passar de R$ 200k fácil
• Prazo: 3 a 6 meses até a primeira versão publicada

PWA

• Um desenvolvimento só. É um webapp responsivo com camada de PWA (service worker, manifest, offline support). Funciona em qualquer dispositivo com navegador moderno
• Publicou o site, tá no ar. Sem aprovação de loja, sem review, sem espera
• Atualização automática e transparente. O service worker detecta nova versão e atualiza em background. O usuário sempre tem a versão mais recente
• É um site. Atualiza o site, atualiza o “app”. Sem preocupação com versão de iOS ou Android
• Custo: o mesmo de um webapp. R$ 15.000 a R$ 50.000 dependendo da complexidade. Faixas detalhadas aqui
• Prazo: 4 a 12 semanas, mesmo prazo de um webapp

A diferença de custo pode ser de 3x a 5x. E o resultado pro usuário final é praticamente idêntico na maioria dos casos.

Tem um custo oculto do app nativo que poucos mencionam: manutenção. Apple lança iOS novo todo setembro. Google lança Android novo todo outubro. Cada versão pode deprecar APIs, mudar permissões ou alterar comportamento de notificações. Se o app não é atualizado, a loja pode remover da listagem. Com PWA, o navegador é que se atualiza — e navegadores mantêm compatibilidade retroativa muito melhor que sistemas operacionais mobile.

Cases reais: PWA em produção

AutoPars

O AutoPars é marketplace de autopeças com 3 painéis (comprador, vendedor, admin). O vendedor precisa responder pedidos pelo celular, muitas vezes no balcão da loja com uma mão segurando peça e outra no celular.

Se tivesse feito app nativo, seriam dois apps (iOS + Android) por painel, totalizando 6 builds separados. Seis processos de aprovação, seis pipelines de deploy, seis versões pra manter. Com PWA, é um webapp responsivo que o vendedor adiciona à tela inicial e usa como app. Atualização é automática. Se corrijo um bug às 14h, às 14h01 todo mundo tem a correção.

FitPlan

O FitPlan é plataforma pra academias com 6 painéis. O aluno abre o app no celular pra ver o treino do dia, assistir vídeo de exercício e registrar evolução. O personal usa pra montar treinos e acompanhar alunos.

PWA foi a escolha natural. O aluno instala em 10 segundos (sem App Store, sem download de 80 MB), e o sistema de notificação avisa quando ele tá há 6 dias sem treinar. Essa notificação ajudou a reduzir cancelamento em 37%.

Outro detalhe: o personal monta treino no computador da academia e o aluno visualiza no celular. Se fosse app nativo, seria necessário desenvolver e manter versão desktop separada ou forçar o personal a usar o celular pra tudo. Com PWA, a mesma aplicação funciona em qualquer tela — desktop, tablet, celular — sem desenvolver nada extra.

Mariah

O app da Mariah (controle de encomendas) também é PWA. Minha irmã de 15 anos instalou no celular entre uma aula e outra. Sem App Store, sem conta de desenvolvedor, sem configuração. Acessou o link, clicou em “Adicionar à tela inicial”, e pronto.

Quando o app nativo faz sentido

PWA não resolve tudo. App nativo é a escolha certa quando:

• Jogo ou aplicação com performance gráfica pesada. PWA não consegue rodar motor 3D com a mesma fluidez que app nativo
• Produto que depende de Bluetooth, NFC ou sensores avançados. Controle de dispositivos IoT, pagamento por aproximação, realidade aumentada nativa
• Produto B2C com milhões de usuários onde presença na App Store é canal de aquisição. Se o público busca “app de delivery” na App Store, você precisa estar lá. Se o público acessa via link direto, não precisa
• Requisito regulatório que exige app nativo. Alguns setores (bancos, saúde) têm regulações específicas sobre distribuição de software

E o React Native / Flutter?

São opções intermediárias. Um codebase que gera apps nativos pra iOS e Android. Custo menor que nativo puro, mas ainda maior que PWA. E ainda precisa de aprovação de loja, processo de deploy mobile, e manutenção de compatibilidade.

Faz sentido quando você precisa de funcionalidades nativas reais (push notification avançada no iOS, Bluetooth) mas quer manter um codebase só. Pra a maioria dos projetos que atendo, PWA resolve antes de chegar nessa decisão.

Três perguntas pra decidir

Se tá na dúvida entre PWA e app nativo, responda essas três perguntas:

1. Seu público vai buscar o produto na App Store? Se sim, considere nativo ou React Native. Se não (se o acesso é por link direto, QR code ou indicação), PWA resolve.

2. Precisa de hardware específico (Bluetooth, NFC, sensores)? Se sim, nativo. Se não, PWA.

3. Seu orçamento e prazo permitem desenvolvimento mobile duplo? Se não (e na maioria dos MVPs não permite), PWA é o caminho viável.

Na maioria dos projetos que atendo, a resposta pra todas é: PWA. O app nativo fica como evolução futura, se os dados de uso justificarem o investimento.

O futuro do PWA

Apple tem melhorado o suporte a PWA no iOS a cada versão. Push notifications, instalação mais intuitiva, melhor integração com o sistema. A tendência é a diferença entre PWA e app nativo ficar cada vez menor.

Google já trata PWAs como cidadãos de primeira classe no Android. Instalação é nativa, notificações funcionam sem limitação, e a experiência é indistinguível de app nativo pra maioria dos usuários.

O que importa é se o seu caso específico precisa do que só app nativo entrega. Na maioria das vezes, não precisa.

O Web Bluetooth API, por exemplo, já permite comunicação com dispositivos BLE em Chrome e Edge. Web NFC funciona no Chrome Android. APIs como Web Share, Contact Picker e File System Access estão expandindo o que PWAs conseguem fazer a cada release de navegador. A cada ano, a lista de “coisas que só app nativo faz” fica menor.