La Palabra de 40.000 Dólares: "App"

Un cliente me dice que quiere "una app." Aprendí a detenerme y hacer una pregunta antes de escribir una sola línea de propuesta, porque esa palabra esconde tres productos completamente distintos con tres presupuestos completamente distintos: una app nativa construida para App Store y Google Play, una aplicación web responsive que vive en una URL, y una Progressive Web App (PWA) que intenta quedarse con lo mejor de ambos mundos. Elegís mal y terminás gastando decenas de miles de dólares en algo que tus clientes nunca instalan, o gastás poco y entregás algo que no puede hacer lo que tu negocio realmente necesita.

Construí los tres tipos para clientes que van desde negocios de servicios locales hasta plataformas fintech, y la decisión casi nunca se reduce a qué tecnología es "mejor." Se reduce a qué hacen realmente tus usuarios, con qué frecuencia lo hacen, y si podés vivir sin las funciones que te tienta agregar solo porque suenan impresionantes en una presentación comercial.

Tres Productos, No Un Solo Espectro

Las apps nativas se construyen específicamente para iOS (Swift/SwiftUI) o Android (Kotlin), o para ambos a la vez usando un framework multiplataforma como React Native o Flutter. Viven en App Store y Google Play, tienen acceso completo a la cámara, GPS, Bluetooth y procesamiento en segundo plano del dispositivo, y en general se sienten más fluidas de usar.

Las aplicaciones web corren en un navegador a través de una URL, funcionan en cualquier dispositivo al instante, no requieren descarga, y se actualizan en el momento en que hacés el deploy — sin esperar la aprobación de nadie. Si ya tenés un sitio responsive, escribí sobre las decisiones de fondo en diseño web responsive, que es la base sobre la que se construye toda buena aplicación web.

Las PWAs son aplicaciones web potenciadas con un service worker y un archivo manifest, que permiten "instalarlas" en la pantalla de inicio, cachear recursos para uso offline y, en algunos casos, enviar notificaciones push. En Android, esta experiencia se acerca bastante a la nativa. En iOS, es un compromiso — y cada vez más limitado, como voy a explicar más abajo.

Costo: Adónde Va Realmente el Presupuesto

Este suele ser el factor decisivo, y las cifras no están para nada parejas. Una sola app nativa (iOS o Android) con funcionalidad real típicamente cuesta entre 30.000 y 80.000 dólares para un MVP, y construir para ambas plataformas por separado prácticamente duplica esa cifra. Los frameworks multiplataforma como React Native o Flutter achican la brecha — he visto reducciones de costo total del 30-40% comparado con dos códigos nativos completamente separados — pero igual pagás por los ciclos de revisión de las tiendas, testing en múltiples dispositivos y mantenimiento continuo cada vez que Apple y Google lanzan actualizaciones de sistema operativo, dos veces al año.

Una aplicación web o una PWA, en cambio, es un solo código, un solo pipeline de deploy, y ninguna cola de revisión de App Store. Para una pyme con presupuesto limitado, esto suele ser todo el argumento. Prefiero que un cliente invierta en una aplicación web rápida y bien construida — con el tipo de trabajo de performance de frontend que cubro en optimización de Core Web Vitals — antes que estirar un presupuesto ajustado entre dos plataformas nativas y terminar con una versión mediocre de cada una.

Alcance y Distribución

Las apps nativas dependen del descubrimiento dentro de la tienda, lo que significa competir por posicionamiento en la búsqueda de App Store o Play Store, además del proceso de revisión de Apple, que puede sumar días de idas y vueltas si tu app toca pagos, datos de salud, o cualquier cosa con lineamientos ambiguos. Un build rechazado es una semana perdida, a veces más.

Las aplicaciones web y las PWAs son alcanzables en el momento en que alguien hace clic en un link — desde una búsqueda de Google, un mensaje de texto, un email o un código QR en un folleto. No hay fricción de instalación ni intermediario que apruebe nada. Si tu estrategia de crecimiento depende de búsqueda orgánica o de que la gente comparta enlaces, esto importa más de lo que muchos dueños de negocio imaginan al principio.

