Una aplicación web progresiva depende de la Web Push API y un Service Worker para reconectar con los usuarios — recordatorios de carrito, noticias de última hora, alertas de viaje, códigos de verificación. Esa canalización es exactamente lo que no existe dentro de un WebView. Android WebView no tiene Push API ni ejecución en segundo plano; los propios ingenieros DTS de Apple afirman claramente que Web Push no funciona en ninguna app que use WKWebView. El aviso de permiso nunca aparece, la suscripción falla en silencio y cada mensaje de reconexión que el H5 debía enviar desaparece. Un runtime propio del host restaura el canal con un puente de notificaciones nativo: FCM o APNs en el dispositivo, un puente JS para registrar el token y una entrega idéntica al estándar web para la página.
Android: sin Push API, sin activación en segundo plano
La documentación de Android y el ecosistema coinciden: WebView es un componente de renderizado, no un navegador completo. No implementa la Push API, no mantiene un Service Worker vivo para push y, cuando la app está cerrada, no puede despertar para recibir nada. Quienes intentan «fusionar web push con el WebView» concluyen que no es posible con el WebView solo; la solución es bajar al lado nativo con Firebase Cloud Messaging y empujar la carga a través de un puente JavaScript. Eso es trabajo real — un servicio de mensajería, un canal de notificación, un flujo de sincronización de tokens — que un WebView estándar simplemente no ofrece.
iOS: la plataforma dice no
En iOS la situación es más aguda. Una página en WebView puede registrar un Service Worker en algunas configuraciones (con dominios vinculados a la app o un permiso de navegador), pero Web Push en sí no está disponible. En los foros de desarrolladores de Apple, un ingeniero DTS responde directamente: «Las notificaciones Web Push no funcionarán en apps con un WKWebView. Puedes usar notificaciones push nativas con una app que también tenga un WKWebView, pero no Web Push». La misma página que muestra un botón de suscripción limpio en Safari no muestra nada en la vista embebida — sin aviso, sin error, solo silencio.
Qué pierdes sin un canal de push
- Botones de suscripción muertos. El aviso nunca aparece, así que quienes habrían aceptado simplemente no lo hacen.
- Reconexión perdida. Recordatorios de carrito abandonado, actualizaciones de envío y alertas de noticias — toda la razón por la que las PWA invierten en push — nunca llegan.
- Identidad fragmentada. Un usuario que inició sesión en el H5 desde un navegador del sistema es un desconocido dentro del WebView de la app, y push tampoco cubre esa brecha.
- Divergencia silenciosa. El mismo código se suscribe bien en Chrome y Safari y no hace nada en el WebView.
- Sin sincronización en segundo plano. La sincronización en segundo plano y las recuperaciones periódicas del Service Worker no están disponibles, así que las colas de escritura offline se bloquean.
La solución del runtime
Un runtime propio del host incluye un puente de push nativo por debajo de la página. Registra el dispositivo con FCM o APNs, expone una pequeña API JS (solicitar permiso, obtener token, recibir carga) que refleja la Push API web y enruta las notificaciones a la ruta correcta de la app al tocarlas. El autor del H5 escribe el mismo flujo de suscripción; el runtime aporta el canal que falta al WebView, en ambas plataformas, con un contrato consistente.
| Dimensión | WebView | Runtime propio del host |
|---|---|---|
| Push API | No implementada | Puente nativo (FCM/APNs) |
| Aviso de permiso | Nunca se muestra | Aviso nativo, reflejado en JS |
| Activación en segundo plano | Imposible con app cerrada | Entrega a nivel de SO |
| Push de Service Worker | No soportado | Conectado a nativo |
| Reconexión | Perdida | Restaurada |
| Contrato multiplataforma | Ninguno | Una API, ambos SO |
Un navegador trata un botón de suscripción como la promesa de un mensaje futuro. Un WebView estándar lo trata como una petición que puede ignorar. Un runtime cumple la promesa — un canal de push, nativo en el dispositivo, con forma web para la página.
Fuentes
- Foros de Desarrolladores de Apple — Web Push no funciona en apps con WKWebView (ingeniero DTS) — la confirmación a nivel de plataforma.
- Stack Overflow — WebView no soporta la Push API en Android — la API ausente.
- MDN — Referencia de la Push API — el estándar web que le falta al WebView.
- web.dev — Visión general de notificaciones push — cómo debería funcionar la canalización.
- MDN — API de Service Worker — el script en segundo plano que el WebView no puede mantener vivo para push.
