Aplicaciones web progresivas (PWA) en 2026: guía para crear una PWA

Anna Kowalski Senior Mobile Engineer, YuSMP Group · Publica productos con React Native, Flutter y PWA para clientes de EE. UU. y la UE desde 2017

¿Cómo se crea una PWA en 2026?

Considere esta guía como el manual práctico de desarrollo. Recorre los service workers, la caché, el manifest, el modo sin conexión, las notificaciones push y dónde siguen divergiendo iOS y Android en lo que permiten hacer. Si aún está sopesando la propia arquitectura, nuestro equipo de desarrollo de aplicaciones web entrega PWA como un resultado de primer nivel, y el artículo comparativo Web App vs Native vs PWA sopesa coste y alcance antes de comprometerse.

¿Qué hace que una PWA sea una PWA?

Los ingenieros de Google Alex Russell y Frances Berriman acuñaron el término Progressive Web App en 2015. Una década después, lo que empezó como un experimento de navegador se ha convertido en una estrategia de producción seria: Twitter (ahora X Lite), Pinterest, Starbucks y Uber publican una. La palabra «progresiva» alude al enfoque por capas. En esencia, una PWA es simplemente una aplicación web; después mejora su propio comportamiento allí donde el navegador admite la capacidad adicional.

En esencia, una PWA se sostiene sobre tres pilares técnicos:

• Service worker. Un archivo JavaScript que se ejecuta en un hilo aparte, actúa como proxy de red entre el navegador e internet y habilita la funcionalidad sin conexión, la sincronización en segundo plano y las notificaciones push.
• Web App Manifest. Un archivo JSON que indica al navegador cómo presentar la app una vez instalada: su nombre, iconos, color del tema, modo de visualización y URL de inicio.
• HTTPS. Los service workers requieren un contexto seguro. Toda PWA de producción debe servirse por HTTPS (localhost está exento durante el desarrollo).

Más allá de esos tres, el conjunto de funciones más amplio añade la Push API, Background Sync, la Badging API, la File System Access API, Web Bluetooth, Web NFC y la Screen Wake Lock API. La compatibilidad de cada una varía de un navegador a otro, y precisamente por eso el enfoque «progresivo» se gana su sitio: la experiencia básica funciona en todas partes, mientras que las funciones más ricas solo se activan donde un navegador puede respaldarlas.

Si aún está decidiendo si una PWA es la arquitectura adecuada para su producto, nuestro artículo Web App vs Native vs PWA: How to Choose in 2026 recorre el análisis completo de contrapartidas de coste, alcance y capacidades. Esta guía da por hecho que ya ha tomado la decisión y quiere construir.

Service workers: el motor bajo el capó

Ninguna otra pieza de una PWA pesa tanto como el service worker. Aprenda a usarlo bien y esquivará los errores que dan mala fama a las PWA cuando los equipos aceleran la implementación: cachés obsoletas, actualizaciones que nunca llegan, alternativas sin conexión que fallan en silencio.

Así funciona el ciclo de vida:

1. Registro. La página principal registra el script del service worker: navigator.serviceWorker.register('/sw.js'). El navegador descarga y analiza el script en un hilo aparte.
2. Instalación. Se dispara el evento install. Aquí se abre una caché y se precachea el app shell: el conjunto mínimo de HTML, CSS y JS necesario para renderizar la interfaz sin red.
3. Activación. Tras la instalación, el nuevo service worker espera a que se cierren todas las pestañas que usan la versión anterior antes de activarse. Durante el evento activate se eliminan las cachés antiguas. Llamar a self.skipWaiting() fuerza la activación inmediata (útil en desarrollo; cuidado en producción, porque puede romper solicitudes en curso).
4. Interceptación de fetch. Una vez activo, el service worker intercepta todas las solicitudes de red de las páginas que controla mediante el evento fetch. Aquí residen las estrategias de caché.
5. Inactividad y terminación. El navegador puede terminar un service worker inactivo en cualquier momento para ahorrar memoria. Se vuelve a crear bajo demanda. No guarde nunca estado en variables globales del service worker; use IndexedDB o la Cache API.

Un error habitual es registrar el service worker demasiado pronto, antes de que se hayan cargado los recursos críticos. El patrón recomendado:

if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js')
      .then(reg => console.log('SW registered:', reg.scope))
      .catch(err => console.error('SW registration failed:', err));
  });
}

Envolver la llamada en window.addEventListener('load', …) evita que la instalación del service worker compita por ancho de banda con las descargas críticas de la página. Si se omite ese paso, se retrasa el First Contentful Paint en la primera visita, justo cuando una carga lenta más perjudica.

Estrategias de caché en la práctica

Su manejador de fetch es donde decide cómo se sirve cada recurso. No busque una única mejor estrategia, porque no existe. Lo adecuado depende de dos cosas: con qué frecuencia cambia el recurso y cuánta obsolescencia pueden tolerar sus usuarios.

Workbox, de Google, se ha convertido en la biblioteca por defecto para estos patrones. Se encarga del precacheo con hashes de integridad, del almacenamiento en caché en tiempo de ejecución con plugins de caducidad y de mantener coherentes los nombres de caché entre actualizaciones del service worker. A menos que tenga un motivo real para escribir a mano su propia lógica de caché, recurra a Workbox.

Los cuatro patrones que usará en casi cualquier PWA:

• Cache-First. Comprueba primero la caché; solo recurre a la red si el recurso no está en caché. Ideal para recursos estáticos (fuentes, iconos, bundles de JS/CSS versionados) que cambian con poca frecuencia. Ofrece el tiempo de carga más rápido posible.
• Network-First. Prueba la red y, si falla, recurre a la caché. Lo mejor para endpoints de API en los que la frescura de los datos es crítica (p. ej., el saldo de la cuenta de un usuario o el estado de un pedido). La caché actúa como respaldo de emergencia cuando el usuario está sin conexión.
• Stale-While-Revalidate. Sirve de inmediato desde la caché y después actualiza la caché en segundo plano desde la red. Equilibra velocidad y frescura en recursos que se actualizan periódicamente: feeds de artículos, listados de productos, respuestas de API no críticas. El usuario siempre obtiene una respuesta rápida; la siguiente carga recibe datos frescos.
• Network-Only. Va siempre a la red; nunca usa la caché. Úselo para pings de analítica, pagos, inicio y cierre de sesión o cualquier solicitud en la que nunca sean aceptables los datos obsoletos.
• Cache-Only. Sirve siempre desde la caché; nunca accede a la red. Solo tiene sentido para recursos que precacheó durante el evento install del service worker y que no necesitan actualizarse, como los recursos gráficos estáticos o las cadenas de localización incluidas en el app shell.

Una configuración de Workbox que cubre una SPA o una app de Next.js típicas:

// sw.js (with Workbox imported via CDN or bundler)
import { precacheAndRoute } from 'workbox-precaching';
import { registerRoute } from 'workbox-routing';
import { CacheFirst, NetworkFirst, StaleWhileRevalidate } from 'workbox-strategies';
import { ExpirationPlugin } from 'workbox-expiration';

// Precache app shell (injected at build time by workbox-webpack-plugin)
precacheAndRoute(self.__WB_MANIFEST);

// Static assets — Cache-First, 30-day expiry
registerRoute(
  ({ request }) => request.destination === 'image' || request.destination === 'font',
  new CacheFirst({ cacheName: 'static-assets', plugins: [new ExpirationPlugin({ maxAgeSeconds: 30 * 24 * 60 * 60 })] })
);

// API responses — Network-First, 7-day fallback
registerRoute(
  ({ url }) => url.pathname.startsWith('/api/'),
  new NetworkFirst({ cacheName: 'api-cache', plugins: [new ExpirationPlugin({ maxEntries: 50, maxAgeSeconds: 7 * 24 * 60 * 60 })] })
);

// Page navigations — Stale-While-Revalidate
registerRoute(
  ({ request }) => request.mode === 'navigate',
  new StaleWhileRevalidate({ cacheName: 'pages' })
);

Frameworks y herramientas para PWA en 2026

Crear una PWA de producción desde cero es posible, pero rara vez es el camino más rápido. La mayoría de los equipos recurre a una integración con un framework o a una cadena de herramientas específica que conecta automáticamente los service workers y los manifests con el proceso de compilación, gestiona el versionado de las cachés y genera avisos de actualización.

