Swift vs Flutter: RAM, CPU y lo que dicen realmente las mediciones

En resumen

• Flutter está cerca de nativo en velocidad. Su código se compila anticipadamente, así que tu lógica se ejecuta como código máquina. En el estudio independiente más riguroso que encontramos, Flutter añadió la menor sobrecarga de todos los frameworks multiplataforma probados
• En memoria no está cerca. Un desplazamiento por una lista añadió 9,74 MB en Swift frente a 25,33 MB en Flutter — alrededor de un 62% menos. Es una prueba de tres ejecuciones, y mide crecimiento, no uso total
• La diferencia es estructural. Flutter lleva su propio motor en memoria todo el tiempo y necesita espacio libre para limpiar lo que ya no usa. Swift libera la memoria en cuanto deja de necesitarla
• Una aplicación Flutter mínima son 10,9 MB de descarga antes de escribir una línea de código, unos 4 MB de ellos el motor
• El punto débil de Flutter son los límites, no la velocidad. Los widgets de la pantalla de inicio funcionan con un límite demasiado pequeño para un motor incorporado, así que tus widgets serán Swift de todos modos
• La memoria decide si tu aplicación sobrevive a una sesión. Los iPhone no ralentizan una aplicación pesada, la cierran — y tu cliente ve un carrito vacío en vez de un fallo
• Una sola cifra no dice nada sin la carga de trabajo. El propio uso de procesador de Flutter se duplicó entre desplazar una lista y usar la cámara, en el mismo estudio

Trabajamos tanto con Swift nativo como con Flutter. Así que esto compara compromisos que mantenemos en producción. No defiende a ninguno de los dos.

¿Es Flutter tan eficiente como Swift nativo?

Abajo está cada cifra que pudimos encontrar con un dispositivo, una versión del framework y una herramienta de medición declarados. También señalamos qué cifras muy citadas carecen de eso y, por tanto, no se usan aquí.

Una definición primero, porque se difumina a menudo. Por “Swift nativo” entendemos Swift con UIKit o SwiftUI. Esos dos tampoco son idénticos en huella de memoria. Pero ambos funcionan bajo el conteo de referencias, y ninguno incorpora un segundo entorno de ejecución. Ese segundo entorno es sobre lo que gira 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. Esto es lo que se ha medido realmente de cada una, y lo que no.

Lee la columna de la derecha antes de usar cualquier fila. Y lee las filas que dicen nadie ha publicado esto, porque hay más de las que admitirá cualquiera que te esté vendiendo un framework.

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

Qué se midió	Swift nativo	Flutter	Quién lo midió, y sobre qué
Memoria — la única pregunta con una respuesta real
Memoria extra que ocupó la aplicación al desplazar una lista larga	9,74 MB	25,33 MB	SynergyBoat, agosto de 2025. La misma aplicación construida de las dos formas, iPhone 16 Plus, tres ejecuciones de cada una
La misma cifra, junto a Swift	la referencia	2,6× más	Calculado a partir de la fila anterior — Swift usó alrededor de un 62% menos de memoria
Cuánto varió el resultado entre ejecuciones	± 0,18	± 0,47	Misma prueba. Ambos son estables, que es justamente por lo que esta comparación merece citarse
Memoria frente a una aplicación nativa, en Android	no hay Swift en Android	en la media de los frameworks probados	Oliveira y colegas, 2023, el único estudio aquí revisado por pares. Android, y la aplicación nativa con la que se comparó estaba en Java. Una dirección, no una cifra de iPhone
Cifras antiguas de iPhone que aún se citan hoy	48 MB	117 MB	inVerita, junio de 2020, iPhone 6s — medido antes de que Flutter reemplazara todo su motor de renderizado. Aparece para que lo reconozcas cuando te lo citen como actual
Uso del procesador — ninguna prueba en iPhone incluye Swift
iPhone, misma aplicación, de las dos formas	nadie ha publicado esto	nadie ha publicado esto	Buscamos a fondo y no encontramos ninguna
Flutter medido contra sí mismo, en iPhone	no incluido	9,33% en un iPhone 16 Pro, 13,72% en un iPhone 11	El panel en vivo del propio Flutter. Útil para seguir a Flutter a lo largo del tiempo, pero no hay ninguna aplicación en Swift dentro, y se cuenta de una forma que no encajará con una cifra que midas tú
Tamaño de descarga — lo que tu cliente espera
Una aplicación mínima, tal como se descarga en iPhone	nadie ha publicado esto	10,9 MB	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, así que esta no tiene nada justo al lado
Maquinaria que la aplicación carga solo para funcionar	ninguna — usa lo que ya está en el teléfono	unos 4 MB de motor	Preguntas frecuentes de Flutter. Esta es la diferencia estructural: Flutter trae su propio motor de renderizado, Swift toma prestado el del sistema
Rapidez de apertura — medida, pero nunca publicada
Arranque en frío en iPhone, misma aplicación	nadie ha publicado esto	nadie ha publicado esto	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 — no lo hemos vuelto a ejecutar, así que no citamos sus números aquí

