Flutter vs React Native vs Nativo en 2026: cómo elegir

Si estás eligiendo un stack móvil en 2026, la respuesta corta es: usa React Native con Expo si tu equipo ya escribe TypeScript y la app debe sentirse nativa; usa Flutter si quieres un único motor de renderizado en móvil, web y escritorio o si tu equipo viene de Dart, Java o C#; usa Kotlin Multiplatform si tienes ingenieros Android y quieres UIs nativas con lógica compartida; y ve totalmente nativo, en Swift y Kotlin, cuando el producto depende de una integración profunda con el sistema operativo. El resto de este artículo explica cómo saber en cuál de esos cuatro casos estás.

Las cuatro opciones realistas en 2026

El debate "Flutter vs React Native" se ha quedado anticuado como elección binaria. Hoy hay cuatro caminos serios, y difieren en un eje fundamental: quién dibuja los píxeles y dónde se ejecuta la lógica de negocio.

Flutter compila Dart por adelantado (AOT) a código nativo y dibuja cada píxel por su cuenta con su propio motor (Impeller es el renderizador por defecto en iOS y Android). El sistema operativo aporta una superficie; Flutter hace el resto. Por eso una app Flutter se ve igual en cualquier dispositivo y se extiende de forma natural a web, Windows, macOS y Linux.

React Native ejecuta JavaScript o TypeScript en el motor Hermes y renderiza widgets reales de la plataforma. Con la New Architecture, JavaScript llama a código nativo de forma síncrona a través de JSI, el layout pasa por Fabric y los módulos nativos son TurboModules tipados. El antiguo bridge asíncrono, origen de la mayoría de las quejas históricas de rendimiento, ya no existe. Expo es hoy la forma por defecto de crear y publicar un proyecto: aporta el servicio de build (EAS), actualizaciones over-the-air, enrutado basado en archivos con Expo Router y un conjunto curado de módulos nativos. Los config plugins permiten añadir código nativo sin salir de Expo.

Kotlin Multiplatform (KMP) es la tercera opción en ascenso. Escribes red, persistencia, reglas de dominio y view models una vez en Kotlin y los compilas a una biblioteca JVM para Android y a un framework nativo para iOS. La UI puede seguir siendo totalmente nativa (Jetpack Compose en Android, SwiftUI en iOS) o compartirse con Compose Multiplatform, que es estable en iOS. Google recomienda KMP para compartir lógica entre Android e iOS, y JetBrains mantiene el tooling.

Nativo significa Swift con SwiftUI en iOS y Kotlin con Jetpack Compose en Android. Dos bases de código, dos equipos o un equipo con dos conjuntos de habilidades, y ninguna abstracción entre tú y la plataforma.

Flutter vs React Native vs KMP vs nativo: tabla comparativa

Criterio	Flutter	React Native (Expo)	Kotlin Multiplatform	Nativo (Swift / Kotlin)
Lenguaje	Dart	TypeScript / JavaScript	Kotlin (+ Swift para la UI de iOS)	Swift, Kotlin
Renderizado	Motor propio (Impeller); dibuja cada píxel	Widgets nativos de la plataforma vía Fabric	UI nativa, o Compose Multiplatform (basado en Skia)	Toolkits de UI nativos
Aspecto nativo	Consistente entre plataformas; el estilo de la plataforma debe emularse (Material / Cupertino)	Alto; vistas reales de UIKit / Android	Alto con UI nativa; medio con UI Compose compartida	Máximo
Perfil de rendimiento	Código AOT predecible y renderizado por GPU; binario grande	Cercano al nativo en la UI; el hilo JS puede ser un cuello de botella en cómputo pesado	Nativo en la lógica; el rendimiento de la UI es el del toolkit usado	Mejor techo, el más predecible
Acceso a APIs de la plataforma	Mediante plugins y platform channels	Mediante TurboModules / módulos Expo; config plugins para configuración nativa	Directo en cada plataforma (expect/actual)	Directo, desde el primer día de cada versión del SO
Alcance web / escritorio	Fuerte: web, Windows, macOS y Linux desde una sola base	Web vía React Native Web / Expo; escritorio mantenido por la comunidad	Escritorio vía Compose; web aún experimental	Ninguno sin un proyecto aparte
Mercado de contratación	Medio; Dart rara vez es el primer lenguaje	El mayor; todo equipo web conoce React	Medio; fuerte en equipos Android	Medio; los especialistas cuestan más, dos conjuntos de habilidades
Madurez del tooling	Madura: hot reload, DevTools, soporte oficial en IDEs	Madura: Expo CLI, EAS, Metro, React DevTools	Madurando rápido; el lado iOS aún depende de Xcode más tooling Kotlin	La más madura: Xcode, Android Studio
Tamaño de la app (orden de magnitud)	Decenas de MB de base (motor incluido)	Decenas de MB de base (Hermes + runtime)	Cercano al nativo; la biblioteca compartida añade unos pocos MB	El menor; pocos MB en apps simples

