Swift nativo vs Flutter vs React Native: RAM, CPU y eficiencia real

En resumen

• En la única prueba en iPhone que mide las tres de la misma forma, Swift usó bastante menos memoria que el resto. Un solo desplazamiento por una lista añadió 9,74 MB en Swift, 25,33 MB en Flutter y 45,13 MB en React Native — alrededor de un 62% y un 78% menos
• Esa diferencia es estructural, no un error. Flutter y React Native llevan cada uno su propio motor en memoria. Una aplicación en Swift usa lo que el teléfono ya tiene
• La memoria importa porque los iPhone no se ralentizan: cierran aplicaciones, empezando por la más pesada. Tu cliente ve un carrito vacío, no un fallo. Y nunca aparece en tus informes de errores
• Los widgets zanjan la discusión por sí solos. Los widgets de la pantalla de inicio y las Live Activities funcionan con un límite demasiado pequeño para un motor incorporado, así que esa parte se escribe en Swift elijas lo que elijas para la aplicación principal
• La mayoría de los usuarios nunca notará la diferencia. En un teléfono reciente, las tres se sienten igual. Se vuelve decisiva en teléfonos antiguos, en sesiones largas y allí donde la aplicación hace trabajo sostenido
• Nativo gana las mediciones y cuesta más en cuanto necesitas Android, porque no hay una segunda plataforma incluida en el precio. Ese es el verdadero compromiso: no Swift contra Flutter, sino una aplicación contra dos
• Desconfía de las cifras que te enseñan. En tres de las cuatro preguntas que más hacen los compradores — uso del procesador, tamaño de descarga y velocidad de apertura — nadie ha publicado una prueba en iPhone que incluya Swift. La mayoría de las cifras que circulan son de 2020 y describen software que ya nadie distribuye

Construimos con las tres: Swift nativo, Flutter y React Native. Así que esta es una comparación de compromisos con los que convivimos, no un argumento de venta a favor de uno de ellos.

¿Cuánta más RAM y CPU usan Flutter o React Native frente a Swift nativo?

Crecimiento de memoria en un desplazamiento automatizado de 100 elementos. SynergyBoat, iPhone 16 Plus, N=3, agosto de 2025. Esto es un incremento de crecimiento, no una huella total. Las condiciones y los límites completos están en la tabla de abajo.

Dos cosas que esa cifra no te dice, y ambas importan.

Es memoria, no CPU. Ninguna prueba publicada mide la CPU de las tres en iOS contra una referencia en Swift. Buscamos a fondo y no existe. Todo lo que aparece abajo con una cifra de CPU se ejecutó en Android o no tenía ninguna versión nativa, y lo decimos cada vez.

La mayoría de los usuarios nunca lo notará. En pantallas normales las tres mantienen 60 fps en hardware moderno, y una diferencia de 35 MB es invisible en un teléfono con 8 GB de RAM. La diferencia se vuelve decisiva en tres sitios concretos: las extensiones con límite de memoria, el cálculo sostenido, y los dispositivos antiguos o con poca RAM. De esos casos trata realmente este artículo.

El resto del artículo te da todas las cifras que pudimos verificar. Cada una está etiquetada con el dispositivo, la versión del framework y la herramienta de la que salió. Las etiquetamos por una razón. La mayoría de las cifras sobre este tema no llevan ninguna etiqueta, y alrededor de la mitad están desfasadas.

Una definición primero, porque se difumina constantemente. Por “Swift nativo” entendemos Swift con UIKit o SwiftUI. Esos dos también se diferencian entre sí en huella de memoria. Pero ambos funcionan bajo ARC, y ninguno carga un segundo entorno de ejecución. Esa es la distinción sobre la que descansa toda esta comparación.

¿Qué te cuesta en realidad esa cifra de memoria?

Un iPhone no ralentiza una aplicación cuando se queda sin memoria — la cierra, empezando por la más pesada. Tu cliente no ve un fallo. Cambia a otra aplicación durante veinte segundos, vuelve, y se encuentra un carrito vacío y una pantalla de inicio de sesión. Es el coste menos entendido de una aplicación más pesada, y nunca aparece en tus informes de fallos.

Lo hemos desarrollado por separado, junto con el límite de los widgets que impide construir algunas funciones: Por qué los iPhone cierran primero las aplicaciones pesadas.

