Aplicativo web progressivo - quando não precisa de app e o site como aplicação basta

Um aplicativo web progressivo (PWA) é um site que se instala na tela inicial, abre quase como um app nativo e pode funcionar offline ou com internet fraca. Para muitos negócios um lançamento completo na App Store e no Google Play são meses e orçamento a mais: catálogos, áreas do cliente, agendamentos, cardápios e portais B2B costumam resolver com uma PWA sobre HTML, CSS e JavaScript comuns. Abaixo - quando o «site como app» basta, quais tecnologias são obrigatórias e onde o nativo ainda é necessário.

• PWA - site + manifesto + service worker: ícone, tela cheia, cache, às vezes push
• Não substitui qualquer app - gráficos pesados, acesso profundo ao dispositivo e SLAs rígidos da App Store ficam no nativo
• Um codebase - uma versão web em vez de equipes iOS/Android separadas no início
• Atualizações sem lojas - publicou no servidor: o usuário recebe a nova versão na próxima visita
• SEO permanece - ainda são páginas na busca, não um binário fechado
• Checklist inicial - HTTPS, manifest.webmanifest, service worker, responsivo e First Contentful Paint rápido

O que é PWA em palavras simples

PWA (Progressive Web App) é um conjunto de práticas e APIs web com as quais o site se comporta como um aplicativo instalado:

1. Instala no telefone ou no desktop pelo navegador (ícone, janela própria sem a barra de endereço habitual).
2. Abre rápido graças ao cache do shell (casca da interface).
3. Aguenta rede ruim - mostra telas em cache ou enfileira ações para «enviar depois».
4. Parece nativo - splash, theme-color, display: standalone.

Não é outra linguagem nem «mais um framework». É o seu site atual, levado a critérios de installability e entrega confiável de conteúdo. No Chrome, Edge, Safari e Firefox o cenário básico já é maduro; restam nuances em push, sync em segundo plano e parte das APIs do dispositivo.

Quando o site como aplicação basta

A PWA vale a pena quando o produto é, em essência, uma interface de dados no navegador, não um jogo nem uma ferramenta de sistema.

Bons candidatos:

Se o usuário volta várias vezes por semana, quer um ícone «como o do banco» e UX estável no metrô sem rede - a PWA cobre a expectativa sem review da App Store.

Quando é melhor um app nativo

Uma resposta honesta vale mais que o marketing «PWA substitui tudo»:

• são necessárias tarefas em segundo plano rígidas, Bluetooth / NFC complexo ou sensores de baixo nível;
• são críticos o desempenho 3D/AR, câmera pesada e jogos offline;
• o produto precisa viver só nas lojas (vitrines de parceiros, MDM corporativo que exige nativo);
• você precisa de pagamentos e assinaturas estritamente via IAP Apple/Google como canal principal;
• a equipe já mantém times fortes de iOS/Android e a web é secundária.

Compromisso comum em 2026: PWA ou site responsivo para todos + app nativo só onde as métricas provarem demanda (retenção, fatia de tráfego mobile, visitas repetidas).

Do que uma PWA é feita

O mínimo sem o qual não há «progressividade»:

1. HTTPS

Service worker e installability exigem origem segura. O localhost local é exceção para desenvolvimento.

2. Web App Manifest

O arquivo manifest.webmanifest (ou JSON) descreve nome, ícones (em geral 192 e 512), start_url, display, cores do tema. Sem ele o navegador não oferecerá «Instalar aplicativo».

3. Service Worker

Script em segundo plano: cacheia o shell e o estático, serve fallback offline, às vezes enfileira POST quando a rede cai. Estratégias típicas: cache-first para CSS/JS/ícones, network-first para API e preços.

4. UI responsiva e rápida

PWA não salva um site lento. É preciso responsivo, compressão de imagens e um bundle razoável de JavaScript. Caso contrário, instalam o «app» uma vez e apagam.

5. Opcional: push, Share Target, shortcuts

Push e badge aumentam retenção, mas complicam consentimento e política de notificações. Shortcuts no manifesto dão ações rápidas com toque longo no ícone.