La tabla muestra el patrón: cada capa que pones entre tu código y el SO te compra alcance y velocidad de entrega y te cobra en fidelidad y acceso. La pregunta nunca es "cuál es mejor", sino "qué compromiso tolera este producto".

Rendimiento en la práctica, no en benchmarks

La mayoría de los artículos de benchmarks miden el scroll de listas o el arranque en un móvil de gama alta y concluyen que las diferencias son pequeñas. En un Android de gama media, que es lo que tiene en la mano la mayoría de tus usuarios fuera de Europa Occidental y EE. UU., el panorama es más matizado.

Arranque: las apps nativas arrancan más rápido. Flutter y React Native añaden un paso de inicialización del runtime que cuesta cientos de milisegundos en hardware modesto; el bytecode de Hermes y los builds AOT de Flutter mantienen esa penalización acotada.

Renderizado: Flutter controla todo el pipeline, así que las animaciones son consistentes, pero la compilación de shaders solía provocar tirones en la primera ejecución; Impeller se construyó precisamente para eliminarlos. React Native renderiza vistas nativas, así que una FlatList o FlashList es tan fluida como permita la plataforma, pero cualquier trabajo en el hilo de JavaScript compite con las actualizaciones de la UI. Mueve el trabajo pesado a módulos nativos o worklets (Reanimated ejecuta las animaciones en el hilo de UI por esta razón).

Trabajo intensivo en CPU: procesamiento de imágenes, cifrado, inferencia de ML en el dispositivo. Flutter puede usar isolates y FFI hacia C; React Native necesita un módulo nativo o una biblioteca C++ enlazada vía JSI; KMP y nativo simplemente llaman a la plataforma. Si tu bucle central está limitado por CPU, cuéntalo como un punto a favor de KMP o nativo.

Mide antes de decidir: construye tu pantalla real más pesada en los dos stacks candidatos y ejecútala en el dispositivo más barato que muestre tu analítica.

Cuándo lo nativo es innegociable

Los frameworks multiplataforma pueden llegar a cualquier API del SO mediante un módulo nativo. La pregunta honesta es cuánto de tu app serán módulos nativos. Cuando la respuesta es "la mayoría de las funcionalidades diferenciadoras", deberías ser nativo desde el principio.

• Pipelines de cámara y AR. ARKit y ARCore, controles de cámara personalizados, filtros en tiempo real, sensor de profundidad. Existen plugins, pero van por detrás de las versiones del SO y exponen un subconjunto de la API.
• Widgets de pantalla de inicio y de bloqueo, Live Activities, App Intents. Se ejecutan fuera del proceso de tu app, en frameworks específicos de la plataforma (WidgetKit, Glance). Son código nativo sea cual sea tu stack principal.
• Wearables. Las apps para watchOS y Wear OS son targets separados, con sus propios frameworks de UI y límites de recursos estrictos.
• CarPlay y Android Auto, plataformas de TV. Frameworks nativos basados en plantillas, con restricciones de revisión.
• Ejecución en segundo plano. Reproducción de audio, VoIP, seguimiento de ubicación, periféricos Bluetooth, sincronización de datos de salud. Viable en multiplataforma, pero la depuración ocurre en código nativo y las reglas del SO cambian cada año.
• Funciones sensibles en seguridad. Secure Enclave, StrongBox, passkeys, atestación de hardware. Primero las APIs nativas, después los wrappers.
• Adopción inmediata de nuevas funciones del SO. Si tu marketing depende de lanzar la nueva función de iOS la misma semana en que sale, no puedes esperar a un plugin.

