Quase toda conversa sobre aplicativo chega, cedo ou tarde, à mesma pergunta: precisa mesmo ir para a loja? O PWA aparece como resposta fácil — um site que se instala, funciona offline e manda notificação, sem passar pela Apple nem pelo Google. A promessa é verdadeira em parte, e a parte que falta costuma aparecer só depois que o projeto foi contratado.
Este guia explica o que é PWA para quem decide o projeto: o que precisa existir no site para ele ser instalável, o que muda entre Android e iPhone segundo a documentação oficial dos navegadores, e em quais casos o PWA resolve sozinho ou a loja continua sendo o motivo do app.
O que é PWA (Progressive Web App)?
PWA é a sigla de Progressive Web App. A definição da documentação do MDN, mantida pela Mozilla, é direta: um app construído com as tecnologias da web, mas que oferece uma experiência parecida com a de um aplicativo feito para um sistema específico. Por baixo, continua sendo um site — HTML, CSS e JavaScript, num endereço que qualquer navegador abre.
A diferença é o que acontece depois da visita. Um site comum é um lugar que a pessoa visita; um PWA pode virar algo que ela tem no aparelho. Instalado, ele ganha ícone ao lado dos outros apps, abre em janela própria, sem barra de endereço, e pode funcionar sem conexão e receber mensagens do servidor quando o projeto prevê isso.
O "progressive" do nome é literal: o mesmo código entrega mais recursos onde o navegador suporta e continua funcionando como site onde não suporta. Quem abre num navegador que não instala PWA usa a versão web normalmente. É por isso que a mesma pergunta — "o PWA manda notificação?" — tem respostas diferentes conforme o aparelho de quem pergunta.
O que um PWA tem que um site comum não tem?
Dois componentes técnicos separam um PWA de um site responsivo. O primeiro é obrigatório; o segundo, não — e confundir os dois é a origem de boa parte das promessas exageradas.
- Manifest (web app manifest): um arquivo JSON que diz ao navegador como o app deve aparecer e se comportar no aparelho — nome, ícones, endereço inicial e modo de exibição. Sem ele, não há instalação no sentido de PWA. Se o site tem várias páginas, todas precisam apontar para o manifest.
- Service worker: um script que roda em segundo plano, intercepta as requisições e permite guardar conteúdo para uso sem internet, além de receber mensagens push. O MDN é explícito: ele não é requisito para o PWA ser instalável, embora muitos PWAs o usem para oferecer a experiência offline.
Na prática, isso significa que "ser PWA" não garante nada além da instalação. Offline e notificação são funcionalidades que alguém precisa desenhar, programar e testar. Se a proposta comercial diz "PWA com offline" e não diz o que fica disponível sem internet, o escopo ainda não foi escrito.
Qual a diferença entre PWA, site responsivo e app nativo?
Os três resolvem o acesso pelo celular, mas com custo, alcance e dependência diferentes. A comparação abaixo usa o que a documentação do MDN descreve para cada modelo:
| Site responsivo | PWA | App nativo (loja) | |
|---|---|---|---|
| Como o usuário chega | Busca, link, anúncio | Busca e link; pode instalar a partir do site | Busca dentro da App Store ou do Google Play |
| Código | Uma base para todos os aparelhos | Uma base para todos os aparelhos | Em geral, uma por sistema (iOS e Android) |
| Ícone no aparelho | Não, salvo atalho manual | Sim, depois de instalado | Sim |
| Funciona sem internet | Não | Se o service worker for programado para isso | Sim, conforme o app |
| Notificação push | Só com service worker, no Android e no computador; no iPhone, não | Sim no Android; no iPhone, só instalado na Tela de Início | Sim |
| Aprovação de loja | Não | Não (é opcional empacotar e publicar) | Sim, pelas regras de cada loja |
| Indexado pelo Google | Sim | Sim | O conteúdo do app, não; a página dele na loja, sim |
Comparativo elaborado pela Alliance Comunicação a partir da documentação de PWA do MDN Web Docs e do anúncio do WebKit sobre o iOS 16.4.
O ponto que mais pesa para empresa é a última linha. O PWA continua sendo um site: é encontrado na busca e compartilhado por link, coisa que o app de loja não faz. Por isso ele raramente substitui o site — ele é o site, com uma camada a mais. Quem ainda não resolveu a versão móvel deve começar por ela: o guia sobre o que some do site responsivo no celular mostra o que conferir antes.
O que precisa existir no site para ele ser instalável?
Aqui está a lista que os primeiros resultados da busca não trazem. Segundo o guia de instalação de PWAs do MDN, os navegadores baseados em Chromium — Google Chrome, Samsung Internet e Microsoft Edge — exigem estes itens antes de oferecer a instalação:
1. HTTPS em todo o site
O PWA precisa ser servido por https. A única exceção é o ambiente de desenvolvimento local (localhost ou 127.0.0.1). Site com certificado vencido ou com páginas ainda em http simplesmente não entra no fluxo de instalação.
2. Um manifest com os campos obrigatórios
- name ou short_name — o nome que aparece no ícone e no aviso de instalação;
- icons — com pelo menos um ícone de 192 px e um de 512 px;
- start_url — a página que abre quando o usuário toca no ícone;
- display e/ou display_override — o modo de exibição; "standalone" faz o app abrir sem a interface do navegador;
- prefer_related_applications — ausente ou falso, senão o navegador entende que você prefere mandar o usuário para o app da loja.
3. O manifest ligado em todas as páginas
O manifest entra no cabeçalho do HTML por uma tag link rel="manifest". O MDN avisa que, se o PWA tem mais de uma página, cada uma precisa referenciar o arquivo. É comum o manifest estar só na home e o usuário que entrou por um post do blog nunca ver a opção de instalar.
Como a instalação funciona no Android e no iPhone?
Cumpridos os requisitos, o navegador passa a promover a instalação. No navegador, isso pode ser um ícone de instalar na barra de endereço, que abre um aviso, com o nome e o ícone tirados do manifest. E o site pode ir além: o evento beforeinstallprompt permite ao PWA ter o próprio botão "Instalar", posicionado onde faz sentido, com uma frase explicando por que vale a pena.
No iPhone, o mesmo trecho da documentação traz a frase que muda o planejamento: o beforeinstallprompt não é suportado no iOS. Não há aviso automático nem botão de instalar controlado pelo site. Desde o iOS 16.4, a instalação é feita pelo menu Compartilhar → Adicionar à Tela de Início, no Safari, Chrome, Edge, Firefox e Orion; até o iOS 16.3, só pelo Safari.
Há ainda uma diferença no Android que pouca gente conhece. O MDN registra que só dois navegadores instalam o PWA como app de verdade (WebAPK), com entrada na lista de apps e nas configurações do sistema: o Chrome em aparelhos com os serviços do Google e o Samsung Internet em aparelhos Samsung. Firefox, Edge, Opera e outros criam um atalho na tela inicial que abre o site dentro do navegador.
Um detalhe a favor do Android: se o manifest tiver os campos description e screenshots, o aviso de instalação mostra texto e imagens do app. Segundo o MDN, isso vale só no Android — no iPhone, o usuário vê apenas o nome e o ícone na hora de adicionar.
O que o iPhone exige antes de mandar notificação?
É a lacuna que quase todo texto sobre PWA deixa em aberto, resumida em "alguns recursos não funcionam bem no Safari". A regra é mais precisa do que isso, e está escrita no anúncio do próprio WebKit, o motor do Safari:
Traduzindo para o funil: no iPhone, a notificação depende de três passos que o usuário precisa dar, nesta ordem. Primeiro, achar o menu Compartilhar e adicionar o site à Tela de Início — sem aviso do site para ajudar. Depois, abrir o app pelo ícone. Por fim, tocar num botão que peça a permissão e aceitar o pedido do sistema. Quem só visita pelo Safari não recebe notificação nenhuma.
A tabela de compatibilidade do PushManager no MDN confirma o desenho: o Chrome para Android suporta a API de push desde a versão 42, de 2015, enquanto o Safari do iOS só a partir do 16.4, lançado em março de 2023 — com a nota de que as notificações funcionam em web apps salvos na Tela de Início.
Cumpridos os passos, o WebKit descreve uma notificação de primeira classe: aparece na tela de bloqueio, na Central de Notificações e no Apple Watch pareado, respeita os modos de Foco e é gerenciada nos Ajustes como a de qualquer app. O web app também pode mostrar o número de pendências no ícone (Badging API). E não é preciso ser membro do Apple Developer Program para usar o serviço de push.
No iPhone, a notificação do PWA não é um recurso do site: é uma recompensa para quem já instalou.
Mais dois detalhes do mesmo anúncio afetam o projeto. Se o manifest não pedir exibição standalone ou fullscreen, o que vai para a Tela de Início é só um favorito, que abre no navegador padrão — e aí não há notificação. E se o site declarar o ícone tanto no manifest quanto pela tag apple-touch-icon, o iOS usa a apple-touch-icon.
O PWA funciona offline?
Pode funcionar, mas não por ser PWA. O offline é trabalho do service worker, que guarda arquivos e respostas no aparelho e decide o que mostrar quando a rede cai. Como o MDN deixa claro que ele não é requisito para a instalação, existe PWA instalável que abre uma tela de erro sem internet.
O que faz sentido guardar depende do uso. Um catálogo pode mostrar os produtos já vistos; uma área do cliente, o último pedido e os boletos baixados; um formulário de campo pode salvar o preenchimento e enviar quando a conexão voltar. Cada um desses comportamentos é uma decisão de escopo, com teste próprio. "Funciona offline" sem lista do que funciona é promessa, não especificação.
Quando o PWA resolve e quando o app precisa da loja?
A pergunta certa não é "PWA ou nativo?", e sim "qual é o motivo do app?". Quando o motivo é acesso rápido para quem já é cliente, o PWA costuma resolver com uma base de código só. Quando o motivo é a notificação, ele resolve no Android e exige um esforço de instalação no iPhone. Quando o motivo é estar na loja, ele precisa ser empacotado — ou o projeto pede um app nativo.
O caminho do meio existe: um PWA pode ser empacotado e publicado nas lojas. O MDN cita o PWABuilder como ferramenta para isso, com suporte a Google Play, Microsoft Store, Meta Quest Store e App Store. Só que, ao entrar na loja, o projeto herda as regras dela — aprovação, conta de desenvolvedor e atualização periódica. O guia sobre quanto custa criar um aplicativo e o prazo das lojas detalha o que isso soma ao orçamento.
Na leitura da Alliance, a tabela abaixo resume onde cada tipo de negócio costuma cair. É um ponto de partida para a conversa, não uma regra: o público de cada empresa, e a fatia dele que usa iPhone, pode mudar a resposta.
| Tipo de negócio | Uso típico | PWA resolve? | O que observar |
|---|---|---|---|
| Distribuidora B2B | Catálogo e pedido recorrente do revendedor | Em geral, sim | Offline do catálogo e acesso por login |
| Clínica ou escritório | Agenda, documentos, área do cliente | Sim, para consulta | Lembrete por push depende da instalação no iPhone |
| E-commerce | Recompra e acompanhamento de pedido | Complementa o site | Aviso de status por e-mail ou WhatsApp cobre quem não instalou |
| Serviço por assinatura | Uso diário, conteúdo, notificação | Parcialmente | Se a notificação é o produto, a loja ganha peso |
| Equipe de campo | Formulário, checklist, foto | Sim, com offline bem feito | Teste em aparelhos reais e sem sinal |
Leitura editorial da Alliance Comunicação sobre o encaixe do PWA por tipo de uso; não é um levantamento estatístico.
Como planejar um PWA na prática
1. Escreva o motivo do app em uma frase
"O revendedor refaz o pedido semanal em dois toques" é um motivo. "Ter um app" não é. A frase decide se o PWA basta e o que precisa funcionar offline, e serve de régua para cortar funcionalidade que não serve a ela.
2. Feche o checklist técnico antes do design
HTTPS em todas as páginas, manifest com nome, ícones de 192 e 512 px, start_url, display e o link do manifest em cada página. Parece trivial, mas é o que separa um PWA de um site responsivo com ícone bonito.
3. Desenhe a instalação para o iPhone
Como o site não pode disparar o aviso no iOS, a instalação precisa ser ensinada: uma tela curta, com o ícone de Compartilhar e o passo "Adicionar à Tela de Início", mostrada no momento em que o usuário vê valor — depois do primeiro pedido, por exemplo, e não no primeiro segundo da visita.
4. Peça a notificação no momento certo
No iPhone, o pedido de permissão precisa partir de um toque do usuário. Isso favorece o que já é boa prática: um botão claro, do tipo "avisar quando o pedido sair", junto da ação que justifica o aviso. Na experiência da Alliance, pedido de permissão feito na abertura do app, sem contexto, tende a ser recusado — e depois disso a permissão passa a ser gerenciada nos Ajustes, longe do alcance do site.
5. Tenha um canal para quem não instalou
Parte dos usuários de iPhone não vai instalar. Se a mensagem importa — status de pedido, lembrete de consulta —, ela precisa de um segundo canal, como e-mail ou WhatsApp. O push vira um reforço para quem instalou, não o único aviso.
Quais os erros mais comuns em projeto de PWA?
- Vender notificação como recurso garantido. No iPhone, ela só existe depois da Tela de Início. Se o plano de comunicação depende de push para todos, ele já nasce com um buraco.
- Esperar o aviso de instalação no iOS. Ele não existe. Sem uma orientação dentro do próprio site, a instalação no iPhone fica por conta de quem já sabe o caminho.
- Esquecer o display no manifest. Sem standalone ou fullscreen, o iPhone salva um favorito, não um web app — e o favorito não recebe notificação.
- Manifest só na home. Cada página precisa referenciar o arquivo; quem chega por outra página pode não ver a instalação.
- Chamar de offline o que é só cache de arquivos. Guardar CSS e logo não faz a área do cliente funcionar sem rede.
- Testar só no Chrome do computador. O comportamento muda entre Chrome com e sem os serviços do Google, Samsung Internet e iPhone. O teste precisa passar por aparelhos reais.
Como medir se o PWA está funcionando?
PWA bem-sucedido é o que muda o comportamento de quem volta. Por isso a medição separa quem instalou de quem só visita:
- Taxa de instalação — instalações sobre usuários recorrentes, separada por Android e iPhone. A diferença entre as duas mostra o peso da falta de aviso no iOS.
- Sessões abertas pelo ícone — um parâmetro próprio no start_url permite separar no analytics quem entrou pelo app instalado.
- Adesão à notificação — permissões concedidas sobre pedidos feitos, e quantos desses usuários estão no iPhone.
- Recompra e frequência — o indicador de negócio: quem instalou volta mais vezes ou compra mais que quem não instalou?
- Erros sem conexão — se o offline foi prometido, registre quantas vezes a tela de erro apareceu.
Se a instalação no iPhone ficar muito abaixo da do Android, o problema raramente é técnico: é a orientação de instalação que não aparece, ou aparece cedo demais. Para entender onde esse canal entra no conjunto do marketing, o diagnóstico de marketing gratuito avalia presença digital, retenção e tecnologia de uma vez.
Por onde começar hoje?
Comece pelo teste do destaque acima: abra o painel Application do Chrome e veja se o seu site já tem manifest. Depois, escreva em uma frase o motivo do app e confira em qual das três caixas da árvore de decisão ele cai. Se cair na primeira, o PWA provavelmente resolve sobre o site que você já tem; se cair na do meio, planeje desde já a orientação de instalação no iPhone e o canal alternativo.
Quando a decisão envolve site, PWA e app de loja ao mesmo tempo, vale olhar os três juntos antes de contratar. O time de desenvolvimento web e apps da Alliance faz esse recorte: o que o site atual já entrega, o que o PWA acrescenta e quando a loja passa a valer o custo.