App nativa, PWA o web responsive: cuál necesitás

En corto: si tus usuarios son empleados o clientes empresariales, casi siempre alcanza con una web responsive o una PWA. Una app se justifica por cinco razones: operación seria sin conexión, GPS en segundo plano, notificaciones push confiables en iPhone, uso intensivo del hardware o que estar en la tienda sea parte del negocio. Si hacés app, multiplataforma (React Native o Flutter) es la respuesta para la enorme mayoría de las apps de empresa.

"Necesitamos una app" es una de las frases que más plata hace gastar de más en proyectos de software. No porque las apps no sirvan, sino porque en la mitad de los casos lo que se necesita no es una app.

La discusión de app nativa, PWA o web responsive suele plantearse como una cuestión técnica, y en realidad es una cuestión de negocio: quién va a usar el sistema, con qué frecuencia, en qué lugar y con qué dispositivo. Esta nota ordena las opciones, incluida la que casi siempre se nombra mal (la app "híbrida"), da una forma concreta de decidir y deja claro qué hay que dejar cerrado si finalmente hacés una app.

Las opciones, sin vueltas

Web responsive. Un sitio o sistema web que se adapta al tamaño de la pantalla. Se entra por link, no se instala nada, se actualiza al instante y funciona en cualquier dispositivo con navegador.

PWA (aplicación web progresiva). Una web con capacidades extra: se puede "instalar" en la pantalla de inicio, funciona sin conexión hasta cierto punto y puede mandar notificaciones. Sigue siendo una web: no pasa por las tiendas ni tiene que ser aprobada por Apple o Google.

App híbrida. Es la palabra que más confunde. Históricamente se llamó híbrida a una app que adentro es una web empaquetada (con herramientas como Ionic o Capacitor) y se publica en las tiendas. Hoy mucha gente usa "híbrida" como sinónimo de multiplataforma. Conviene preguntar siempre a qué se refiere el proveedor, porque el costo y la experiencia son distintos.

App multiplataforma. Un solo código (React Native o Flutter) que genera una app para iOS y otra para Android, con componentes que el usuario siente como nativos. Es la opción por defecto para casi todo lo que no sea un juego o una app de hardware especializado.

App nativa. Se desarrolla por separado para cada sistema (Swift para iPhone, Kotlin para Android) y se descarga de App Store o Google Play. Acceso completo al hardware y al rendimiento del teléfono, al precio de mantener dos desarrollos.

App nativa vs híbrida vs PWA: la comparación completa

Esta tabla resume lo que importa a la hora de decidir. Son criterios generales: antes de comprometerte, verificá cada punto contra tu caso, sobre todo en iPhone.

Dos aclaraciones sobre la tabla. La primera: una PWA en iPhone tiene condiciones propias. Para recibir notificaciones, el usuario tiene que agregar la web a la pantalla de inicio y aceptar el permiso, y esa fricción hace que la tasa de activación sea menor que en una app instalada. La segunda: la "web empaquetada" tiene un problema en Apple, cuya guía de revisión rechaza apps con funcionalidad mínima, es decir, las que son sólo una web con un marco. Si el proveedor propone envolver tu web y publicarla, preguntale cómo van a justificar ante la revisión que aporta algo más que el sitio.

La diferencia de costo

Sobre una base común, y como orden de magnitud:

• Web responsive: el punto de partida.
• PWA: entre un 10% y un 30% más que la web responsive.
• App multiplataforma (React Native, Flutter): entre 1,5 y 2,5 veces la web responsive.
• App nativa doble (iOS y Android por separado): entre 2 y 4 veces.

Y el costo que casi nunca se cotiza: una app tiene mantenimiento obligatorio de USD 1.500 a 4.000 anuales sólo para seguir existiendo en las tiendas, sin agregarle una funcionalidad. Una web no tiene ese piso. Si querés los rangos en dólares por tipo de desarrollo, están en cuánto cuesta desarrollar una app móvil en Argentina.

Cuándo necesitás una app de verdad

Sólo cinco razones lo justifican. Si tu caso no está acá, probablemente no la necesites.

1. Funcionar sin conexión de forma seria. Un repartidor en una zona sin señal, un relevamiento en el campo, un inventario en un depósito sin wifi. Una PWA cubre casos livianos; operación real sin conexión pide app.
2. GPS en segundo plano. Seguir un recorrido con la app cerrada. Una web no puede.
3. Notificaciones push confiables en iPhone. Las PWA mejoraron mucho, pero en iOS siguen teniendo más limitaciones que una app.
4. Uso intensivo del hardware. Escaneo continuo de códigos, cámara con procesamiento, Bluetooth con impresoras o balanzas, lectores NFC.
5. Estar en la tienda es parte del negocio. Si tus usuarios te van a buscar ahí, o si la presencia en la tienda es señal de seriedad frente a tu cliente.

Cuándo NO la necesitás, aunque te la pidan

