Por que uma página no Google Play faz diferença para um SaaS
Uma aba do navegador disputa atenção com todas as outras abas abertas. Um app instalado tem o próprio ícone na tela inicial, na frente do usuário toda vez que ele desbloqueia o celular. Para um SaaS que as pessoas abrem todo dia, essa diferença não é cosmética: ela aparece na retenção.
Ícone na tela inicial
Um lembrete diário do seu produto, onde uma aba acaba esquecida
Notificações push
Trazer de volta usuários inativos, avisar antes do fim de um teste, anunciar novidades
Visibilidade na loja
A busca do Google Play traz usuários que nunca viram o seu site
Sinal de confiança
“Disponível no Google Play” passa segurança para quem ainda está em dúvida
Sem reescrita
Sua stack web é o app: você atualiza o site e o app acompanha
O que o Play Store realmente verifica
A revisão automatizada do Google Play para pacotes de web apps verifica quatro coisas:
- API level alvo — deve ser 36 (Android 16) para todos os novos apps e atualizações desde 31 de agosto de 2026.
- Funcionalidade mínima — pelas regras do Google sobre spam e funcionalidade mínima, o app deve fazer algo útil. Uma página estática de uma tela falha; um app multipage, um dashboard SaaS ou uma plataforma de conteúdo passa.
- Formulário de segurança de dados — você deve declarar quais dados seu app coleta. Obrigatório para todos os apps.
- Assinatura válida — o .aab deve ser assinado com um keystore. O mesmo keystore deve ser usado para cada atualização futura desse nome de pacote.
TWA vs Capacitor: escolher o build certo para sua web app
| Critério | TWA | Capacitor |
|---|---|---|
| Manifest PWA obrigatório | Sim (ícone ≥192px, HTTPS); service worker recomendado, não obrigatório | Não — qualquer URL HTTPS funciona |
| Tamanho do app | Bem leve | Maior: inclui um invólucro nativo |
| Renderização | Navegador Chrome (compartilha cookies/cache) | WebView do sistema (isolado) |
| Notificações push | Web Push do seu site (service worker) | Firebase nativo (mais confiável) |
| Plugins nativos | Não | Câmera, biometria, atalhos |
| API level 36 | ✓ (via Bubblewrap) | ✓ (via Capacitor CLI) |
| Suporte offline | Requer service worker no seu app | Pode injetar SW ou usar cache nativo |
Passo a passo: da URL da web app ao Play Store
1. Executar uma verificação PWA
Cole sua URL em um verificador PWA gratuito. Isso mostra sua pontuação de manifest, se você tem um service worker, e se TWA ou Capacitor é o caminho de build correto. Leva 10 segundos.
2. Configurar a identidade do seu app
Definir um nome de pacote no formato de domínio reverso (com.suaempresa.nomeapp). É permanente — identifica seu app no Play Store para sempre.
3. Construir o .aab assinado
Um build pago do SaasToStore gera o Android App Bundle assinado. Seu keystore é criado no primeiro build pago, guardado criptografado e reutilizado em cada atualização; a senha chega para você uma vez por e-mail. O build tem como alvo o API level 36 (Android 16) automaticamente e leva alguns minutos.
4. Criar uma conta no Play Console
Registrar-se em play.google.com/console e pagar a taxa única de 25$ para desenvolvedor. A verificação de identidade geralmente leva 1–2 dias.
5. Criar um novo app e fazer upload
No Play Console, criar novo app → pista de produção → fazer upload do .aab. Completar as seções obrigatórias: conteúdo do app, público-alvo, declaração de segurança de dados, questionário de classificação de conteúdo, URL de política de privacidade. Em seguida, enviar para revisão.
Preparar a página do app e evitar rejeições
Antes de enviar, a página do app no Google Play precisa estar completa. Veja o que ela pede. O SaasToStore pode gerar para você o ícone, o gráfico de destaque, as capturas e um primeiro rascunho das descrições.
Arquivo do app
Um .aab assinado
Ícone
PNG de 512×512 px
Gráfico de destaque (feature graphic)
1024×500 px
Capturas de tela
Pelo menos 2, de celular
Descrição curta
Até 80 caracteres
Descrição completa
Até 4.000 caracteres
Política de privacidade
Uma URL pública
Os quatro erros que mais travam uma primeira publicação:
Perder o keystore
Sem a chave original, não dá para publicar uma atualização com o mesmo nome de pacote. O SaasToStore cria a chave de cada app no primeiro build pago, guarda-a criptografada e a reutiliza em cada atualização; a senha chega para você uma vez por e-mail.
Enviar sem política de privacidade
Publique uma política de privacidade e informe a URL dela antes de enviar o app. O SaasToStore pode gerar uma para você.
Um ícone no tamanho errado ou com transparência
Prepare um PNG quadrado de 512×512 px com fundo sólido. O Google Play arredonda os cantos sozinho.
Um site sem HTTPS
Ative o HTTPS na sua hospedagem antes de iniciar o build: sem HTTPS, nenhum wrapper funciona.
Quanto custa publicar
Do lado do Google, o cadastro de desenvolvedor do passo 4 custa 25$ uma única vez e vale para todos os apps que você publicar com essa conta. O outro custo é produzir o bundle assinado. Na mão, as ferramentas são gratuitas: a CLI Bubblewrap do Google para uma TWA, a CLI do Capacitor para um invólucro nativo. Você paga com tempo: instalar e manter o SDK do Android e o Java, depurar os builds que falham e guardar uma chave de assinatura que nunca pode ser perdida. Um builder hospedado cuida de tudo isso e guarda a chave para cada atualização.
Com o SaasToStore, o build de teste gratuito é um APK com o logo do SaasToStore, para ver o app no seu próprio celular. O .aab que você envia ao Google Play vem com um build pago: veja os preços.
O que muda para um SaaS: login e notificações push
Login: quase nunca é preciso mudar algo
Sua autenticação atual (Supabase, Auth0, Clerk, suas próprias sessões) continua funcionando no app. E-mail e senha ou códigos de uso único se comportam como no seu site; os magic links também, depois que os deep links os levam para o app. Em uma TWA, o app compartilha os cookies do Chrome: um usuário que já entrou pelo Chrome nesse celular muitas vezes já está logado no app também. Um build nativo Capacitor tem a própria sessão: o usuário faz login uma vez no app. A exceção é o Google: ele recusa o login dentro de uma WebView incorporada, então o app nativo abre "Fazer login com o Google" no navegador do sistema e depois traz o usuário de volta. Esse retorno exige autorizar um endereço no seu provedor de autenticação.
Notificações push para a retenção
O push é a principal alavanca de retenção que um app de loja dá a um SaaS. As mensagens que funcionam melhor:
- — O teste termina em 3 dias, com um link para assinar
- — Nova atividade em algo que o usuário acompanha: um comentário, uma menção, uma atualização
- — Um resumo semanal, ou um marco de uso atingido
- — Um novo recurso, enviado aos usuários ativos
- — Um lembrete depois de 7 dias sem visita
No build nativo, as notificações saem do próprio app: as notificações de navegador do seu site não passam para o app.
Além do Google Play
A mesma sessão de build que produz seu Google Play AAB também pode gerar um Windows .msi, macOS .dmg e Linux .AppImage — publicados no Microsoft Store, no Snap Store, no Flathub e no GitHub Releases. Se você vai empacotar sua web app uma vez, não há custo marginal para alcançar todos os 7 stores no mesmo build.
No Android, o mesmo app também vai para a Amazon Appstore e a Samsung Galaxy Store, e a mesma URL gera um app de iPhone para a App Store. Seu site foi feito com uma ferramenta no-code? Veja os guias de Lovable, Bubble e Webflow.
Verifique se sua web app está pronta para os stores
Verificação PWA gratuita — pontuação de manifest, status do service worker, recomendação de caminho de build. 10 segundos.
Verificar meu app →