Aplicaciones web progresivas para empresas: capacidad offline y caso de negocio

Una aplicación web progresiva (PWA) compensa a las empresas sobre todo cuando los equipos o los clientes usan con regularidad la misma aplicación, la conexión no siempre es estable y la app debe distribuirse por enlace en lugar de a través del App Store. Es una aplicación web que se puede instalar como una app, funciona sin conexión y cubre todos los dispositivos con un único código base. Hay límites en la integración profunda de hardware y en algunas funciones de iOS.

En este artículo mostramos cuándo compensa una PWA, cómo funciona técnicamente la capacidad offline, qué hay que tener en cuenta con las notificaciones push y cuándo una app nativa es, a pesar de todo, la mejor inversión.

Qué caracteriza a una aplicación web progresiva

En esencia, una PWA es una aplicación web que se ejecuta en el navegador pero se comporta como una app. Puede instalarse en el smartphone o en el escritorio, se inicia a pantalla completa y puede ofrecer contenidos sin conexión. Tres componentes técnicos forman la base:

• Manifiesto de aplicación web: describe el nombre, los iconos, los colores y el comportamiento de inicio de la app.
• Service worker: un script que se sitúa entre la app y la red, intercepta las solicitudes y almacena contenidos en caché.
• HTTPS: sin conexión cifrada, los navegadores rechazan el service worker y, con él, las funciones más importantes de una PWA.

La instalación varía según el sistema: Android y los navegadores de escritorio como Chrome o Edge la ofrecen directamente, mientras que en el iPhone los usuarios añaden la PWA a la pantalla de inicio desde el menú Compartir de Safari. Explíquelo durante la introducción.

Cuándo es una PWA la opción adecuada

Las PWA destacan especialmente allí donde las personas trabajan con regularidad con la misma aplicación y la conexión no siempre es estable. Campos de uso típicos:

• Servicio técnico in situ: los técnicos consultan pedidos, instrucciones y listas de control incluso en sótanos o naves sin cobertura.
• Listas de control y protocolos de inspección: los formularios se rellenan sin conexión y se sincronizan en cuanto hay red de nuevo.
• Catálogos de productos: el personal comercial en ruta muestra el surtido y las fichas técnicas en casa del cliente, con independencia del wifi del lugar.
• Portales para usuarios recurrentes: los portales de clientes o socios se benefician de la rápida visualización desde la caché.

Otra ventaja: no siempre hace falta la tienda de apps. La distribución se hace por enlace, por ejemplo por correo electrónico, código QR o intranet. Las actualizaciones están disponibles para todos de inmediato, sin que los usuarios tengan que actualizar nada ni esperar a una revisión de la tienda. En herramientas internas, esto ahorra esfuerzo de coordinación con el departamento de IT.

Criterio	PWA	App multiplataforma	App nativa
Distribución	enlace, código QR, intranet	tienda o distribución interna	tienda o distribución interna
Actualizaciones	de inmediato para todos	a través de la tienda	a través de la tienda
Funciones del dispositivo	cámara, ubicación y archivos bien; Bluetooth, NFC y procesos en segundo plano limitados	en gran medida, en parte mediante módulos adicionales	acceso completo
Código base y mantenimiento	uno para todas las plataformas	uno, más adaptaciones específicas de cada plataforma	separado por plataforma
Visibilidad	búsqueda web y enlace directo	búsqueda en la tienda	búsqueda en la tienda

Cuándo las apps nativas llevan ventaja

Por convincentes que sean, las PWA no son una panacea. Una app nativa o una solución multiplataforma suele ser la mejor opción cuando:

• se requiere una integración profunda de hardware, por ejemplo con dispositivos Bluetooth, NFC o procesos en segundo plano; en el iPhone estas interfaces del navegador apenas están disponibles,
• la presencia en el App Store es un canal de ventas importante,
• las funciones que requieren mucha capacidad de cálculo o los gráficos complejos son el centro de la aplicación,
• los usuarios de iPhone son un público central y se necesitan funciones que Safari admite solo de forma limitada; las notificaciones push, por ejemplo, solo funcionan allí cuando la PWA está instalada en la pantalla de inicio.

La decisión rara vez es blanco o negro. A menudo un proyecto arranca como PWA y más adelante se amplía, con la misma interfaz de backend, con una app nativa. Si una PWA debe aparecer igualmente en la tienda, es posible mediante un wrapper; Apple, no obstante, suele rechazar las apps que solo incrustan un sitio web. Encontrará más sobre las opciones en nuestra página de apps móviles.

Capacidad offline y estrategias de caché

Que una PWA resulte agradable en el día a día depende de la estrategia de caché. El service worker decide para cada tipo de contenido si procede de la red o de la caché. Bibliotecas como Workbox se encargan de parte del trabajo manual.

Estrategia	Funcionamiento	Adecuada para
Cache first	el contenido procede primero de la caché y la red solo si hace falta	logotipos, fuentes, hojas de estilo y la estructura de la interfaz: la app arranca casi al instante, incluso sin conexión
Network first	primero la red; si no hay conexión, la última versión guardada	listas de pedidos, existencias, citas; idealmente con un aviso como «Sin conexión: situación a las 9:15 h»
Stale while revalidate	la versión guardada al instante y actualización en segundo plano	datos de producto, instrucciones, catálogos: la rapidez importa más que la actualidad al segundo