Distribución en tiendas de apps sin código nativo. PWABuilder y Trusted Web Activity (TWA) permiten envolver una PWA que cumpla los requisitos en una ficha de Google Play Store sin necesidad de Kotlin: la app debe obtener ≥80 en Lighthouse y devolver un 200 en su URL de inicio. Microsoft Store acepta PWA empaquetadas en MSIX directamente desde PWABuilder. Así, los equipos consiguen una ficha en una tienda de apps (a menudo una señal de confianza en las compras empresariales) manteniendo una única base de código web. La App Store de Apple no acepta envíos de PWA sin empaquetar; exige un contenedor de Capacitor o React Native.

Web app manifest e instalabilidad

El Web App Manifest es un archivo JSON que indica al navegador cómo debe verse y comportarse su PWA una vez instalada. Lighthouse de Chrome lo lee y señala cualquier error, y el propio navegador lo usa para crear tanto el aviso de instalación como el icono que llega a la pantalla de inicio.

Un manifest listo para producción en 2026:

{
  "name": "My PWA App",
  "short_name": "MyPWA",
  "description": "A short description visible in some OS app stores",
  "start_url": "/?utm_source=pwa",
  "id": "/",
  "display": "standalone",
  "background_color": "#0B1020",
  "theme_color": "#2b8ad6",
  "orientation": "any",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png", "purpose": "any" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png", "purpose": "any" },
    { "src": "/icons/icon-512-maskable.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
  ],
  "screenshots": [
    { "src": "/screenshots/desktop.png", "sizes": "1280x800", "type": "image/png", "form_factor": "wide" },
    { "src": "/screenshots/mobile.png", "sizes": "390x844", "type": "image/png", "form_factor": "narrow" }
  ],
  "categories": ["productivity", "utilities"],
  "shortcuts": [
    { "name": "Dashboard", "url": "/dashboard", "icons": [{ "src": "/icons/shortcut-dashboard.png", "sizes": "96x96" }] }
  ]
}

Enlácelo desde el <head> de su HTML:

<link rel="manifest" href="/manifest.json">

Campos clave del manifest que hay que acertar en 2026:

• id (novedad de 2023). Un identificador estable de la app. Si cambia start_url, especificar id garantiza que el navegador trate la nueva versión como una actualización de la app ya instalada y no como una app nueva.
• screenshots. Necesario para la «interfaz de instalación enriquecida» que Android 14 + Chrome 119+ muestran antes del aviso de instalación: una vista previa de la app. Las tarjetas al estilo de Google Play aparecen automáticamente cuando hay capturas.
• Iconos maskable. Los iconos adaptativos de Android se recortan en círculo, squircle u otra forma. Sin un icono maskable, su logotipo aparecerá con un margen blanco dentro de la forma. Use maskable.app para generarlo y previsualizarlo.
• display: "standalone". La app instalada oculta el chrome del navegador (la barra de direcciones) y parece una app nativa. "minimal-ui" mantiene una barra mínima de volver/recargar, útil si su app depende de la navegación del navegador.

Avisos de instalación y añadir a la pantalla de inicio

Conseguir que alguien instale su PWA es una conversión y debe tratarla como tal. La propia interfaz de instalación del navegador es tan discreta que la mayoría de los usuarios nunca la advierte. Cree su propio aviso y las tasas de instalación aumentarán.

En Android (Chrome): el navegador dispara el evento beforeinstallprompt cuando se cumplen todos los criterios de instalabilidad. Captúrelo y actívelo con un gesto del usuario:

let deferredPrompt;

window.addEventListener('beforeinstallprompt', (e) => {
  e.preventDefault();          // Suppress the automatic mini-infobar
  deferredPrompt = e;
  showInstallButton();         // Reveal your custom "Install App" button
});

installButton.addEventListener('click', async () => {
  if (!deferredPrompt) return;
  deferredPrompt.prompt();
  const { outcome } = await deferredPrompt.userChoice;
  console.log('User choice:', outcome); // 'accepted' or 'dismissed'
  deferredPrompt = null;
  hideInstallButton();
});

