Nueva Arquitectura de React Native en 2026: Hermes V1, Modo Bridgeless y Preguntas de Entrevista

La Nueva Arquitectura de React Native alcanzó su madurez plena en 2026. Con React Native 0.84 entregando Hermes V1 como motor predeterminado y la versión 0.85 eliminando todo rastro del bridge heredado, el framework ofrece ahora rendimiento casi nativo sin que los desarrolladores tengan que preocuparse por flags de arquitectura o capas de compatibilidad.

Qué cambió en la pila arquitectónica de React Native

La arquitectura anterior de React Native dependía de un bridge JSON asíncrono de un solo hilo para transmitir mensajes entre JavaScript y el código nativo. Cada interacción pasaba por este cuello de botella: eventos táctiles, cálculos de layout, llamadas a módulos. La Nueva Arquitectura reemplaza cada capa de este pipeline con una alternativa directa y síncrona.

| Capa | Arquitectura Anterior | Nueva Arquitectura | |------|----------------------|--------------------| | Motor JS | JavaScriptCore | Hermes V1 (bytecode + JIT) | | Renderizado | Paper (bridge async) | Fabric (síncrono, C++ compartido) | | Módulos Nativos | Bridge Modules (serialización JSON) | TurboModules (JSI, llamadas directas) | | Comunicación | Bridge JSON Async | JSI (JavaScript Interface) | | Inicialización | Init bridge + registro de módulos | Bridgeless (lazy, bajo demanda) |

JSI (JavaScript Interface) es el fundamento. En lugar de serializar cada llamada a JSON y pasarla a través de una cola, JSI expone objetos host C++ directamente a JavaScript. Una llamada TurboModule que anteriormente requería codificación JSON, encolado en el bridge y decodificación JSON ahora se ejecuta como una invocación de función directa.

Hermes V1: el motor JavaScript predeterminado

Hermes V1 se convirtió en el motor predeterminado en React Native 0.84, lanzado en febrero de 2026. Representa una reescritura completa del compilador y la VM, no una simple actualización incremental sobre las versiones anteriores de Hermes.

Las mejoras abarcan cuatro áreas: un compilador reescrito con un nuevo formato de bytecode, un compilador JIT mejorado, el recolector de basura concurrente Hades y mejor soporte para los patrones JavaScript modernos utilizados por React 19.

// Comparing startup and runtime metrics

// Hermes V1 bytecode is pre-compiled at build time
// No parse-compile step at runtime = faster cold starts

// Cold start comparison (production build, Pixel 8):
// Hermes V1:  ~850ms TTI
// JSC:        ~1200ms TTI  (29% slower)

// Memory footprint (complex app, 50+ screens):
// Hermes V1:  ~45MB baseline
// JSC:        ~72MB baseline (38% more)

// GC pause comparison (FlatList, 500+ complex cells):
// Hermes V1 (Hades):  <12ms max pause
// Old Hermes:         ~45ms occasional pauses
// Result: zero dropped frames in scroll benchmarks

Hades, el recolector de basura concurrente, merece atención especial. Las versiones anteriores de Hermes utilizaban un GC con parada total (stop-the-world) que ocasionalmente causaba stuttering visible durante el desplazamiento de listas. Hades ejecuta la recolección de forma concurrente en un hilo de fondo, manteniendo las pausas del GC por debajo de los 12 ms. Para aplicaciones que renderizan listas largas con celdas complejas, esto elimina la última fuente de caídas de frames en el lado de JavaScript.

Fabric: renderizado y layout síncronos

Fabric reemplaza el motor de renderizado Paper con un núcleo C++ compartido entre iOS y Android. La diferencia fundamental: los cálculos de layout ocurren de forma síncrona en el hilo de JavaScript en lugar de hacerlo asincrónicamente a través del bridge.

Este modelo síncrono habilita dos capacidades que eran imposibles con Paper:

1. Soporte de renderizado concurrente: Fabric se integra con las características concurrentes de React 19. Las transiciones, los boundaries de Suspense y useTransition funcionan correctamente porque Fabric puede interrumpir y reanudar el renderizado.