Cada fila está referenciada en Fuentes, con el hardware, las versiones y las herramientas exactas. Las filas que dicen nadie ha publicado esto son el hallazgo, no un hueco que no supiéramos llenar.

¿Deberías elegir Swift o Flutter?

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

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 previsto	Swift nativo	El más ligero de los dos por un factor de 2,6, todas las funciones de Apple desde el primer día, nada extra en la descarga	Nada extra. Con una sola plataforma, nativo es además la opción más barata — un solo código y ninguna capa de framework entre tú y los errores
Ambas plataformas, y la eficiencia es el producto — audio en segundo plano, cámara, mapas, IA en el dispositivo, 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 manda	Flutter	Un solo equipo cubriendo ambas plataformas es un ahorro real, y en una aplicación que muestra listas y formularios puede que la diferencia de memoria no llegue nunca a tus clientes	Una aplicación más pesada. Presupuesta probar en el teléfono más antiguo que admitas, no en el más nuevo — ahí es donde se nota
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 — el precio de traer tu propio motor de renderizado
Los widgets o las Live Activities importan en el producto	Swift, elijas lo que elijas	Funcionan bajo un límite demasiado bajo para que quepa dentro un motor incorporado	No es realmente una elección. Cuenta con Swift en el equipo desde el principio en lugar de descubrirlo tarde

Elige Swift nativo cuando el producto sea iOS primero. Elígelo cuando los widgets, las Live Activities o las extensiones tengan peso real. Elígelo cuando necesites soporte desde el primer día para nuevos frameworks de Apple. Elígelo cuando tus usuarios estén en hardware antiguo y con poca memoria.

Elige Flutter cuando necesites un sistema de diseño renderizado de forma idéntica en iOS y Android, cuando la interfaz sea a medida y con muchas animaciones, y cuando un único código con lógica compilada anticipadamente compense una línea base del tamaño de un motor. En CPU estás renunciando a muy poco: los datos de EASE lo dicen, y son los datos más rigurosos disponibles.

Para la versión a tres bandas de esta comparación, consulta Swift nativo vs Flutter vs React Native. Para la otra comparación cara a cara, consulta Swift vs React Native. Y para entender por qué la diferencia de memoria decide si tu aplicación sobrevive a una sesión, consulta Por qué los iPhone cierran primero las aplicaciones pesadas. Si prefieres la respuesta para un producto concreto, habla con nosotros. Trabajamos con ambos y no tenemos nada que venderte en esta elección.

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. 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.
5. Notas de la versión Flutter 3.22 (14 de mayo de 2024)De primera mano y con dispositivo declarado: el tiempo de CPU y GPU del desenfoque “casi la mitad” en un iPhone 11; rasterizado de Lottie de 64 ms por fotograma a “casi 10 veces más rápido”; uso de GPU de las vistas de plataforma en iOS un 50% menor.

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.

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.
3. Biørn-Hansen, Rieger, Grønli, Majchrzak y Ghinea — “An empirical investigation of performance overhead in cross-platform mobile development frameworks” (Empirical Software Engineering, 2020)Uno de varios estudios anteriores revisados por pares con referencia nativa. Se cita aquí porque desmiente cualquier afirmación de que EASE 2023 sea el único.