Desarrollo25 de septiembre de 2026

Lo que 'nativo' realmente significa en apps móviles

Nativo no significa que una app hable con el kernel. Android no usa Dalvik desde hace una década. Las builds de release de Flutter no son una VM. Qué cambia realmente entre iOS, Android y multiplataforma, con cada afirmación referenciada a la documentación de cada plataforma.

Gráfico de barras isométrico del crecimiento de memoria en un desplazamiento de 100 elementos en un iPhone 16 Plus: Swift nativo 9,74 MB, Flutter 25,33 MB, React Native 45,13 MB

La versión corta

"Nativo" no significa que una app hable directamente con el kernel. Ninguna app lo hace — ni siquiera las de Swift. Toda app de terceros en iOS, sea cual sea su tecnología, se ejecuta dentro del mismo sandbox impuesto por el sistema operativo y accede al hardware a través de los mismos frameworks del sistema
El ART de Android primero ejecuta tu código con un intérprete y un JIT, y luego compila las rutas más usadas por adelantado en segundo plano — el orden inverso al que la mayoría asume, y es el runtime por defecto de Android desde Android 5.0
Las builds de release de Flutter también se compilan por adelantado, a código máquina real. No "se ejecuta en una VM" como suele describirse. El coste real y medible es el motor que mantiene residente en memoria — lo cubrimos aparte, con cifras
La diferencia real es contra qué enlaza el lenguaje, no cuánto privilegio tiene. Swift llama directamente a Core Data, Core Animation y Metal. Flutter y React Native llegan al mismo hardware a través de un puente que alguien tiene que escribir y mantener
Ese puente es también la razón por la que las nuevas funciones de Apple llegan primero a Swift. Un SDK nuevo llega a todo proyecto Swift el día que Apple lo publica. Un plugin multiplataforma para esa misma función llega cuando su mantenedor tiene tiempo
Nada de esto hace que multiplataforma sea "peor" por defecto. Es un conjunto distinto de compromisos — y los que realmente llegan a tus clientes son medibles. Los hemos medido

Construimos en Swift nativo, Flutter y React Native, así que esta es la explicación que le damos a un cliente antes de que elija — no un argumento a favor del que preferiríamos vender.

Qué entiende la gente por "nativo" — y qué es cierto realmente

"Nativo" se usa como atajo para decir "más rápido y más seguro", como si fuera un nivel de privilegio. No lo es. Toda app de terceros en un iPhone — Swift, Flutter o React Native — se ejecuta como un proceso ordinario y aislado, y llega al sistema operativo por la misma puerta. Lo que realmente cambia entre ellas es contra qué frameworks enlaza directamente el código de la app, y si hay un segundo runtime sentado en memoria junto a ella.

La propia documentación de seguridad de Apple lo afirma sin excepción: "Todas las apps de terceros están aisladas en un sandbox." Si una app de terceros necesita acceder a información que no es suya, solo puede hacerlo mediante servicios que iOS ofrece explícitamente. No existe un sandbox aparte, más laxo, para las apps escritas en Swift — el límite lo impone el sistema operativo para toda app, sea cual sea el lenguaje en el que se envió.

Nativo iOS: más cerca de los frameworks de Apple, no del kernel

Lo que Swift y SwiftUI realmente dan es enlace directo. Una app de iOS escrita en Swift llama a Core Data, Core Animation y Metal igual que cualquier app propia de Apple — sin capa de traducción, sin puente, sin un mantenedor de plugin entre tu código y la API. También significa que tu interfaz puede seguir las Human Interface Guidelines de Apple usando los componentes reales de la plataforma, no una aproximación redibujada de ellos.

Es una ventaja real. Solo que no es la que implica "acceso a nivel de kernel". El sandbox, los requisitos de firma de código y el proceso de revisión se aplican igual, tanto si el binario se escribió en Swift como si se compiló desde Dart.

Android nativo también es nativo — solo compila distinto

Las apps de Android escritas en Kotlin o Java son tan nativas de Android como Swift lo es de iOS. Donde ambas plataformas divergen de verdad es en el runtime que hay debajo — y la descripción habitual de ese runtime tiene el orden invertido. El ART de Android ejecuta una app recién instalada primero con su intérprete y su compilador JIT; el JIT le pasa después al compilador dex2oat del propio dispositivo lo que aprendió sobre qué métodos se ejecutan realmente con frecuencia, y ese compilador los compila por adelantado en segundo plano. El código frío se queda interpretado todo el tiempo. ART es el runtime por defecto de Android desde Android 5.0, en sustitución de Dalvik — hace más de una década.