2. Layout C++ directo: Yoga (el motor de layout) se ejecuta en el mismo espacio de memoria que el runtime de JavaScript. Sin sobrecarga de serialización para los cálculos de flexbox.

// Concurrent features work correctly with Fabric
import React, { useState, useTransition } from 'react'
import { View, Text, FlatList, TextInput, StyleSheet } from 'react-native'

type Item = { id: string; name: string; category: string }

function SearchableList({ items }: { items: Item[] }) {
  const [query, setQuery] = useState('')
  const [filtered, setFiltered] = useState(items)
  const [isPending, startTransition] = useTransition()

  const handleSearch = (text: string) => {
    setQuery(text) // Urgent: update input immediately
    startTransition(() => {
      // Non-urgent: filter can be deferred
      const result = items.filter(item =>
        item.name.toLowerCase().includes(text.toLowerCase())
      )
      setFiltered(result)
    })
  }

  return (
    <View style={styles.container}>
      <TextInput
        value={query}
        onChangeText={handleSearch}
        placeholder="Search items..."
        style={styles.input}
      />
      {isPending && <Text style={styles.pending}>Filtering...</Text>}
      <FlatList
        data={filtered}
        keyExtractor={item => item.id}
        renderItem={({ item }) => (
          <View style={styles.row}>
            <Text>{item.name}</Text>
          </View>
        )}
      />
    </View>
  )
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 16 },
  input: { borderWidth: 1, borderColor: '#ccc', padding: 12, marginBottom: 8 },
  pending: { color: '#888', marginBottom: 4 },
  row: { padding: 12, borderBottomWidth: 1, borderBottomColor: '#eee' },
})

El hook useTransition en este ejemplo demuestra por qué Fabric es fundamental. Con Paper, startTransition no tenía efecto porque el renderizador no podía interrumpir un renderizado en progreso. La integración de Fabric con el modo concurrente de React 19 permite que las actualizaciones diferidas funcionen según lo diseñado, manteniendo el campo de texto responsivo mientras filtra miles de elementos en segundo plano.

TurboModules y JSI: eliminación de la sobrecarga de serialización

Los TurboModules reemplazan el antiguo sistema NativeModules. La diferencia de rendimiento proviene de eliminar completamente la serialización JSON. Una llamada a un módulo del bridge seguía esta ruta: objeto JS -> JSON.stringify -> cola del bridge -> JSON.parse -> llamada nativa -> JSON.stringify -> cola del bridge -> JSON.parse -> callback JS. Una llamada TurboModule es una invocación directa de función C++ a través de JSI.

// TurboModule spec using the Codegen
import type { TurboModule } from 'react-native'
import { TurboModuleRegistry } from 'react-native'

export interface Spec extends TurboModule {
  // Synchronous: returns immediately, no bridge round-trip
  getDeviceModel(): string
  getOSVersion(): string
  getBatteryLevel(): number

  // Asynchronous: for operations that genuinely need async
  getStorageUsage(): Promise<{ used: number; total: number }>
}

export default TurboModuleRegistry.getEnforcing<Spec>('DeviceInfo')

// Native Android implementation of the TurboModule
package com.app.modules

import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.bridge.ReadableMap
import com.facebook.react.bridge.WritableNativeMap
import com.facebook.react.module.annotations.ReactModule

@ReactModule(name = "DeviceInfo")
class DeviceInfoModule(reactContext: ReactApplicationContext) :
  NativeDeviceInfoSpec(reactContext) {

  // Synchronous via JSI - no bridge, no JSON, no queue
  override fun getDeviceModel(): String {
    return android.os.Build.MODEL
  }

  override fun getOSVersion(): String {
    return "Android ${android.os.Build.VERSION.RELEASE}"
  }

  override fun getBatteryLevel(): Double {
    val manager = reactApplicationContext
      .getSystemService(android.content.Context.BATTERY_SERVICE)
      as android.os.BatteryManager
    return manager.getIntProperty(
      android.os.BatteryManager.BATTERY_PROPERTY_CAPACITY
    ).toDouble()
  }

  override fun getStorageUsage(
    promise: com.facebook.react.bridge.Promise
  ) {
    val stat = android.os.StatFs(
      android.os.Environment.getDataDirectory().path
    )
    val map = WritableNativeMap().apply {
      putDouble("used", (stat.totalBytes - stat.availableBytes).toDouble())
      putDouble("total", stat.totalBytes.toDouble())
    }
    promise.resolve(map)
  }

  override fun getName(): String = "DeviceInfo"
}

