PWA o app móvil: qué necesita de verdad tu negocio

«Necesitamos una app». Es una de las frases que más escucho cuando un negocio empieza a crecer. A veces es verdad, pero muchas otras lo que de verdad se necesita es que el cliente pueda reservar, consultar o pedir desde el móvil con dos toques, y eso no siempre exige pasar por la App Store y Google Play. Entre una web normal y una app nativa hay una opción intermedia que cada vez cubre más casos: la PWA, o aplicación web progresiva.

En este artículo te explico qué es una PWA, qué puede y qué no puede hacer hoy (sobre todo en iPhone, donde están las limitaciones que más sorprenden), en qué se diferencia de una app nativa o híbrida y qué costes ocultos tiene publicar en las tiendas de aplicaciones. Al final tendrás unas preguntas sencillas para decidir qué le conviene a tu negocio sin dejarte llevar por la moda ni por quien te quiera vender el proyecto más caro.

Una PWA es una aplicación web construida con tecnologías web estándar que se comporta como una app: se puede añadir a la pantalla de inicio del móvil, se abre a pantalla completa sin la barra del navegador, puede seguir funcionando con mala conexión y, en muchos casos, enviar notificaciones. Por debajo sigue siendo una web: se visita desde una URL, se actualiza al publicar cambios en el servidor y Google puede indexar su contenido.

Técnicamente, lo que convierte una web en PWA son dos piezas: un manifiesto (un pequeño fichero que define el nombre, el icono y cómo se abre la app) y un service worker, un script que se queda en el dispositivo y decide qué guardar en caché, cómo responder cuando no hay conexión y cómo recibir notificaciones push. Si quieres profundizar, la guía de Progressive Web Apps de web.dev es la referencia más completa.

Lo que una PWA no es: no es una app que se descargue de la App Store por defecto, no tiene acceso completo al hardware del teléfono y no es una web antigua con un icono pegado. Una buena PWA está pensada desde el principio para el móvil, con una interfaz rápida y adaptada al dedo, igual que harías con una aplicación web a medida.

Las capacidades de la web han avanzado mucho en los últimos años. Con una PWA bien desarrollada puedes ofrecer a tus clientes:

• Instalación en la pantalla de inicio, con su propio icono y abriéndose como una app independiente.
• Funcionamiento sin conexión o con conexión pobre: las pantallas principales y los datos recientes se guardan en el dispositivo.
• Notificaciones push para avisar de una cita, un pedido listo o un mensaje nuevo, con el permiso del usuario.
• Acceso a funciones del móvil como la cámara, la geolocalización o compartir contenido con otras apps.
• Actualizaciones inmediatas: publicas una mejora y todos tus usuarios la tienen en la siguiente apertura, sin esperar revisiones ni descargas.
• Un solo desarrollo que funciona en Android, iPhone, tablets y ordenador.
• Visibilidad en Google, porque el contenido público sigue siendo una web indexable y enlazable.

Para muchos negocios eso ya cubre el 100 % de lo que imaginaban cuando decían «queremos una app»: que el cliente reserve, pague, consulte su historial o reciba un aviso sin tener que buscar la web cada vez.

Aquí está la letra pequeña. En Android, Chrome trata las PWA casi como ciudadanas de primera: puede mostrar un aviso de instalación y tu web puede ofrecer su propio botón de «Instalar». En iPhone y iPad la historia es distinta, y conviene conocerla antes de decidir:

• No hay aviso automático de instalación. Safari no permite que la web lance un botón de instalar: el usuario tiene que ir a Compartir y elegir «Añadir a pantalla de inicio». Por eso las PWA que funcionan bien en iPhone incluyen una pequeña guía visual que explica esos pasos.
• Desde iOS 26, añadir una web a la pantalla de inicio la abre como app por defecto, según anunció el propio equipo de WebKit en su presentación de Safari 26. Es un paso adelante, pero el gesto de añadirla sigue siendo manual.
• Las notificaciones push existen desde iOS 16.4, pero solo para webs añadidas a la pantalla de inicio y después de que el usuario dé permiso. Si tu cliente no instala la PWA, en iPhone no recibirá tus avisos.
• Algunas funciones de hardware no están disponibles en Safari, como Web Bluetooth o Web NFC, ni la sincronización en segundo plano que sí ofrece Chrome en Android.
• El almacenamiento local no es un archivo eterno. El sistema puede liberar los datos guardados de webs que llevan tiempo sin usarse, así que todo lo importante debe vivir en el servidor y no solo en el dispositivo.

Hay además un factor de incertidumbre: Apple decide qué soporta Safari y cuándo. En 2024, por ejemplo, anunció que retiraría las web apps de la pantalla de inicio en la Unión Europea para adaptarse a la Ley de Mercados Digitales, y semanas después dio marcha atrás. Hoy funcionan, pero es un recordatorio de que en iOS dependes de las decisiones de un solo fabricante.

Una app nativa se programa con las herramientas de cada sistema: Swift para iOS y Kotlin para Android. Tiene acceso completo al dispositivo, el mejor rendimiento posible y se integra con todo lo que ofrece el sistema operativo: widgets, tareas en segundo plano, Bluetooth, NFC, pagos dentro de la app o accesos directos de Siri. El inconveniente es que, en la práctica, son dos aplicaciones distintas que hay que desarrollar y mantener.

Una app híbrida o multiplataforma se escribe una sola vez con frameworks como React Native o Flutter y se compila para ambos sistemas. Se publica en las tiendas como cualquier app, accede a casi todo el hardware mediante complementos y reduce mucho el coste frente a dos apps nativas. Para la mayoría de pymes que necesitan estar en las tiendas, es el punto de partida razonable.

Ambas tienen algo en común que a menudo se olvida: necesitan un backend. La app es la cara visible, pero los datos, los usuarios, los pagos y las notificaciones viven en un servidor con su API, su base de datos y su panel de gestión. Ese backend es el mismo que necesitaría una PWA, así que no es un argumento a favor ni en contra, pero sí un coste que debe estar en el presupuesto desde el principio.

Desarrollar la app es solo la primera factura. Publicar y mantener una app en las tiendas tiene costes y obligaciones que una PWA no tiene:

1. 1Cuentas de desarrollador: Apple cobra una cuota anual por su programa de desarrolladores y Google Play un pago único de registro.
2. 2Revisión de cada versión: cada actualización pasa por la revisión de la tienda, que puede tardar o rechazar la versión por motivos que hay que corregir antes de publicar.
3. 3Actualizaciones obligatorias del sistema: cada año cambian iOS y Android, y Google Play exige que las apps apunten a versiones recientes de Android para seguir aceptando actualizaciones. Una app que nadie toca acaba quedándose fuera.
4. 4Fichas, capturas y etiquetas de privacidad: hay que preparar y mantener la ficha de cada tienda y declarar qué datos recoge la app.
5. 5Comisiones: si vendes contenido o servicios digitales dentro de la app, las tiendas se quedan una parte de cada venta. Los productos físicos y los servicios presenciales normalmente quedan fuera, pero conviene revisarlo según tu caso.
6. 6Usuarios con versiones antiguas: no todos actualizan, así que el backend tiene que seguir siendo compatible con varias versiones de la app a la vez.

Nada de esto es un drama si la app aporta valor de verdad, pero es un coste recurrente que hay que mirar de frente. Igual que una web necesita mantenimiento, una app lo necesita con más motivo, porque además del servidor hay que cuidar el código instalado en miles de teléfonos que no controlas.

Una PWA suele ser la mejor opción cuando lo que buscas es comodidad y presencia en el móvil del cliente, no funciones avanzadas del hardware. Estos son los casos en los que la recomiendo casi siempre:

• Reservas y citas: peluquerías, clínicas, centros deportivos o academias donde el cliente reserva y recibe recordatorios. Si te interesa este caso, lo desarrollo más en el artículo sobre reservas y citas online.
• Áreas de clientes y herramientas internas: consultar pedidos, descargar documentos o fichar el trabajo del equipo.
• Pedidos y catálogos: cartas de restaurante con pedido, catálogos para comerciales o pedidos de clientes profesionales.
• Negocios que viven de Google: si la mayoría de tus clientes llegan buscando, una PWA mantiene el posicionamiento de la web y además se puede instalar.
• Presupuestos ajustados o proyectos que hay que validar: una sola base de código, sin tiendas ni revisiones, y con cambios inmediatos.

Hay proyectos en los que intentar meter todo en una PWA es hacerse trampas al solitario. Merece la pena ir a las tiendas cuando:

• Necesitas funciones que la web no ofrece en iPhone: Bluetooth con dispositivos, NFC, seguimiento de ubicación continuo en segundo plano o integración profunda con el sistema.
• Tu negocio depende de notificaciones fiables en iPhone para usuarios que no van a instalar una web en la pantalla de inicio.
• La app es el producto en sí y se usa a diario durante mucho rato: una red social, una app de entrenamiento o una herramienta de campo con mucho trabajo sin conexión.
• Quieres que las tiendas sean un canal de captación, porque tu público busca soluciones directamente en App Store o Google Play.
• Hay requisitos gráficos o de rendimiento muy altos, como juegos o edición de vídeo.

La decisión no tiene por qué ser para siempre. Una estrategia que funciona muy bien para pymes es empezar con una PWA bien hecha, medir cómo la usan los clientes y, solo si aparecen necesidades que la web no cubre, dar el salto a una app de tienda. Si el backend se diseña desde el principio como una API limpia, la futura app reutiliza todo ese trabajo: usuarios, datos, pagos y lógica de negocio.

Así inviertes primero en lo que genera valor (el servicio, los procesos, la experiencia) y dejas la parte más cara para cuando tengas datos reales. Es el mismo enfoque con el que planteo cualquier proyecto de desarrollo web: construir lo justo, medir y crecer sobre una base sólida en lugar de rehacerlo todo al año siguiente.

Antes de pedir presupuesto, responde a estas preguntas con sinceridad. Te ahorrarán semanas de vueltas:

1. 1¿Qué tiene que poder hacer el cliente desde el móvil que hoy no puede hacer con tu web?
2. 2¿Alguna de esas funciones necesita hardware que Safari no ofrece, como Bluetooth, NFC o ubicación en segundo plano?
3. 3¿Con qué frecuencia lo va a usar? Una vez al mes no justifica que alguien descargue una app; a diario, quizá sí.
4. 4¿De dónde llegan tus clientes: de Google, de redes sociales, del boca a boca o de las tiendas de apps?
5. 5¿Tienes presupuesto no solo para desarrollarla, sino para mantenerla actualizada durante años?

La pregunta útil no es «¿PWA o app?», sino «¿qué tiene que hacer mi cliente y dónde lo va a hacer?». Para la mayoría de pymes, una PWA bien construida resuelve reservas, pedidos, áreas privadas y avisos con un coste y un mantenimiento mucho menores. Las apps nativas o híbridas tienen su sitio cuando el hardware, el uso intensivo o las tiendas son parte del negocio. Conocer las limitaciones de iPhone de antemano evita la peor situación posible: descubrirlas con el proyecto ya terminado.

Soy Elmar Mamedova, desarrollador full stack en Málaga, y paso buena parte de mi trabajo convenciendo a clientes de que no gasten en lo que todavía no necesitan. Desarrollo PWA, aplicaciones web y backends preparados para crecer hacia una app si algún día hace falta. Si estás dudando entre una cosa y otra, cuéntame tu idea y te doy una opinión honesta, aunque la respuesta sea que todavía no necesitas ninguna de las dos.