---
term: 'PWA (Progressive Web App)'
seoTitle: '¿Qué es una PWA (Progressive Web App)? Service workers, offline, push'
headline: '¿Qué es una PWA (Progressive Web App)?'
slug: pwa
category: frontend-web
shortDefinition: 'Una PWA es una app web que usa service workers, un manifest y HTTPS para ser instalable, funcionar offline y recibir notificaciones push.'
relatedTerms:
  - push-notifications-apns-fcm
  - cross-platform-development
  - ssr-vs-csr-vs-ssg
  - baas-vs-custom-backend
contrastsWith:
  - cross-platform-development
aboutTerms:
  - 'Service Worker'
  - 'Web App Manifest'
  - 'Caché Offline'
faq:
  - question: '¿Qué es una PWA?'
    answer: 'Una app construida con tecnologías web estándar que usa capacidades modernas del navegador para comportarse como una app instalada — ícono en la pantalla de inicio, ventana propia, soporte offline y notificaciones push — todo desde una sola base de código entregada por la web. El término lo acuñaron Alex Russell y Frances Berriman en 2015.'
  - question: '¿Qué convierte a una app en una PWA?'
    answer: 'Tres piezas trabajando juntas: un service worker (un script en segundo plano que cachea los assets y habilita el uso offline y el push), un web app manifest (metadatos JSON que hacen la app instalable) y HTTPS (los service workers se niegan a correr fuera de un contexto seguro). En la práctica, la vara es: instalable y confiable sin importar la red.'
  - question: '¿Qué es un service worker?'
    answer: 'Un archivo JavaScript que corre en segundo plano, en su propio hilo, actuando como proxy de red entre la app y la red. Intercepta las solicitudes y las responde desde el caché o desde la red — eso es lo que habilita el uso offline, la sincronización en segundo plano y recibir mensajes push incluso con la app cerrada.'
  - question: '¿PWA o app nativa: cuál es mejor?'
    answer: 'Una PWA es más rápida y barata de construir, usa una sola base de código, se actualiza al instante, no necesita tienda de aplicaciones y aparece en los buscadores. Una app nativa tiene acceso completo al hardware, la UX más fluida, push más confiable y presencia en la tienda. Elige nativo para gráficos pesados o integración profunda con el dispositivo; una PWA para alcance y velocidad de salida al mercado.'
  - question: '¿Cuál es la diferencia entre una PWA y un sitio responsivo?'
    answer: 'Un sitio responsivo solo adapta su layout al tamaño de la pantalla y necesita conexión. Una PWA agrega encima instalación, caché offline y notificaciones push. Toda PWA es responsiva, pero un sitio responsivo solo se vuelve PWA cuando suma un service worker y un manifest.'
  - question: '¿Las PWA pueden enviar notificaciones push?'
    answer: 'Pueden recibir web push vía las APIs Push y Notification, pero el cliente solo se suscribe — quien envía de verdad es un backend. En iOS el soporte llegó en la versión 16.4 y solo funciona con la PWA instalada en la pantalla de inicio, así que el web push alcanza a un público más estrecho que el push nativo.'
  - question: '¿Las PWA funcionan offline?'
    answer: 'Sí — el service worker cachea assets y datos, y los sirve cuando la red desaparece. Las estrategias comunes son cache-first para assets estáticos, network-first para datos que deben estar frescos y stale-while-revalidate para mostrar al instante con actualización en segundo plano. Las escrituras hechas offline se encolan y sincronizan cuando vuelve la conectividad.'
  - question: '¿Se puede publicar una PWA en una tienda de aplicaciones?'
    answer: 'En parte. La tienda de Android acepta PWA empaquetadas como trusted web activities, y algunas tiendas de desktop las tratan como ciudadanas de primera clase. La App Store de Apple, en la práctica, no — las PWA que son sitios reempaquetados suelen ser rechazadas — lo que explica en parte por qué iOS sigue siendo la plataforma más difícil para las PWA.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'What is a progressive web app? — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/What_is_a_progressive_web_app'
  - name: 'Service Worker API — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API'
  - name: 'Web App Manifest — W3C'
    url: 'https://www.w3.org/TR/appmanifest/'
  - name: 'Progressive Web Apps: Escaping Tabs Without Losing Our Soul (Russell, 2015)'
    url: 'https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/'
  - name: 'Progressive web app — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Progressive_web_app'