El detalle clave: getDeviceModel(), getOSVersion() y getBatteryLevel() son síncronos. El hilo de JavaScript llama directamente al código nativo y recibe el valor de retorno en el mismo tick. Sin promesas, sin callbacks, sin ida y vuelta por el bridge. Esto solo es posible a través de JSI.

Modo Bridgeless: qué elimina y por qué importa

El Modo Bridgeless, introducido en React Native 0.73 y convertido en predeterminado en la 0.74, completa la migración arquitectónica al eliminar por completo la inicialización del bridge. Incluso después de adoptar Fabric y TurboModules, el antiguo bridge seguía inicializándose al arranque para manejar emisores de eventos globales, timers y manejo de errores. El Modo Bridgeless migra estos sistemas restantes a implementaciones basadas en JSI.

El impacto práctico:

• Arranque más rápido: sin sobrecarga de inicialización del bridge. El runtime solo inicia lo que la aplicación realmente utiliza mediante carga diferida.
• Menor consumo de memoria: sin estructuras de datos del bridge asignadas al arranque.
• Manejo de errores más limpio: los error boundaries y los manejadores de errores globales funcionan a través de la nueva arquitectura sin fallbacks del bridge.

React Native 0.82 deshabilitó permanentemente el antiguo bridge. React Native 0.85, lanzado en abril de 2026, eliminó todo el código restante relacionado con el bridge del código fuente. No existe ruta de retorno.

Migración en producción: benchmarks de rendimiento reales

Las migraciones en producción de la arquitectura anterior a la Nueva Arquitectura muestran mejoras consistentes en las métricas clave:

| Métrica | Arquitectura Anterior | Nueva Arquitectura | Mejora | |---------|----------------------|--------------------|---------| | Arranque en frío (TTI) | 1,4s | 0,8s | 43% más rápido | | Transición de pantalla | 180ms | 110ms | 39% más rápido | | Memoria base | 89MB | 66MB | 26% menor | | Llamada JS-a-nativo | ~5ms (async) | ~0,1ms (sync) | 40x más rápido | | Pausa GC máxima | 45ms | 12ms | 73% más corta | | Scroll FlatList (1000 elementos) | Stuttering ocasional | 60fps fluido | Sin frames perdidos |

La mejora más significativa para la calidad percibida por el usuario es la reducción de pausas del GC. Hades mantiene las pausas de recolección por debajo del presupuesto de un frame (16,6 ms a 60 fps), eliminando la fuente más común de stuttering visible en aplicaciones React Native complejas.

Compatibilidad del ecosistema en 2026

El ecosistema ha convergido completamente hacia la Nueva Arquitectura. Expo SDK 55 y versiones posteriores funcionan exclusivamente con la Nueva Arquitectura, sin opción para desactivarla. Puntos clave de compatibilidad:

• React Navigation 7.2+: soporte completo de Fabric con pantallas native-stack
• Reanimated 3.5+: backend de animación compartido con React Native 0.85
• Gesture Handler 2.16+: reconocimiento de gestos directo basado en JSI
• Vision Camera 4.0+: procesamiento de frames a través de JSI
• Detox: testing E2E compatible con la Nueva Arquitectura

Para equipos que usan Expo, npx create-expo-app genera un proyecto con la Nueva Arquitectura habilitada por defecto. Sin configuración necesaria.

Preguntas de entrevista: Nueva Arquitectura de React Native

Estas preguntas aparecen frecuentemente en entrevistas de React Native de nivel senior en 2026. Cada respuesta cubre la profundidad esperada a nivel staff/senior.

P1: Explicar la diferencia entre el antiguo Bridge y JSI. ¿Por qué JSI permite llamadas nativas síncronas?