Todas las cifras que pudimos verificar, en una tabla

Cuatro cosas que la gente pregunta — memoria, uso del procesador, tamaño de descarga y rapidez de apertura. Las cifras están abajo. Las condiciones en que se midió cada una están numeradas debajo, para que puedas leer primero la tabla y consultar la letra pequeña solo donde importe.

Una aplicación de tarjetas de memoria, construida de cuatro formas y ejecutada en un iPhone, es la única prueba pública que pone Swift nativo junto a Flutter y React Native. Cubre la memoria. Para las otras tres preguntas no se ha publicado ninguna prueba así.

Qué se midió	Swift nativo	Flutter	React Native
Memoria — la única pregunta con una respuesta real
Memoria extra usada al desplazar una lista larga 1	9,74 MB	25,33 MB	45,13 MB
La misma cifra, junto a Swift 1	la referencia	2,6× más	4,6× más
Cuánto varió el resultado entre ejecuciones 1	± 0,18	± 0,47	± 10,94
Memoria frente a una aplicación nativa, en Android 2	no hay Swift en Android	en la media del grupo	la más alta de todos los frameworks probados
Cifras antiguas de iPhone que aún se citan hoy 3	48 MB	117 MB	135 MB
Uso del procesador — ninguna prueba en iPhone incluye Swift
iPhone, misma aplicación, las tres 4	nadie ha publicado esto	nadie ha publicado esto	nadie ha publicado esto
Desplazando una lista, en Android 5	no hay Swift en Android	43,4%	52,9%
Usando la cámara, en Android 5	no hay Swift en Android	81,6%	49,1%
Tamaño de descarga — lo que tu cliente espera
Una aplicación mínima, descargada en iPhone 6	nadie ha publicado esto	10,9 MB	nadie ha publicado esto
Maquinaria que carga solo para funcionar 7	ninguna — usa lo que hay en el teléfono	~4 MB de motor	un motor de JavaScript, ~2,4 MB
Rapidez de apertura — no existe nada comparable
Arranque en frío en iPhone, misma aplicación 8	nadie ha publicado esto	nadie ha publicado esto	nadie ha publicado esto

1. SynergyBoat, agosto de 2025 — la misma aplicación de tarjetas de memoria construida de cuatro formas, iPhone 16 Plus, tres ejecuciones de cada una. Swift usó alrededor de un 62% menos de memoria que Flutter y un 78% menos que React Native. React Native no solo usó más, fue el menos predecible — variando alrededor de una cuarta parte de su propia media, así que léelo como “aproximadamente entre cuatro y cinco veces”, no como exactamente 4,6.
2. Oliveira y colegas, 2023 — el único estudio aquí que pasó una revisión académica por pares. Teléfono Android, y la aplicación nativa con la que se comparó estaba escrita en Java, no en Swift. Una dirección de tendencia, no una cifra de iPhone.
3. inVerita, junio de 2020, en un iPhone 6s. Medido antes de tres de los mayores cambios de rendimiento que estos frameworks han lanzado nunca. Aparece para que lo reconozcas cuando alguien te lo cite como actual — no lo es.
4. Ninguna prueba pública en iPhone mide el uso del procesador con una aplicación nativa en Swift dentro. Flutter publica cifras en vivo de iPhone, pero solo de Flutter, y contadas de una forma que no encajará con nada que midas tú.
5. Tollin y Lidekrans, Universidad de Linköping, 2023. Solo Android, sin ninguna versión en Swift. Fíjate en que el orden se invierte entre las dos cargas de trabajo — que es exactamente por lo que un único porcentaje de procesador para un framework vale muy poco.
6. Las propias preguntas frecuentes de Flutter, medido en marzo de 2021 sobre una aplicación vacía. Apple no publica una cifra equivalente para Swift y no encontramos una equivalente para React Native, así que esta cifra no tiene nada justo con lo que compararse.
7. Las preguntas frecuentes de Flutter para el tamaño del motor; las mediciones de Callstack para el de React Native. Esta es la diferencia estructural: una aplicación multiplataforma incorpora un segundo entorno de ejecución y lo mantiene en memoria. Una aplicación en Swift toma prestado lo que el teléfono ya tiene.
8. El equipo de Flutter ejecuta una prueba de velocidad de apertura entre Swift y Flutter dentro de su propio sistema de compilación, pero no publica cifras. Un proyecto de código abierto sí publica velocidad de apertura frente a una aplicación real en Swift — pero no tiene ninguna versión en React Native.

