revista-apd-372-1

revista-apd-372-2

Entrevista José Carlos Jiménez, Socio de Innusual

Este análisis pone el foco especialmente en entornos móviles, que es donde la tensión entre PWA y apps nativas resulta más determinante. Las PWA también tienen presencia en escritorio pero la mayor parte de las decisiones estratégicas en torno a esta tecnología se libran en el móvil.

Durante años, las Progressive Web Apps (PWA) se presentaron como el puente definitivo entre la web y las aplicaciones nativas. La promesa era potente: experiencias instalables, rápidas, capaces de funcionar sin conexión y, sobre todo, independientes de las tiendas de aplicaciones. En 2026, la pregunta ya no es si funcionan —porque funcionan— sino si siguen siendo una opción competitiva frente a un ecosistema donde lo nativo y el cross-platform han evolucionado mucho.

La respuesta corta es sí, pero ya no como una apuesta generalista, sino como una decisión que requiere criterio.

## El reto nunca fue solo uno

Durante mucho tiempo se ha repetido que las PWA no triunfaron por razones corporativas —resistencia de Apple a apoyarlas activamente, el interés de Google Play y App Store en mantener sus ecosistemas cerrados, o la falta de incentivos reales para que los fabricantes las promovieran—, pero es una explicación parcial que no refleja toda la complejidad del problema. También hubo —y sigue habiendo— limitaciones técnicas reales: acceso restringido a ciertas APIs, diferencias de comportamiento entre navegadores, y restricciones en el acceso a capacidades del sistema que sí están disponibles en entornos nativos.

En cualquier caso, las PWA han crecido dentro de un ecosistema que no las favorece especialmente: tiendas de aplicaciones dominantes, modelos de distribución cerrados y expectativas de usuario moldeadas por experiencias nativas muy pulidas. El resultado no es un fracaso, sino una tecnología que ha encontrado un espacio más acotado de lo que se esperaba.

## Qué es una PWA (y por qué importa definirlo bien)

Uno de los errores más comunes hoy es llamar PWA a cualquier aplicación web moderna. No lo es. Una PWA implica ciertas capacidades concretas: instalación, capacidad de funcionamiento offline, uso de Service Workers y un manifiesto que permite integrarse parcialmente con el sistema.

Esta distinción no es teórica. Si confundimos optimización web con PWA, perdemos claridad a la hora de tomar decisiones. Una web rápida no es automáticamente una PWA, y una PWA no es necesariamente rápida.

## Entendiendo las PWA más allá de las expectativas

**Rendimiento: determinado por la arquitectura**

Convertir una aplicación en PWA no mejora el rendimiento por sí mismo. El rendimiento depende de decisiones de arquitectura y del comportamiento del runtime del navegador: modelo de renderizado, carga y ejecución de JavaScript en el main thread, estrategia de hidratación y gestión de caché.

El uso de tecnologías asociadas a PWA —como Service Workers, Web App Manifest o APIs específicas del navegador— habilita capacidades como offline, instalación o ciertos mecanismos de sincronización, pero también introduce complejidad. En particular, la gestión de caché mediante Service Workers puede generar errores como contenido desactualizado o bugs difíciles de reproducir en producción.

**El factor Apple en móvil sigue siendo determinante**

La situación en iOS ha mejorado, pero sigue siendo el principal punto de fricción de las PWA en móvil. No tanto por ausencia de funcionalidades, sino por limitaciones específicas y por el hecho de que todo se ejecuta sobre WebKit.

Apple ha ido incorporando mejoras relevantes en el soporte de PWA en los últimos años: la llegada de Web Push, mejoras en Service Workers y una experiencia de instalación algo más consistente que en versiones anteriores de iOS. Estas mejoras han reducido parte de la brecha histórica con Android y hacen viable construir PWAs funcionales para usuarios de iPhone.

Aun así, persisten diferencias estructurales importantes que condicionan el desarrollo:

- **Motor de navegador:** iOS obliga a usar WebKit en todos los navegadores, mientras que Android permite motores basados en Chromium, lo que acelera la adopción de nuevas APIs web.
- **Instalación:** en Android el prompt de instalación es automático y puede ser gestionado por la aplicación; en iOS depende de acciones manuales del usuario desde Safari, lo que reduce su visibilidad.
- **Background sync:** sigue siendo limitado en iOS, mientras que en Android está mejor soportado.
- **Almacenamiento:** iOS aplica políticas más agresivas de limpieza de datos, especialmente en apps con poco uso.
- **Funcionalidades avanzadas:** el acceso a APIs más avanzadas o experimentales suele llegar antes —o exclusivamente— a navegadores basados en Chromium.

Esto no hace inviables las PWAs en iOS, pero sí introduce incertidumbre y obliga a diseñar teniendo en cuenta estas limitaciones desde el inicio.

**Coste operativo y económico: cuando el ahorro no es tan simple**

Existe una percepción extendida de que el desarrollo de una PWA implica una reducción directa de costes frente a soluciones nativas. Si bien esto puede ser cierto en determinados contextos, no constituye una regla general. La eficiencia económica depende en gran medida del grado de alineación entre los requisitos del producto y las capacidades del modelo web. En escenarios donde esta alineación no es óptima, la complejidad no desaparece, sino que se traslada a otras capas del sistema.

Desde una perspectiva operativa, las PWAs introducen elementos adicionales que incrementan la complejidad del ciclo de vida de la aplicación. En particular, el uso de Service Workers añade una capa de abstracción que impacta en aspectos como el debugging, la gestión de despliegues y el versionado de recursos. La implementación de estrategias de gestión de caché requiere un diseño cuidadoso, ya que errores en la invalidación o actualización de contenido pueden derivar en inconsistencias en producción, difíciles de detectar y corregir.