cta:
  title: 'El backend debajo de tu PWA'
  text: 'El service worker cachea; Back4app es la fuente de la verdad — autenticación, datos sincronizados y el servidor que de verdad envía tus notificaciones web push, un solo backend para PWA, web y nativo.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-04'
translationKey: progressive-web-app-pwa
---

**Una PWA es una app web que usa service workers, un manifest y HTTPS para ser instalable, funcionar offline y recibir notificaciones push.** Acuñado por Alex Russell y Frances Berriman en 2015, el término cierra la brecha entre un sitio web y una app instalada sin salir de la web: una sola base de código, un ícono en la pantalla de inicio, una ventana propia y una pantalla que sigue funcionando cuando el tren entra al túnel. El ángulo que este glosario agrega — y que las guías de frontend se saltan: **una PWA sigue siendo un cliente** — el service worker cachea, pero tu [backend](/glossary/es/baas-vs-backend-propio/) es la fuente de la verdad.

## Puntos clave

| Pregunta | Respuesta |
| --- | --- |
| Los tres pilares | Service worker · web app manifest · HTTPS |
| Qué agrega | Instalable · funciona offline · recibe push — sobre una sola base de código |
| vs. sitio responsivo | Agrega service worker + manifest; el layout solo no hace una PWA |
| vs. nativo | Alcance y velocidad vs. acceso al hardware y presencia en la tienda |
| La verdad del backend | El caché del SW es un espejo; la [API/BaaS](/glossary/es/baas-vs-backend-propio/) es la autoridad |

## Los tres pilares, y el backend detrás de ellos

**JavaScript:**

```javascript
// JavaScript — the PWA's three pillars + the backend behind them
// 1 · Service worker: caches the shell, buffers writes when offline
navigator.serviceWorker.register('/sw.js');

// 2 · Manifest (public/manifest.json) makes it installable:
//    { "name": "Notes", "display": "standalone", "start_url": "/", "icons": [...] }

// 3 · HTTPS is required — service workers refuse to run otherwise.

// The catch: the SW cache is a MIRROR, not the source of truth.
// When back online, queued writes sync to the real backend:
const note = new Parse.Object('Note').set('text', draft);
await note.save(); // the BaaS is authoritative; the cache was a buffer
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK (Flutter web compiles to a PWA)
// The service worker caches the app shell; data still lives on the backend.
final note = ParseObject('Note')..set('text', draft);
await note.save();
// Offline-first pattern: write locally, queue, and sync when connectivity
// returns — the API/BaaS is the source of truth, the cache is a local mirror.
// Push notifications need a BACKEND to send them; the client only subscribes.
```

**Swift:**

```swift
// Swift — a native shell can host a PWA/WebView; the backend is shared
// The point of parity: whatever the client (PWA, native, web), the
// source of truth is the same backend API.
var note = Note()
note.text = draft
_ = try await note.save()
// Offline-first: cache locally, sync when online — the API is authoritative.
// Web push (PWA) and native push (APNs) both need a backend to SEND them.
```

**Kotlin:**

```kotlin
// Kotlin — a native shell can host a PWA/WebView; the backend is shared
// The point of parity: whatever the client (PWA, native, web), the
// source of truth is the same backend API.
val note = ParseObject("Note")
note.put("text", draft)
note.save()
// Offline-first: cache locally, sync when online — the API is authoritative.
// Web push (PWA) and native push (APNs/FCM) both need a backend to SEND them.
```