Las filas que dicen nadie ha publicado esto son el hallazgo, no un hueco que no supiéramos llenar. En tres de las cuatro preguntas que más hacen los compradores, no existe ninguna prueba publicada en iPhone que incluya una aplicación nativa en Swift.

Cifras que parecen comparaciones pero no lo son

Estas cuatro aparecen en casi cualquier discusión sobre frameworks. Cada una mide un framework contra una versión anterior de sí mismo. Ninguna implica a Swift. Si alguien te cita una como razón para saltarte lo nativo, ha respondido a otra pregunta.

Lo que se dice	Lo que se comparó en realidad	El detalle que se omite
“React Native arranca un 40% más rápido”	Dos motores de JavaScript, uno contra otro	Callstack, en iPhone, allá por React Native 0.64. La memoria bajó alrededor de un 18%, y la aplicación creció 2,4 MB
“La Nueva Arquitectura lo hizo más rápido”	React Native 0.76 contra React Native 0.75	Sus propias notas de versión, en Android: la aplicación quedó unos 3,8 MB más pequeña y abrió unos 15 milisegundos antes. No se publicó ninguna cifra de memoria
“Shopify demostró que React Native está listo para producción”	Las aplicaciones de Shopify antes y después de su propia actualización	Shopify, septiembre de 2025: abrir se volvió ~10% más rápido en Android y ~3% en iPhone — y algunas pantallas se volvieron hasta un 20% más lentas, los bloqueos aumentaron en ambas plataformas, y las sesiones sin fallos estuvieron por debajo de su propio objetivo durante un par de semanas
“Flutter arregló sus problemas de rendimiento”	Flutter 3.22 contra versiones anteriores de Flutter	El anuncio del propio Flutter, en un iPhone 11: los efectos de desenfoque redujeron su coste aproximadamente a la mitad. Real, y se agradece — pero no dice nada sobre cómo se compara Flutter con Swift

El DeviceLab de Flutter publica RAM y CPU en vivo, por commit, desde iPhones reales. Esta es la prueba de desplazamiento del 6 de septiembre de 2026: un iPhone 16 Pro con 84,70 MB y un iPhone 11 con 80,91 MB. No está en la tabla de arriba, y es deliberado — mide Flutter contra Flutter, sin ninguna aplicación en Swift por ninguna parte.

Dos advertencias sobre las unidades, eso sí. Las cifras de CPU que las acompañan son 9,33% y 13,72%. Ambas se miden sobre todos los núcleos. Esa no es la convención que usa Xcode Instruments. Así que no se pueden alinear con los porcentajes de CPU de Android de más arriba, ni con ninguna cifra de Swift que midas tú. La serie de memoria es la muestra dirty_memory_usage del propio motor. No es la huella de páginas sucias más comprimidas de Apple, y la memoria de GPU se informa aparte. Así que tampoco es directamente comparable con una lectura de huella de Instruments.

Ese laboratorio tampoco tiene una versión en Swift ni en React Native. Compara Flutter con Flutter anterior. Estos son los datos mejor instrumentados de todo el artículo, y aun así no pueden zanjar la comparación.

Si lees esa tabla con honestidad, saltan cuatro cosas a la vista.

• Nadie ha publicado una prueba controlada en iOS de la misma aplicación escrita de tres formas sobre las versiones actuales. No existe tal estudio. Cualquiera que presente uno está extrapolando
• El trabajo académico riguroso es de Android con una referencia en Java, así que no puede decir nada sobre Swift. Además midió Flutter 3.0.3 sobre Skia y React Native 0.68.2 sobre JavaScriptCore. Ambos frameworks han sustituido desde entonces esos componentes exactos. Su método es el mejor del campo. Sus versiones tienen dos generaciones de antigüedad
• El resultado se invierte con la carga de trabajo. En los datos de Linköping, Flutter gana en el desplazamiento de listas. Y luego pierde la prueba de la cámara por 32 puntos
• Las cifras de memoria de iOS y Android no son comparables en absoluto — ver abajo

