Aplicación web o app móvil: cómo elegir la primera plataforma

Elija entre una aplicación web y una app móvil según la tarea que sus usuarios necesitan completar. Una aplicación web suele ser un buen punto de partida para el trabajo al que se llega mediante un enlace y que se realiza desde distintos dispositivos. Una app móvil nativa es una candidata más sólida cuando el recorrido principal depende de capacidades concretas del dispositivo o de un uso frecuente en el teléfono. Pruebe los requisitos antes de comprometerse con una u otra.

«La gente la usará en el móvil» no zanja la decisión. Una aplicación web puede funcionar en el navegador de un móvil. Tampoco basta con «necesitamos acceso sin conexión»: el comportamiento sin conexión hay que diseñarlo, y algunas aplicaciones web pueden admitirlo. La pregunta útil es qué enfoque puede cubrir su flujo de trabajo real con restricciones aceptables.

¿Cuál es la diferencia?

Una aplicación web se ejecuta en un navegador. Los usuarios suelen acceder mediante una URL, y la interfaz puede adaptarse a un teléfono, una tableta o un equipo de escritorio. Sus capacidades dependen de los navegadores y dispositivos que usted admita.

Una aplicación móvil nativa se construye para una plataforma concreta, como iOS. Se instala en el dispositivo y usa las convenciones de interfaz y las APIs disponibles de esa plataforma. Admitir otra plataforma nativa supone trabajo adicional de entrega y verificación.

Una aplicación web progresiva, o PWA, usa tecnologías web con capacidades adicionales, como la instalación y un comportamiento sin conexión diseñado a propósito. La documentación de MDN sobre las PWA explica esas posibilidades. Su disponibilidad y su comportamiento aún deben comprobarse en sus dispositivos de destino; «PWA» no es una promesa de que todas las funciones nativas funcionen en todas partes.

Use los requisitos siguientes para elegir la primera plataforma del producto.

Compare las restricciones antes que la tecnología

En una pantalla estrecha, desplace la tabla hacia los lados para leer todas las columnas.

Requisito	Aplicación web: qué comprobar	App nativa: qué comprobar
Los clientes llegan mediante un enlace	¿Pueden completar el recorrido en los navegadores admitidos sin instalar nada?	¿Es aceptable que instalen una app antes de recibir valor?
El trabajo abarca escritorio y teléfono	¿Los diseños y las interacciones sirven para ambos?	¿Los usuarios de escritorio necesitarán también una interfaz web?
Una función del dispositivo es esencial	¿La API necesaria está disponible y es fiable en los navegadores exactos que debe admitir?	¿La plataforma ofrece la capacidad, y qué permisos y restricciones se aplican?
La conexión no es fiable	¿Qué acciones funcionan sin conexión y cómo se sincronizará el trabajo almacenado?	Se aplican las mismas preguntas; instalar la app no hace que funcionen sin conexión las acciones que dependen del servidor.
Se necesitan varias plataformas	Verifique el comportamiento en las combinaciones de navegador y dispositivo admitidas.	Defina el alcance de cada plataforma y las pruebas, el trabajo de publicación y el mantenimiento que necesita.
Las versiones deben cambiar con frecuencia	Planifique el despliegue, la compatibilidad y la recuperación para los cambios en el servicio en funcionamiento.	Tenga en cuenta también la distribución, la revisión cuando proceda y los usuarios con versiones antiguas de la app.

No trate esto como una puntuación en la que gana quien suma más marcas. Una sola capacidad esencial puede determinar el enfoque. Varias preferencias pueden no justificar plataformas adicionales.

Dos ejemplos que llevan a primeras versiones distintas

Un portal de aprobación para clientes: los clientes reciben un enlace, revisan documentos, aprueban trabajos y a veces completan la tarea desde el teléfono. El personal gestiona los registros desde un escritorio. Una aplicación web adaptable es una primera candidata razonable. Antes de construir una app, compruebe si instalarla mejoraría en algo el recorrido importante.

Una herramienta de registro en campo: el personal captura información durante todo el día en lugares con mala conexión. El producto necesita un comportamiento específico del dispositivo, registros locales y sincronización posterior. Evalúe una app nativa y una PWA frente a esos requisitos exactos. Un pequeño experimento de capacidad en los dispositivos reales puede resolver la elección mejor que una comparación genérica de funciones.