window.addEventListener('appinstalled', () => {
  console.log('PWA installed');
  analytics.track('pwa_installed');
});

En iOS (Safari): no existe el evento beforeinstallprompt. El usuario debe pulsar manualmente el botón Compartir y después «Añadir a pantalla de inicio». Lo mejor es un modal que aparezca cuando el usuario haya visitado la app varias veces y que explique el gesto con una breve animación. Detecte iOS con navigator.userAgent y compruebe si la app ya está instalada con window.navigator.standalone (devuelve true en iOS cuando se ejecuta como app de la pantalla de inicio).

Trate la tasa de instalación como una métrica de producto y haga pruebas A/B de cuándo aparece el aviso. Esperar a que el usuario haga algo relevante (guardar un documento, hacer un primer pedido) convierte mucho mejor que lanzar el aviso en cuanto se carga la página.

Cómo crear para el modo sin conexión

Nada distingue tanto a una PWA de una app web corriente como la compatibilidad sin conexión. Si se hace bien, la app sigue haciendo algo útil (completo o reducido) cuando se cae la red. Si se hace mal, el usuario se queda mirando una pantalla en blanco o un error críptico del navegador, lo cual es posiblemente peor que no tener una PWA.

Empiece por el app shell. Precachee el puñado de recursos que dibujan el esqueleto de la interfaz (navegación, maquetación, recursos de marca) y sírvalos directamente desde la caché en cada carga. El contenido dinámico entra después, ya sea desde la red o desde una caché local. Google Maps, Twitter Lite y Starbucks se apoyan en este patrón.

Una vez montado el shell, tres API hacen el trabajo pesado del modo sin conexión:

• Cache API. Almacén clave-valor de pares Request/Response. Vive dentro de los service workers. Workbox lo envuelve con caducidad, limpieza y versionado. Úselo para páginas, instantáneas de API y contenido multimedia.
• IndexedDB. Una base de datos completa en el cliente con transacciones, índices y cursores. Úsela para datos estructurados que necesitan consultas: contenido creado por el usuario, borradores, elementos de colas sin conexión. Bibliotecas como Dexie.js hacen cómoda la API.
• Background Sync API. Pone en cola las solicitudes de red hechas sin conexión y las reproduce cuando vuelve la conectividad. El caso de uso canónico: un usuario envía un formulario en el metro; Background Sync lo entrega en silencio en cuanto vuelve a tener señal. Compruebe ServiceWorkerRegistration.sync para ver la compatibilidad del navegador antes de confiar en ella.

Proporcione siempre una página alternativa explícita sin conexión. Regístrela en el evento install de su service worker y devuélvala en el manejador de fetch cuando falle la navegación:

// In sw.js install event, precache the offline page
self.addEventListener('install', (e) => {
  e.waitUntil(
    caches.open('app-shell-v2').then(cache =>
      cache.addAll(['/offline.html', '/assets/css/main.css?v=nav-20261011', '/assets/img/logo.svg'])
    )
  );
});

// In fetch handler, return offline page for failed navigations
self.addEventListener('fetch', (e) => {
  if (e.request.mode === 'navigate') {
    e.respondWith(
      fetch(e.request).catch(() => caches.match('/offline.html'))
    );
  }
});

Merece la pena añadir dos API más recientes si su caso de uso va más allá del modo sin conexión básico:

• Navigation Preload API. Normalmente, el service worker debe arrancar por completo antes de poder responder a una solicitud de navegación, lo que añade una latencia medible cuando el service worker ha estado inactivo. Navigation Preload permite que el navegador inicie la solicitud de red en paralelo con el arranque del service worker. Actívelo en el evento activate: await self.registration.navigationPreload?.enable(). En su manejador de fetch, compruebe primero event.preloadResponse antes de recurrir a la caché: así se recupera el tiempo de arranque que de otro modo se desperdicia.
• Periodic Background Sync. Un service worker registrado puede recibir un evento periodicsync según un calendario configurado por el usuario, lo que permite a la PWA precargar contenido fresco (feeds de artículos, precios, eventos de calendario) con la app cerrada. Por ahora solo es compatible con Chrome y Edge; trátela como una mejora progresiva con una alternativa controlada de Stale-While-Revalidate en la siguiente apertura. Regístrela con registration.periodicSync.register('content-sync', { minInterval: 24 * 60 * 60 * 1000 }).

