La pregunta llega casi siempre en el mismo momento: el producto web funciona, alguien pide una aplicación para el móvil, y hay que decidir en una reunión con qué se construye. La respuesta rápida suele ser cross-platform, porque suena a ahorro, y a veces lo es.
Lo que decide bien no es el ahorro en la primera versión sino tres cosas concretas: qué necesitas del teléfono, cómo va a llegar la aplicación al usuario, y quién la va a mantener dentro de dos años.
Las tres opciones, en una frase cada una
Antes de comparar conviene fijar de qué hablamos, porque las etiquetas se usan con holgura.
Nativo es escribir la aplicación con las herramientas del propio sistema: Swift y SwiftUI para iOS, Kotlin y Jetpack Compose para Android. Dos bases de código, dos equipos o un equipo que sabe las dos cosas.
Cross-platform es escribir una sola base de código que produce aplicaciones para ambos sistemas, con React Native, Flutter o similares. Una base, con partes específicas de cada sistema cuando hace falta.
PWA es una aplicación web que el navegador permite instalar y que funciona sin conexión gracias a un service worker. No hay aplicación que compilar; es tu web con capacidades añadidas.
Hay una cuarta vía que se olvida y que a menudo es la correcta: una web normal, bien hecha para móvil, sin instalación. Para muchos productos es todo lo que hacía falta.
La comparación en los cuatro criterios que deciden
Puestas una al lado de la otra, las diferencias que importan se reducen a un puñado.
El criterio del acceso al hardware es el que descarta opciones antes que ningún otro. Si necesitas Bluetooth de baja energía, NFC, procesamiento de vídeo en tiempo real o seguimiento de ubicación en segundo plano, la PWA queda fuera en la mayoría de los casos y con cross-platform dependes de que exista un plugin mantenido.
El de la distribución decide en la otra dirección. Si quieres que el usuario entre desde un enlace sin pasar por una tienda, sin actualizaciones que aprobar y sin revisión externa, la PWA es la única que lo permite.
El coste de arranque ordena las tres de forma previsible, pero es el criterio menos fiable de los cuatro, porque el coste que duele no es el de la primera versión.
Lo que de verdad cuesta: el mantenimiento
La comparación de costes que se hace en la reunión suele ser la de construir. La que se paga después es la de mantener, y ahí el orden cambia.
En nativo, mantener significa seguir dos ciclos de actualización del sistema, con sus cambios de API y sus requisitos nuevos cada año. Es predecible y está documentado por quien fabrica el sistema.
En cross-platform, mantener significa seguir esos dos ciclos más el del framework, más el de cada plugin que usas para acceder al hardware. Cuando un sistema cambia algo, esperas a que el framework lo adopte y luego a que cada plugin lo adopte. Ese retraso es el coste real y no aparece en ninguna estimación inicial.
En PWA, mantener es mantener una web, que es lo que tu equipo probablemente ya sabe hacer. El riesgo aquí no es el mantenimiento sino que una capacidad que necesitas no llegue nunca a estar disponible.
La pregunta útil para la reunión no es cuánto cuesta hacerla, sino quién va a actualizarla dentro de dieciocho meses y con qué conocimientos.
Cuándo nativo es la respuesta
Hay casos donde la discusión sobra, y casi todos tienen que ver con lo que la aplicación hace con el teléfono, no con su tamaño.
Cuando el producto depende de hardware específico o de rendimiento sostenido: cámara con procesamiento en vivo, audio de baja latencia, realidad aumentada, mapas con muchos elementos, sensores continuos.
Cuando la aplicación es el producto y compite con otras del mismo sector donde la fluidez es parte de lo que se compra. En esa categoría, las diferencias de sensación al desplazar y animar se notan y pesan.
Cuando necesitas capacidades nuevas del sistema el día que salen, sin esperar a que un intermediario las envuelva.
Y cuando ya tienes gente que trabaja en nativo. El argumento del ahorro de cross-platform desaparece si el equipo va a tener que aprender un entorno nuevo para conseguirlo.
Cuándo cross-platform compensa
El terreno donde rinde es más amplio de lo que sugieren sus críticos y más estrecho de lo que prometen sus defensores.
Compensa cuando la aplicación es fundamentalmente listas, formularios, detalle y navegación sobre datos que vienen de una API, que es la forma de la mayoría de las aplicaciones de empresa y de servicio.
Compensa cuando necesitas estar en las tiendas, con notificaciones y funcionamiento sin conexión, pero no necesitas nada exótico del hardware más allá de cámara, ubicación y almacenamiento.
Y compensa mucho cuando el equipo ya sabe el lenguaje. Un equipo de JavaScript llega antes con React Native que aprendiendo Swift y Kotlin a la vez, aunque el resultado sea algo menos fino.
El punto donde deja de compensar es reconocible: cuando la proporción de código específico por sistema empieza a crecer. Si acabas escribiendo la mitad dos veces, estás pagando la complejidad de las tres opciones y disfrutando de las ventajas de ninguna.
Cuándo la PWA es suficiente
Es la opción que más se descarta por reflejo y la que más veces habría bastado.
Basta cuando el producto es consumo de contenido o gestión de datos: un panel, un catálogo, un lector, una herramienta interna, un sistema de reservas. Nada de eso necesita salir del navegador.
Basta cuando el usuario llega por un enlace, y ese es además el escenario donde gana: no hay descarga previa, no hay instalación obligatoria, y la actualización es inmediata para todos.
Y es especialmente adecuada para herramientas internas, donde distribuir una aplicación a los empleados es un problema administrativo que una URL resuelve de golpe.
Las limitaciones que hay que aceptar son concretas: las notificaciones en iOS requieren que el usuario instale la aplicación en la pantalla de inicio, el acceso a hardware avanzado es reducido, y el sistema puede liberar el almacenamiento local si el dispositivo va justo de espacio.
Lo que la comparación clásica se deja fuera
Hay dos costes que no aparecen en las tablas y que a menudo son mayores que la elección de tecnología.
El primero es la tienda como proceso. Cuentas de desarrollador con su cuota anual, certificados y firmas, revisiones que tardan y a veces rechazan, y usuarios que se quedan en versiones antiguas durante meses. Nativo y cross-platform pagan esto por igual; la PWA no lo paga.
El segundo es la compatibilidad hacia atrás. En web, un cambio en el servidor llega a todos a la vez. En una aplicación instalada conviven varias versiones durante meses, así que la API tiene que seguir respondiendo a la versión que alguien no ha actualizado desde marzo.
Ese segundo punto cambia el diseño del backend, no solo el del cliente, y es lo que más gente descubre tarde.
El camino intermedio que suele funcionar
La elección no tiene por qué ser definitiva desde el primer día, y tratarla como si lo fuera es lo que hace la reunión tan difícil.
Un recorrido que funciona bien: empezar por la web bien hecha para móvil, convertirla en PWA cuando haga falta funcionamiento sin conexión o instalación, y construir una aplicación nativa solo cuando aparezca una necesidad concreta que la web no cubra.
Ese orden tiene una ventaja que se aprecia después: para cuando construyas la aplicación, ya sabrás qué usa la gente de verdad, y podrás hacer una aplicación centrada en eso en lugar de replicar el producto entero.
La variante intermedia, envolver la web en un contenedor nativo para poder publicarla en las tiendas, sirve para casos acotados. Funciona si el contenedor aporta dos o tres capacidades concretas; se convierte en lo peor de ambos mundos si la aplicación acaba siendo solo un navegador sin barra de direcciones.
Cómo comprobarlo antes de decidir
Buena parte de la discusión se resuelve con una tarde de trabajo en lugar de con opiniones.
La comprobación más útil es tomar la pantalla más exigente del producto, la lista larga con imágenes o el formulario complejo, y construirla en las dos opciones que estés considerando. No la aplicación entera: una pantalla.
# Levantar un proyecto de prueba en cada opcion
npx create-expo-app@latest prueba-rn # React Native con Expo
flutter create prueba_flutter # Flutter
# Medir el tamano del paquete resultante, que condiciona la instalacion
flutter build apk --analyze-sizePara la PWA, la comprobación es distinta: se mide sobre la web que ya tienes, con las herramientas del propio navegador.
# Auditar instalabilidad, funcionamiento sin conexion y rendimiento movil
npx lighthouse https://tu-sitio.example --preset=desktop --view
npx lighthouse https://tu-sitio.example --form-factor=mobile --viewY una prueba que vale más que las tres anteriores: instalar el prototipo en el teléfono más antiguo y más barato al que vayas a dar soporte. La mitad de las decisiones se toman solas después de eso.
Qué se le escapa a una IA con esto
Preguntar cuál elegir produce una respuesta equilibrada y genérica que no sirve para decidir, y conviene entender por qué.
No sabe qué sabe tu equipo, que es el factor con más peso en el resultado. Recomendará Flutter con el mismo tono a un equipo de Dart y a uno que no ha visto Dart en su vida.
Tiende a recomendar cross-platform por omisión, porque es la respuesta más frecuente en el material sobre el que se entrenó, sin comprobar si tu caso entra en las excepciones que la descartan.
Y subestima sistemáticamente lo que no es código: las cuentas de desarrollador, los tiempos de revisión, la convivencia de versiones antiguas, el soporte de dispositivos viejos. Son la mayor parte del coste real de publicar en móvil.
La forma de usarlo bien aquí es darle las restricciones antes de pedir la recomendación: qué sabe el equipo, qué necesitas del hardware, cómo va a llegar al usuario y cuánto tiempo tiene que durar. Con esas cuatro, la respuesta empieza a valer algo.