Son flujos de trabajo hipotéticos, no afirmaciones sobre resultados de clientes de AL+. El primero favorece el acceso sencillo desde distintos dispositivos; el segundo pone en el centro el comportamiento del dispositivo y de la conexión. Ninguno determina la arquitectura de todos los productos de su categoría.

El trabajo sin conexión necesita un comportamiento escrito, no una etiqueta

Describa qué ocurre antes, durante y después de que falle la conexión:

¿Qué información debe estar ya en el dispositivo?
¿Qué acciones puede completar el usuario sin respuesta del servidor?
¿Cómo muestra la interfaz el trabajo guardado, pendiente, fallido y sincronizado?
¿Qué ocurre si otra persona modifica el mismo registro?
¿Qué ocurre si el usuario cierra sesión, pierde el dispositivo o vuelve tras una interrupción larga?

Una pantalla en caché y una transacción de negocio sin conexión son requisitos distintos. Por ejemplo, mostrar una cita cargada antes no demuestra que se pueda confirmar una reserva nueva sin conectar con el sistema que gestiona la disponibilidad.

Tanto las implementaciones nativas como las web requieren decisiones sobre datos, conflictos y recuperación. Consulte la documentación de la plataforma pertinente y verifique el comportamiento crítico en lugar de prometerlo por el nombre de una tecnología.

El backend es una parte aparte de la decisión

Una app instalada puede seguir dependiendo de cuentas, registros compartidos, pagos, notificaciones y herramientas administrativas que funcionan en otro lugar. Una aplicación web puede necesitar esos mismos servicios.

En ambos casos, identifique qué backend existe ya, quién lo controla, qué interfaces hay disponibles y qué hay que construir. Llevar la interfaz a un teléfono no resuelve una integración poco fiable ni una titularidad de los datos poco clara.

Incluya el flujo de trabajo administrativo. Si alguien tiene que corregir un registro o atender a un cliente, decida cómo lo hará. Una experiencia móvil para el cliente y una interfaz web de administración pueden ser dos interfaces distintas de un mismo producto, pero ambas forman parte del alcance.

Compare estimaciones de la versión completa

Pida a cada propuesta que separe el trabajo común del producto del trabajo de cada plataforma:

Comportamiento compartido: reglas de negocio, datos, accesos, integraciones y operación del servidor.
Trabajo de interfaz: recorridos de usuario y diseños para cada interfaz admitida.
Verificación: los dispositivos, los navegadores, los permisos y los casos de fallo que se comprobarán.
Publicación: despliegue o envío a la tienda, acceso a las cuentas, información de soporte y recuperación.
Mantenimiento: cambios de compatibilidad, correcciones, versiones y cargos continuos de proveedores.

No existe un porcentaje universal fiable por el que un enfoque sea más barato que el otro. Un backend existente, una capacidad imprescindible del dispositivo o una segunda interfaz pueden cambiar la comparación. Compare la misma versión útil, no dos recuentos de pantallas ni dos tarifas por hora.

Nuestra guía del costo de una app móvil (en inglés) explica el trabajo que implica una estimación de una app nativa para iOS. Es una lista de verificación del alcance, no la promesa de un precio estándar de proyecto.

Un briefing para decidir la plataforma

Escriba estas seis líneas antes de pedir a un desarrollador que elija la tecnología:

Recorrido principal: lo que un usuario debe completar, desde el principio hasta el resultado.
Usuarios y dispositivos: quién lo usa, dónde, con qué frecuencia y en qué dispositivos.
Capacidades esenciales: el comportamiento exacto del dispositivo o las integraciones de las que depende el recorrido.
Comportamiento de la conexión: qué debe ocurrir cuando la red no está disponible.
Sistemas existentes: el backend, los datos, las cuentas y las interfaces que ya existen.
Límite de la primera versión: las plataformas admitidas, las exclusiones, las limitaciones de presupuesto y el motivo de cualquier fecha fija.

Si una capacidad pudiera cambiar la decisión, solicite una comprobación técnica concreta antes de construir todo. Si la incertidumbre es cómo usan las personas la interfaz, un prototipo puede ser el primer paso adecuado.

Hable del flujo de trabajo antes de comprometerse con una plataforma

AL+ crea aplicaciones web a medida y apps nativas para iPhone y iPad, y se responsabiliza de los servicios conectados y del mantenimiento tras el lanzamiento. Podemos hablar de la primera plataforma a partir de la tarea, los dispositivos de destino y el sistema existente.

Escriba a AL+ sobre su proyecto web o iOS. Envíe el briefing de seis líneas para que la conversación empiece con los requisitos que determinan el trabajo.