Notificaciones push de extremo a extremo

Pocas herramientas de reenganche igualan a una notificación push bien gestionada, y pocas se utilizan tan mal. Si pide el permiso en el momento equivocado, los usuarios bloquean su app al instante, sin vuelta atrás. Si elige bien el momento y el contenido merece la pena, su interacción puede competir con la de una app nativa.

El flujo técnico tiene cinco pasos:

1. Solicitar el permiso. Llame a Notification.requestPermission() dentro de un gesto del usuario (clic en un botón, no al cargar la página). Esto muestra el cuadro de diálogo de permisos del navegador. Si el usuario lo rechaza, no puede volver a pedirlo: el permiso del navegador es persistente.
2. Suscribirse al servicio push. Llame a registration.pushManager.subscribe() con su clave pública VAPID. El navegador devuelve un objeto PushSubscription con la URL del endpoint y las claves de cifrado.
3. Guardar la suscripción en su servidor. Envíe por POST el JSON de PushSubscription a su API y almacénelo asociado a la cuenta del usuario.
4. Enviar desde el servidor. Use el protocolo Web Push (o una biblioteca como web-push para Node.js) para enviar por POST una carga cifrada al endpoint. Firebase Cloud Messaging (FCM) puede actuar como servicio de entrega de push tanto para Android como para iOS.
5. Mostrar en el service worker. El service worker recibe un evento push, analiza la carga y llama a self.registration.showNotification(title, options) para mostrar la notificación.

// sw.js — handle incoming push
self.addEventListener('push', (e) => {
  const data = e.data?.json() ?? { title: 'New message', body: '' };
  e.waitUntil(
    self.registration.showNotification(data.title, {
      body: data.body,
      icon: '/icons/icon-192.png',
      badge: '/icons/badge-72.png',
      data: { url: data.url ?? '/' },
      actions: [
        { action: 'open', title: 'Open' },
        { action: 'dismiss', title: 'Dismiss' }
      ]
    })
  );
});

// Handle notification click
self.addEventListener('notificationclick', (e) => {
  e.notification.close();
  if (e.action === 'dismiss') return;
  e.waitUntil(
    clients.matchAll({ type: 'window', includeUncontrolled: true }).then(clientList => {
      const target = e.notification.data?.url ?? '/';
      for (const client of clientList) {
        if (client.url === target && 'focus' in client) return client.focus();
      }
      if (clients.openWindow) return clients.openWindow(target);
    })
  );
});

Nota sobre iOS: las notificaciones push de las PWA en la pantalla de inicio son compatibles desde iOS 16.4 (Safari 16.4 / marzo de 2023). La PWA debe estar instalada en la pantalla de inicio: el push no funciona en las PWA que se ejecutan en la pestaña del navegador en iOS. Pida primero a los usuarios que instalen y solicite después el permiso de notificaciones.

Capacidades de las PWA: iOS vs Android en 2026

iOS y Android se han acercado mucho en los últimos tres años, pero aún importan algunas diferencias. La tabla siguiente refleja la situación a mediados de 2026, con WebKit 17.x y Chrome 125:

Resultados reales de PWA

La adopción de las PWA ha dejado atrás con creces la fase de los pioneros. Estas son cifras divulgadas y verificables de empresas conocidas, útiles para elaborar el caso de negocio interno de dejar una app nativa o de mejorar una experiencia web móvil existente.

El patrón común a todos ellos: las mayores mejoras proceden de la fiabilidad y la velocidad, no de capacidades llamativas. Es más probable que convierta, y que instale, un usuario con conexión 3G que recibe un artículo en menos de un segundo desde la caché que uno que espera cuatro segundos a que se renderice una página completa. Esa inversión en rendimiento se acumula con cada sesión.

IA en las PWA: novedades de 2026

Los tres pilares anteriores (service worker, manifest, HTTPS) no han cambiado. Lo que ha cambiado desde que se publicó esta guía por primera vez es lo que los equipos construyen sobre ellos. Hay tres patrones lo bastante comunes en las PWA de producción como para influir en las decisiones de arquitectura:

• Inferencia de IA en el dispositivo. La WebNN API y bibliotecas como Transformers.js permiten que un service worker ejecute modelos pequeños (clasificación, embeddings, ordenación de búsquedas en el dispositivo) directamente en el navegador, sin ida y vuelta a un servidor. Esto importa en una PWA en concreto porque mantiene las funciones de IA operativas sin conexión, igual que las páginas en caché: el modelo se entrega como un recurso precacheado junto al app shell y la inferencia se ejecuta sobre datos almacenados en IndexedDB.
• Personalización de notificaciones en el momento del envío. En lugar de una única carga push para todos los suscriptores, los equipos ejecutan un paso ligero de ordenación en el servidor antes del POST de Web Push: reordenan o filtran el contenido según el comportamiento reciente dentro de la app almacenado junto a la suscripción. La mecánica de entrega descrita en la sección de notificaciones push no cambia; solo cambia el contenido de la carga.
• Configuración de caché asistida por IA. Las herramientas basadas en Workbox analizan ya los registros de tráfico reales (qué rutas se consultan, con qué frecuencia cambian las respuestas) y sugieren qué estrategia de caché (Cache-First, Network-First, Stale-While-Revalidate) encaja con cada ruta, en lugar de que un desarrollador lo adivine en el momento de la solicitud. Tome la sugerencia como punto de partida y verifíquela con sus propios requisitos de frescura: una herramienta no puede saber que su API de precios no debe servir nunca datos obsoletos.

Nada de esto cambia los fundamentos: una PWA sin una base sólida de service worker, manifest y HTTPS no obtiene ningún beneficio de añadirle IA por encima. Si su producto necesita inferencia en el dispositivo o una interacción personalizada con IA, nuestro equipo de IA, ML y datos y el equipo web mencionado antes trabajan a partir del mismo briefing: no necesita dos proveedores distintos.

Cuándo una PWA es la decisión acertada

Ahora que las capacidades y los límites están sobre la mesa, así es como decidimos en YuSMP Group, a partir de los tipos de productos que desarrollamos:

Cree una PWA cuando:

• Su principal canal de distribución sea la búsqueda web (SEO) y no quiera fragmentar la visibilidad entre una tienda de apps y una página web.
• Sus usuarios estén en un conjunto diverso de dispositivos y sistemas operativos: usuarios de SaaS B2B en portátiles Windows corporativos, trabajadores de campo en Android y directivos en iPhone acceden a la misma URL.
• Su necesidad sin conexión sea moderada: contenido en caché, envíos de formularios en cola, CRUD básico desde una IndexedDB local. No necesita descargas grandes en segundo plano ni acceso complejo al hardware.
• Las restricciones presupuestarias hagan inviable mantener bases de código nativas separadas para iOS y Android, pero la opción multiplataforma de React Native o Flutter aún le parezca demasiado pesada para su conjunto de funciones.
• Esté creando un producto con mucho contenido (noticias, documentación, cursos, catálogo de e-commerce) en el que la latencia de revisión de las tiendas de apps ralentizaría las actualizaciones de contenido.

Contexto de costes. El desarrollo de una PWA suele costar entre un 50 % y un 70 % menos que mantener bases de código nativas separadas para iOS y Android con la misma paridad de funciones. Las estimaciones de Gartner sitúan el ahorro en 3–4× para las empresas que de otro modo necesitarían dos equipos distintos. La ausencia de comisiones de las tiendas de apps (15–30 % en las compras dentro de la app) es un factor adicional para bienes digitales y productos de suscripción a gran volumen. Sin embargo, estos ahorros se evaporan si acaba necesitando Capacitor o un contenedor nativo para acceder a API de hardware a las que una PWA sin empaquetar no llega en iOS.

Considere nativo o React Native en su lugar cuando:

• Necesite Bluetooth, NFC, GPS continuo en segundo plano o capacidades avanzadas de AR.
• Su producto sea un juego o una experiencia de streaming de audio/vídeo en la que necesite acceso a códecs, audio en segundo plano o API de renderizado de bajo nivel.
• Sus usuarios de iOS sean un segmento importante y necesiten notificaciones push entregadas en la pestaña del navegador (no solo cuando la PWA está instalada).
• La presencia en una tienda de apps sea una señal de confianza en su mercado: los compradores empresariales de sectores regulados suelen esperar una ficha en Apple Business Manager o Google Play.
• Necesite una integración profunda con el SO: widgets, Siri Shortcuts, acciones de pantalla de inicio, extensiones para compartir, app complementaria para el reloj.

Para muchos productos SaaS B2B, plataformas de e-commerce y herramientas de productividad, una PWA es sencillamente la mejor rentabilidad por el dinero invertido en 2026. Se desarrolla una vez, llega a todo el mundo y las actualizaciones se publican sin esperar a un revisor de la tienda de apps. El servicio de desarrollo de aplicaciones web que ofrece nuestro equipo trata las PWA como un resultado de primer nivel, junto a las SPA estándar y las apps renderizadas en servidor. Para el desglose completo de coste y alcance, nuestra comparativa Web App vs Native vs PWA: How to Choose in 2026 profundiza más.

Lista de verificación para crear una PWA

Repase esta lista de verificación antes de publicar. Sigue los mismos criterios que Lighthouse comprueba en su auditoría PWA, más un puñado de elementos de preparación para producción que hemos aprendido por las malas publicando PWA para clientes de EE. UU. y la UE.

Ejecute npx lighthouse https://your-pwa.com --view antes de cualquier publicación en producción. La sección PWA del informe de Lighthouse se corresponde directamente con esta lista y señala las regresiones automáticamente.

Para equipos nuevos en el desarrollo de PWA, nuestro servicio de desarrollo de aplicaciones web incluye auditorías y migraciones de PWA como encargo independiente: evaluamos su app web actual y entregamos una hoja de ruta priorizada para hacerla instalable, utilizable sin conexión y con notificaciones push.

Preguntas frecuentes

¿Qué es una aplicación web progresiva y en qué se diferencia de una app web normal?

Una aplicación web progresiva (PWA) es una aplicación web que usa API modernas del navegador (principalmente service workers, el Web App Manifest y la Push API) para ofrecer una experiencia comparable a la de una app nativa. A diferencia de una app web normal, puede funcionar sin conexión, almacenar recursos en caché para cargas casi instantáneas, recibir notificaciones push e instalarse en la pantalla de inicio sin pasar por una tienda de apps. La base de código sigue siendo HTML, CSS y JavaScript; la diferencia es una capa de capacidades añadida por encima.

¿Funcionan las PWA en iOS en 2026?

Sí, con matices. iOS 16.4+ admite Web Push (incluidas las PWA en la pantalla de inicio), Background Sync, la Badging API y las solicitudes de almacenamiento persistente. Sin embargo, iOS sigue sin tener Background Fetch, acceso completo a Bluetooth y NFC, Screen Wake Lock ni la File System Access API completa. El flujo de instalación en iOS exige que el usuario pulse manualmente «Añadir a pantalla de inicio» en Safari; no hay un aviso de instalación a nivel de sistema. Para la mayoría de las PWA de contenido, comercio y productividad, la compatibilidad con iOS es suficiente en 2026.

¿Qué estrategia de caché debo usar en mi PWA?

Depende del tipo de recurso. Use Cache-First para recursos estáticos (JS, CSS, fuentes, logotipo) que cambian poco: se sirve desde la caché y se actualiza en segundo plano. Use Network-First para las llamadas a API en las que importa la frescura: se prueba la red y, si falla, se recurre a la caché. Use Stale-While-Revalidate para las páginas en las que un contenido algo obsoleto es aceptable pero se quieren cargas rápidas. Workbox, de Google, automatiza los tres patrones con precacheo, caché en tiempo de ejecución y caducidad de la caché integrados.

¿Cómo activo el aviso de instalación «Añadir a pantalla de inicio» en Android?