Formularios offline y sincroniza­ción

Los datos introducidos, como protocolos de inspección o jornadas de trabajo, se guardan localmente en el navegador, normalmente en IndexedDB, y se transfieren en cuanto vuelve la conexión. Un tipo de proyecto que ya hemos realizado es una app móvil para técnicos de servicio con sincronización offline. Lo que importa:

• Regla de conflictos: ¿qué ocurre si dos personas han editado el mismo pedido: gana el último cambio, se fusionan o se consulta?
• Estado visible: los usuarios ven qué aún no se ha transferido.
• Desencadenante de la transferencia: no todos los navegadores admiten la sincronización en segundo plano; Safari, por ejemplo, no. Prevea por ello una transferencia al iniciar la app y cuando vuelva la conexión.
• No sobrestimar el almacenamiento: los navegadores pueden eliminar datos locales si falta espacio. Los datos importantes deben llegar pronto al servidor.

Invalidación de caché: para que nadie vea datos desac­tuali­zados

La mayor trampa de las PWA no es la falta de caché, sino el exceso. Si un service worker entrega precios antiguos o instrucciones obsoletas, los usuarios pierden rápidamente la confianza. Por eso documentamos en cada proyecto qué contenidos se almacenan en caché, durante cuánto tiempo y cómo se renuevan.

Han demostrado su eficacia las cachés versionadas, que se vacían de forma selectiva en cada versión, y un aviso discreto como «Nueva versión disponible: actualizar ahora». Un nuevo service worker se instala primero en segundo plano y a menudo no toma el control hasta que la app se ha cerrado y vuelto a abrir; el aviso con botón resuelve justamente este problema. Así la app sigue siendo rápida y, aun así, fiablemente actual.

Notifica­ciones push: solo con consenti­miento y valor añadido real

Las notificaciones push pueden hacer volver a los usuarios, o ahuyentarlos. Técnicamente requieren un permiso explícito en el navegador. No lo pida en la primera visita, sino en un momento en que el beneficio esté claro, por ejemplo tras un pedido: «¿Desea recibir un aviso en cuanto su envío esté en camino?» En el iPhone, además, las notificaciones push solo funcionan si la PWA está instalada en la pantalla de inicio.

Igual de importantes son los contenidos claros, una frecuencia moderada y una forma sencilla de desactivar de nuevo las notificaciones. Qué consentimientos e informaciones exige la normativa de protección de datos es mejor acordarlo con su delegado de protección de datos.

El caso de negocio: ¿PWA o app nativa?

Cinco preguntas ayudan a decidir:

1. Público objetivo: ¿equipos internos, socios o clientes finales, y en qué dispositivos?
2. Distribución: ¿basta un enlace o la app debe poder encontrarse en la tienda?
3. Funciones: ¿qué funciones del dispositivo son obligatorias y cuáles opcionales?
4. Mantenimiento: ¿cuánto esfuerzo se ha previsto para el mantenimiento y las actualizaciones? Una PWA supone un único código base para todas las plataformas.
5. Plazo hasta el lanzamiento: ¿con qué rapidez debe estar operativa una primera versión?

Si varias respuestas apuntan a un enlace, usuarios recurrentes y una introducción rápida, una PWA suele ser un buen punto de partida. Cómo se compone el presupuesto de los proyectos de apps se explica en el artículo ¿Cuánto cuesta una app?

Ejemplo práctico: protocolos de inspección en una empresa de instala­ciones

Supongamos que una empresa de instalaciones quiere que sus técnicos rellenen digitalmente los protocolos de mantenimiento en casa del cliente. Los dispositivos son smartphones corporativos con iOS y Android, los sótanos y las salas de calderas suelen carecer de cobertura y la app solo se usa internamente. Las cinco preguntas arrojan: público interno, basta un enlace para la distribución, se necesitan cámara y formularios, un único código base ahorra mantenimiento y el lanzamiento debe ser rápido. El resultado es una PWA con formularios offline y sincronización. Si más adelante se añade un aparato de medición Bluetooth, esa parte puede complementarse como app nativa; el backend sigue siendo el mismo.

Checklist para su proyecto de PWA

• Casos de uso con conexión fluctuante identificados
• Manifiesto con nombre, iconos y comportamiento de inicio definido
• Estrategia de caché por tipo de contenido definida y documentada
• Avisos offline y lógica de sincronización con regla de conflictos previstos para los formularios
• Versionado e invalidación de caché por versión regulados
• Push solo con consentimiento, beneficio claro y posibilidad de darse de baja
• Pruebas en iPhones reales, dispositivos Android y escritorio, incluidos escenarios offline

Cómo le ayuda Nano Concepts

En nuestra página de servicio sobre aplicaciones web progresivas puede ver cómo trabajamos: desde la pregunta de si una PWA encaja en su proyecto, pasando por la estrategia de caché y el concepto offline, hasta las pruebas en iOS, Android y escritorio. Las PWA sencillas sin backend complejo pertenecen a nuestro paquete Starter desde 2.500 €; las soluciones con backend, gestión de usuarios e interfaces, al paquete Professional desde 8.000 €. En la primera consulta gratuita analizamos juntos qué camino es el adecuado para usted. El proceso del desarrollo de una app se describe en el artículo Desarrollo de apps: el proceso de la idea a la tienda.

Este artículo no sustituye el asesoramiento jurídico.