Nueva Arquitectura de React Native: guía 2026

React Native pasó por el cambio interno más grande de su historia, y lo hizo con tanta discreción que muchos dueños de apps solo se enteraron cuando una dependencia dejó de instalarse. La Nueva Arquitectura se volvió el valor por defecto para proyectos nuevos a finales de 2024, y las versiones posteriores han ido retirando de forma constante la opción de correr la vieja. En 2026 la pregunta para quien tiene una app en React Native ya no es “¿deberíamos adoptarla?” sino “¿qué cambió de verdad, cuánto nos va a costar llegar ahí y cuáles de nuestras librerías van a ser el problema?”. Este artículo responde esas tres preguntas tanto para quien aprueba el presupuesto como para los ingenieros que van a gastarlo.

Qué era la vieja arquitectura, en un párrafo

Durante la mayor parte de su vida, React Native ejecutaba tu JavaScript en un hilo y la interfaz nativa en otro, y los dos se comunicaban mediante un “puente” asíncrono que serializaba cada mensaje a JSON y de vuelta. Cada evento táctil, cada medición de layout, cada llamada a un módulo nativo cruzaba ese puente como un lote de texto. Era un diseño ingenioso para 2015, y también la raíz de la reputación del framework: listas que trastabillaban al desplazarse rápido, animaciones que perdían cuadros cuando JavaScript estaba ocupado, y un arranque que pagaba por cada módulo nativo lo usara la app o no.

Qué cambió: cuatro piezas que reemplazan el puente

Junto con el motor Hermes, que ahora es el runtime de JavaScript estándar, estas piezas le dan a React Native una base que se parece a cómo se estructura una app nativa, con una capa de scripting encima. El framework también entró en lo que llama modo “bridgeless” (sin puente), en el que el puente heredado no solo se evita sino que está ausente. Esa palabra importa cuando leas los changelogs de librerías: un paquete que funciona con la Nueva Arquitectura activada puede seguir apoyándose en el viejo puente a través de una capa de interoperabilidad, y un paquete “listo para bridgeless” no.

Qué cambió para los dueños de apps, no para los ingenieros

Si encargas o eres dueño de una app en lugar de escribirla, vale la pena entender cuatro consecuencias.

• Los techos de rendimiento se movieron. Interfaces que antes necesitaban código nativo para sentirse bien, listas pesadas, animaciones guiadas por gestos, actualizaciones en tiempo real, ahora están al alcance de equipos centrados en JavaScript. La afirmación es cualitativa y no le pondremos un número; el efecto práctico son menos conversaciones de “tenemos que bajar a nativo para esta pantalla”.
• React concurrente funciona en móvil. Funciones como las transiciones y la carga guiada por Suspense, que mejoraron las apps web en los últimos años, dependen de Fabric. En la vieja arquitectura estaban parcial o totalmente fuera de alcance.
• Quedarse atrás ahora tiene una curva de costo. Las versiones nuevas, las librerías nuevas y los SDK nuevos de Expo asumen la Nueva Arquitectura. Una app congelada en la vieja pierde gradualmente acceso a actualizaciones, y cuanto más espera, más cambios se acumulan en la migración final. Es la misma dinámica que lleva apps a nuestra lista de software al final de su vida.
• Expo pasó a ser el valor por defecto, no el atajo. El equipo de React Native recomienda Expo como framework para apps nuevas, y las herramientas de Expo manejan la mayor parte de la configuración nativa que antes hacía dolorosas las actualizaciones. Una app que empezó “bare” en 2021 suele valer la pena moverla a la generación nativa gestionada de Expo como parte de esta migración y no después.

La migración rara vez tiene que ver con tu JavaScript. Tiene que ver con las dependencias nativas que hay debajo, y con cuáles de ellas siguieron el ritmo.

Compatibilidad de librerías: la imagen honesta

Cada historia de migración que hemos vivido giró en torno a la lista de dependencias, así que aquí va cómo se ordena realmente el ecosistema en 2026. Existen, a grandes rasgos, tres niveles.

Nivel uno: el ecosistema central ya terminó. Navegación, manejo de gestos, animación (Reanimated, cuya versión mayor actual exige la Nueva Arquitectura sin más), las primitivas de pantallas y áreas seguras, los paquetes populares de almacenamiento y red, y todo lo que Expo incluye en su SDK. Migraron temprano y, en la mayoría de los casos, sus builds para la Nueva Arquitectura son ahora los únicos builds.

Nivel dos: paquetes mantenidos que todavía usan la capa de interoperabilidad. El framework incluye una capa de compatibilidad que permite que muchos módulos nativos y view managers heredados corran bajo la Nueva Arquitectura sin cambios. Funciona lo bastante bien como para que muchos paquetes simplemente nunca se reescribieran. El riesgo no es que se rompan hoy; es que la capa de interoperabilidad es una herramienta de transición, y un paquete que todavía depende de ella en 2026 tiene un mantenedor que quizá no esté para la siguiente transición.

Nivel tres: módulos nativos abandonados. El envoltorio que alguien escribió en 2019 alrededor de un SDK de pagos, un lector de códigos de barras, un periférico Bluetooth, el kit de analítica de un proveedor. Estos son los módulos que bloquean migraciones. Suelen tener pocos archivos nativos, ninguna prueba y un último commit más viejo que la propia Nueva Arquitectura. Cada uno necesita una de tres resoluciones: un reemplazo mantenido, un fork que ahora es tuyo, o una reescritura como Turbo Module.