Efeito de negócio: números sem ilusões

Compare orçamento e ciclo de release, não «está na moda / não».

A economia é real na validação de hipótese e em serviços onde conteúdo e formulários importam mais que acesso a hardware. A economia some se você promete «sensação bancária nativa com biometria complexa e geo-triggers em segundo plano» - aí o nativo cabe melhor.

Checklist de implantação em um site existente

1. Fechar velocidade e responsivo básicos - senão a PWA só cristaliza um UX ruim.
2. Publicar o manifesto e o conjunto de ícones (tema claro/escuro se necessário).
3. Registrar o service worker com política de cache clara; não cachear dados pessoais sem expiração.
4. Verificar installability no Chrome DevTools / Lighthouse (categoria PWA).
5. Testar Safari (iOS) - instalação via «Adicionar à Tela de Início»; push e parte das APIs diferem do Android.
6. Medir instalações e caminhos «abriu pelo ícone» vs «chegou pelo link».
7. Não quebrar a indexação - o conteúdo deve permanecer em URLs normais; PWA é camada, não beco SPA sem SSR/prerender.
8. Descrever o offline com honestidade - o que funciona sem rede e o que não.

Em construtores de sites depende da plataforma: às vezes PWA liga com um interruptor, às vezes precisa de hosting próprio e código customizado. O princípio é o mesmo - manifesto + worker + HTTPS.

Erros comuns

• Chamar de PWA qualquer site responsivo sem service worker e manifesto.
• Cachear API de preços e estoque «para sempre» - o usuário vê a tabela de ontem.
• Prometer «como na App Store» e ao mesmo tempo cortar orçamento de UX e performance.
• Ignorar iOS: testar só Android Chrome.
• Montar SPA pesado sem indexação e perder tráfego de busca.
• Ativar push agressivo na primeira visita - bloqueiam notificações e a marca.

Conclusão

Um aplicativo web progressivo é o caminho pragmático quando você precisa de «ícone na tela + revisitas rápidas», não de um produto nativo completo para as duas plataformas. Para catálogos, portais, agendamentos e ferramentas internas, o site como aplicação muitas vezes basta. Para jogos, hardware profundo e monetização centrada em lojas - planeje nativo. Comece por HTTPS, manifesto, service worker e velocidade; o resto é iteração sobre retenção, não sobre hype.

Perguntas frequentes

Em que uma PWA difere de um site mobile comum?

Um site responsivo comum abre numa aba do navegador. Uma PWA adiciona installability (ícone, janela standalone), service worker para cache e offline, e um manifesto com metadados do app. Visualmente pode ser o mesmo design, mas o modelo de entrega e de retorno se aproxima de um aplicativo.

Dá para publicar uma PWA na App Store e no Google Play?

O Google Play é relativamente amigável a Trusted Web Activity / wrappers de PWA. A App Store é mais rígida: um simples «site em casca» costuma ser rejeitado sem valor nativo claro. Para a maioria o canal principal da PWA é o navegador e «Adicionar à Tela»; lojas são outro produto com outros requisitos.

Uma PWA funciona totalmente offline?

Raramente por completo. Em geral ficam offline o shell, páginas já abertas e o estático. Preços ao vivo, conta e pagamentos precisam de rede. Uma boa PWA mostra com honestidade o que está indisponível e, se preciso, enfileira ações até a internet voltar.

É preciso um domínio ou subdomínio separado para a PWA?

Um domínio separado não é obrigatório. Importa mais um origin estável (esquema + host + porta), um start_url correto e atualizações do service worker que não conflitem com cache antigo. Às vezes a app vai para app.example.com, mas isso é escolha organizacional, não exigência da especificação.

Por onde começar se o site já está no WordPress, Tilda ou stack próprio?

Verifique se a plataforma oferece manifesto e service worker de fábrica. Se não - adicione o manifesto estático, um worker mínimo do shell e ícones; no stack próprio costuma ser um sprint. Depois meça Core Web Vitals, teste instalação em Android e iOS e defina a política de cache da API. Não comece pelo push: primeiro garanta instalação rápida e reabertura estável.