React Native 0.87 y SwiftPM en 2026: Build iOS Moderno y Preguntas de Entrevista

React Native 0.87, lanzado el 11 de agosto de 2026, trae soporte experimental de Swift Package Manager (SwiftPM) a los builds iOS, marcando el primer paso hacia la eliminación de CocoaPods de los proyectos React Native. Esta versión también establece la API TypeScript Estricta como predeterminada, incluye Metro 0.87 con generación de source maps 2x más rápida, y eleva los requisitos mínimos de la cadena de herramientas a Node.js 22, Kotlin 2.0 y Android compileSdk 37.

Swift Package Manager Reemplaza CocoaPods para Dependencias iOS

El soporte de SwiftPM en React Native 0.87 es opt-in y experimental. CocoaPods sigue siendo el gestor de dependencias predeterminado para aplicaciones en producción. La ruta SwiftPM consume los mismos XCFrameworks pre-construidos que React Native ya publica, por lo que no se requieren descargas binarias adicionales.

El beneficio clave: un proyecto basado en SwiftPM solo necesita Xcode. Ruby, Bundler y CocoaPods ya no son necesarios en las máquinas de los desarrolladores ni en los pipelines de CI.

# ios-swiftpm-setup.sh
# Paso 1: Navegar al directorio iOS
cd ios

# Paso 2: Desintegrar CocoaPods y generar referencias SwiftPM
npx react-native spm --deintegrate

# Paso 3: Abrir el proyecto en Xcode y compilar
open MyApp.xcworkspace

El comando spm --deintegrate inyecta referencias de paquetes Swift en el .xcodeproj existente en lugar de reemplazar el archivo del proyecto. La configuración de firma de código, las fases de build y las capabilities permanecen intactas. Para revertir el cambio, ejecute npx react-native spm deinit.

Cómo Funciona el Autolinking de SwiftPM Sin pod install

Después de la configuración inicial, los cambios de dependencias activan el relinking automático. Instale o elimine un paquete nativo con npm o yarn, luego compile. El proyecto detecta los cambios y vuelve a ejecutar el autolinking durante la fase de build de Xcode.

# dependency-workflow.sh
# Instalar una dependencia nativa
npm install react-native-reanimated

# El build activa el relinking automático
npx react-native run-ios
# No se requiere pod install

Para clones frescos y entornos de CI, ejecute npx react-native spm una vez antes del primer build. Esto genera el archivo Package.swift y resuelve las dependencias de paquetes Swift.

Limitaciones de SwiftPM y Preparación para Producción

El soporte de SwiftPM en 0.87 tiene limitaciones importantes que afectan las decisiones de adopción:

Para aplicaciones en producción, CocoaPods sigue siendo la ruta recomendada. Los equipos que evalúan SwiftPM deberían crear prototipos en una rama y probar todo su árbol de dependencias antes de comprometerse con la migración.

Cambio Importante: Imports de Headers iOS con Namespace

React Native 0.87 incluye nuevos XCFrameworks: ReactNativeHeaders.xcframework y ReactNativeDependenciesHeaders.xcframework. Los módulos nativos que usan includes de ángulo en forma simple deben agregar el prefijo de namespace React/.

// Antes de 0.87 - include simple
#import <RCTAppDelegate.h>
#import <RCTBridge.h>
#import <RCTRootView.h>

// Después de 0.87 - include con namespace
#import <React/RCTAppDelegate.h>
#import <React/RCTBridge.h>
#import <React/RCTRootView.h>

Este cambio se aplica tanto a builds de CocoaPods como de SwiftPM. Los proyectos con módulos nativos personalizados necesitan actualizar todos los imports de headers antes de actualizar.

API TypeScript Estricta: La Nueva Interfaz JavaScript Predeterminada

La API TypeScript Estricta, previamente mostrada en 0.80, se convierte en la predeterminada en 0.87. Los tipos ahora se generan directamente desde el código fuente de React Native, eliminando la deriva entre las definiciones de TypeScript y el comportamiento real en tiempo de ejecución.