Chrome en Android dispara el evento beforeinstallprompt cuando la PWA cumple los criterios de instalabilidad: HTTPS, un Web App Manifest válido con name, short_name, iconos (al menos de 192x192 y 512x512), start_url y display establecido en standalone o fullscreen, además de un service worker registrado con un manejador de fetch. Capture el evento con window.addEventListener('beforeinstallprompt', …), guárdelo y llame a prompt() cuando el usuario haga clic en su botón de instalación personalizado. En iOS, el aviso debe activarse manualmente: muestre un modal que explique el gesto Compartir > Añadir a pantalla de inicio.

¿Puede una PWA enviar notificaciones push?

Sí. La Push API combinada con la Notifications API permite enviar notificaciones push mediante un servicio push del lado del servidor. El flujo es: solicitar el permiso de notificaciones en el navegador, suscribirse a un servicio push para obtener un objeto PushSubscription, enviar esa suscripción a su servidor, enviar por POST un mensaje push desde su servidor al endpoint push, y el service worker recibe un evento push y muestra una notificación. En iOS esto exige que la PWA esté instalada en la pantalla de inicio (iOS 16.4+).

¿Cuándo debo crear una PWA en lugar de una app nativa?

Una PWA es la decisión acertada cuando su objetivo principal es la visibilidad web y el SEO, necesita llegar a los usuarios en distintos dispositivos sin la fricción de las tiendas de apps, su presupuesto no permite bases de código separadas para iOS y Android, sus necesidades sin conexión son moderadas y no necesita Bluetooth, NFC, AR ni una integración profunda con el SO. Si necesita alguna de esas API de hardware, o su producto es un juego o una experiencia con mucho contenido multimedia, lo mejor es nativo o React Native. Consulte nuestra comparativa completa en Web App vs Native vs PWA: How to Choose in 2026.

¿Qué tamaño puede tener la caché de una PWA?

Las cuotas de almacenamiento dependen del navegador y del espacio disponible en disco. Chrome concede aproximadamente el 60 % del espacio total en disco para todo el almacenamiento de un origen. En la práctica, una PWA en un móvil de 64 GB puede usar varios GB. Sin embargo, el navegador puede desalojar el almacenamiento bajo presión, salvo que llame a navigator.storage.persist() y el usuario conceda el almacenamiento persistente. Planifique su caché con criterio: precachee solo los recursos del shell (normalmente menos de 5 MB) y almacene las respuestas de API de forma selectiva con límites de caducidad.

¿Se puede enviar una PWA a Google Play Store o a Microsoft Store?

Sí, a ambas. Google Play acepta PWA empaquetadas como Trusted Web Activity (TWA), una Chrome Custom Tab que presenta su PWA sin chrome del navegador visible. Microsoft Store acepta PWA empaquetadas en MSIX generadas directamente desde PWABuilder. Ambas vías exigen que su PWA supere una auditoría básica de Lighthouse (puntuación ≥80) y devuelva HTTP 200 en su URL de inicio. La App Store de Apple no acepta envíos de PWA sin empaquetar; necesita un contenedor nativo mediante Capacitor o React Native. La entrega de notificaciones push mediante Firebase Cloud Messaging funciona tanto para las PWA publicadas en Play Store como para las PWA instaladas desde el navegador en Android.

¿Cuánto cuesta el desarrollo de una PWA frente a una app nativa?

El desarrollo de una PWA suele costar entre un 50 % y un 70 % menos que crear y mantener apps nativas separadas para iOS y Android con la misma paridad de funciones. Las estimaciones de Gartner sitúan el ahorro en 3–4× para las empresas que de otro modo necesitarían dos bases de código y dos canales de publicación. Se ahorra además por la ausencia de comisiones de las tiendas de apps (15–30 % en las compras dentro de la app para suscripciones y bienes digitales) y por los ciclos de publicación más rápidos, sin cola de revisión de la tienda. La salvedad: si necesita API de hardware (Bluetooth, NFC, GPS en segundo plano, AR), la vía nativa es necesaria sea cual sea el coste, ya que una PWA sin empaquetar no puede acceder a ellas en iOS.

Última actualización: septiembre de 2026. Los detalles técnicos reflejan las matrices de compatibilidad de WebKit 17.x y Chrome 125+ vigentes a mediados de 2026. Las capacidades de los navegadores evolucionan con rapidez: verifique en MDN y caniuse.com antes de cerrar las decisiones de implementación.