Acceso Offline y Funciones del Dispositivo

Acá tengo que ser directo sobre una limitación que sorprende a mucha gente: las PWAs en iOS siguen siendo ciudadanas de segunda clase. Apple obliga a los usuarios a agregar manualmente una PWA a la pantalla de inicio a través del menú Compartir — no existe un aviso de instalación automático como en Android — y en la Unión Europea, Apple restringió aún más el comportamiento standalone de las PWAs bajo la Digital Markets Act, lo que significa que algunas PWAs en la UE simplemente abren como pestañas de navegador. El soporte offline mediante service workers funciona razonablemente bien para cachear páginas y recursos estáticos, pero no reemplaza la sincronización en segundo plano y el almacenamiento local sin restricciones que tiene una app nativa.

Si tu producto realmente necesita carga de datos offline confiable (por ejemplo, un equipo de técnicos de campo registrando trabajos sin señal), lo nativo suele ser la apuesta más segura. Si el soporte offline solo significa "que la página no se rompa con el wifi débil de un hotel," una PWA lo resuelve sin problema.

Notificaciones Push: La Función Que Todos Creen Necesitar

Todos los clientes preguntan por las notificaciones push, y pocos realmente las necesitan. Las apps nativas tienen capacidad push completa en ambas plataformas, sin salvedades. Las PWAs reciben push en Android sin mucha fricción, pero en iOS solo funciona para PWAs instaladas en la pantalla de inicio con iOS 16.4 en adelante — una pestaña abierta en Safari no cuenta, y el alcance realista que lográs de esta forma es una fracción de lo que consigue una app nativa, una vez que considerás cuán pocos usuarios completan el paso manual de instalación. Si las notificaciones push son centrales en tu estrategia de engagement y una porción importante de tus usuarios usa iPhone, presupuestá para nativo o aceptá un alcance considerablemente menor en iOS.

Un Marco de Decisión Simple

Factor Nativa App Web PWA
Costo inicial El más alto El más bajo Bajo-Medio
Tiempo de lanzamiento El más lento El más rápido Rápido
Distribución en tienda No Parcial (mejor en Android que en iOS)
Capacidad offline Completa Mínima Buena en Android, limitada en iOS
Notificaciones push Completas Ninguna Completas en Android, restringidas en iOS
Acceso a funciones del dispositivo Completo Limitado Moderado

Un Caso Real

Un cliente regional de servicios para el hogar vino a verme queriendo "una app" para agendar turnos y despachar técnicos. Su necesidad real era más simple de lo que pensaban: los clientes necesitaban reservar turnos y recibir recordatorios, y los técnicos necesitaban una vista mobile-friendly de los trabajos del día. Ninguno de los dos grupos necesitaba carga de datos offline ni acceso a la cámara más allá de subir una foto, algo que cualquier navegador moderno maneja sin problema. Construimos una aplicación web responsive con una capa PWA para el lado de los técnicos, de modo que pudieran agregarla a la pantalla de inicio y recibir recordatorios push en Android. El costo total de construcción fue una fracción de lo que hubieran costado dos apps nativas, y salió a producción en semanas, no en meses.

La Conclusión

No empieces por la tecnología. Empezá por lo que necesitan hacer tus usuarios, con qué frecuencia, y si van a tolerar una pestaña de navegador en lugar de un ícono de app. En la mayoría de los escenarios de pymes y B2B que veo, una aplicación web o una PWA bien construida entrega el 90% de la experiencia a una fracción del costo y sin ninguna fricción de tienda. Lo nativo justifica su costo cuando tu producto realmente depende de integración profunda con el dispositivo, confiabilidad offline, o alcance push específicamente en iPhones — no porque "app" suene más serio que "sitio web."

Si estás tratando de definir cuál de estas opciones se ajusta a tu situación, hablemos de su situación.