Por qué no puedes poner la memoria de iOS y la de Android en la misma columna

Esto hace tropezar a casi todos los artículos comparativos, incluidos los que por lo demás son cuidadosos. En “iOS Memory Deep Dive” de la WWDC18, Apple define la huella de memoria de una aplicación como sus páginas sucias y comprimidas (“la memoria limpia en realidad no cuenta”), contadas en páginas de 16 KB. El meminfo de Android informa de PSS/RSS con un modelo completamente distinto. Una cifra de 90 MB en iOS y una de 90 MB en Android no son la misma medición. Promediarlas u ordenarlas entre sí produce un sinsentido.

Merece la pena llevarse dos cosas más de esa sesión. Apple nunca publica el límite numérico de huella de memoria. Depende del dispositivo, y superarlo provoca un EXC_RESOURCE.

La propia documentación de Apple sobre los informes de eventos de jetsam desarrolla un caso de ejemplo. Un proceso está usando 92.802 páginas × 16.384 bytes = 1,52 GB cuando lo cierran por per-process-limit. Pero eso es lo que la aplicación estaba usando. No es un techo publicado. Cualquiera que cite una cifra concreta del tipo “iOS cierra las aplicaciones a los X GB” se está inventando una especificación.

Entonces, ¿qué deberías elegir?

La eficiencia es un factor, y rara vez el decisivo. El compromiso honesto es este: Swift nativo gana todas las mediciones de arriba, y nativo cuesta más en cuanto necesitas Android también — porque no hay una segunda plataforma incluida en el precio.

Esa es la comparación real. No Swift contra Flutter, sino una aplicación nativa contra dos aplicaciones nativas contra una aplicación compartida que es más pesada en ambas. Busca tu situación abajo.

Qué construir, y qué te cuesta cada respuesta. La última columna es la que la gente se salta.

Si esta es tu situación	Construye esto	Por qué	Qué te cuesta
Solo iPhone, sin Android en la hoja de ruta	Swift nativo	La menor memoria de todo lo medido, todas las funciones de Apple disponibles el día que salen, y nada extra metido en la descarga	Nada extra. Este es el caso en que nativo es además la opción más barata — una plataforma, un solo código, y ninguna capa multiplataforma que depurar cuando algo falla
Ambas plataformas, y la eficiencia es el producto — audio en segundo plano, cámara, mapas, IA en el dispositivo, sesiones largas, o clientes con teléfonos antiguos	Nativo en ambas	Aquí es donde la diferencia de memoria deja de ser una estadística y empieza a cerrar tu aplicación a mitad de sesión	La respuesta cara, siendo honestos. Dos bases de código: cada pantalla se construye dos veces. El diseño, el backend, el producto y las pruebas no se duplican, así que queda bastante por debajo de pagar el doble — pero la capa de aplicación sí se duplica de verdad
Ambas plataformas, aplicación normal de contenidos, reservas o tienda, y el presupuesto es la restricción que manda	Flutter o React Native	Un solo equipo y un solo código cubriendo ambas plataformas es un ahorro real, y en una aplicación que sobre todo muestra listas y formularios puede que la diferencia de memoria no llegue nunca a tus clientes	Aceptas una aplicación más pesada. Presupuesta pruebas en el teléfono más antiguo que pienses admitir, no en el más nuevo — ahí es donde aparece la diferencia
Los widgets, las Live Activities o las extensiones importan en cómo se usa tu producto	Swift, elijas lo que elijas	Funcionan bajo un límite de memoria tan bajo que la propia documentación de React Native dice que puede no caber	No es realmente una elección. Incluso una aplicación en Flutter o React Native entrega esta parte en Swift — así que cuenta con esa habilidad en el equipo desde el principio en lugar de descubrirlo tarde
Ya tienes un equipo de React y TypeScript	React Native	El equipo que tienes vale más que una prueba de rendimiento. Lanzar este trimestre gana a ser 4× más ligero el año que viene	El más pesado y menos predecible de los tres en la única prueba en iPhone que incluye Swift. Merece revisarse si tu aplicación se vuelve sensible al rendimiento
Un sistema de diseño propio, idéntico en ambas plataformas, con muchas animaciones	Flutter	Flutter dibuja cada píxel por su cuenta, así que un diseño a medida se ve igual en todas partes en vez de pelearse con dos conjuntos de componentes nativos	Unas 2,6 veces el crecimiento de memoria de Swift en esa misma prueba — el precio de traer tu propio motor de renderizado