• "Para que esté en el celular." Una web responsive está en el celular.
• "Para que sea más rápida." Una web bien hecha es rápida. Una app mal hecha es lenta.
• "Para que se vea profesional." Eso es diseño, no tecnología.
• "Para que la tengan a mano." Una PWA se agrega a la pantalla de inicio y queda igual que una app.
• "Porque la competencia tiene." Fijate cuántas descargas tiene y cuándo fue su última actualización antes de usarla como argumento.

El punto que decide la mayoría de los casos

Si tus usuarios son empleados o clientes empresariales, casi siempre gana la web.

Motivo práctico: instalar una app tiene fricción. Hay que buscarla, bajarla, permitirla, actualizarla. Con empleados eso significa soporte; con clientes empresariales significa que una parte simplemente no la va a instalar.

Un link funciona el primer día para todo el mundo.

Si tus usuarios son consumidores finales y vas a usarlos seguido, la app tiene más sentido: la recurrencia justifica la fricción inicial, y las notificaciones son un canal que la web no te da con la misma confiabilidad.

Qué conviene según el rubro

La misma pregunta tiene respuestas distintas según quién use el sistema. Algunos ejemplos típicos, sin que sean reglas fijas:

• Distribuidora con vendedores en la calle. Toman pedidos en el cliente, a veces sin señal. Si el vendedor necesita cargar pedidos sin conexión y sincronizar después, es un caso de app multiplataforma. Si trabaja casi siempre con datos, una PWA o una web responsive alcanza. Más en software para distribuidoras mayoristas.
• Logística y reparto. Seguimiento de recorrido con la app cerrada y firma de entrega con foto: GPS en segundo plano y cámara. Es de los pocos rubros donde la app casi siempre se justifica. Ver software para empresas de logística.
• Clínicas y consultorios. El personal usa el sistema desde una computadora; el paciente, para sacar turnos o ver resultados, con una web responsive o un portal funciona perfecto. Una app suele ser un lujo temprano.
• Constructoras. Un capataz en una obra sin buena señal que carga avances y fotos: PWA con cola de envío o app multiplataforma, según cuánto se trabaje desconectado.
• Agro. Recorridas de campo con GPS y sin señal: caso clásico de funcionamiento sin conexión. Mirá software para empresas agropecuarias.
• Estudios contables. El cliente sube comprobantes y consulta vencimientos. Una web responsive o un portal cubre todo; la foto del ticket se saca desde el navegador del celular.
• Inmobiliarias. El agente muestra fichas y carga visitas desde el celular. Web responsive con buena carga de fotos. La app propia sólo aparece cuando el negocio es el portal de búsqueda.

Nativa, híbrida o multiplataforma, si ya decidiste app

Para la enorme mayoría de las apps de empresa, multiplataforma es la respuesta correcta. Un solo código para iOS y Android, una sola vez que mantener, bastante menos plata.

La nativa se justifica cuando la app exige lo último del hardware, cuando el rendimiento gráfico importa, o cuando dependés de funciones muy específicas del sistema operativo.

La híbrida en el sentido de web empaquetada puede servir para un prototipo o para una app muy simple que ya existe como web, pero tiene dos límites: la sensación de uso es menos fluida y la revisión de Apple puede objetarla si aporta poco más que el sitio.

Quien te empuje a nativa doble sin explicar cuál de esas razones aplica a tu caso te está encareciendo el proyecto sin darte nada a cambio.

Un camino que casi siempre conviene

Empezá por la web responsive.

Sale antes, cuesta menos y te deja algo funcionando frente a usuarios reales. De ahí salen dos cosas que ningún relevamiento te da: descubrís cómo se usa realmente, y comprobás si alguna de las cinco razones para tener app aplica de verdad a tu caso.

Si a los tres meses la web alcanza, te ahorraste la app y su mantenimiento anual. Si no alcanza, llegás a la app sabiendo exactamente qué tiene que hacer, que es la diferencia entre un presupuesto que se cumple y uno que se estira.

El orden natural de escalada es este: web responsive, después PWA si hace falta instalación y avisos, y recién después app multiplataforma si aparece una de las cinco razones. Cada paso reutiliza buena parte del anterior, sobre todo el backend, que es donde se concentra el trabajo grande. Por eso conviene que el sistema esté pensado desde el principio con una API que después pueda alimentar una app, aunque hoy no la haya.

Cómo decidir en seis pasos

1. Escribí quién la usa. Empleados, clientes empresariales o consumidores. Es la variable que más pesa.
2. Anotá dónde la usan. Oficina, calle, depósito, obra, campo. El lugar define la señal y el hardware.
3. Contá cuántas veces por día se abre. Si es una o dos veces por semana, nadie va a instalar nada. Si son quince veces por día, el ícono vale.
4. Marcá cuáles de las cinco razones aplican. Si no marcás ninguna, quedate en web o PWA.
5. Pedí que cotizen dos escenarios. Web responsive o PWA, y app multiplataforma. La diferencia entre las dos cifras es el precio real de la decisión.
6. Definí qué se mide para pasar al siguiente nivel. Por ejemplo: "si más del 30% del equipo pide trabajar sin señal, pasamos a app". Sin un número, la decisión se vuelve opinión.

