Um aplicativo web progressivo depende da Web Push API e de um Service Worker para reconectar com os usuários — lembretes de carrinho, notícias de última hora, alertas de corrida, códigos de verificação. Esse pipeline é exatamente o que não existe dentro de um WebView. O Android WebView não tem Push API nem execução em segundo plano; os próprios engenheiros DTS da Apple afirmam claramente que o Web Push não funciona em nenhum app que use WKWebView. O aviso de permissão nunca aparece, a inscrição falha silenciosamente e cada mensagem de reconexão que o H5 deveria enviar desaparece. Um runtime próprio do host restaura o canal com uma ponte de push nativa: FCM ou APNs no dispositivo, uma ponte JS para registrar o token e uma entrega idêntica ao padrão web para a página.
Android: sem Push API, sem ativação em segundo plano
A documentação do Android e o ecossistema concordam: o WebView é um componente de renderização, não um navegador completo. Ele não implementa a Push API, não mantém um Service Worker vivo para push e, quando o app está fechado, não pode ser acordado para receber nada. Quem tenta «juntar web push com o WebView» conclui que não é possível com o WebView sozinho; a solução é descer para o lado nativo com o Firebase Cloud Messaging e empurrar a carga por uma ponte JavaScript. Isso é trabalho real — um serviço de mensagens, um canal de notificação, um fluxo de sincronização de tokens — que um WebView padrão simplesmente não oferece.
iOS: a plataforma diz não
No iOS a situação é mais aguda. Uma página em WebView pode registrar um Service Worker em algumas configurações (com domínios vinculados ao app ou um entitlement de navegador), mas o Web Push em si não está disponível. Nos fóruns de desenvolvedores da Apple, um engenheiro DTS responde diretamente: «As notificações Web Push não funcionarão em apps com um WKWebView. Você pode usar notificações push nativas com um app que também tenha um WKWebView, mas não Web Push.» A mesma página que mostra um botão de inscrição limpo no Safari não mostra nada na visão embutida — sem aviso, sem erro, apenas silêncio.
O que você perde sem um canal de push
- Botões de inscrição mortos. O aviso nunca aparece, então quem aceitaria simplesmente não o faz.
- Reconexão perdida. Lembretes de carrinho abandonado, atualizações de entrega e alertas de notícias — toda a razão pela qual os PWA investem em push — nunca chegam.
- Identidade fragmentada. Um usuário logado no H5 a partir de um navegador do sistema é um estranho dentro do WebView do app, e o push também não cobre essa lacuna.
- Divergência silenciosa. O mesmo código se inscreve bem no Chrome e no Safari e não faz nada no WebView.
- Sem sincronização em segundo plano. A sincronização em segundo plano e as buscas periódicas do Service Worker não estão disponíveis, então as filas de escrita offline travam.
A correção do runtime
Um runtime próprio do host entrega uma ponte de push nativa abaixo da página. Registra o dispositivo com FCM ou APNs, expõe uma pequena API JS (solicitar permissão, obter token, receber carga) que espelha a Push API web e roteia as notificações para a rota correta do app ao tocar. O autor do H5 escreve o mesmo fluxo de inscrição; o runtime fornece o canal que falta ao WebView, em ambas as plataformas, com um contrato consistente.
| Dimensão | WebView | Runtime próprio do host |
|---|---|---|
| Push API | Não implementada | Ponte nativa (FCM/APNs) |
| Aviso de permissão | Nunca exibido | Aviso nativo, espelhado no JS |
| Ativação em segundo plano | Impossível com app fechado | Entrega em nível de SO |
| Push do Service Worker | Não suportado | Conectado ao nativo |
| Reconexão | Perdida | Restaurada |
| Contrato multiplataforma | Nenhum | Uma API, ambos SO |
Um navegador trata um botão de inscrição como a promessa de uma mensagem futura. Um WebView padrão o trata como uma solicitação que pode ignorar. Um runtime cumpre a promessa — um canal de push, nativo no dispositivo, com forma web para a página.
Fontes
- Fóruns de Desenvolvedores da Apple — Web Push não funciona em apps com WKWebView (engenheiro DTS) — a confirmação em nível de plataforma.
- Stack Overflow — WebView não suporta a Push API no Android — a API ausente.
- MDN — Referência da Push API — o padrão web que falta ao WebView.
- web.dev — Visão geral de notificações push — como o pipeline deveria funcionar.
- MDN — API do Service Worker — o script em segundo plano que o WebView não consegue manter vivo para push.