Regla práctica: si más de aproximadamente un tercio de tu roadmap vive en la lista anterior, el multiplataforma te ahorra poco y añade una capa que depurar. Ve nativo, o usa KMP para compartir la lógica y mantener la UI nativa.

Equipo y contratación

El stack que puedes dotar de personal gana al stack que mejor rinde en benchmarks.

Equipo web existente. React Native con Expo es el camino de menor fricción. Modelo mental de React, TypeScript, npm, los mismos patrones de gestión de estado que ya usas. Espera una curva de aprendizaje en el tooling de build nativo, la firma y el envío a las tiendas, que EAS oculta en los casos comunes. Si ya has invertido en TypeScript, esa inversión se aprovecha por completo.

Equipo Android existente. KMP es la extensión natural. Los ingenieros Kotlin conservan su lenguaje y comparten el código que resulta aburrido escribir dos veces. El lado iOS sigue necesitando a alguien cómodo con Swift y Xcode, al menos para la UI y la integración con la plataforma.

Equipo nuevo, sin un historial fuerte. Flutter y React Native son igual de razonables. La ventaja de Flutter es una toolchain única y opinada, sin depender de la rotación del ecosistema npm. La ventaja de React Native es el tamaño del mercado de contratación y la opción de compartir código con una app web.

Agencias y equipos externalizados. Pregunta qué stack entregan más y revisa en las tiendas las reseñas de sus apps publicadas buscando quejas de rendimiento o de aspecto poco nativo.

Elijas lo que elijas, presupuesta al menos un ingeniero por plataforma capaz de leer stack traces nativos, configurar la firma y la CI y escribir un módulo nativo. Todo proyecto multiplataforma necesita a esa persona, normalmente antes de lo previsto. Nuestra guía sobre cómo elegir el stack tecnológico para una startup cubre los compromisos más amplios de contratación.

Migración y coexistencia: integración brownfield

Muy pocos equipos empiezan de cero. El escenario realista es una app nativa existente, o dos, y la duda de si las próximas cien pantallas hay que escribirlas dos veces.

Las tres opciones multiplataforma soportan ejecutarse dentro de una app nativa existente:

• Flutter add-to-app empaqueta tu código Flutter como un AAR en Android o un framework en iOS. La app anfitriona crea un FlutterEngine, opcionalmente precalentado, y presenta un FlutterViewController o FlutterFragment para una ruta determinada. Varios engines pueden compartir recursos mediante un engine group.
• React Native incrusta una root view (RCTRootView en iOS, ReactRootView en Android) que la app anfitriona apila como cualquier otra pantalla. Expo soporta este camino, así que brownfield no significa renunciar al ecosistema de módulos de Expo.
• KMP es brownfield por diseño. El módulo compartido es solo una biblioteca; la app Android existente depende de él como módulo Gradle y la app iOS enlaza un XCFramework. Nada de la UI cambia el primer día.

Una migración que funciona sigue el patrón strangler usado en sistemas heredados: elige un flujo autocontenido y de bajo riesgo (ajustes, un centro de ayuda, una encuesta de onboarding), entrégalo en el stack nuevo detrás de una feature flag, mide la tasa de crashes y el rendimiento frente a la versión nativa y luego amplía. Mantén la interfaz entre anfitrión y módulo fina y tipada: navegación, token de autenticación, tema, analítica. Cada llamada adicional que cruza esa frontera es mantenimiento que pagarás por ambos lados.

Dos costes son fáciles de subestimar: el tamaño de la app (la primera pantalla incrustada trae consigo todo el runtime del framework) y la navegación (dos pilas generan casos límite en el botón atrás, los deep links y la restauración de estado). Decide pronto qué lado es dueño de la navegación.

Checklist de decisión por tipo de app

Usa el perfil que coincida con tu producto. Si coinciden dos, quédate con el más restrictivo.

App de consumo (marketplace, medios, fitness, social)