Errores comunes al elegir

• Elegir la tecnología antes que el uso. Se discute React Native contra Flutter cuando todavía no se sabe quién va a abrir la app.
• Cotizar sólo la app y no el backend. La app es la punta visible; detrás hay una API, permisos y un panel donde se administra todo. Si el presupuesto no lo menciona, preguntá dónde está.
• Ignorar el mantenimiento. Una app abandonada dos años no es una app vieja: puede dejar de estar disponible en las tiendas.
• Pagar nativa doble por un beneficio que el usuario no nota. En una app de gestión, la diferencia con multiplataforma es casi imperceptible.
• Lanzar la app antes de probar la web. Es la manera más cara de descubrir que nadie necesitaba instalarla.
• Olvidar los teléfonos reales. Los equipos de trabajo suelen ser de gama baja con Android viejo. Probalo ahí, no sólo en el emulador.
• No presupuestar el tiempo de revisión. Apple revisa cada versión a mano. En el primer lanzamiento conviene contar unas dos semanas entre "lista" y "publicada".

Lo que hay que dejar cerrado si hacés app

Dos cosas, y las dos se arreglan al principio o no se arreglan nunca:

• Las cuentas de desarrollador de Apple y Google a nombre de tu empresa, no del proveedor. Si están a nombre de quien la desarrolló, tu app es rehén de esa relación.
• Quién publica las actualizaciones y con qué tiempo de respuesta cuando Apple o Google cambian un requisito. Porque lo van a cambiar, y con fecha límite.

Sumá una tercera, que depende del contrato: que el código y los accesos a los servicios (notificaciones, mapas, base de datos) queden a tu nombre. La lista completa de lo que pedir al recibir un desarrollo está en qué pedir cuando te entregan un desarrollo.

Preguntas frecuentes

¿Cuánto cuesta mantener una app en las tiendas?

Entre USD 1.500 y 4.000 por año sólo para seguir existiendo en las tiendas, sin agregar funcionalidades, porque Apple y Google cambian sus requisitos todos los años. Una web no tiene ese piso.

¿Cuándo no hace falta una app aunque la pidan?

Cuando la razón es que esté en el celular, que sea más rápida, que se vea profesional, tenerla a mano o que la competencia tiene una. Una web responsive está en el celular y una PWA se agrega a la pantalla de inicio igual que una app.

¿Nativa o multiplataforma?

Para la enorme mayoría de las apps de empresa, multiplataforma: un solo código para iOS y Android, una sola vez que mantener y bastante menos plata. La nativa se justifica por hardware de punta, rendimiento gráfico o funciones muy específicas del sistema operativo.

¿Qué hay que dejar cerrado si finalmente se hace una app?

Las cuentas de desarrollador de Apple y Google a nombre de tu empresa y no del proveedor, y quién publica las actualizaciones y con qué tiempo de respuesta cuando las tiendas cambian un requisito.

¿Qué diferencia hay entre una app nativa, una híbrida y una PWA?

La nativa se desarrolla por separado para iPhone y Android y aprovecha todo el hardware. La híbrida, en su sentido clásico, es una web empaquetada que se publica en las tiendas, y hoy a veces se usa como sinónimo de multiplataforma. La PWA es una web instalable que no pasa por las tiendas. Cambian el costo, la experiencia y el mantenimiento.

¿Una PWA funciona bien en iPhone?

Funciona, con condiciones. Se puede agregar a la pantalla de inicio y, desde las versiones recientes de iOS, recibir notificaciones si el usuario la instaló y aceptó el permiso. Aun así tiene más limitaciones que en Android, sobre todo en segundo plano y en acceso al hardware, y conviene probarla contra tu caso antes de comprometerte.

¿Se puede empezar con una web y después hacer la app?

Sí, y es el camino que más conviene. Si el sistema tiene una API bien armada, la app reutiliza el backend y sólo hay que construir las pantallas móviles. Además, después de unos meses de uso real sabés qué pantallas necesita la app, y la que sale es mejor y más chica que la que hubieras especificado de entrada.

¿Cuánto tarda en publicarse una app en App Store y Google Play?

Apple revisa cada versión a mano y puede tardar entre un día y una semana, con posibilidad de rechazo. Google suele ser más rápido. Para el primer lanzamiento conviene presupuestar dos semanas entre que la app está lista y que está publicada.

Cómo encaramos una app, y la web o la PWA que suele antecederla, con demo gratis en 24 a 48 horas y un proyecto de USD 5.000 a 10.000, más sólo en casos excepcionales, está en desarrollo de apps. Si preferís charlarlo, agendá una llamada.

Para elegir quién la desarrolla: los mejores desarrolladores de apps de Argentina, comparados.