# React Native 0.87 y SwiftPM en 2026: Build iOS Moderno y Preguntas de Entrevista > React Native 0.87 introduce soporte experimental para Swift Package Manager, eliminando CocoaPods de los builds iOS. Esta guía cubre la configuración de SwiftPM, la API TypeScript Estricta, optimizaciones de Metro 0.87, y preguntas de entrevista para desarrolladores móviles senior. - Published: 2026-09-03 - Updated: 2026-09-03 - Author: Anthony Fillion-Maillet - Tags: react-native, ios, swiftpm, typescript, mobile-development - Reading time: 9 min --- 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. > **Configuración SwiftPM en Un Comando** > > Después de desintegrar CocoaPods, ejecute `npx react-native spm --deintegrate` una sola vez. El proyecto luego reenlaza automáticamente las dependencias nativas en cada build sin necesidad de `pod install`. ## 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. ```bash # 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. ```bash # 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: | Limitación | Impacto | |------------|--------| | Soporte de bibliotecas de la comunidad | Cada biblioteca debe incluir un archivo `Package.swift` | | Estabilidad de comandos | Los flags y el layout generado pueden cambiar en 0.88+ | | Configuración de CI | Requiere el paso `npx react-native spm` antes de los builds | | Documentación | Recursos de troubleshooting limitados disponibles | 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/`. ```objective-c // AppDelegate.m // Antes de 0.87 - include simple #import #import #import // Después de 0.87 - include con namespace #import #import #import ``` 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. ```typescript // component-refs.tsx import { useRef } from 'react'; import { View, TextInput, ViewInstance, TextInputInstance } from 'react-native'; export function FormComponent() { // Nuevos tipos de ref dedicados reemplazan RefObject genérico const containerRef = useRef(null); const inputRef = useRef(null); const focusInput = () => { // Acceso a métodos con type-safety inputRef.current?.focus(); }; return ( ); } ``` 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: ```json // tsconfig.json { "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. | Requisito | Versión | |-----------|--------| | Node.js | ≥ 22.13.0 | | Kotlin | ≥ 2.0 (bundled: 2.2.0) | | Android minCompileSdk | 34 | | Android compileSdk | 37 | | Android Gradle Plugin | 9.x | Para problemas de compatibilidad con AGP 9, agregue opt-outs en `android/gradle.properties`: ```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. | API Eliminada | Reemplazo | |---------------|-------------| | `InteractionManager` | `requestIdleCallback` | | Prop animated de `Modal` | Usar comportamiento de transición predeterminado | | Tipo `NativeMethods` | `HostInstance` | | Flag `useTurboModules` | Siempre habilitado, flag eliminado | | Export raíz `Touchable` | Extender `ViewProps` directamente | | `react-native/rn-get-polyfills` | `@react-native/js-polyfills` | Las deprecaciones adicionales que apuntan a eliminación futura incluyen `ImageBackground` (usar `View` con `Image` posicionado absolutamente), `DrawerLayoutAndroid` (usar [react-native-drawer-layout](https://github.com/react-navigation/react-navigation/tree/main/packages/drawer)), 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](/technologies/react-native/interview-questions/rn-native-modules) y [estrategias de testing](/technologies/react-native/interview-questions/rn-testing). ## Estrategia de Actualización para Proyectos React Native 0.87 El [React Native Upgrade Helper](https://react-native-community.github.io/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](/blog/react-native/react-native-new-architecture-hermes-v1-bridgeless) que cubre las características de rendimiento de Hermes V1 y el modo bridgeless. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/es/blog/react-native/react-native-087-swiftpm-ios-build-interview-questions