--- title: "Por qué un senior de React Native debería aprender nativo en 2026" description: "Cuándo iOS nativo le gana a React Native (widgets, APIs del día uno, ML en el dispositivo), cuándo pierde (dos plataformas, OTA, equipo) y por qué aprender Swift suma en vez de reemplazar." author: Ramón Chancay date: 2026-09-01 lang: es tags: [React Native, Swift, SwiftUI, iOS, Expo, Arquitectura móvil] canonical: https://www.ramonchancay.me/es/blog/por-que-un-senior-de-react-native-deberia-aprender-nativo --- # Por qué un senior de React Native debería aprender nativo en 2026 Aprender iOS nativo cuando ya llevas años entregando apps con React Native no es empezar de cero: ya sabes construir productos móviles, negociar con App Review, medir un scroll que se traba y explicarle a un cliente por qué una funcionalidad cuesta tres semanas. Lo que cambia es la capa donde vives. Esta serie parte de esa premisa. No voy a explicar qué es una variable en Swift; voy a explicar qué decisiones cambian de verdad cuando pasas de Expo a Xcode, y qué cosas de React Native vas a extrañar desde el primer día. Este primer post es la tesis: cuándo nativo gana, cuándo pierde, y por qué la respuesta correcta para un senior no es reemplazar una herramienta por otra, sino sumar la segunda.
Resumen para perezosos
**En este artículo:** - **La tesis** — [Qué cambia para un senior](#qué-cambia-cuando-ya-sabes-construir-apps) · [Cuándo nativo gana](#cuándo-nativo-gana-de-verdad) · [Cuándo nativo pierde](#cuándo-nativo-pierde-y-conviene-decirlo-sin-rodeos) - **La decisión** — [Sumar, no reemplazar](#por-qué-es-sumar-y-no-reemplazar) · [Cómo decidir por proyecto](#cómo-decidir-por-proyecto-una-tabla-y-tres-preguntas) - **La honestidad** — [Lo que vas a extrañar](#lo-que-vas-a-extrañar-de-react-native) · [El mapa de la serie](#el-mapa-de-la-serie) ## Qué cambia cuando ya sabes construir apps Casi todo el material para aprender Swift está escrito para alguien que nunca programó para móvil. Explica qué es un `struct`, qué es un `ViewController`, cómo se declara un opcional. Para un senior de React Native ese material es ruido: ya sabes qué es un componente, un estado, una navegación, un caché de red, un build firmado. Lo que no sabes es cómo se llama cada una de esas cosas en el otro lado, y cuáles de tus reflejos dejan de funcionar. Por eso el enfoque de esta serie no es "aprende Swift". Es "ya sabes construir apps; esto es lo que cambia". Cada post arranca de una decisión o un dolor que reconoces: cómo manejo el estado global, cómo navego sin file-based routing, qué reemplaza a TanStack Query, cómo firmo un build sin que EAS lo haga por mí. El objetivo es que al terminar puedas abrir un proyecto en Xcode y tomar las mismas decisiones de arquitectura que tomas hoy en Expo, con criterio, no copiando un tutorial. Hay una segunda razón para escribirla desde ese ángulo. Un senior de React Native ya vive parcialmente en nativo aunque no lo admita: cada vez que un módulo de Expo no cubre un caso, cada vez que un crash llega con un stack trace de Objective-C, cada vez que hay que tocar un `Podfile` o entender por qué la New Architecture cambió el comportamiento de una librería. Aprender nativo formalmente no es cambiar de carrera; es dejar de tratar esa mitad del trabajo como una caja negra. ## Cuándo nativo gana de verdad Voy a ser concreto porque el argumento genérico ("nativo es más rápido") ya no convence a nadie que haya usado React Native con la New Architecture. Hay cuatro terrenos donde nativo gana hoy de forma clara. **Widgets, Live Activities y todo lo que corre fuera de tu proceso.** Un widget de pantalla de inicio o una Live Activity en la Dynamic Island no es una vista de tu app: es una extensión que el sistema renderiza por su cuenta, sin tu runtime de JavaScript, a partir de una descripción en SwiftUI. Con React Native puedes agregar el target con un config plugin de la comunidad, pero la interfaz del widget la escribes en Swift igual: el sistema renderiza y actualiza el widget bajo sus propias reglas, sin mantener vivo tu runtime de JavaScript. Lo mismo aplica a App Intents, a las extensiones de Siri y a los complications de watchOS. **Las APIs del día uno.** Apple presenta las APIs en junio y las publica en septiembre. Con Swift las usas el día del anuncio, en la beta de Xcode. Con React Native la secuencia es otra: alguien tiene que escribir el módulo nativo, publicarlo, mantenerlo, y tú tienes que confiar en que esa persona siga ahí el año siguiente. Con Expo Modules escribir ese puente es mucho más razonable que antes, pero sigue siendo trabajo en Swift, que es exactamente el punto. Liquid Glass, el nuevo lenguaje visual de iOS 26, es el ejemplo reciente: las apps SwiftUI lo adoptaron al recompilar; el resto tuvo que esperar o imitarlo. **Modelos de ML en el dispositivo.** Core ML, Vision, Speech y, desde iOS 26, el framework Foundation Models con un modelo de lenguaje que corre en el teléfono sin red y sin costo por token. Estas APIs son nativas, sincrónicas con el ciclo de vida de la app y pensadas para integrarse con Swift Concurrency. Se pueden exponer a JavaScript, pero cada capa de puente añade serialización, latencia y una superficie más para depurar. Cuando el producto es la inferencia local, esa capa es un costo permanente. **El rendimiento de las pantallas exigentes.** Aquí conviene matizar. Para una app de formularios y listas, React Native con la New Architecture rinde de forma que el usuario no distingue. La diferencia aparece en los extremos: listas con celdas complejas y miles de elementos, transiciones que dependen de gestos con precisión de frame, arranques en frío en dispositivos viejos, consumo de memoria en apps que abren cámara y mapas a la vez. En esos casos la diferencia no es "un poco mejor": puedes perfilar una app de React Native con Instruments, pero en nativo hay menos capas de abstracción entre lo que mides y lo que puedes cambiar, y el control es más directo. ```text ¿Dónde vive la funcionalidad? Dentro de tu proceso, en pantallas normales │ ├── formularios, listas, navegación, red ────► RN o nativo, empate práctico │ └── scroll pesado, gestos de precisión, arranque en frío, memoria ──────────────► nativo gana (menos capas) Fuera de tu proceso o en el borde del sistema │ ├── widgets, Live Activities, App Intents ──► esa parte va en Swift ├── API nueva de iOS, el día del anuncio ───► nativo (RN espera el módulo) └── ML en el dispositivo ───────────────────► nativo (cada puente cuesta) ``` ## Cuándo nativo pierde, y conviene decirlo sin rodeos Si la serie solo enumerara ventajas sería propaganda, y un senior la cerraría en el segundo párrafo. Nativo pierde en tres frentes, y los tres son de negocio, no de técnica. **Dos plataformas.** Una app nativa en iOS es una app; el cliente casi siempre quiere dos. Kotlin y Jetpack Compose se parecen bastante a Swift y SwiftUI, y eso ayuda, pero sigue siendo el doble de código, el doble de tests y el doble de bugs de plataforma. React Native resuelve esto con una base de código y un equipo. Kotlin Multiplatform y Compose Multiplatform están cerrando la brecha desde el lado nativo, pero todavía no ofrecen la madurez de Expo para un equipo pequeño que necesita entregar en ambas tiendas el mismo mes. **Actualizaciones OTA.** Con EAS Update corriges un bug de JavaScript y el usuario lo recibe la próxima vez que abre la app, sin App Review. En nativo no existe ese camino: cada corrección es un build, un envío y una revisión que puede tardar horas o días. Para productos que iteran a diario, esa diferencia pesa más que cualquier ventaja de rendimiento. **El equipo.** Contratar desarrolladores de JavaScript es más fácil y más barato que contratar desarrolladores de Swift en casi cualquier mercado, y más aún en Latinoamérica. Un equipo web puede pasar a React Native en semanas; pasar a Swift toma meses. Si el proyecto lo va a mantener una agencia o un equipo que ya vive en TypeScript, imponer nativo es imponer un costo de contratación que nadie te pidió. Y hay un cuarto frente que no es de negocio sino de ergonomía, y que merece su propia sección al final: la experiencia de desarrollo de React Native, en muchos aspectos, es mejor. Fast Refresh contra tiempos de compilación, Metro contra Xcode, un `package.json` contra un `.pbxproj`. Lo dejo para el cierre porque es la parte que le da credibilidad al resto. ## Por qué es sumar y no reemplazar La pregunta mal planteada es "¿debería dejar React Native por Swift?". La pregunta que un senior debería hacerse es "¿qué gano si domino los dos?". Y la respuesta tiene dos partes. La primera es que saber nativo te hace mejor ingeniero de React Native. Cuando entiendes cómo funciona un `UIViewController` sabes por qué la navegación nativa de React Navigation se comporta como se comporta. Cuando entiendes Swift Concurrency sabes qué está pasando cuando un TurboModule bloquea el hilo principal. Cuando has firmado un build a mano sabes qué hace EAS por ti y qué hacer cuando falla. Los seniors de React Native que más valor aportan en un equipo son los que pueden abrir Xcode, leer el crash log y arreglar el módulo en vez de abrir un issue y esperar. La segunda es comercial. Hay proyectos que necesitan Swift: la app con widgets como funcionalidad central, la que corre modelos en el dispositivo, la que vive en watchOS, la que quiere adoptar cada API nueva de Apple el día que sale. Si solo ofreces React Native, esos proyectos van a otro. Si ofreces los dos, eres la persona que puede decirle al cliente "esto en React Native, esto en Swift, y aquí está el razonamiento", y esa conversación vale más que cualquiera de las dos habilidades por separado. > En mi experiencia, el argumento que más convence a un cliente no es "nativo es mejor" ni "React Native es más barato", sino tener criterio para decir cuál conviene en su caso y por qué. Ese criterio solo se construye habiendo entregado con las dos. Nada de esto implica abandonar Expo. Implica dejar de depender de que alguien más haya escrito el módulo que necesitas, y poder elegir la herramienta por proyecto en vez de por costumbre. ## Cómo decidir por proyecto: una tabla y tres preguntas Esta es la tabla que uso para orientar la conversación con un cliente antes de escribir una línea. No es una regla fija; es una forma de que la decisión quede explícita en vez de implícita. | Criterio | Inclina a React Native | Inclina a nativo | |---|---|---| | Plataformas | iOS y Android desde el día uno, un solo equipo | Solo iOS, o iOS primero y Android en otro ciclo | | Cadencia de cambios | Correcciones diarias, OTA como parte del proceso | Releases planificados, la revisión de App Store cabe en el calendario | | Funcionalidad central | Pantallas, formularios, listas, red | Widgets, Live Activities, ML local, watchOS, APIs nuevas | | Rendimiento | Estándar de una app de contenido | Scroll, gestos y arranque medidos en milisegundos | | Equipo | JavaScript, web, agencia | Ya hay conocimiento de Swift, o el proyecto justifica formarlo | | Compartir con web | Sí, con Expo web o lógica compartida | No, o la web es un producto aparte | Las tres preguntas que resumen la tabla: 1. **¿Cuántas plataformas y con qué equipo?** Si son dos y el equipo es uno, React Native, salvo que la segunda pregunta lo contradiga con fuerza. 2. **¿La funcionalidad que vende el producto vive dentro de la app o en el borde del sistema?** Widgets, extensiones, ML local y APIs del día uno viven en el borde: nativo. 3. **¿Cuánto vale iterar sin App Review?** Si el negocio depende de corregir en horas, OTA pesa más que casi cualquier otra cosa. Cuando las tres apuntan al mismo lado, la decisión es obvia. Cuando se contradicen, la respuesta suele ser híbrida: una app React Native con targets nativos para los widgets y las extensiones, escritos en Swift. Y para eso, otra vez, hay que saber Swift. ## Lo que vas a extrañar de React Native Esta sección es la que más me costó escribir, y es la que más importa. Si vienes de Expo, esto es lo que vas a perder al abrir Xcode. Sin suavizarlo. **Fast Refresh.** Guardas un archivo y la app cambia en menos de un segundo, conservando el estado. En SwiftUI tienes Xcode Previews, que son buenas para diseñar una vista aislada, y una compilación incremental que en un proyecto mediano tarda lo que tarda. Xcode ha mejorado la velocidad de las Previews y de los builds incrementales, pero el ciclo "guardar y ver" sigue siendo más lento que en Metro, y un cambio en un tipo compartido puede recompilar medio módulo. Uno de los posts de la serie es sobre cómo modularizar para bajar esos tiempos, porque es un problema real que hay que atacar con arquitectura. **Actualizaciones OTA.** Ya lo dije arriba y lo repito porque es lo que más se nota en operación: en nativo no hay forma de corregir un bug sin pasar por la tienda. Puedes mitigarlo con feature flags remotos y con configuración descargada del servidor, pero el código que corre es el que firmaste. **Expo Go y los dev clients.** Escanear un QR y tener la app en el teléfono en segundos, sin cable ni provisioning profile. En nativo, instalar en un dispositivo físico requiere que ese dispositivo esté registrado en tu cuenta de desarrollador y que el perfil de firma lo incluya. Xcode automatiza casi todo con la firma automática, pero "casi" es la palabra: la primera vez que un perfil se corrompe vas a extrañar el QR. **El ecosistema de npm.** Para casi cualquier problema hay tres paquetes en npm con miles de descargas semanales. Swift Package Manager tiene un ecosistema sólido, pero más pequeño, y en varios dominios (gráficas, editores de texto enriquecido, ciertos SDK de terceros) la opción madura es una sola o ninguna. Vas a escribir más código propio. **Una sola base de código.** Aunque el proyecto sea solo iOS hoy, en React Native la puerta a Android estaba abierta a un costo mucho menor: compartir la base de código no hace gratis la segunda plataforma, pero la deja lejos de ser un segundo proyecto. En Swift esa puerta no existe; Android es otro proyecto. **Flexbox.** El sistema de layout de SwiftUI es distinto: cada vista propone un tamaño a sus hijas, cada hija decide el suyo, y la madre las posiciona. Es coherente y potente, pero tus reflejos de `flex: 1` y `justifyContent` no se traducen uno a uno. El post sobre SwiftUI explica el sistema completo, porque es el cambio mental más grande de toda la serie. **Un `package.json` en vez de un `.pbxproj`.** El archivo de proyecto de Xcode es un formato propietario que genera conflictos de merge cada vez que dos personas agregan archivos. Hay solución (Tuist, o generar el proyecto desde una descripción) y la serie la cubre, pero el hecho de necesitar una herramienta para que el archivo de proyecto no rompa el equipo dice bastante. **TanStack Query.** No hay equivalente con la misma adopción. Vas a diseñar tu capa de caché, invalidación y reintentos. Hay librerías que ayudan y patrones claros con `AsyncStream` y SwiftData, pero la decisión y el mantenimiento son tuyos. **La comunidad en español.** React Native tiene una comunidad enorme en Latinoamérica: meetups, Discord, contenido. La de Swift existe y es buena, pero es más pequeña y está más concentrada en inglés. Nada de esto es un motivo para no aprender nativo. Es la lista de lo que vas a tener que compensar con arquitectura, tooling o paciencia, y prefiero que la tengas antes de empezar que descubrirla en la segunda semana. ## El mapa de la serie Los siguientes posts van en el orden en que un senior se encuentra con los problemas al construir su primera app seria en Swift, no en el orden de un curso: | # | Tema | El dolor de React Native del que parte | |---|---|---| | 2 | [Swift para quien ya domina TypeScript](/es/blog/swift-para-quien-domina-typescript) | Opcionales, enums y Codable en vez de `null`, uniones y zod | | 3 | [SwiftUI no es React](/es/blog/swiftui-no-es-react) | `body` vs `render`, identidad de vistas, layout sin flexbox, hooks vs property wrappers | | 4 | [Estado y arquitectura](/es/blog/estado-y-arquitectura-de-zustand-a-observable-y-tca) | De Zustand y Redux a `@Observable` y TCA | | 5 | [Navegación sin file-based routing](/es/blog/navegacion-en-swiftui-sin-file-based-routing) | De Expo Router a `NavigationStack` y un enum de rutas | | 6 | [Data: lo que TanStack Query hacía por ti](/es/blog/data-en-swift-lo-que-tanstack-query-hacia-por-ti) | Caché, invalidación y `URLSession` | | 7 | [Concurrencia real](/es/blog/concurrencia-en-swift-adios-al-event-loop) | Del event loop a actores y Swift 6 | | 8 | [Persistencia](/es/blog/persistencia-en-ios-swiftdata-grdb-keychain) | SwiftData, GRDB, Keychain y sincronización | | 9 | [Del ecosistema expo-* a los frameworks de Apple](/es/blog/del-ecosistema-expo-a-los-frameworks-de-apple) | La tabla de equivalencias por dominio | | 10 | [UI, theming y animaciones](/es/blog/ui-theming-y-animaciones-en-swiftui-sin-nativewind-ni-reanimated) | Sin NativeWind ni Reanimated | | 11 | [Build, firma y App Store](/es/blog/build-firma-y-app-store-lo-que-eas-te-escondia) | Lo que EAS hacía por ti | | 12 | [Testing y tooling](/es/blog/testing-y-tooling-en-ios-para-seniors) | Swift Testing, snapshots, Instruments, tiempos de compilación | | 13 | [Lo que solo puedes hacer en nativo](/es/blog/lo-que-solo-puedes-hacer-en-nativo-ios) | Widgets, Live Activities, App Intents, StoreKit 2, Foundation Models | Cada post se puede leer suelto, pero el orden importa: el de estado asume el de SwiftUI, el de navegación asume el de estado, y el de data asume concurrencia aunque la concurrencia venga después, porque en la práctica te vas a topar con `async` antes de entenderlo. ## Preguntas frecuentes ### ¿Vale la pena aprender Swift si la New Architecture de React Native ya cerró la brecha de rendimiento? Sí, porque el rendimiento no es el argumento principal. Los argumentos principales son las funcionalidades que viven fuera del proceso (widgets, extensiones, Live Activities), las APIs que llegan primero a Swift y el ML en el dispositivo. La New Architecture mejoró mucho la comunicación entre JavaScript y nativo, pero no cambia dónde corre un widget ni quién escribe el módulo para una API nueva. ### ¿Debería aprender UIKit o directamente SwiftUI? SwiftUI, con una excepción práctica: vas a leer UIKit constantemente, porque muchas librerías, muchos ejemplos y algunos componentes del sistema todavía se exponen así. Aprende SwiftUI como lenguaje principal y UIKit lo suficiente para envolver un `UIViewController` cuando haga falta y para entender qué hay debajo de una `List`. ### ¿Y Kotlin? ¿La serie cubre Android? No. La serie es de iOS por foco: el cambio mental de React Native a SwiftUI y a Swift Concurrency ya da para trece posts. Mucho de lo que se explica sobre arquitectura, navegación y estado se traslada a Jetpack Compose con otros nombres, pero eso es otra serie. ### ¿Cuánto tiempo toma ser productivo en Swift viniendo de TypeScript? Depende de qué signifique productivo. Escribir una pantalla en SwiftUI que compila: días. Tomar decisiones de arquitectura correctas sobre estado, navegación y concurrencia: meses, y ese es justamente el tramo que la serie intenta acortar. El lenguaje se aprende rápido; lo lento es dejar de aplicar reflejos de React donde no corresponden. ## Conclusión Para un senior de React Native, aprender iOS nativo no es cambiar de herramienta, es dejar de tener una mitad del trabajo en una caja negra y poder elegir por proyecto en vez de por costumbre: saber cuándo lo que vende el producto vive en el borde del sistema y cuándo el negocio manda dos plataformas y OTA. Y lo que vas a extrañar es real. Si vas a empezar, hazlo en este orden: primero decide con la tabla qué tipo de proyecto justifica Swift en tu contexto, después construye una app pequeña que use al menos una capacidad que React Native no ofrece (un widget es la elección más honesta) y, mientras la construyes, lee la serie en orden. El [siguiente post](/es/blog/swift-para-quien-domina-typescript) es el único sobre el lenguaje: las cinco diferencias entre Swift y TypeScript que sí cambian cómo diseñas el código, sin repasar sintaxis.