App nativa, web o PWA: cuál necesita tu negocio de verdad
Casi todo el mundo pide una app cuando lo que necesita es una web que funcione bien en el móvil. A veces es al revés. Cómo saber en qué caso estás.
Pocas peticiones llegan tan decididas de antemano como «quiero una app». Viene con el formato ya elegido, antes de que nadie haya puesto por escrito qué problema hay que resolver, y por eso mismo acierta menos veces de las que debería. Muchas veces lo que ese negocio necesita es una web que funcione bien en el móvil, más barata y más rápida de tener lista. Otras, la app sí es la respuesta correcta, y pedir lo contrario —una web, por ahorrar— sale caro por otro camino. La diferencia entre estar en un caso o en el otro no depende de gustos ni de qué suena más moderno: depende de un puñado de preguntas concretas con respuesta clara.
#Las tres opciones, en una frase cada una
Una web es una página a la que se entra desde el navegador del móvil o del ordenador, sin instalar nada. Se actualiza sola, en el momento en que se publica un cambio, y la usa cualquiera que tenga un enlace.
Una app nativa es un programa que el usuario instala desde la tienda de su teléfono —la de dispositivos con un tipo de sistema o la del otro—, ocupa espacio en su memoria, y aparece como un icono más entre el resto de sus aplicaciones.
Una PWA —una web que se comporta como una app— es un término medio: sigue siendo, por dentro, una página web, pero el usuario puede «instalarla» como un icono en su pantalla de inicio, puede seguir funcionando parcialmente sin conexión y puede enviarle notificaciones aunque no la tenga abierta. No pasa por la tienda de aplicaciones ni exige el proceso de revisión de esas tiendas.
#Las preguntas que deciden
Antes de elegir, hay un puñado de preguntas que, respondidas con honestidad, dejan la decisión bastante más clara de lo que parecía al principio.
¿Necesitas acceso a funciones del propio teléfono que una web no puede usar bien? Cámara con procesado avanzado, sensores del dispositivo, lectura de etiquetas por proximidad, funcionamiento completo sin conexión durante horas, o cobro dentro de la propia aplicación con los sistemas de pago de la tienda. Si tu negocio necesita de verdad alguna de estas cosas —no «estaría bien tenerla», sino que el servicio no funciona sin ella—, empieza a inclinar la balanza hacia la app nativa.
Conviene retirar de esa lista una función que se sigue citando como si obligara a ir a nativo y ya no lo hace: las notificaciones que llegan con la aplicación cerrada. Una web instalada en la pantalla de inicio también las envía —en los teléfonos con sistema de Google desde hace bastantes años, y en el iPhone desde hace ya varios—, así que querer avisar a tu cliente de algo no es, por sí solo, un motivo para pagar dos desarrollos. Lo que sigue siendo terreno propio de la app nativa es el acceso profundo al aparato: todo aquello donde el programa necesita hablar de tú a tú con el hardware o con el sistema del teléfono.
¿Tu usuario va a volver a diario, o entra dos veces al año? Esta es, con diferencia, la pregunta que más pesa de todas. Alguien que consulta tu servicio a diario está dispuesto a instalar algo, porque el esfuerzo de instalarlo una vez se compensa con el uso frecuente que le va a dar después. Alguien que entra dos veces al año —para reservar unas vacaciones, para pedir un presupuesto puntual, para consultar un horario ocasional— no va a instalar nada por ti, por buena que sea la app, porque el esfuerzo de instalarla es mayor que el beneficio de tenerla instalada para un uso tan esporádico.
#El coste real de una app nativa que casi nadie cuenta
Cuando se presupuesta una app nativa, es habitual que la cifra que llega solo contemple el desarrollo de la aplicación en sí. Hay al menos tres costes más, tan reales como ese, que rara vez aparecen en la primera conversación:
- Normalmente hacen falta dos desarrollos, no uno. Existen dos grandes tipos de teléfono en el mercado, cada uno con su propio sistema, y aunque hay formas de compartir parte del código entre ambos, cada tienda tiene sus propias reglas y sus propias particularidades técnicas. En la práctica, es casi como mantener dos productos en paralelo en lugar de uno.
- Cada tienda revisa la aplicación antes de publicarla, y puede rechazarla. Publicar una actualización no es subirla y ya está: pasa por un proceso de revisión que puede tardar días, y que puede devolver la aplicación pidiendo cambios antes de aprobarla, incluso para una corrección pequeña y urgente.
- Las actualizaciones dependen de que el usuario acepte instalarlas. Una web se actualiza para todo el mundo en el instante en que se publica el cambio. Una app nativa se actualiza solo para quien decide, de forma activa, descargar la nueva versión —y una parte de los usuarios de cualquier aplicación se queda, durante meses, en versiones antiguas sin darse cuenta.
Cada paso que exiges antes de que alguien use tu servicio —buscar la aplicación, descargarla, esperar a que se instale, aceptar permisos— pierde a una parte de la gente que llegó con intención real de usarlo. Si esa persona solo te iba a usar una vez, ese coste de instalación puede ser mayor que el valor que le vas a dar a cambio. Es la razón de fondo por la que tantas apps con buena idea detrás terminan sin descargas: no fallan por el producto, fallan por pedir un compromiso que el usuario no estaba dispuesto a dar para ese caso de uso.
#Cuándo la app sí compensa
Hay un perfil de negocio en el que la app nativa deja de ser un capricho y pasa a ser la opción con más sentido: cuando el usuario vuelve con mucha frecuencia, cuando el servicio depende de verdad de una función profunda del teléfono que una web no puede ofrecer con la misma calidad, y cuando ese usuario ya tiene un motivo fuerte para instalar algo antes incluso de que exista la aplicación —por ejemplo, porque ya es cliente habitual y quiere llevar encima, de forma cómoda, algo que antes solo tenía en papel o por email.
Una tienda con web y local físico que quiera ofrecer una tarjeta de fidelización que el cliente presenta en cada visita es un ejemplo razonable, siempre que la tarjeta tenga que integrarse con el monedero del propio teléfono o leerse en el mostrador con el lector que ya hay allí: el uso es repetido, el aparato participa de verdad en el trámite, y el cliente que ya compra allí con regularidad tiene un motivo real para instalar algo. Si esa misma tarjeta se resuelve enseñando un código en pantalla, el argumento a favor de la app se desinfla, y con un catálogo de productos para consultar de vez en cuando desaparece del todo: ahí una web bien resuelta cumple exactamente igual, sin pedirle nada a nadie.
#Cuántas veces al mes: el número que decide
Si solo puedes hacerte una pregunta antes de decidir, que sea esta: ¿cuántas veces al mes va a abrir esto una misma persona?
Si la respuesta es «varias veces por semana», la balanza se inclina hacia la app nativa, siempre que además haga falta alguna de esas funciones profundas del teléfono. Si la respuesta es «una o dos veces al año», casi cualquier app nativa es una inversión que no se va a rentabilizar, y una web —o, si hace falta algo de comportamiento de aplicación, una PWA— resuelve lo mismo sin pedirle al usuario un compromiso que no está dispuesto a dar. Entre medias, cuando el uso es moderado pero no diario, la PWA suele ser el punto de equilibrio: se instala con un paso, no pasa por ninguna tienda, avisa al usuario cuando hace falta igual que lo haría una app de la tienda, y ofrece buena parte de lo demás que un usuario espera de una aplicación sin cargar con el coste doble de mantener dos desarrollos distintos.
Antes de aprobar el presupuesto de una app nativa, haz que alguien te responda esa pregunta con un número, no con una intuición. Es la que más veces separa un acierto de un gasto que termina, meses después, sin apenas descargas.