Si tu situación abarca dos filas, la pregunta que decide no suele ser la eficiencia. Es si los widgets y las extensiones son parte esencial del producto, y si tus clientes están en teléfonos antiguos. Ambas empujan hacia nativo con independencia del presupuesto.

Este es el resumen honesto. Para la inmensa mayoría de las aplicaciones, los usuarios nunca percibirán la diferencia de memoria o de CPU. Sí percibirán una aplicación mal construida en cualquiera de las tres. Elige por el equipo, la estrategia de plataformas y los frameworks del sistema concretos de los que dependas. Y luego mide tu propia versión en un dispositivo real antes de comprometerte.

Para las versiones cara a cara de esta comparación, con la evidencia específica de cada framework al completo: Swift vs Flutter y Swift vs React Native.

Fuentes

Cada cifra de arriba viene de una de estas. Cada entrada indica las condiciones que la hacen citable: dispositivo, versiones, herramienta, tamaño de muestra. Un número sin eso no es evidencia.

Las mediciones

1. SynergyBoat — “Flutter vs React Native vs Native: 2025 Performance Benchmark” (31 de agosto de 2025)Las cifras de incremento de memoria. iPhone 16 Plus, N=3, crecimiento de RSS en un desplazamiento de 100 elementos. Publicado por un proveedor. Usamos solo su apartado de memoria; su comparación de tiempos de fotograma mide cantidades distintas contra un mismo presupuesto.
2. Oliveira, Moraes, Castor y Fernandes — “Analyzing the Resource Usage Overhead of Mobile App Development Frameworks” (EASE 2023)Revisado por pares. Samsung Galaxy S20 FE, Android 12, adb batterystats + meminfo, 45 ejecuciones por prueba descartando las 15 primeras. Flutter 3.0.3 (Skia), React Native 0.68.2 (Hermes desactivado), frente a Java nativo. Sin iOS, sin Swift. PDF de acceso abierto vía la Universidad de Utrecht; DOI 10.1145/3593434.3593487.
3. Tollin y Lidekrans — “React Native vs. Flutter: A performance comparison” (Universidad de Linköping, 2023)Solo Android. Flutter 3.10.0 frente a React Native 0.71.6, adb shell top, cinco ejecuciones de 30 segundos. Sin versión en Swift. Su apartado de discusión explica la diferencia en la prueba de cámara que la mayoría de las citas omiten.
4. Shopify Engineering — “Migrating to React Native’s New Architecture” (5 de septiembre de 2025)Datos de producción de Shopify Mobile y Point of Sale. Informa tanto de sus regresiones como de sus mejoras, que es por lo que la usamos.
5. Panel de rendimiento DeviceLab de FlutterRAM y CPU en vivo, por commit, desde hardware real: iPhone 11 e iPhone 16 Pro. Solo Flutter. La CPU es un porcentaje sobre todos los núcleos, no la convención de Xcode Instruments. Enlazado desde la documentación de métricas de rendimiento de Flutter.
6. React Native — “Toward Hermes being the default”Recoge las cifras de iOS de Callstack/Mattermost: arranque ~40% más rápido, memoria ~18% menor, aplicación +2,4 MiB, en React Native 0.64.
7. Callstack — “Hermes performance on iOS”Las mediciones originales sobre Mattermost detrás de esas cifras.

Documentación de primera mano

