He lanzado apps de producción en Swift, en Kotlin, en Flutter, e heredado muchas en React Native. Así que esto no es un post de benchmark. Es la respuesta que doy a founders que necesitan decidir esta semana y no revisitarlo por dos años.
La versión corta
- Flutter si necesitas dos plataformas, un equipo, y UI custom pesada. Mejor relación costo-calidad para la mayoría de productos en 2026.
- Native si la app es el negocio, o dependes de features de plataforma el día del launch.
- React Native si ya tienes un equipo fuerte de React y una app web para compartir lógica. Si no, el caso es más débil que antes.
Todo lo de abajo es por qué.
Native (Swift / Kotlin)
Dos bases de código, dos skill sets, dos ciclos de release. Aproximadamente 1,6–1,9× el costo de build de un equivalente cross-platform — no el 2× que la gente asume, porque el trabajo compartido (design, backend, product thinking) no se duplica.
Qué consigues: cada capability de plataforma en el día uno. Widgets, App Clips, Live Activities, CarPlay, Wear, integraciones profundas del OS, las APIs de cámara y ML más nuevas. Sin capa de abstracción entre tú y la plataforma, lo que significa sin esperar a que alguien envuelva lo que necesitas.
Elige esto cuando: la app es el producto y su calidad es el diferenciador; estás en una categoría donde features de plataforma conducen retención; necesitas el mejor rendimiento absoluto y comportamiento de memoria; o eres lo suficientemente grande que dos equipos especialistas son normales.
Flutter
Una base de código, un equipo, su propio motor de rendering. Esa última parte es lo que la gente entiende mal: Flutter no envuelve componentes nativos, dibuja los suyos. Esa es exactamente la razón por la que UI custom pesada es barata en Flutter y exactamente por qué puede sentirse sutilmente no-nativa si luchas contra las convenciones de la plataforma.
Qué consigues: genuinamente la misma app en ambas plataformas, un equipo para contratar, un bug para fijar. Excelente para productos dirigidos por design donde la interfaz es a medida de todos modos.
Lo que cuesta: estás una capa removida de las nuevas features del OS, y binarios más grandes. Cualquier cosa profundamente específica de plataforma significa escribir un platform channel — lo que está bien, y es también código nativo que ahora mantienes.
Elige esto cuando: dos plataformas importan, el presupuesto es real pero finito, la UI es custom, y preferirías un equipo fuerte que dos delgados.
React Native
El caso se ha estrechado. La nueva arquitectura arregló los viejos problemas de rendimiento de bridge, y si tienes ingenieros React, son productivos en el día uno — esa es una ventaja genuina y grande.
Lo que cuesta: la superficie de dependencias. Una app de React Native es tú más una larga cola de paquetes de comunidad, y su mantenimiento no es tu decisión. Los upgrades son la fuente más común de trabajo no planeado que veo en codebases heredadas de RN.
Elige esto cuando: tienes un equipo React y un producto web para compartir lógica. Si estarías contratando para ello de nuevo, Flutter es usualmente la mejor apuesta en 2026.
La comparación de costo, concretamente
Para una app de consumidor de tamaño medio — auth, un core loop, payments, push, offline handling, ambas plataformas — la forma se parece aproximadamente a esto:
- Flutter: un equipo, una base de código. Línea base. Digamos X €.
- React Native: ~1,0–1,15× línea base si ya tienes gente de React; ~1,2× si estás contratando, porque el conocimiento del ecosistema toma más tiempo en adquirir que la sintaxis.
- Native ambas plataformas: ~1,6–1,9× línea base. No 2×, porque design, backend y product thinking no se duplican — solo el trabajo del cliente lo hace.
- Native una plataforma primero: ~0,75× línea base, y entonces tienes la conversación de segunda plataforma en seis meses con menos dinero que tienes ahora. Popular, y usualmente lamentado.
El mantenimiento es donde la divergencia se compone. Dos codebases nativos significa cada cambio es especificado una vez y construido dos veces, para siempre. Sobre tres años ese gap es típicamente más grande que la diferencia de build inicial.
La realidad de contratación que nadie valora en el costo
En Barcelona, Madrid, Lisboa y la mayoría de Europa Central, contratar un fuerte ingeniero de Flutter en 2026 toma semanas. Contratar un fuerte ingeniero iOS senior toma meses, y cuesta 20–30% más cuando lo encuentras. En Londres, Ámsterdam o Estocolmo ambos son más difíciles y más caros.
Esta es una consideración real para la decisión y casi nunca aparece en la comparación técnica. La mejor arquitectura que no puedes staffear es peor que la buena arquitectura que puedes.
Si ya estás en una y te preguntas sobre cambiar
Respuesta corta: usualmente no, y aquí está la prueba. Reescribir cuesta 60–80% de un build fresco y entrega cero nuevo valor de usuario el día que se lanza. Solo se justifica cuando:
- Físicamente no puedes contratar para el stack actual a ningún precio razonable.
- Un requisito de plataforma forzará el trabajo de todos modos dentro de doce meses.
- El codebase existente falla los básicos — ver la lista de verificación de auditoría — en cuyo caso no estás reescribiendo por el framework.
- Estás manteniendo dos codebases nativos con un equipo demasiado pequeño para una.
"Nuestros ingenieros preferirían X" no está en esa lista, y es la razón por la que la mayoría de rewrites realmente comienzan.
Las preguntas que realmente lo deciden
No "cuál es el más rápido". Estas:
- ¿Quién mantiene esto en dos años? Elige el stack que puedes contratar en tu ciudad o tu presupuesto. Una elección técnica perfecta sin ingenieros disponibles es una mala elección.
- ¿Cuán custom es la interfaz? Muy custom favorece Flutter. Convencional de plataforma favorece native.
- ¿Necesitas una feature de plataforma en el día del launch? Si es así, native. Todo lo demás espera un wrapper.
- ¿Hay una app web existente? Si es React y la lógica es genuinamente compartible, el caso de React Native se vuelve mucho más fuerte.
- ¿Cuál es el presupuesto real? Native para ambas plataformas en un presupuesto de 40 000 € significa una plataforma, malamente. Sé honesto antes que después.
Lo que no importa tanto como crees
- Rendimiento bruto. Para la abrumadora mayoría de apps, todos los tres están mucho más allá del límite donde los usuarios notan. Tu capa de red y tu manejo de imágenes importan más que tu framework.
- "No se siente native." Usualmente cierto de apps malas en cada framework. Es un problema de design y atención más a menudo que de tecnología.
- Argumentos de longevidad de framework. Los tres sobrevivirán tu roadmap actual. Apuesta en tu equipo, no en los comunicados de prensa de una fundación.
Si estás heredando una app existente en lugar de comenzar una, la pregunta de framework es secundaria — comienza con qué una auditoría debería realmente mirar.