El bridge serializaba cada mensaje JS-a-nativo como JSON, lo empujaba a una cola asíncrona y lo deserializaba en el lado nativo. JSI (JavaScript Interface) expone objetos host C++ directamente en la VM de JavaScript. Las funciones nativas registradas a través de JSI aparecen como funciones JavaScript ordinarias que ejecutan código nativo en línea, sin serialización ni encolamiento. Las llamadas síncronas son posibles porque JSI opera en el mismo contexto de hilo sin una cola de mensajes intermedia.

P2: ¿Qué problema resuelve el renderizador Fabric que Paper no podía resolver?

Paper renderizaba asincrónicamente a través del bridge, haciendo imposible el soporte de las características concurrentes de React. Una llamada a startTransition no tenía efecto porque Paper no podía interrumpir un árbol de renderizado en progreso. Fabric implementa el renderizado en código C++ compartido, se integra directamente con el reconciliador de React 19 y soporta renderizado concurrente, Suspense y transiciones. Los cálculos de layout a través de Yoga también ocurren sincrónicamente en el mismo espacio de memoria, eliminando la latencia del bridge.

P3: ¿Por qué se requiere Hermes para la Nueva Arquitectura? ¿Podría usarse otro motor?

La Nueva Arquitectura depende de JSI, que requiere que el motor JavaScript soporte el registro de objetos host C++. Hermes fue diseñado desde cero con integración JSI. JavaScriptCore podría teóricamente soportar JSI, pero la implementación oficial y las pruebas están construidas alrededor de Hermes. Hermes V1 proporciona además precompilación a bytecode (eliminando el parsing en runtime), el GC concurrente Hades (pausas menores a 12 ms) y soporte WebAssembly, ninguna de las cuales está disponible a través de la integración JSC de React Native.

P4: ¿En qué se diferencian los TurboModules de la antigua API NativeModules desde la perspectiva del desarrollador?

Los TurboModules requieren una especificación Codegen (una interfaz TypeScript que extiende TurboModule) que genera bindings nativos con tipado seguro en tiempo de build. El antiguo NativeModules usaba reflexión en runtime sin verificación de tipos. Los TurboModules soportan valores de retorno síncronos (no solo promesas), inicialización diferida (los módulos se cargan solo al primer acceso) y llamadas JSI directas sin serialización JSON. El desarrollador escribe una especificación TypeScript, ejecuta Codegen e implementa la interfaz nativa generada.

P5: Describir el Modo Bridgeless y qué elimina en comparación con usar solo Fabric y TurboModules.

Incluso después de adoptar Fabric y TurboModules, el antiguo bridge seguía inicializándose al arranque para manejar emisores de eventos globales, timers, manejo de errores y otra infraestructura de runtime. El Modo Bridgeless reemplaza estos sistemas residuales dependientes del bridge con implementaciones basadas en JSI. Elimina la sobrecarga de inicialización del bridge, reduce el consumo de memoria base y garantiza que todo el runtime opere a través de JSI. Desde React Native 0.85, el Modo Bridgeless es el único modo operativo.

Practicar estas preguntas con ejemplos de código funcionales fortalece tanto la comprensión conceptual como la memoria práctica. El módulo Nueva Arquitectura de React Native de SharpSkill cubre más de 40 preguntas adicionales sobre Fabric, TurboModules, internos de Hermes y estrategias de migración.

Conclusión

• Hermes V1 ofrece arranques en frío un 29% más rápidos, un 38% menos de uso de memoria y pausas de GC inferiores a 12 ms desde React Native 0.84+
• Fabric habilita las características concurrentes de React 19 (transiciones, Suspense) que Paper nunca pudo soportar
• Los TurboModules eliminan la serialización JSON, haciendo las llamadas JS-a-nativo 40x más rápidas mediante invocación directa por JSI
• El Modo Bridgeless elimina las últimas dependencias del bridge; React Native 0.85 no contiene código bridge restante
• El ecosistema es completamente compatible: Expo SDK 55+, React Navigation 7.2+, Reanimated 3.5+ y todas las bibliotecas principales soportan exclusivamente la Nueva Arquitectura
• La preparación para entrevistas debe enfocarse en la mecánica de JSI, las diferencias entre Fabric y Paper, el flujo de trabajo Codegen de TurboModules y los cambios de runtime del Modo Bridgeless