Native vs cross-platform: la decisión de build que el founder no técnico sí debe tomar
Nunca vas a escribir una línea de Swift ni de Flutter. Así que deja de intentar responder esta pregunta en el terreno técnico. Native vs cross-platform es una decisión de presupuesto y plazo disfrazada de cuestión de desarrollador, y aquí está el test de cuatro preguntas que la resuelve.
Un founder con el que trabajamos estaba en una reunión con un proveedor el año pasado y le preguntaron, sin rodeos: “¿Nativo o cross-platform?” No lo sabía. Había levantado una ronda seed para construir un producto de agendamiento para clínicas, describía el flujo del paciente con los ojos cerrados, y no tenía idea de si la respuesta correcta involucraba Kotlin, Flutter o algo de lo que nunca había oído hablar. Así que hizo lo razonable que hace una persona de finanzas cuando la acorralan: preguntó cuánto costaba cada opción. El proveedor dio una respuesta directa, y la pregunta técnica se disolvió en una de negocio. Ese es todo el truco.
Si buscas native vs cross-platform, todos los resultados de la primera página están escritos por o para desarrolladores. CircleCI, Microsoft, Kotlin, un hilo de Reddit, dos canales de YouTube, un par de software houses. Discuten la tasa de cuadros, la madurez del framework y si Swift le gana a Flutter. Todo eso es real, y casi nada es decisión tuya. No estás eligiendo un lenguaje. Estás eligiendo una restricción, y el estudio elige el lenguaje que encaja en ella.
Aquí está la definición sin la jerga. Una app nativa se construye por separado para cada plataforma: un código en las herramientas de Apple para iPhone, un segundo código en las herramientas de Google para Android. Una app cross-platform se construye una vez, desde un único código, y corre en ambas. El desarrollo cross-platform usa frameworks como Flutter (Google) o React Native (Meta) para escribir la app una sola vez y publicarla en ambas tiendas. Nativo significa dos builds. Cross-platform significa uno. Ese único hecho gobierna la mayor parte de lo que sigue, incluida la parte de la cuenta que de verdad te importa.
Por qué esto es una decisión de dinero, no de tecnología
Dos códigos cuestan más que uno. No en un sentido abstracto de “deuda técnica”. En el sentido literal de que estás pagando a gente para construir, probar y mantener el mismo producto dos veces, en dos lenguajes, en dos ciclos de release. Un build nativo para iOS y Android suele costar entre 1,5x y 2x el costo y el calendario de un único build cross-platform que cubre ambas. El múltiplo exacto depende de cuánto de la app es lógica compartida frente a superficie específica de cada plataforma, pero la dirección nunca cambia: nativo es el camino más caro, por diseño.
Ese sobreprecio compra algo. La pregunta es si necesitas lo que compra. Para una app de agendamiento de clínica, un marketplace, un dashboard de fintech, una herramienta interna de operaciones, un SaaS en etapa temprana con un companion móvil, la respuesta honesta suele ser no. Esos productos son pantallas, formularios, listas y llamadas a API. Un framework cross-platform renderiza todo eso con calidad y lo publica en ambas tiendas desde un solo equipo. Llegas al mercado más rápido, gastas menos, y tienes un código que mantener en vez de dos cuando tu único desarrollador se enferma o, peor, renuncia. Esto se conecta directo con la decisión anterior en la misma cadena, construir o comprar: ambas preguntas se responden mal cuando es la asignación del proveedor, y no tu producto, la que conduce la recomendación.
Las cuatro preguntas que de verdad lo deciden
No puedes evaluar Flutter. Puedes responder estas cuatro. Cada una mueve la decisión, y juntas la resuelven sin un solo argumento técnico.
1. ¿Cuántas plataformas necesitas genuinamente el día uno? Si tus usuarios están tanto en iPhone como en Android (la mayoría de los productos de consumo y pyme en Latinoamérica y EE. UU. lo están), necesitas ambas, y la economía de un-solo-código del cross-platform se vuelve muy atractiva. Si estás construyendo una herramienta interna para un equipo comercial que es 100% iPhone corporativo, quizá solo necesites iOS, y la cuestión nativo-vs-cross-platform en parte se evapora. Una plataforma cambia la cuenta.
2. ¿Qué tan pesado de dispositivo es el producto? Sé específico sobre lo que la app hace con el teléfono. Una app de agendamiento lee un calendario y llama a una API. Un editor de video fuerza la GPU, una app de fitness lee sensores a alta frecuencia, una app social camera-first vive y muere en el pipeline nativo de la cámara. Cuanto más profundo llega tu producto al hardware del aparato, y cuanto más cerca del metal necesita correr, más justifica el nativo su sobreprecio. Los productos de pantallas-y-formularios casi nunca llegan a esa profundidad.
3. ¿Cuánto tiempo va a vivir este producto? Un MVP desechable que pretendes validar y posiblemente tirar en seis meses debería ser cross-platform siempre. Estás comprando velocidad y opcionalidad, no una arquitectura de 10 años. Un producto que ya sabes que es la empresa, que vas a mantener y extender por años, merece una conversación más deliberada, porque la diferencia de costo se acumula a lo largo de una vida de mantenimiento más larga, en ambos sentidos.
4. ¿Una experiencia específica de plataforma es el producto de verdad? A veces el feel nativo es el punto. Si tu diferenciación es una interacción suave, a 120fps, profundamente idiomática de iOS que un usuario de Android nunca vería, nativo es defendible. Pero sé implacable aquí. “Tiene que sentirse premium” no es lo mismo que “el feel nativo premium es la razón por la que el cliente nos elige sobre la alternativa”. La mayoría de los founders se convencen de que están en el segundo grupo cuando están cómodamente en el primero.
Si respondiste “ambas plataformas, no es pesado de dispositivo, vida incierta o corta, ninguna experiencia específica de plataforma como producto”, tienes tu respuesta, y es cross-platform. Eso cubre la gran mayoría de los productos en etapa temprana. La regla de bolsillo que vale anotar: asume cross-platform por defecto, y haz que el nativo se gane el upgrade con una razón específica, nombrada, que puedas defender en una reunión de directorio.
Lo que el nativo de verdad te cuesta (las desventajas que nadie en la búsqueda pone primero)
Las páginas de software house listan las desventajas del nativo en una columnita ordenada de bullets y siguen adelante. Las que muerden a un founder no técnico son estas. Dos códigos significan dos de cada decisión futura: dos revisiones de release en dos tiendas, dos conjuntos de bugs, dos lugares donde una feature debe construirse antes de salir. Tu velocidad cae a la mitad en cualquier cosa que toque ambas plataformas, o tu costo se duplica para mantener a dos desarrolladores ocupados. Tu problema de contratación también se duplica, porque ahora necesitas competencia en iOS y Android, no un único skill cross-platform. Y tu riesgo de un solo desarrollador se vuelve más filoso: con dos códigos nativos, perder a la persona equivocada puede dejar huérfana la mitad de tu producto. Nada de esto aparece en un benchmark de framework. Todo esto aparece en tu runway.
Dónde el nativo todavía gana
Este no es un artículo anti-nativo. Existe un ~20% real de productos en los que nativo es la decisión correcta y adulta, y fingir lo contrario sería exactamente el tipo de consejo talla-única que el resto de internet ya ofrece. Nativo justifica su sobreprecio cuando el producto es genuinamente pesado de dispositivo: juegos de alta tasa de cuadros, apps serias de cámara o AR, herramientas de audio, cualquier cosa que fuerce sensores o la GPU. Gana cuando una UX específica de plataforma es el diferencial, no el adorno. Y gana a una escala en la que la mayoría de quienes leen esto todavía no están, donde tienes equipos separados de iOS y Android, los códigos divergieron a propósito, y la abstracción cross-platform empezó a costar más de lo que ahorra.
“¿Netflix es una app nativa?” es la pregunta que la búsqueda insiste en hacer, y la respuesta es instructiva. Las apps móviles de Netflix son en buena parte nativas, y esa es la decisión correcta para Netflix: una empresa a esa escala, con tanto en juego en el rendimiento de video y la reproducción específica de cada plataforma, puede pagar dos equipos de primerísimo nivel y necesita lo que el nativo compra. Tú, con todo respeto, todavía no eres Netflix. La lección no es “haz lo que hace Netflix”. Es “nativo es la decisión correcta cuando tus restricciones se parecen a las de Netflix, y ni un día antes”.
Native vs cross-platform vs híbrido, y la confusión con la web app
Dos términos enturbian esta búsqueda, así que aclárelos rápido. Híbrido suele significar una app que envuelve una web view en una cáscara nativa (el enfoque más antiguo, tipo Cordova/Ionic). Es una tercera opción distinta y por lo general de menor fidelidad, y la mayoría de los equipos modernos elige un framework cross-platform de verdad como Flutter o React Native en vez de un wrapper híbrido, porque el resultado queda más cerca del nativo por el mismo precio de un-solo-código. Cuando alguien dice “cross-platform” hoy, asume que es Flutter o React Native, los dos frameworks que dominan el uso profesional cross-platform en la encuesta de Stack Overflow, no un wrapper de web.
Una app nativa frente a una web app es una bifurcación totalmente distinta: una web app corre en el navegador, sin instalación en la tienda, mientras que tanto el nativo como el cross-platform producen una app instalable. Si tus usuarios no necesitan estar en las tiendas, esa es una conversación que vale tener antes de esta. Pero es una decisión separada, y mezclarla con nativo-vs-cross-platform es como los founders terminan confundidos en reuniones con proveedores.
Qué hacer de verdad en la reunión
Entra habiendo respondido las cuatro preguntas, no habiendo googleado comparaciones de framework. Dile al estudio qué plataformas necesitas, qué tan pesado de dispositivo es el producto, la vida que esperas, y si un feel específico de plataforma es central. Después haz que justifiquen su recomendación contra tus respuestas, no su asignación. Un buen socio asumirá cross-platform por defecto y te dirá con claridad el día en que el nativo pasa a valer el sobreprecio, de la misma forma en que debería ser transparente sobre cuánto cuesta de verdad construir una app. Un proveedor que empieza con “nativo, obvio” antes de oír tus restricciones está respondiendo una pregunta distinta de la que le pagas por responder.
La decisión técnica nunca fue tuya. La restricción sí. Acierta la restricción y el framework se elige solo.
FAQ
¿Cuáles son las desventajas de las apps nativas?
Para un founder, las desventajas son casi todas económicas, no técnicas. Mantienes dos códigos, publicas por dos revisiones de tienda, construyes la mayoría de las features dos veces, y necesitas skills de iOS y Android en el equipo. Eso más o menos duplica el costo y el riesgo de un solo desarrollador frente a un build cross-platform. El techo de rendimiento es más alto, pero la mayoría de los productos nunca se le acerca.
¿Dónde sería mejor el nativo que el cross-platform?
Cuando el producto es pesado de dispositivo (juegos de alta tasa de cuadros, cámara/AR seria, audio, uso intenso de sensores), cuando una experiencia específica de plataforma es el diferencial de verdad, o a una escala en la que ya corres equipos separados de iOS y Android a propósito. Para productos de pantallas-y-formularios en etapa temprana, cross-platform casi siempre gana en costo y velocidad.
¿Las apps nativas rinden mejor?
En los extremos, sí: el nativo tiene un techo de rendimiento más alto porque habla directo con cada plataforma. Pero los frameworks cross-platform modernos como Flutter y React Native son lo bastante rápidos como para que la mayoría de los usuarios no note la diferencia en una app de negocio típica. La brecha de rendimiento importa para una minoría de productos y es invisible en el resto.
¿Netflix es una app nativa?
Las apps móviles de Netflix son en buena parte nativas, lo que es la decisión correcta para una empresa a esa escala, con demandas pesadas de rendimiento de video y presupuesto para dos equipos de primera línea. Es un pésimo modelo para un producto en etapa temprana, donde el sobreprecio del nativo normalmente no compra nada que tus usuarios notarían.
¿El desarrollo cross-platform es más barato?
En general, sí. Un código que cubre ambas plataformas suele costar bastante menos de construir y mantener que dos códigos nativos, muchas veces en el orden de 1,5x a 2x menos, porque no estás construyendo y manteniendo el mismo producto dos veces. El ahorro es mayor a lo largo de la vida de mantenimiento del producto, no solo en el lanzamiento.