Donde la sobrecarga de Android sí es real es en la fragmentación: una app tiene que funcionar correctamente en muchos más chipsets, tamaños de pantalla y versiones de sistema operativo de los que iOS exige jamás, y buena parte de la percepción de "Android es más lento" es en realidad un dispositivo de gama baja con poca RAM, no el runtime en sí.

Dónde los frameworks multiplataforma añaden una capa real

Esta es la parte que vale la pena entender bien, porque ambos frameworks principales se describen mal, en direcciones opuestas.

Flutter no se interpreta en tiempo de ejecución en producción. La propia documentación de arquitectura de Flutter es explícita: "para release, las apps de Flutter se compilan directamente a código máquina, ya sean instrucciones Intel x64 o ARM." La VM solo se usa durante el desarrollo, para el hot reload. El coste estructural real es otro: Flutter incluye y mantiene su propio motor de renderizado residente en memoria durante toda la vida de la app, porque dibuja cada píxel él mismo en lugar de usar los componentes de UIKit. Es una diferencia de memoria real y medible — cubrimos exactamente cuánta, y en qué condiciones, aparte.

React Native toma un enfoque distinto: mantiene un motor de JavaScript (Hermes) corriendo junto a las vistas nativas de UIKit durante toda la vida de la app, así que pagas por dos gestores de memoria donde una app en Swift paga por uno. Ese coste también es medible, y lo hemos medido.

La otra brecha real es el alcance. La propia documentación de Flutter describe el acceso a una API de plataforma fuera de su núcleo como un mensaje enviado por un "canal de plataforma" hacia código nativo que alguien tiene que escribir. React Native dice lo mismo de sus propios módulos nativos: las funciones de la plataforma "no están directamente disponibles desde react-native", así que llegar a ellas significa escribir y mantener Swift o Kotlin real debajo. Una API nueva de Apple está disponible en todo proyecto Swift el día que Apple la publica. Llega a Flutter o React Native solo cuando existe un plugin para ella, lo que puede tardar días o no llegar nunca.

Qué cambia realmente, lado a lado

No es una clasificación. Lo que hace cada enfoque en realidad, y qué cuesta llegar al mismo resultado.

Qué cambia	Nativo iOS (Swift)	Nativo Android (Kotlin/Java)	Multiplataforma (Flutter / React Native)
Cómo se ejecuta el código	Compilado por adelantado a código máquina ARM	Primero interpretado y compilado con JIT; ART compila las rutas más usadas por adelantado en segundo plano	Compilado por adelantado (Flutter) o bytecode interpretado junto a vistas nativas (React Native)
Contra qué enlaza	Los frameworks propios de Apple, directamente — Core Data, Core Animation, Metal	Los frameworks propios de Android, directamente	El motor o puente propio del framework, que luego llama al framework de la plataforma
Sandbox del sistema operativo	El mismo que cualquier app de terceros	El sandbox propio de Android, igual para toda app	El mismo sandbox que cualquier otra app de terceros en ese sistema operativo
Acceso el primer día a nuevas API de plataforma	Inmediato — está en el SDK	Inmediato — está en el SDK	Depende de que un autor de plugin escriba y publique un puente
Runtime extra mantenido en memoria	Ninguno	Ninguno	El motor de Flutter, o la VM de JavaScript de React Native

Qué cuesta esto en la práctica

Nada de lo anterior es abstracto en cuanto una app está bajo presión de memoria. En la única prueba publicada en iPhone que construye la misma app en Swift nativo, Flutter y React Native y mide las tres de la misma forma, un desplazamiento por una lista de 100 elementos añadió 9,74 MB en Swift, 25,33 MB en Flutter y 45,13 MB en React Native — Swift usó un 62% menos de memoria que Flutter y un 78% menos que React Native (iPhone 16 Plus, tres ejecuciones cada una, agosto de 2025). Un iPhone no ralentiza una app pesada — la cierra, empezando por la más pesada, sin ningún informe de fallo que lo muestre. Explicamos aparte lo que eso cuesta comercialmente, y la comparación completa y referenciada de lo que Flutter y React Native añaden realmente en RAM y CPU, con cada cifra etiquetada por dispositivo y versión de framework, está aquí.

¿Entonces cuándo importa realmente lo "nativo"?

La eficiencia es una variable más, y rara vez es la única que decide un proyecto.

Solo iPhone, y la eficiencia importa — audio en segundo plano, cámara, IA en el dispositivo, hardware antiguo: Swift nativo es la respuesta directa, y con una sola plataforma también es la más barata
Los widgets o las Live Activities están en el roadmap: esa parte es Swift sea lo que sea el resto de la app — el límite de memoria bajo el que se ejecutan no admite un motor incluido
Ambas plataformas, contenido ordinario, presupuesto ajustado: Flutter o React Native es una opción legítima — un equipo, dos plataformas, y para una app de reservas o tienda la diferencia de memoria puede que nunca llegue a un cliente
Ya tienes un equipo de React o Dart: eso es un activo real que un benchmark no captura. Lanzar este trimestre puede pesar más que ser más liviano el próximo