La herramienta práctica para clasificar tus propias dependencias en esos niveles es el React Native Directory de la comunidad, que registra el soporte de la Nueva Arquitectura por paquete, combinado con leer el repositorio de cada paquete en lugar de su README. Una insignia verde y un último commit de hace dos años cuentan historias distintas.

Lista de verificación para migrar

Esta es la secuencia que corremos. Está deliberadamente cargada al frente con investigación, porque la parte barata de una migración es el código y la parte cara es descubrir sorpresas tarde.

1. Inventaría las dependencias nativas. Lista cada paquete que contenga código de iOS o Android, no cada paquete a secas. Registra su estado respecto a la Nueva Arquitectura, su última publicación y si tu app lo usa de una forma que importe.
2. Actualiza primero a un React Native o SDK de Expo actual, todavía con tu configuración existente si la versión lo permite. Separar “actualizar el framework” de “cambiar la arquitectura” reduce a la mitad el espacio de búsqueda cuando algo se rompe.
3. Activa la Nueva Arquitectura en una rama y compila para ambas plataformas. En una versión moderna es el valor por defecto, y el interruptor del modo heredado, donde todavía exista, es lo que estás eliminando. Espera que el primer build falle; los fallos son tu lista de trabajo.
4. Resuelve los módulos de nivel tres uno por uno. Prefiere reemplazar antes que hacer fork; prefiere el fork antes que reescribir; reescribe solo cuando el módulo es central para el producto y no existe nada más.
5. Corre la app en dispositivos reales, incluido un teléfono Android de gama media con algunos años, y recorre cada pantalla. La capa de interoperabilidad esconde algunos problemas hasta que se monta una vista concreta.
6. Vigila las suposiciones de layout síncrono. El código que medía una vista y esperaba la respuesta en el siguiente tick, o que usaba atajos al estilo de setNativeProps, a menudo se comporta distinto bajo Fabric. Esos son los errores sutiles; los ruidosos aparecen al compilar.
7. Publícalo como su propia versión con un despliegue escalonado. Una migración empaquetada dentro de un sprint de funciones no tiene marcha atrás limpia.
8. Borra los interruptores heredados después, para que nadie reactive la vieja ruta seis meses más tarde para arreglar un error y deje la app varada ahí.

Escribir un Turbo Module cuando no queda otra

Cuando una reescritura es inevitable, la buena noticia es que la Nueva Arquitectura hizo los módulos nativos más agradables de escribir, no menos. Un módulo parte de una especificación tipada, y Codegen produce el andamiaje en ambas plataformas. La especificación es TypeScript común:

// specs/NativeReceiptScanner.ts
import type { TurboModule } from "react-native";
import { TurboModuleRegistry } from "react-native";

export interface Spec extends TurboModule {
  scan(imagePath: string): Promise<{ total: number; vendor: string }>;
  isAvailable(): boolean;      // síncrono: solo es posible gracias a JSI
}

export default TurboModuleRegistry.getEnforcing<Spec>("ReceiptScanner");

A partir de ese archivo, Codegen genera las interfaces que tu implementación en Swift o Kotlin debe cumplir, y un desajuste entre la firma de JavaScript y la nativa rompe el build. El método síncrono es la parte que antes era imposible: bajo el viejo puente, cada llamada era una promesa. Reescribir un módulo pequeño abandonado suele ser un trabajo acotado una vez acordada la especificación; el esfuerzo escala con el SDK nativo que envuelve, no con React Native en sí.

Lo que no arregla

La Nueva Arquitectura no hace rápida a una app mal construida. Volver a renderizar el árbol completo con cada tecla, traer una lista de mil elementos y filtrarla en JavaScript, enviar imágenes sin optimizar o depender de una API parlanchina se sentirá exactamente igual de lento que antes, porque el cuello de botella nunca fue el puente. Tampoco cambia el compromiso fundamental entre React Native y su principal alternativa: React Native sigue renderizando vistas reales de la plataforma y heredando su comportamiento, y Flutter sigue dibujando las suyas. Si estás eligiendo entre los dos para un producto nuevo, la comparación que importa está en nuestra guía Flutter frente a React Native, y el caso de Flutter en sus propios términos está en Flutter en 2026.

Decidir qué hacer con una app existente

Una consideración más para los dueños: la migración es un momento natural para hacer una auditoría de software más amplia. Ya vas a estar leyendo cada dependencia nativa, cada configuración de build y cada atajo; capturar al mismo tiempo hallazgos de seguridad, cumplimiento con las tiendas y mantenibilidad cuesta poco extra y ahorra una segunda pasada.

La conclusión

La Nueva Arquitectura es una mejora genuina, no cambio por cambiar. Interfaces más fluidas, arranque más rápido, React concurrente, fronteras nativas tipadas y una plataforma cuyo ecosistema entero se movió con ella. Las apps nuevas la reciben gratis. Las apps existentes deberían planear una migración deliberada guiada por un inventario de dependencias, resolver los módulos nativos abandonados con los ojos abiertos y publicar el cambio por separado. Si quieres ayuda para dimensionar ese trabajo, o un socio para construir una app nueva sobre el stack moderno, mira cómo abordamos el desarrollo de apps móviles, explora nuestro trabajo móvil o escríbenos.