Un **service worker** es un script en segundo plano que se ubica entre la app y la red como un proxy — cachea el shell y lo sirve offline; un **web app manifest** es el archivo de metadatos JSON (nombre, íconos, `display: standalone`, URL de inicio) que hace la app instalable; y **HTTPS** es obligatorio, porque los service workers se niegan a correr fuera de un contexto seguro. Esos tres construyen el frente de la app. El `save()` en las pestañas de código muestra lo que queda detrás: el caché es un *espejo*, y cuando la red vuelve, la escritura se sincroniza con el backend autoritativo.

## Cómo una PWA sirve una página offline

```mermaid
flowchart LR
  accTitle: Un service worker mediando entre una PWA y su backend
  accDescr: Una solicitud de la progressive web app pasa por el service worker, que devuelve una respuesta cacheada para uso offline o la busca en la red. Las lecturas y escrituras de datos llegan a la API del backend, que es la fuente de la verdad; las escrituras hechas offline se encolan en el caché y se sincronizan con el backend cuando vuelve la conectividad. Las notificaciones push nacen en el backend y llegan al service worker a través de un servicio de push.
  APP["UI de la PWA"] --> SW["Service worker<br/>(proxy de red)"]
  SW -->|"cache hit"| C[("Caché<br/>espejo local")]
  SW -->|"cache miss / datos frescos"| API[("API del backend<br/>fuente de la verdad")]
  C -.->|"escrituras offline en cola<br/>se sincronizan al reconectar"| API
  API -->|"mensaje push"| PS["Servicio de push"] --> SW
```

## Estrategias de caché offline

| Estrategia | Sirve desde | Ideal para |
| --- | --- | --- |
| Cache-first | Caché, luego red | Assets estáticos — shell, íconos, fuentes |
| Network-first | Red, con fallback al caché | Datos frescos que deben estar al día |
| Stale-while-revalidate | Caché ahora, refresco en segundo plano | Contenido que puede quedar un instante desactualizado |
| Cache-only / network-only | Una sola fuente | Esenciales precacheados / llamadas que nunca se cachean |

La decisión es por recurso, no por app: el shell de la app quiere cache-first para cargar al instante; los datos vivos del usuario quieren network-first para frescura; un feed acepta stale-while-revalidate para sentirse instantáneo y corregirse solo. Elijas lo que elijas, el caché es un *buffer de lectura/escritura* sobre la [API](/glossary/es/api/) — las escrituras offline se encolan localmente y se reconcilian al reconectar, la [misma disciplina de puesta al día](/glossary/es/live-queries-tiempo-real/) que necesita cualquier cliente offline-first.

## De dónde vienen realmente las notificaciones push

El mecanismo que casi ningún glosario explica, y la razón por la que una PWA necesita un backend hasta para notificar. El cliente solo *se suscribe*: pide permiso y recibe un endpoint de suscripción. Enviar es trabajo del servidor — **tu backend → el servicio de push del navegador → el evento `push` del service worker → una notificación mostrada.** El service worker puede despertar para mostrarla con la app cerrada, pero nada llega si un backend no lo envió — por eso "las PWA tienen push" es solo la mitad de una funcionalidad sin la mitad del servidor. La entrada de [notificaciones push](/glossary/es/notificaciones-push/) cubre la cadena de entrega; el punto aquí es que tanto el web push como el push nativo terminan en *tu* código decidiendo enviar.

## PWA vs. app nativa

| | PWA | Nativa |
| --- | --- | --- |
| Base de código | Una, en la web | Una por plataforma (o [multiplataforma](/glossary/es/desarrollo-multiplataforma/)) |
| Distribución | Una URL — sin tienda | Tiendas de aplicaciones, con revisión |
| Actualizaciones | Instantáneas, del lado del servidor | Ciclo de release de la tienda |
| Descubribilidad | Indexada por los buscadores | Solo la búsqueda de la tienda |
| Acceso al hardware | Limitado (varía por SO) | Completo |
| Confiabilidad del push | Buena en Android, restringida en iOS | Confiable vía [APNs/FCM](/glossary/es/notificaciones-push/) |
| Realidad en iOS | Instalación solo por Safari, push desde 16.4 | Ciudadana de primera clase |