1. Apple — “iOS Memory Deep Dive”, sesión 416 de la WWDC18Define la huella de memoria de una aplicación como páginas sucias más comprimidas, contadas en páginas de 16 KB. Afirma que el límite depende del dispositivo y nunca publica una cifra.
2. Apple — “Profile and optimize your game’s memory”, sesión 10106 de la WWDC22Fuente de la afirmación de que, en Apple silicon, los recursos de Metal a los que se accede cuentan como memoria sucia porque CPU y GPU comparten un mismo pool.
3. Apple — “Identifying high-memory use with jetsam event reports”El ejemplo que citamos: 92.802 páginas × 16.384 bytes = 1,52 GB en uso en una terminación por per-process-limit. Eso es el uso en el momento de morir, no un techo publicado.
4. Foros de desarrolladores de Apple — EXC_RESOURCE RESOURCE_TYPE_MEMORY (limit=30 MB)Informes de fallos de WidgetKit publicados por desarrolladores, no una especificación de Apple. La fuente del límite de ~30 MB para widgets.
5. Preguntas frecuentes de Flutter — “How big is the Flutter engine?”Los tamaños de aplicación mínima: ~4,8 MB de descarga en Android ARM64, 10,9 MB de descarga en iOS, ~4 MB de ellos el motor. Medido en marzo de 2021, sin Material Components, con --split-per-abi.
6. Flutter — motor de renderizado ImpellerConfirma que Impeller es el único motor de renderizado en iOS y que precompila los shaders en tiempo de compilación.
7. Flutter — “Don’t Fear the Garbage Collector” (Matt Sullivan, 2019)La descripción del recolector generacional: barrido del espacio joven, marcado y barrido en paralelo, ganchos de inactividad del motor.
8. Meta Engineering — “Hermes: An open source JavaScript engine optimized for mobile apps” (2019)Por qué Hermes no incluye JIT: el calentamiento perjudica el tiempo hasta poder interactuar, y un JIT cuesta tamaño de código y memoria.
9. facebook/hermes, incidencia #1829 — consumo de memoria en Hermes V1Un mantenedor de Meta explicando que HV32 usa ~40% menos memoria pero necesita un mapeo de memoria no disponible en iOS, así que allí Hermes V1 distribuye HV64. Aplica desde React Native 0.84 (febrero de 2026).
10. Notas de la versión React Native 0.70 (5 de septiembre de 2022)Hermes pasa a ser el motor por defecto.
11. React Native — “The New Architecture is Here” (23 de octubre de 2024)Fabric, TurboModules y modo sin puente por defecto. También es la fuente del hecho de que el puente antiguo sigue en 0.76 por compatibilidad.
12. Notas de la versión React Native 0.76Las únicas cifras oficiales: APK de Android ~3,8 MB más pequeño (20%), arranque mediano ~15 ms (~8%) más rápido. No se publicó ninguna cifra de memoria.
13. React Native — documentación de extensiones de aplicaciónLa propia advertencia de React Native de que su uso de memoria “tiende a ser demasiado alto” para los presupuestos de extensión más ajustados. Nota: la página aún habla del widget Today de 16 MB, que Apple retiró en iOS 18.

Código abierto que puedes ejecutar tú

1. Código fuente de la prueba de SynergyBoatLas cuatro implementaciones — Swift, Flutter, React Native, Kotlin — con la instrumentación. Clónalo y vuelve a ejecutarlo.
2. Paquete de replicación de EASE 2023Todos los volcados de adb en bruto detrás del artículo. Reejecutable.
3. jacobras/flutter-vs-native-vs-kmpUna aplicación en cuatro tecnologías, incluida una referencia nativa en Swift/SwiftUI. Publica solo tamaño de aplicación y arranque — ni RAM ni CPU. Archivado en agosto de 2026.
4. flutter/flutter — imitation_game_swiftui e imitation_game_flutterLa propia comparación de Flutter entre SwiftUI y Flutter, ejecutándose en integración continua sobre iOS. Mide tiempo de compilación, tamaño y tiempo hasta el primer fotograma. Ni RAM ni CPU, y no publica cifras.

Fuentes que revisamos y no usamos

1. inVerita — “Deep Performance Comparison” (junio de 2020)El origen de las cifras “48 MB / 117 MB / 135 MB”. iPhone 6s y un iPad Mini 3 de 2014, antes de Hermes, Impeller y la Nueva Arquitectura. Enlazado para que la afirmación sea comprobable, no como recomendación.
2. inVerita — “Examining Performance” (marzo de 2020)Las micropruebas de dígitos de pi detrás de “Flutter es un 15% más rápido que Swift”. Mide aritmética en un bucle, en un iPhone 6s.

Si quieres una segunda opinión sobre esa decisión para un producto concreto, habla con nosotros. Trabajamos con las tres y no tenemos ningún interés en cuál elijas.