**Distribución y adquisición: un factor determinante**

La elección entre PWA y apps nativas no puede evaluarse únicamente desde una perspectiva tecnológica. El modelo de distribución y adquisición de usuarios juega un papel crítico en la viabilidad del producto.

Las PWA ofrecen acceso inmediato y sin fricción, eliminando barreras iniciales de instalación. Por otro lado, las tiendas de aplicaciones continúan proporcionando un canal estructurado de descubrimiento, junto con un marco de confianza percibida por el usuario final.

No obstante, el ecosistema de adquisición ha evolucionado significativamente. El descubrimiento de productos digitales se produce cada vez más a través de plataformas de terceros y redes sociales. En este contexto, la decisión entre PWA y app nativa trasciende lo técnico y se convierte en una cuestión estratégica vinculada al posicionamiento y crecimiento del producto.

## El nuevo contexto: PWA, cross-platform y apps nativas

Hoy no estamos ante una simple elección binaria. El ecosistema se ha sofisticado y las soluciones cross-platform han madurado hasta convertirse en una alternativa sólida, no solo en términos de productividad, sino también de capacidades técnicas.

**React Native y Flutter: la tercera vía**

Frameworks como React Native y Flutter combinan reutilización de código con acceso a funcionalidades nativas, ofreciendo alternativas más robustas frente a las PWA:

- **React Native** ha evolucionado hacia la denominada New Architecture, donde Fabric y TurboModules redefinen el modelo de comunicación, reduciendo la dependencia del bridge clásico y permitiendo comunicación más directa mediante JSI, con menor latencia entre la capa JavaScript y los componentes nativos.
- **Flutter** adopta un enfoque diferente: no depende de componentes nativos del sistema, sino que renderiza toda la interfaz mediante su propio motor, lo que le permite un control completo del pipeline de renderizado y una alta consistencia visual entre plataformas, a costa de una mayor abstracción respecto al sistema operativo.

Estas aproximaciones permiten acceder a funcionalidades que en la web siguen siendo limitadas o inconsistentes: acceso a Bluetooth, sensores específicos, ejecución robusta en segundo plano o integración profunda con el sistema operativo.

**¿Cómo se comparan las tres opciones?**

| Criterio | PWA | Cross-platform (RN / Flutter) | App nativa |
|---|---|---|---|
| Acceso a APIs del sistema | Limitado | Alto | Completo |
| Rendimiento UI | Medio | Alto | Muy alto |
| Distribución | Web directa, sin tiendas | App stores + web posible | App stores |
| Coste de entrada | Bajo | Medio | Alto |
| Soporte offline | Sí (con Service Workers) | Sí | Sí |
| Consistencia iOS/Android | Variable (WebKit vs Chromium) | Alta | Nativa por plataforma |
| Velocidad de iteración | Alta | Media-alta | Media |
| Integración con el SO | Parcial | Alta | Completa |

Esto ha reducido significativamente el espacio donde las PWA eran la única opción eficiente. Ya no compiten solo contra apps nativas independientes para iOS y Android, sino contra soluciones que ofrecen un equilibrio entre reutilización de código y acceso a herramientas del sistema, elevando el nivel de exigencia técnica en la toma de decisiones.

## Dónde las PWA encajan (y dónde no)

**Las PWA son especialmente eficaces cuando el problema a resolver se alinea con las fortalezas del modelo web**: distribución inmediata, bajo coste de entrada y una capa de interacción que no depende de capacidades avanzadas del sistema operativo. Esto ocurre, por ejemplo, en:

- Herramientas internas o aplicaciones empresariales donde la accesibilidad multiplataforma es clave y la distribución a través de app stores no es un factor relevante
- Fases tempranas de producto donde la velocidad de iteración y despliegue es prioritaria
- Contextos donde la conectividad es limitada y el soporte offline aporta valor real

Sin embargo, estas ventajas dejan de serlo cuando el producto exige capacidades que la web no puede ofrecer de forma consistente o eficiente. Las PWA tienden a encontrar límites claros en aplicaciones con uso intensivo de hardware, en experiencias gráficas complejas y en productos donde la integración profunda con el sistema operativo forma parte del valor diferencial.

En estos casos, las restricciones de la plataforma —tanto a nivel de APIs como de rendimiento y comportamiento— hacen que soluciones nativas o cross-platform resulten más adecuadas.

## Entonces, ¿sigue siendo una opción?

Sí, pero no como solución universal.

Las PWA han pasado de ser una promesa a ser una herramienta madura. Han perdido parte de la expectación inicial, pero han ganado claridad. Ya no buscan reemplazar a las apps nativas, sino coexistir con ellas dentro de un stack donde cada enfoque tiene su lugar.

La diferencia hoy no está en si puedes construir algo con PWA, sino en si deberías hacerlo. Y esa decisión depende de entender con precisión las capacidades reales de la plataforma, sus limitaciones y el contexto de tu producto.

Hoy en día, las posibilidades son muy amplias, pero elegir bien importa más que nunca.


Entrevista José Carlos Jiménez, Socio de Innusual

>>> Podría interesarte

PWA: ¿siguen siendo una opción?

Cómo elegir el stack de JavaScript adecuado para cada solución

NestJS: estructura, velocidad y escalabilidad para tu backend en Node.js

.css-adcnbg{font-family:var(--chakra-fonts-body);font-weight:300;color:inherit;}>>> Podría interesarte

PWA: ¿siguen siendo una opción?

Cómo elegir el stack de JavaScript adecuado para cada solución

NestJS: estructura, velocidad y escalabilidad para tu backend en Node.js

>>> Podría interesarte