import { useRef } from 'react';
import { View, TextInput, ViewInstance, TextInputInstance } from 'react-native';

export function FormComponent() {
  // Nuevos tipos de ref dedicados reemplazan RefObject<T> genérico
  const containerRef = useRef<ViewInstance>(null);
  const inputRef = useRef<TextInputInstance>(null);

  const focusInput = () => {
    // Acceso a métodos con type-safety
    inputRef.current?.focus();
  };

  return (
    <View ref={containerRef}>
      <TextInput ref={inputRef} placeholder="Email" />
    </View>
  );
}

Tres cambios de tipos importantes requieren atención durante la migración:

1. Imports profundos bloqueados: Las rutas react-native/Libraries/* ahora producen errores de tipo. Todas las exportaciones deben provenir del paquete raíz react-native.

2. Actualizaciones de tipos ref: ViewInstance y TextInputInstance reemplazan los tipos ref genéricos. Los alias de tipo *Properties se eliminan en favor de *Props.

3. Cambio en useColorScheme: Retorna ColorSchemeName | null en lugar del valor string anterior 'unspecified'.

Desactivar TypeScript Estricto Durante la Migración

Los equipos que necesitan más tiempo para migrar pueden restaurar los imports profundos legacy hasta React Native 0.88:

{
  "extends": "@react-native/typescript-config",
  "compilerOptions": {
    "customConditions": ["react-native", "react-native-legacy-deep-imports"]
  }
}

Esta vía de escape será eliminada en React Native 0.89. Los proyectos deben priorizar la migración antes de esa versión.

Metro 0.87: Source Maps 2x Más Rápidos y 50% Menos Memoria

La versión 0.87 del bundler Metro incluye mejoras de rendimiento significativas que afectan el flujo de trabajo de desarrollo y el tiempo de inicio de React Native DevTools.

La generación de source maps es 2x más rápida debido al manejo optimizado de strings. DevTools ahora carga más rápido porque los source maps se generan más eficientemente durante los builds de desarrollo.

El uso de memoria disminuye 50% a través de un almacenamiento más eficiente de source maps. Esto importa para bases de código grandes donde Metro anteriormente consumía RAM significativa durante sesiones de desarrollo prolongadas.

Cambios adicionales de Metro:

• Soporte estable para archivos de configuración TypeScript (metro.config.mts)
• Soporte de archivos de config ESM junto con CommonJS
• Auto-resolución de paquetes en el resolver
• Eliminación del soporte para extensiones de archivo .es6 y archivos de configuración YAML

Requisitos Mínimos de la Cadena de Herramientas para React Native 0.87

Esta versión eleva los requisitos de versión mínima en toda la cadena de herramientas. Los pipelines de CI y los entornos de desarrolladores necesitan actualizaciones antes de actualizar.

Para problemas de compatibilidad con AGP 9, agregue opt-outs en android/gradle.properties:

# android/gradle.properties
# Opt-outs temporales para la migración de AGP 9
android.builtInKotlin=false
android.newDsl=false

APIs Eliminadas en React Native 0.87

Varias APIs deprecadas se eliminan en esta versión. Los proyectos que usan estas APIs necesitan refactorización antes de actualizar.

Las deprecaciones adicionales que apuntan a eliminación futura incluyen ImageBackground (usar View con Image posicionado absolutamente), DrawerLayoutAndroid (usar react-native-drawer-layout), y react-native/Libraries/Core/InitializeCore (usar react-native/setup-env).

Preguntas de Entrevista de React Native 0.87 para Desarrolladores Senior

Estas preguntas aparecen en entrevistas de desarrolladores móviles senior después de lanzamientos importantes de React Native. Entender las decisiones arquitectónicas detrás del soporte de SwiftPM y la API TypeScript Estricta demuestra conocimiento a nivel de framework.

P: ¿Por qué React Native 0.87 introduce SwiftPM como experimental en lugar de reemplazar CocoaPods inmediatamente?

El soporte de SwiftPM depende de que las bibliotecas de la comunidad incluyan archivos Package.swift. A diferencia de CocoaPods donde existe un registro central Podspec, SwiftPM requiere que cada autor de biblioteca agregue configuración de paquete Swift nativo. La fase experimental permite que el ecosistema adopte SwiftPM gradualmente mientras CocoaPods permanece estable para apps en producción. Además, los comandos CLI y el layout de proyecto generado pueden cambiar basándose en los comentarios de los desarrolladores antes de estabilizarse.

P: ¿Qué problema resuelve la API TypeScript Estricta que las definiciones de tipos mantenidas manualmente no podían?

Las definiciones de tipos mantenidas manualmente derivan del comportamiento en tiempo de ejecución entre versiones. Los refactorings internos que cambian firmas de funciones o agregan parámetros pueden no reflejarse en los tipos inmediatamente, causando crashes en tiempo de ejecución que TypeScript debería haber capturado. La API Estricta genera tipos directamente desde el código fuente, haciendo que los tipos sean autoritativos en lugar de aspiracionales. También bloquea imports profundos que acceden a APIs internas inestables, previniendo roturas cuando esos internos cambian.

P: ¿Cómo difiere el autolinking de SwiftPM del autolinking de CocoaPods en React Native?

El autolinking de CocoaPods se ejecuta durante pod install, que los desarrolladores deben recordar ejecutar después de cambios de dependencias. El autolinking de SwiftPM se ejecuta durante la fase de build de Xcode automáticamente. El sistema de build detecta cambios de dependencias y regenera el manifiesto del paquete sin intervención manual. Esto elimina una fuente común de problemas de "funciona en mi máquina" donde los desarrolladores olvidan ejecutar pod install después de hacer pull de cambios.

Para preparación adicional de entrevistas de React Native, consulte los bancos de preguntas sobre módulos nativos en profundidad y estrategias de testing.

Estrategia de Actualización para Proyectos React Native 0.87

El React Native Upgrade Helper genera un diff entre el template de proyecto actual y 0.87. Este diff muestra exactamente qué archivos necesitan cambios.

Priorice estos pasos de migración:

1. Actualizar Node.js a 22.13.0+ y verificar que los entornos de CI coincidan
2. Ejecutar compilación TypeScript para identificar violaciones de imports profundos
3. Actualizar tipos ref de genéricos a tipos de instancia dedicados
4. Actualizar imports de headers iOS al formato con namespace
5. Probar el árbol completo de dependencias nativas antes de habilitar SwiftPM

Para proyectos Expo, React Native 0.87 está disponible en releases expo@canary. Los proyectos Expo en producción deberían esperar el lanzamiento de SDK estable.

Lo Que el Soporte SwiftPM 0.87 Significa para los Tiempos de Build iOS

SwiftPM elimina pod install del flujo de trabajo de desarrollo, pero la configuración inicial del proyecto requiere más tiempo. El comando npx react-native spm resuelve paquetes Swift desde la fuente, lo cual toma más tiempo que descargar binarios pre-construidos de CocoaPods.

Los builds subsecuentes se benefician de la resolución incremental de paquetes de Xcode. Solo los paquetes modificados se vuelven a descargar. Para equipos con cambio frecuente de dependencias, este enfoque incremental puede ser más rápido que ciclos repetidos de pod install.

La optimización de CI difiere entre los dos enfoques. CocoaPods cachea los directorios Pods/ efectivamente. SwiftPM cachea a través de los derived data de Xcode, lo cual requiere estrategias de clave de cache diferentes. Los equipos que migran pipelines de CI deberían hacer benchmark de ambos enfoques con su conjunto específico de dependencias.

Para técnicas relacionadas de optimización de build iOS, consulte la guía de Nueva Arquitectura de React Native que cubre las características de rendimiento de Hermes V1 y el modo bridgeless.