• ¿Debe seguir de cerca las convenciones de la plataforma? React Native o nativo.
• ¿UI personalizada, con mucha marca, que debe verse idéntica en todas partes? Flutter.
• ¿Versión web prevista desde la misma base de código? React Native (Expo) o Flutter.
• ¿El crecimiento depende de widgets, Live Activities, app de reloj? Nativo, o multiplataforma más extensiones nativas desde el principio.

App interna de campo (inspecciones, logística, mantenimiento)

• ¿Sobre todo formularios, listas, fotos, sincronización offline? Flutter o React Native; ambos lo manejan bien y la base única compensa de inmediato.
• ¿Dispositivos Android robustos, solo Android? Kotlin nativo, o KMP si iOS puede llegar más adelante.
• ¿Códigos de barras, NFC, impresoras, sensores externos? Comprueba la cobertura de plugins para tu hardware exacto antes de comprometerte. Consulta nuestras notas sobre desarrollo de aplicaciones IoT.

App complementaria de SaaS B2B

• ¿Producto web ya en React? React Native con Expo; comparte tipos, clientes de API y a menudo componentes con la app web.
• ¿El producto es un consumidor de tu API tipo dashboard con notificaciones ocasionales? Plantéate si una PWA lo cubre antes de construir cualquier app nativa.
• ¿Los clientes enterprise exigen MDM, SSO, certificate pinning? Todos los stacks pueden; verifica las bibliotecas concretas antes de firmar el contrato.

App vinculada a hardware (dispositivos BLE, médico, automoción, hogar inteligente)

• ¿Bluetooth Low Energy como interacción central? Nativo o KMP. Los stacks BLE difieren lo suficiente entre iOS y Android como para que los plugins oculten los detalles equivocados.
• ¿Sector regulado (médico, automoción)? Nativo reduce la superficie de auditoría: menos dependencias de terceros que documentar.
• ¿UI complementaria simple y el dispositivo hace el trabajo? Multiplataforma sirve, siempre que la capa BLE sea un módulo nativo dedicado y tuyo.

Implicaciones de coste

Las diferencias de coste vienen de tres sitios: cuántas bases de código mantienes, cuántos especialistas necesitas y cuánto código nativo acabas escribiendo de todos modos.

Una sola base multiplataforma para una app con UI mayoritariamente estándar es un build y una línea de mantenimiento en lugar de dos. Ese es todo el business case, y se cumple para la mayoría de las apps de consumo y empresariales. El ahorro se reduce a medida que crece el número de módulos nativos, y en el extremo una app multiplataforma con integración nativa pesada cuesta más que dos apps nativas: tres bases de código más el pegamento entre ellas.

KMP se sitúa en medio. Compartes la lógica (normalmente la mitad más grande y más propensa a errores de una app) mientras pagas por dos UIs. Para equipos con fuertes habilidades Android, suele ser la forma más barata de conseguir una app iOS de calidad nativa.

Costes ocultos a presupuestar, sea cual sea el stack: pruebas en device farm entre versiones de SO, ciclos de revisión de las tiendas, migraciones anuales de SO (tanto Apple como Google deprecan APIs de forma programada) y mantenimiento de dependencias. Para rangos concretos de composición de equipo y tarifas diarias en Europa, consulta cuánto cuesta desarrollar software a medida en Europa. Un buen pipeline de CI/CD, con builds y firma automatizados, no es opcional en ningún stack; es la diferencia entre una release semanal y una mensual.

Recomendación

Elige por defecto React Native con Expo cuando tu organización ya construye en TypeScript y la app debe sentirse nativa. Elige por defecto Flutter cuando una UI personalizada y consistente en móvil, web y escritorio importa más que el idioma de la plataforma, o cuando tu equipo prefiere una toolchain única y opinada. Elige Kotlin Multiplatform cuando tienes ingenieros Android y quieres UIs nativas con lógica de negocio compartida. Ve totalmente nativo cuando el valor del producto está en cámara, AR, widgets, wearables, servicios en segundo plano o hardware, o cuando las funciones del SO desde el primer día forman parte de la estrategia.

Antes de comprometerte, haz un spike de dos semanas en tu pantalla más difícil con los dos candidatos más fuertes, en tu dispositivo objetivo más barato, y decide con números de tu propia app. En Arvucore solemos recomendar ese spike por encima de cualquier cantidad de lectura comparativa, incluido este artículo.