Si prefieres que esto se valore contra un producto concreto en lugar de en abstracto, habla con nosotros — construimos en los tres y no tenemos nada que venderte sobre cuál elegir.

Preguntas frecuentes

¿Las apps nativas tienen acceso a nivel de kernel en un iPhone?

No. La documentación de seguridad de Apple dice que todas las apps de terceros se ejecutan en un sandbox, estén escritas en el lenguaje que sea. Una app en Swift llega al sistema operativo por los mismos frameworks del sistema que una en Flutter o React Native; solo se ahorra la capa intermedia.

¿Android sigue usando Dalvik?

No. ART sustituyó a Dalvik como runtime por defecto en Android 5.0, hace más de una década. ART ejecuta una app recién instalada primero con su intérprete y su compilador JIT, y después compila por adelantado, en segundo plano, el código que realmente se usa más.

¿Flutter se ejecuta en una máquina virtual?

No en producción. Las builds de release de Flutter se compilan por adelantado a código máquina; la VM solo se usa durante el desarrollo, para el hot reload. El coste real de Flutter es el motor de renderizado que mantiene en memoria durante toda la vida de la app.

¿Cuánta más memoria usan Flutter y React Native que Swift?

En la prueba de SynergyBoat en un iPhone 16 Plus, un desplazamiento por una lista de 100 elementos añadió 9,74 MB en Swift, 25,33 MB en Flutter y 45,13 MB en React Native. Es una medición publicada por un proveedor, de un solo escenario, no una regla para toda app.

¿Por qué las nuevas funciones de Apple llegan antes a las apps en Swift?

Una API nueva de Apple está en el SDK el día que Apple la publica, así que cualquier proyecto Swift puede usarla de inmediato. Flutter y React Native llegan a ella solo cuando alguien escribe un plugin que la conecte, lo que puede tardar días o no ocurrir nunca.

¿Es la multiplataforma una mala elección para una startup?

No por defecto. Para las dos plataformas, contenido corriente y un presupuesto ajustado, Flutter o React Native es una opción legítima: un solo equipo publica ambas apps. Swift nativo es la respuesta directa para productos solo de iPhone, sensibles a la eficiencia, y para widgets o Live Activities.

Fuentes

Cada afirmación de arquitectura anterior sale de la documentación propia de la plataforma, no de un resumen de ella.

La medición

SynergyBoat — "Flutter vs React Native vs Native: 2025 Performance Benchmark" (31 de agosto de 2025)Las cifras de memoria de la portada y del texto. iPhone 16 Plus, N=3, crecimiento de RSS en un desplazamiento de 100 elementos. Publicado por el proveedor. Usamos solo su parte de memoria; su comparación de tiempo por fotograma mide magnitudes distintas contra un mismo presupuesto.

Documentación de primera mano

Apple — "Security of runtime process in iOS, iPadOS, and visionOS"Fuente de "todas las apps de terceros están en sandbox" y de que las apps solo acceden a otros datos mediante servicios que iOS ofrece explícitamente.
Apple — Human Interface GuidelinesEl estándar de diseño propio de Apple, referenciado para el punto sobre consistencia de interfaz nativa de plataforma.
Apple — documentación de Core Data
Apple — documentación de Core Animation (QuartzCore)
Apple — documentación de Metal
Android Open Source Project — "Implement JIT compiler"Fuente de que ART ejecuta primero el intérprete y el JIT, y luego usa el perfil del JIT para dirigir la compilación por adelantado del compilador dex2oat en el dispositivo.
Android Developers Blog — "Android 5.0 Lollipop SDK and Nexus Preview Images" (octubre de 2014)Fuente de "ART is enabled by default on API 21 & new Android devices with Android 5.0."
Flutter — Architectural overviewFuente de "para release, las apps de Flutter se compilan directamente a código máquina" y de que la VM es una función exclusiva del modo desarrollo.
Flutter — Platform channelsFuente de cómo Flutter llega a una API de plataforma fuera de su propio núcleo: un mensaje enviado a código nativo a través de un canal.
React Native — Native platform codeFuente de "tu aplicación puede necesitar acceso a funciones de la plataforma que no están directamente disponibles desde react-native", y de que llegar a ellas implica escribir código nativo.

Para el coste medido del motor que mantiene residente cada framework multiplataforma, consulta Swift nativo vs Flutter vs React Native: RAM, CPU y eficiencia real, Swift vs Flutter, o Swift vs React Native. Para lo que ese coste le hace a una sesión en producción, consulta Por qué los iPhone cierran primero las aplicaciones pesadas.