La asimetría honesta vive en la última fila: iOS es donde las PWA son más débiles — instalación solo a través de Safari, sin prompt de instalación automático, push solo con la app instalada y solo en versiones recientes, y sincronización en segundo plano incompleta. En Android y desktop la distancia con lo nativo es pequeña; en iOS es el factor decisivo para muchos productos.

## Casos de uso comunes

- **Contenido y comercio** — alcance, SEO y baja fricción de instalación valen más que una descarga de tienda para llegar a usuarios nuevos.
- **Herramientas internas** — apps instalables y tolerantes al offline para usuarios conocidos, sin distribución por tienda.
- **Apps de campo offline-first** — captura datos sin señal, sincroniza cuando vuelve; el patrón del caché como buffer.
- **Alcance [multiplataforma](/glossary/es/desarrollo-multiplataforma/) con poco presupuesto** — una base de código web cubriendo plataformas que un build nativo triplicaría.
- **Compañera de una app nativa** — el mismo [backend](/glossary/es/baas-vs-backend-propio/) sirviendo una PWA para alcance y una app nativa para profundidad.

## ¿Deberías construir una PWA? Matriz de decisión

| Situación | Inclinación |
| --- | --- |
| Alcance, SEO, baja fricción, una base de código | PWA |
| Audiencia principal en Android/desktop | PWA — la distancia con lo nativo es pequeña |
| iOS crítico con fuerte dependencia del push | Nativo, o acepta las salvedades de iOS |
| Gráficos pesados, AR, hardware profundo | Nativo |
| Captura de datos offline-first | PWA con un backend de sincronización |
| Necesitas presencia en la tienda | Nativo (o PWA en tienda, donde la aceptan) |

## Limitaciones y trade-offs

- **iOS limita el techo.** Instalación solo por Safari, push restringido y huecos en la sincronización en segundo plano hacen de iOS la restricción que más a menudo decide el duelo PWA-versus-nativo.
- **El acceso al hardware es parcial.** Bluetooth, NFC, contactos y APIs avanzadas de cámara están limitados o ausentes según el SO — las apps que se hunden en el dispositivo siguen pidiendo nativo.
- **El caché no es la base de datos.** Tratar el caché del service worker como fuente de la verdad invita escrituras perdidas y conflictos de datos viejos; es un buffer sobre el [backend](/glossary/es/baas-vs-backend-propio/) autoritativo.
- **El push es mitad cliente, mitad servidor.** Suscribirse es fácil; la PWA sigue necesitando un backend para enviar, así que "offline y push" es una funcionalidad de backend con credencial de frontend.
- **La descubribilidad corta por ambos lados.** Sin el peaje de la tienda tampoco hay vitrina de tienda; cambias curaduría y ceremonia de instalación por una URL.

## PWAs en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Es la mitad backend de la funcionalidad que los pilares de frontend apenas completan: el service worker cachea el shell, pero Back4app es la fuente de la verdad que ese caché espeja — usuarios [autenticados](/glossary/es/autenticacion-vs-autorizacion/), datos sincronizados que reconcilian escrituras offline al reconectar, y el *servidor que de verdad envía* el web push al que una PWA solo puede suscribirse. Como un solo backend sirve por igual a una PWA, una app web común y una app nativa a través de [SDKs por plataforma](/glossary/es/sdk-de-backend/), el alcance [multiplataforma](/glossary/es/desarrollo-multiplataforma/) que la PWA promete en el frontend se encuentra con el alcance escribe-una-vez del backend — el cliente cachea, la plataforma recuerda, y las dos mitades de "instalable, offline y push" por fin se juntan.