Meypi Developers, inicioPide presupuesto
Pide presupuesto

App nativa o PWA: qué necesita tu empresa

Meypi Developers · Actualizado el

Elegir entre una app nativa o PWA empieza por lo que debe poder hacer la persona que la usa. Una web instalable puede encajar si el recorrido funciona en el navegador; una app merece estudiarse cuando hay requisitos que ese recorrido no cubre. En Meypi Developers, un estudio de software del área metropolitana de Barcelona, proponemos decidirlo con una lista de tareas y una prueba del requisito más difícil.

1. Qué comparas cuando dices app o web

Una web se abre con un enlace. Una PWA es una web instalable que puede añadirse al dispositivo y abrirse desde su icono. Una app nativa se construye para una plataforma; un proyecto multiplataforma comparte parte del desarrollo para más de una. Estos nombres ayudan a describir la solución, pero no deciden si resuelve tu negocio.

La instalación de una PWA cambia según el navegador y el sistema. La documentación de instalación de MDN recoge esas diferencias. Un icono en el teléfono no demuestra por sí solo uso sin cobertura ni compatibilidad con una función concreta.

2. Una tabla para empezar a decidir

Qué comprobar antes de elegir
Tu necesidadPrimera opción que estudiarPrueba que debe pasar
Publicar información y recibir consultasWeb adaptada al móvilAbrir un enlace, leer y contactar sin instalar nada.
Reservar o consultar una cuenta con frecuenciaWeb instalable o app, según los requisitosCompletar la tarea en los dispositivos del público real.
Trabajar sin coberturaCualquiera que implemente ese recorridoGuardar sin red y recuperar la conexión sin perder ni duplicar el trabajo.
Usar una función concreta del teléfonoComparar la función exacta en ambas opcionesEnsayarla con permisos concedidos, rechazados y retirados.
Estar en las tiendas de aplicacionesProyecto de app con su distribución definidaConcretar quién es titular de las cuentas y qué se publica.

La tabla es un criterio de trabajo de Meypi, no una regla que haga ganadora a una tecnología. Si varias opciones pasan las pruebas, comparamos el coste de construirlas y mantenerlas.

3. Escribe los requisitos como tareas

  • Quién entra: un cliente ocasional, un socio que vuelve cada semana o un equipo que la usa todo el día.
  • Qué tiene que terminar: pedir una cita, consultar un documento, registrar una visita o pagar.
  • Qué ocurre sin red: qué puede consultar, qué puede guardar y cuándo recibe confirmación.
  • Qué avisos necesita: para qué sirven y qué pasa si no da permiso o no los recibe.
  • Qué dispositivos utiliza: teléfonos, ordenadores, versiones y navegadores habituales.
  • Con qué se conecta: qué programa conserva el dato y quién resuelve una conexión interrumpida.

Por ejemplo, «registrar una visita durante una zona sin cobertura y enviarla una sola vez al volver la conexión» permite preparar una prueba. «Que sea como una app» todavía no dice qué hay que comprobar. El ejemplo define un requisito; no describe un proyecto de cliente.

4. Instalar, recibir avisos y trabajar sin red son tres decisiones

El uso sin conexión requiere preparar qué se guarda y cómo se sincroniza. MDN explica la operación sin conexión y en segundo plano. Conviene probar el recorrido entero, incluido lo que ve la persona cuando algo aún no se ha enviado.

En iPhone y iPad, WebKit documenta los avisos web para aplicaciones añadidas a la pantalla de inicio desde iOS y iPadOS 16.4, con permiso solicitado tras una acción de la persona.Condiciones de Web Push en WebKit. No conviene presupuestar «avisos en todos los móviles» sin fijar primero los dispositivos y el recorrido de permisos.

5. Dos recorridos para poner a prueba la decisión

En nuestra página de desarrollo de apps ilustramos un aviso de clase y un test sin conexión. Aquí los usamos para preparar requisitos; no los presentamos como dos clientes ni como pruebas nuevas de compatibilidad.

  • El aviso de una clase.: El socio acepta avisos, recibe uno y abre la clase correcta. Pide probar también qué ocurre si no da permiso y cómo consulta la actividad por otra vía. Tener avisos en una lista de funciones no resuelve esos pasos.
  • El test en el metro.: El alumno responde sin red, cierra la aplicación y recupera su trabajo. Al volver la conexión, comprueba el progreso guardado y que un reintento no lo duplique. La elección queda pendiente de esa prueba en los dispositivos acordados.

6. Pide una prueba del requisito que puede cambiar la decisión

Antes de construir todas las pantallas, elige el requisito que podría descartar una opción. Prepara un recorrido pequeño: entrar, completar la tarea, comprobar el dato y recuperarse de un fallo. La decisión debe apoyarse en su resultado, no solo en una lista de funciones.

  • Repite la tarea en los teléfonos y navegadores acordados.
  • Prueba con poca conexión y vuelve a abrir la aplicación.
  • Comprueba qué pasa al rechazar un permiso y cómo continuar.
  • Verifica el resultado en el programa que guarda el dato.
  • Anota qué funciona, qué falta y qué obliga a cambiar de opción.

7. Qué comparar en el presupuesto

Compara la misma primera versión, con las mismas pruebas. Separa diseño, funciones, conexiones, distribución, mantenimiento y atención de incidencias. Una web instalable no tiene un ahorro fijo frente a una app: depende de lo que haya que construir y conservar.

Nuestra guía de cuánto cuesta crear una app explica los factores del presupuesto. Para conocer las fases del trabajo, puedes leer cómo se desarrolla una app.

8. Qué preparar para estudiar tu proyecto

Trae tres tareas imprescindibles, los dispositivos que usa tu público y los programas con los que hay que conectar. Si existe una web o aplicación anterior, añade qué se quiere conservar y qué falla hoy. Con eso se puede delimitar la primera versión y decidir qué hay que ensayar.

Si quieres valorar el encargo, consulta nuestro servicio de desarrollo de apps o cuéntanos qué necesita tu empresa.

Sigue leyendo

Cuéntanos qué necesitas

Qué quieres construir, para cuándo y con qué presupuesto.

Usamos tus datos solo para responderte.