PWA vs app nativo: por que escolhi PWA para um produto de torneios

A primeira pergunta que recebo quando alguém vê o BeachTennis Manager rodando é: "por que não está na App Store?"

A resposta curta: porque PWA cobre 100% dos meus requisitos, e App Store me custaria muito sem me dar quase nada. A resposta longa é esse post.

O que o usuário precisava

O contexto importa. O BeachTennis Manager nasceu para resolver um problema específico: organizar torneios de Beach Tennis na praia. Os requisitos vieram da observação do que dói no fluxo real:

1. Funcionar no celular (uso primário é em pé, na quadra, com sol)
2. Funcionar offline (sinal na praia é horrível, e o juiz precisa registrar placar mesmo sem 4G)
3. Sincronizar quando voltar online (organizador anota no celular, espectadores acompanham no tablet)
4. Instalável (sem precisar abrir browser e digitar URL toda vez)
5. Compartilhável (espectadores precisam acompanhar sem instalar nada)
6. Atualização rápida (eu corrijo um bug no domingo de manhã, e na partida da tarde o app já está atualizado)

Note que não está na lista: notificações push, integração com câmera, geolocalização, integração com saúde, Live Activity, Apple Watch, ARKit. Nenhuma API exclusiva de nativo.

Essa é a primeira pergunta crítica.

A pergunta-chave: você precisa de API nativa?

A escolha entre PWA e nativo deveria ser, em primeiro lugar, uma questão de capacidades, não de "estética".

Tem coisas que só nativo entrega:

• Live Activity / Dynamic Island (iOS)
• App Intents do Siri / Atalhos
• Integração com Apple Health, Samsung Health
• Apple Watch / Wear OS
• Background processing real (BackgroundTasks framework)
• ARKit, ARCore, Core ML on-device
• Acesso a Bluetooth de baixo nível
• Push notifications confiáveis no iOS (PWA tem limitações)

Tem coisas que PWA também faz:

• Offline (com Service Worker)
• Instalação na home screen
• Câmera, microfone, geolocalização (via Web APIs)
• Push notifications (no Android, e iOS desde 16.4)
• Touch ID / Face ID via WebAuthn
• Compartilhar nativo (Web Share API)

Para o BeachTennis Manager, nada da lista do nativo era requisito. Toda a lista de PWA cobria.

Decisão: PWA.

O que PWA me deu de bônus

Além de cobrir os requisitos, PWA me deu coisas que App Store não dá:

1. Deploy em segundos. git push → Vercel deploya → próximo refresh do app já tem a nova versão. Não tem fila de revisão. Não tem "esperando aprovação". Não tem "rejeitado, refaça".

2. URL compartilhável. Cada torneio tem uma URL pública. Espectador clica no link no WhatsApp e abre o ranking ao vivo, sem instalar nada. Em app nativo, isso seria deep link com fallback pra App Store. Bem mais frágil.

3. Sem 30% da App Store. Se um dia o app monetiza com assinatura, recebo 100%. App Store cobra 30% do primeiro ano e 15% depois (15% sempre se você for "small business" — abaixo de US$ 1M/ano).

4. Independente de plataforma. Mesmo código roda em Android e iOS. Em nativo, eu teria que fazer Swift + Kotlin (ou tentar Flutter / React Native, com seus próprios trade-offs).

5. Sem Apple Developer Program. US$ 99/ano de fee. Nada absurdo, mas é um custo recorrente que não preciso pagar.

O que perdi indo de PWA

Não é tudo flores. Com PWA, eu perdi:

1. Confiança de marca. "Tem na App Store" tem peso. Usuários menos técnicos confiam mais em apps da loja oficial. PWA tem esse atrito de "como assim, abro pelo navegador?".

2. Push notifications no iOS antes de 16.4. Em iOS antigo, PWA não recebe push. Em 16.4+, recebe se foi instalado na home screen. Cobertura ainda é menor que nativo.

3. Background sync robusto. Se o usuário fechar o navegador completamente, o Service Worker some. App nativo pode rodar em background com BackgroundTasks. Para o BeachTennis, isso não é crítico — mas seria pra um app de fitness, por exemplo.

4. Acesso a APIs futuras do iOS. Apple historicamente subinveste em web APIs no Safari. Se uma feature nova do iOS sair, ela vai pro nativo primeiro (e muitas vezes nunca chega no Safari).

5. Onboarding um pouco mais friccionoso. Em iOS, instalar PWA é "compartilhar → adicionar à tela de início". Em Android, é "três pontinhos → instalar app". Na App Store, é "baixar e abrir". O segundo é mais familiar.

A heurística que uso

Depois de fazer essa decisão para três produtos diferentes, minha heurística virou:

Vai de PWA se:

• Nenhuma API exclusiva de nativo é requisito
• Atualização rápida é importante
• O app tem uma versão "compartilhável" (link, embed)
• Você é solo ou time pequeno
• O usuário-alvo é tech-friendly o suficiente para "instalar pelo navegador"

Vai de nativo se:

• Pelo menos uma API exclusiva é requisito real
• Você precisa de visibilidade na App Store (descoberta orgânica)
• O usuário-alvo espera ver o app na loja
• Você tem time/orçamento pra manter Swift + Kotlin
• A monetização compensa o 15-30% da loja

Vai dos dois se:

• O produto tem ambos os requisitos
• O orçamento permite manter três bases (web, iOS, Android)
• Você está em scale-up, não em MVP

Para projeto pessoal, hobby project ou MVP, a resposta tende a ser PWA na maioria dos casos. Existe um viés histórico de "app de verdade vai pra App Store", mas em 2026 esse viés faz cada vez menos sentido.

Quando eu mudaria de ideia

Se um dia o BeachTennis Manager precisar de:

• Apple Watch companion (registrar placar pelo pulso do juiz na quadra) — imediato, isso é nativo
• Live Activity para acompanhar partidas em andamento (placar na tela de bloqueio) — nativo
• Push notifications confiáveis se eu tivesse muitos usuários iOS antes de 16.4

Aí eu adicionaria uma versão nativa complementar à PWA. Não para substituir. PWA seria a versão pública, compartilhável, no navegador. Nativo seria pra power users que querem as integrações do sistema.

A regra que aplico: PWA primeiro; nativo quando uma API exclusiva vira requisito real.

A recomendação prática

Se você está construindo um SaaS solo em 2026 e está achando que precisa de app nativo "porque todo mundo tem", para um momento e responde:

1. Que API nativa eu uso?
2. Meu usuário-alvo procura o app na loja, ou clica em link?
3. Eu consigo manter Swift + Kotlin + Web simultaneamente?

Se a resposta da 1 é "nenhuma" e a da 3 é "não", PWA tende a ser o caminho. Chega mais rápido no usuário, custa menos pra manter, e cobre boa parte do que app nativo cobre.

A parte que falta você adiciona quando virar requisito real, e dificilmente antes disso.