Definición
Una PWA (Progressive Web App) es una web construida de forma que el móvil la trate como una aplicación: se puede instalar en la pantalla de inicio, abre a pantalla completa sin barra de navegador, funciona total o parcialmente sin conexión y puede mandar notificaciones.
No es una tecnología nueva ni un lenguaje distinto. Es una web normal a la que se le añaden tres cosas:
- HTTPS, obligatorio.
- Un manifiesto, un fichero JSON que dice cómo se llama, qué icono usa y de qué color es.
- Un service worker, un script que corre en segundo plano e intercepta las peticiones de red.
Con esas tres piezas, el navegador ofrece instalarla.
El service worker
Es la pieza que lo hace posible y también la que más problemas da.
Un service worker es un script que se ejecuta aparte de la página, sin acceso al DOM, y que puede interceptar cada petición que la web hace a la red. Eso le permite decidir: ¿respondo desde la caché, voy a la red, o intento la red y si falla tiro de caché?
Ahí está lo de "funciona sin conexión": no es magia, es un script que guardó los ficheros antes y los sirve cuando no hay cobertura.
Estrategias habituales:
- Caché primero: ideal para el diseño y los iconos, que no cambian.
- Red primero: para datos que tienen que estar frescos.
- Red con respaldo en caché: intenta la red y, si no hay, sirve lo último que guardó. Es la que mejor equilibrio da.
Ejemplo práctico
El gimnasio que tengo en antonioecheverria.es/gym-app/ es una PWA, y es un caso donde encaja perfectamente.
El escenario de uso lo explica todo: estás en el gimnasio, con el móvil, y ahí abajo no hay cobertura. Necesitas anotar las series entre ejercicio y ejercicio.
Con una web normal, sin cobertura no hay aplicación. Con la PWA instalada, se abre desde el icono como cualquier app, la interfaz está en caché y funciona. Los datos se guardan en el móvil y se sincronizan cuando vuelve la señal.
Y no está en ninguna tienda: se instala entrando a la dirección y dándole a "Añadir a pantalla de inicio". Sin revisión de Apple, sin cuenta de desarrollador, sin esperar aprobaciones para publicar un cambio.
Eso último es la ventaja que más se nota en la práctica: publicar una corrección es desplegar la web. En una app de tienda, cada cambio pasa por revisión.
PWA frente a app nativa
La PWA gana en: coste (una base de código para todo), velocidad de publicación (sin revisiones), descubribilidad (sale en Google), y no depender de que una tienda te apruebe.
La nativa gana en: acceso completo al hardware (Bluetooth avanzado, sensores, biometría), rendimiento en cosas exigentes (juegos 3D), notificaciones más fiables, y presencia en la tienda, que para mucha gente sigue siendo donde se buscan las apps.
Lo que hay que saber de iPhone: Safari ha ido soportando cada vez más, pero históricamente ha ido por detrás de Android. Las notificaciones push llegaron tarde y con condiciones, y hay límites de almacenamiento más estrictos. Si tu público es mayoritariamente iPhone, hay que probar ahí específicamente antes de prometer nada.
Existe una vía intermedia: Capacitor, que empaqueta tu web dentro de una app nativa. Te deja publicar en las tiendas y acceder al hardware manteniendo una sola base de código. Es lo que uso para la app de IMDICA en Android.
Errores comunes
- Caché demasiado agresiva. Es el error clásico: el service worker sirve la versión vieja y el usuario no ve tus cambios por mucho que recargue. Hay que versionar la caché y tener un plan de actualización desde el primer día.
- No probar sin conexión de verdad. Poner el modo avión y usarla. Es la única prueba que vale.
- Pedir permiso de notificaciones nada más entrar. Es la forma más rápida de que te lo denieguen para siempre. Pídelo cuando el usuario haga algo que lo justifique.
- Iconos incompletos en el manifiesto. Cada plataforma quiere sus tamaños; si faltan, la instalación se ve mal o no se ofrece.
- Olvidar HTTPS. Sin él no hay service worker, y sin service worker no hay PWA.
Cuándo usarla
Sí cuando la aplicación es de contenido o de formularios, cuando quieres una sola base de código, cuando necesitas publicar cambios rápido, o cuando el uso sin conexión importa pero no necesitas hardware avanzado.
No cuando dependes de funciones del sistema que la web no alcanza, cuando el rendimiento gráfico es crítico, o cuando estar en la tienda es parte del negocio.
