React Native 0.87 convierte la API TypeScript estricta en la predeterminada. Este es el orden de actualización.

React Native 0.87 se lanzó el 11 de agosto y es la versión más disruptiva del framework en mucho tiempo. El titular es que la API TypeScript estricta, que llegó como vista previa opcional en la 0.80, es ahora la opción predeterminada para todos los proyectos. Además: soporte experimental de Swift Package Manager en iOS, compatibilidad de primera clase con Android Gradle Plugin 9 y un mayor requisito de cadena de herramientas. Node.js 22.13+, Kotlin 2.0+ con 2.2 incluido y compileSdk elevado a 37.

Si su aplicación aún está en una versión anterior, esto no es una actualización rutinaria. El equipo de React Native lo describe como el mayor paso hacia la versión 1.0 en mucho tiempo, y la lista de eliminaciones lo respalda.

Qué cambia realmente la API estricta

Hasta ahora, los tipos TypeScript de React Native se mantenían manualmente de forma separada al código fuente, por lo que divergían. Los tipos prometían cosas que el código no hacía, y las rutas de archivos internos se filtraban como si fueran públicas. La API estricta soluciona esto generando los tipos directamente desde el código fuente y limitando el contrato público a lo que react-native exporta en su raíz.

La consecuencia práctica: las importaciones profundas como react-native/Libraries/... son ahora errores de tipo. Si alguna vez ha accedido a una ruta interna para obtener algo que no se exportaba oficialmente, ese código dejará de pasar la verificación de tipos. Los tipos de referencia también cambian. Los componentes integrados ahora se tipan como funciones, no como clases, por lo que useRef<View>() ya no funciona. Cada componente obtiene un tipo de instancia dedicado, como ViewInstance y TextInputInstance.

Existe una válvula de escape temporal. Puede volver a los tipos manuales antiguos con customConditions: ["react-native-legacy-deep-imports"] en su tsconfig.json. Trátelo como margen de tiempo, no como destino. El equipo ha indicado que esta opción de reversión desaparecerá en una versión futura, por lo que la migración llegará tanto si la hace ahora como si la hace más tarde.

Un detalle que le ahorrará una tarde horrible: la API estricta solo afecta al análisis TypeScript de su propio proyecto, delimitado por su tsconfig.json, y depende de que skipLibCheck esté activado. La configuración TypeScript de React Native lo activa por defecto. Si desactivó skipLibCheck, vuelva a activarlo antes de empezar, o se ahogará en errores provenientes de archivos .d.ts de terceros que no puede corregir.

Las eliminaciones que afectan a las aplicaciones maduras

La API estricta acapara los titulares, pero las eliminaciones silenciosas son las que rompen las bases de código más antiguas. Algunas que buscaríamos con grep primero:

• InteractionManager ha desaparecido. Mueva el trabajo diferido a requestIdleCallback.
• TurboModules siempre está activado. El indicador de funciones useTurboModules se ha eliminado, por lo que si aún lo estaba alternando, ese código tiene que desaparecer.
• useColorScheme() devuelve ColorSchemeName | null y ya no devuelve 'unspecified'. Cualquier rama que maneje esa cadena ahora está inactiva.
• Las props obsoletas de StatusBar (backgroundColor, translucent) y sus setters se han eliminado, junto con la prop animated de Modal y el soporte booleano para keyboardShouldPersistTaps de ScrollView.

Ninguna es difícil por sí sola. El problema es encontrarlas todas en una aplicación grande antes de que aparezcan en tiempo de ejecución o en una ejecución fallida de CI.

SwiftPM y AGP 9: reales, pero no urgentes

Los cambios en el lado nativo son los que más nos interesan de nuestro trabajo en móviles. El soporte de Swift Package Manager significa que finalmente puede compilar un proyecto iOS sin Ruby, Bundler ni CocoaPods en el proceso. Es experimental y opcional, CocoaPods sigue siendo la ruta predeterminada y compatible, y consume los mismos XCFrameworks precompilados que React Native ya incluye. En nuestros proyectos nativos iOS, la cadena de herramientas de CocoaPods ha sido una fuente habitual de fallos de CI del tipo «funciona en mi máquina», por lo que una ruta que sea solo Xcode es genuinamente bienvenida. Aún no moveríamos una compilación de producción a ella, pero vale la pena probarlo en una rama para ver cómo gestiona su gráfico de dependencias.

En Android, la 0.87 es la primera versión que admite AGP 9. La recomendación del propio equipo es reveladora: desactive por ahora el Kotlin integrado y el nuevo DSL de AGP 9 configurando android.builtInKotlin=false y android.newDsl=false en gradle.properties. Esas opciones de desactivación están previstas para desaparecer en torno a AGP 10. En otras palabras, Google y el equipo de React Native aún están estabilizando esto, y la ruta oficial es deliberadamente conservadora. De nuestro trabajo con Kotlin y Jetpack Compose hemos aprendido a respetar ese tipo de orientación. Adoptar un plugin de Gradle mayor la semana en que se lanza, con las opciones predeterminadas que los propios mantenedores le dicen que deshabilite, es la forma de perder un sprint por errores de compilación.

El orden de actualización que usaríamos

Esta es la secuencia que seguiríamos para una aplicación real, empezando por el menor riesgo:

1. Actualice su cadena de herramientas antes de tocar React Native. Pase a Node.js 22.13+, Kotlin 2.0+ y compileSdk 37 como pasos separados y verificables. Si algo falla aquí, quiere saber que fue la cadena de herramientas, no el framework.
2. Actualice a la 0.87 con la opción de retroceso a los tipos heredados aún activada. Esto aísla las eliminaciones en tiempo de ejecución —los cambios de InteractionManager y StatusBar— de la migración de tipos, para que depure una cosa a la vez.
3. Active la API estricta al final. Elimine la opción de retroceso, ejecute tsc y trabaje los errores de importación profunda y tipo de referencia en un pase dedicado. Este es el cambio que más probablemente toque código compartido y bibliotecas de terceros, así que dele su propio PR.

La parte accionable que puede hacer hoy, antes de cualquier actualización: ejecute una búsqueda en todo el proyecto de react-native/Libraries/ y cada importación profunda en los internos de React Native. Ese único grep le indica cuánto trabajo de API estricta le espera realmente. Si el recuento es cero, esta actualización es principalmente mecánica. Si son cientos, tiene una conversación de planificación, no un cambio de un viernes por la tarde.

Hay una lección más amplia aquí que vemos tanto en la web como en móviles. Cuando construimos aplicaciones cloud-native para clientes empresariales, los frameworks que sobreviven son los que eventualmente trazan un límite claro alrededor de su API pública y lo cumplen. React Native se fue a la deriva durante años porque los tipos y el código fuente eran dos cosas diferentes mantenidas manualmente. Esta versión es la corrección. Duele una vez, y luego las refactorizaciones internas dejan de ser sus cambios disruptivos. Es un intercambio que vale la pena, y los equipos empresariales suizos con los que trabajamos —donde un cambio disruptivo inesperado puede detener la aprobación de cumplimiento— preferirán una API predecible a una conveniente en todo momento. Puede ver el tipo de trabajo móvil y de desarrollo que hacemos en proyectos nativos y multiplataforma.

Si una auditoría de «cuáles de nuestras importaciones están a punto de convertirse en errores de tipo» le suena familiar, hablemos. Ayudamos a equipos a planificar actualizaciones de frameworks que no se convierten en meses de trabajo inesperado.