Planificación de la actualización a Expo SDK 58: iOS 27, React Native 0.88 y nuevas herramientas
Un recorrido práctico por la versión beta del Expo SDK 58: qué cambios hay en iOS 27 y React Native 0.88, qué funciones son experimentales, y cómo probar la actualización de forma segura.
Fuentes: Expo SDK 58 Beta: What React Native Developers Actually Need to Know
El Expo SDK 58 no se define por una sola característica destacada. En su lugar, llega de golpe una larga lista de cambios: soporte para iOS 27, React Native 0.88, compilaciones más rápidas en Android, llamadas a módulos nativos más económicas, widgets para la pantalla principal de Android, integración con Siri a través de App Intents, una CLI orientada a la creación de agentes de programación, un Expo Router más maduro y un transformador experimental basado en Rust para Metro. Esta guía ordena esa lista según su impacto práctico, para que pueda saber qué cambios afectarán su código, cuáles son gratuitos, cuáles siguen siendo experimentales y cómo realizar la actualización sin dañar una aplicación en producción.
Trate el SDK 58 como beta, porque lo es
En el momento de escribir esto, el SDK 58 se encuentra en fase beta, y Expo espera que esta etapa dure aproximadamente de tres a cuatro semanas. Consulte el registro de cambios de Expo para conocer el estado actual antes de planificar cualquier cosa en torno a una fecha de lanzamiento.
Un período de beta es la ventana ideal para probar: el código de tu aplicación, las bibliotecas de terceros, los módulos nativos personalizados, el pipeline de compilación y cualquier código nativo escrito a mano. Es un mal momento para actualizar el SDK en una aplicación en producción justo antes de un fin de semana. Sin embargo, para proyectos paralelos y herramientas internas, la versión beta es una forma de bajo riesgo para ver qué está por venir y detectar problemas temprano, mientras aún hay tiempo para solucionarlos en la fuente.
iOS 27 y el ciclo de vida basado en escenas
Una gran parte de la motivación detrás del SDK 58 es iOS 27. Las aplicaciones compiladas con el SDK de iOS 27 utilizan el ciclo de vida basado en escenas de Apple, y Expo ha reestructurado su infraestructura nativa en torno a ese modelo.
Un poco de contexto ayuda aquí. En el modelo anterior, UIApplicationDelegate gestionaba toda la aplicación: una ventana y un conjunto de callbacks de inicio y en primer plano. El modelo de escenas divide esas responsabilidades, de modo que cada instancia de interfaz (una escena) tiene su propio ciclo de vida, gestionado por un delegado de escena. Las tareas que antes estaban en el delegado de la aplicación, como reaccionar a que esta se active o manejar URLs entrantes, pueden trasladarse a los callbacks a nivel de escena.
En un proyecto típico de Expo, esta transición debería ser invisible. Esto es importante cuando se ha personalizado el lado nativo. Un ejemplo común es la configuración adicional dentro del callback de inicio del delegado de la aplicación, como el método en Swift que se muestra a continuación (sin resaltado sintáctico):
func application(
_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions:
[UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
// Custom initialization
return true
}
Si su AppDelegate.swift contiene una lógica personalizada significativa, parte de ella podría pertenecer ahora al manejo de escenas en lugar de a una única ventana global de la aplicación. Expo recomienda consultar sus guías sobre migración del ciclo de vida de las escenas si modifica el delegado de la aplicación nativa.
Proyectos que requieren una atención más detallada
Muchas aplicaciones de Expo nunca ejecutan AppDelegate.swift, y en su caso la migración debería realizarse sin problemas. Sin embargo, las aplicaciones más grandes tienden a acumular código nativo con el paso de los años, y ahí radica el riesgo. Revise cuidadosamente si su proyecto para iOS cuenta con configuración nativa para alguno de los siguientes elementos:
- inicialización del SDK de análisis
- manejo de enlaces profundos y universales
- SDKs de autenticación
- notificaciones push
- SDKs nativos de pagos
Cada uno de estos se conecta típicamente a las funciones de callback al iniciar la aplicación o mediante URL, que son exactamente las callbacks afectadas por el modelo de escenas. Pruebe esos flujos de manera explícita en lugar de asumir que una compilación exitosa implica que la aplicación funcione.
React Native 0.88 y la API estricta de TypeScript
La versión beta del SDK 58 se incluye con la versión candidata a lanzamiento de React Native 0.88. Por lo tanto, actualizar Expo implica asimilar todo lo que cambió en React Native 0.87 y 0.88, no solo en una sola versión.
El cambio con el que probablemente se encontrará primero es la API estricta de TypeScript, que restringe qué se considera parte de la API pública de React Native. Las importaciones que acceden a archivos internos son las principales afectadas:
import Something from 'react-native/Libraries/...';
Las aplicaciones y bibliotecas han utilizado importaciones profundas de esta manera durante años, generalmente porque el punto de entrada público no ofrecía lo que necesitaban. Siempre funcionó por casualidad: las rutas de archivos internos pueden cambiar o modificarse en cualquier versión sin previo aviso. React Native ahora establece una línea clara entre módulos públicos y privados, y un código base lleno de importaciones profundas debería considerar la versión 58 del SDK como una señal para eliminarlas. Si alguna biblioteca en su árbol de dependencias hace esto, verifique si ya existe una versión más reciente que lo haya corregido.
APIs eliminadas como InteractionManager
También han desaparecido algunas API antiguas, y InteractionManager es una de las que hay que buscar. El código que pospone tareas intensivas hasta que se completan las animaciones e interacciones suele verse así:
InteractionManager.runAfterInteractions(() => {
loadHeavyContent();
});
El reemplazo recomendado es la API estándar de callback en estado inactivo:
requestIdleCallback(() => {
loadHeavyContent();
});
La semántica es similar pero no idéntica. InteractionManager esperaba a que terminaran las interacciones registradas, mientras que requestIdleCallback ejecuta la función de callback cuando el hilo de JavaScript está inactivo. En la mayoría de los casos en los que se desea “cargar esto después de que aparezca la pantalla”, la diferencia es irrelevante, pero si dependes de ello para esperar a que termine una animación específica, verifica su comportamiento en un dispositivo real.
En una aplicación pequeña, esta migración suele ser rápida. En una aplicación antigua con muchas dependencias, realiza la actualización en una rama dedicada y deja que el compilador de TypeScript enumere todos los problemas antes de tocar cualquier otra cosa. Los errores del compilador se convertirán en tu lista de verificación para la migración.
Compilaciones más rápidas en Android
expo-modules-core ahora incluye bibliotecas nativas precompiladas para Android. Anteriormente, una compilación limpia de Android dedicaba una parte considerable de su tiempo a compilar el código C++ del cual dependen los módulos de Expo. El SDK 58 omite casi por completo ese paso.
Según las mediciones propias de Expo, al utilizar una aplicación vacía con SDK 58 en una máquina Apple M3 Pro, el tiempo necesario para realizar una compilación de depuración limpia en Android disminuyó de unos 80 segundos a aproximadamente 39 segundos. Sus resultados podrán variar según el tamaño del proyecto y el hardware, pero el ahorro se debe a que se evita por completo esa tarea, por lo que debería notarse en cualquier proyecto que utilice módulos de Expo.
La ventaja se multiplica en CI. Un equipo que abre veinte solicitudes de pull request al día, cada una de las cuales activa la compilación de Android, paga ese costo de compilación en cada ejecución, y las máquinas de CI suelen comenzar con cachés vacíos. Ahorrar medio minuto una sola vez no es algo notable. Pero ahorrarlo en cada compilación local, en cada tarea de CI, en cada rama funcional y en cada compilación de lanzamiento suma un tiempo real y costos reales de procesamiento. La velocidad de compilación también es una forma de rendimiento, solo que se mide en minutos de desarrollo en lugar de en tasas de fotogramas.
Llamadas más económicas entre JavaScript y código nativo
El trabajo de mejora del rendimiento en SDK 58 no se limita a las compilaciones. Expo también ha reducido el costo de llamar a módulos nativos, con la mayor parte de las mejoras en iOS. La transferencia de cadenas largas es significativamente más rápida, y las promesas devueltas por funciones nativas asíncronas generan menos sobrecarga.
No es necesario cambiar nada para beneficiarse: los módulos Expo existentes incorporan estas mejoras una vez que realice la actualización.
Esto es especialmente importante para las aplicaciones que cruzan con frecuencia la frontera entre JavaScript y código nativo. Considere una llamada como esta:
const result = await SomeNativeModule.processLargePayload(data);
La función nativa puede realizar su trabajo rápidamente, pero cada invocación sigue requiriendo esfuerzo para convertir los argumentos a tipos nativos y devolverlos como valores de JavaScript. Si una aplicación realiza tales llamadas miles de veces, por ejemplo al procesar un flujo de datos de sensores o sincronizar grandes volúmenes de información, reducir un poco ese esfuerzo en cada cruce genera una diferencia significativa.
Expo Modules 2.0: clases nativas en lugar de un DSL
Para los equipos que desarrollan sus propios módulos nativos, Expo Modules 2.0 representa uno de los cambios más importantes. En el momento de escribir esto, se encuentra en versión beta tanto para iOS como para Android.
La API actual de Expo Modules describe un módulo a través de un DSL: un bloque de definición donde se declaran funciones, propiedades y eventos. Expo Modules 2.0 adopta un enfoque más convencional. Se escribe una clase común de Swift o Kotlin y se anotan los miembros que deben exponerse a JavaScript.
El efecto práctico es que su código nativo se lee como código nativo. Swift sigue pareciendo Swift y Kotlin sigue pareciéndose a Kotlin, sin necesidad de aprender primero una capa específica del framework. Esto reduce la barrera para los desarrolladores que conocen la plataforma pero no Expo, y también ayuda a las herramientas de programación con IA, ya que cuentan con mucho más código común de Swift y Kotlin en sus datos de entrenamiento que código en DSL de Expo.
También existe el aspecto relacionado con el rendimiento. Los enlaces pueden generarse en tiempo de compilación en lugar de resolverse dinámicamente en tiempo de ejecución, y las pruebas de rendimiento de Expo muestran grandes mejoras en varios micropruebas. Los micropruebas aíslan una sola operación, por lo que rara vez se traducen de forma uno a uno en aceleraciones a nivel de aplicación; no constituyen un motivo por sí solos para rediseñar la arquitectura nativa. Si desea conocer más detalles sobre por qué los enlaces estáticos son más rápidos, la comparación en Nitro Modules: cómo los enlaces estáticos superan a React Native TurboModules aborda el mismo principio. Lo que destaca de Expo Modules 2.0 es que hace que los módulos sean al mismo tiempo más sencillos de escribir y más rápidos, lo cual es una combinación poco común.
Widgets de la pantalla principal en Android
expo-widgets ahora es compatible con Android, lo que abre nuevas posibilidades para crear productos en todo tipo de aplicaciones: registradores de hábitos, herramientas financieras, aplicaciones de entrega, apps de fitness, gestores de tareas y calendarios.
Una app de hábitos podría mostrar el progreso del día sin que sea necesario abrirla. Una app financiera podría mostrar un breve resumen del presupuesto, con un encabezado similar a este:
Monthly Budget
y un desglose de la cantidad restante por categoría debajo:
₹34,500 remainingFood ₹8,200
Travel ₹3,400
Shopping ₹5,100
Un gestor de tareas podría mostrar las tres tareas más importantes del día directamente en la pantalla principal.
En Android, cada widget ejecuta su propio paquete de JavaScript en un entorno de ejecución Hermes dedicado, admite interacciones del usuario y puede utilizar los colores de Material para integrarse con el tema del sistema. Vale la pena entender este entorno de ejecución separado: el widget no comparte memoria ni estado con la aplicación en ejecución, por lo que los datos deben serle pasados de forma explícita en lugar de leerse desde la tienda de aplicaciones del dispositivo. Para los equipos multiplataforma, contar con widgets en ambas plataformas dentro del ecosistema Expo elimina otra razón para mantener implementaciones nativas separadas.
App Intents: Siri, Shortcuts y Spotlight
expo-app-intents conecta las aplicaciones Expo con el sistema App Intents de Apple, que es el mecanismo detrás de varias interfaces del sistema:
- Siri
- Shortcuts
- Spotlight
- Apple Intelligence
Imagínese un administrador de tareas. Normalmente, completar una tarea implica abrir la aplicación, encontrar el elemento correspondiente y tocarlo. Con una intención expuesta, el usuario puede simplemente preguntarle a Siri:
"Completa los documentos con ID de carga."
Siri resuelve la tarea correspondiente e invoca la acción que su aplicación ha declarado. Su código JavaScript recibe esa llamada y actualiza los datos de la aplicación. En el ejemplo de Expo, esto ocurre sin llevar la aplicación al primer plano.
La implicación más amplia es un cambio en la forma en que se estructura una aplicación móvil. El ícono de la aplicación deja de ser el único punto de entrada. Algunas acciones parten de Siri, otras de un widget, algunas de la búsqueda de Spotlight y otras de las automatizaciones Shortcuts del usuario. La aplicación se convierte en un conjunto de capacidades que el sistema operativo puede exponer donde sea útil, y eso merece ser tenido en cuenta al diseñar funciones.
Una advertencia importante: expo-app-intents se encuentra en versión alfa en el momento de escribir esto. Pruébelo, pero no implemente flujos de trabajo críticos para el negocio con él aún.
Expo UI se acerca más a SwiftUI y Jetpack Compose
Expo UI sigue profundizando su integración con SwiftUI y Jetpack Compose. El SDK 58 añade primitivas de navegación de SwiftUI para iOS:
NavigationStack
NavigationLink
NavigationDestination
Toolbar
Estas se corresponden con los propios componentes de navegación de SwiftUI, por lo que se obtiene una navegación nativa mediante pila y barras de herramientas en lugar de una recreación en JavaScript. La versión también incluye más componentes de Jetpack Compose y perfecciona los componentes universales existentes que funcionan en todas las plataformas.
Una mejora menor, pero sorprendentemente útil: ahora cada componente en la documentación de Expo UI viene acompañado de un ejemplo visual. Sin capturas de pantalla, elegir un componente de interfaz suele seguir un ciclo frustrante:
- Encuentre un componente cuyo sonido le parezca adecuado.
- Lea sus propiedades.
- Conéctelo a una pantalla.
- Ejecute la aplicación.
- Descubra que no se parece en nada a lo que imaginaba.
- Comience de nuevo con un componente diferente.
Ver el componente renderizado junto a su API acorta ese ciclo.
Device Hub y control del simulador basado en navegador
Xcode 27 reemplaza Simulator.app por Device Hub, y Expo CLI comprende el nuevo flujo de trabajo. Además, Expo está probando un paquete separado, expo-device-hub, que proporciona un panel de control local en el navegador para sus simuladores y emuladores.
Desde ese panel puede ver:
- un reflejo en tiempo real de la pantalla del dispositivo
- el consumo de CPU y memoria
- el tráfico de red
- opciones de apariencia como modo claro y oscuro
- opciones de accesibilidad
También puede tocar, deslizar y escribir en el dispositivo desde el navegador. Para probarlo, instale el paquete e inicie el servidor de desarrollo:
npx expo install expo-device-hub
npx expo start
Si su día consiste en alternar constantemente entre un editor, una terminal, el emulador de Android, el simulador de iOS y herramientas de análisis separadas, reunir parte de estas funciones en una sola pestaña del navegador puede hacer que el ciclo de desarrollo sea notablemente más fluido.
Expo también está trabajando en el EAS Simulator, cuyo objetivo es ofrecer una experiencia similar con simuladores alojados en la nube, de modo que no sea necesario tener Xcode o Android Studio instalados localmente.
Una CLI diseñada para agentes de programación
Esta adición muestra claramente hacia dónde se dirigen las herramientas para desarrolladores. Expo ha lanzado un paquete experimental:
@expo/agent-cli
Los agentes de codificación tienen dificultades al decidir qué herramienta utilizar: Expo CLI, EAS CLI, expo-doctor, entre otras, cada una con sus propios parámetros y formato de salida. El CLI del agente encapsula todas estas herramientas en una interfaz coherente. La configuración para su proyecto se realiza de la siguiente manera:
npx @expo/agent-cli@latest agents:setup
Algunos de sus comandos ilustran esta idea. El primero es:
status
Verifica aspectos como la compatibilidad con Expo Go sin ejecutar la aplicación. El siguiente es:
dev
Inicia el entorno de desarrollo e intenta encontrar la ruta más rápida para acceder a una aplicación en ejecución. El último es:
smoke
Ejecuta la aplicación, toma una captura de pantalla y la detiene nuevamente.
Esa última orden es la más interesante para los flujos de trabajo automatizados. Supongamos que le pides a un agente que agregue una pantalla de configuración y confirme que la aplicación sigue iniciándose. En lugar de asumir que su edición funciona, el agente puede ejecutar la prueba de funcionamiento básico y observar el resultado. Este es un pequeño paso desde los agentes como generadores de código hacia agentes que pueden verificar su propio trabajo, que es donde radica la mayor parte de su valor práctico. El paquete es experimental, así que espere que sus comandos cambien.
Expo Router estabiliza varias funciones
Expo Router recibe una actualización significativa en SDK 58. Varias funciones que eran experimentales ahora son estables:
- loaders de datos, para obtener información de la ruta antes de que se renderice la pantalla
- renderizado del lado del servidor para la salida web
- middleware que se ejecuta antes de que una solicitud llegue a una ruta
- pestañas nativas respaldadas por las barras de pestañas de la plataforma
- barritas de herramientas
En el fondo, la navegación también ha sido reescrita para que su estado sea más determinista, lo que significa que la misma secuencia de acciones produce de forma fiable el mismo estado. La mayoría de las aplicaciones no deberían notar ninguna diferencia. Si has creado navegadores personalizados o importado directamente desde la ruta siguiente, lee detenidamente la guía de migración:
expo-router/react-navigation
En la web, las rutas asíncronas son ahora la opción predeterminada. Cada ruta puede dividirse en su propio fragmento de JavaScript y cargarse cuando el usuario navega a ella, en lugar de enviar código para cada pantalla al cargar la página por primera vez. Para las aplicaciones web desarrolladas con Expo Router, esta es una opción predeterminada sensata, ya que el tiempo de carga inicial suele ser lo que más notan los usuarios. Ten en cuenta que esto también implica que una ruta podría cargarse brevemente la primera vez que se visita, por lo que los estados de carga en la web merecen una revisión rápida.
Un transformador experimental en Rust para Metro
Técnicamente, esta podría ser el cambio más interesante de esta versión, aunque es explícitamente experimental. Expo está probando un transformador de JavaScript escrito en Rust llamado Noxcturnal, desarrollado con la herramientachain oxc.
Una gran parte del tiempo necesario para el empaquetado en frío de Metro se dedica a las transformaciones de Babel: el análisis de cada archivo, la aplicación de plugins y la generación del resultado. Sustituir ese paso por código nativo en Rust ataca directamente la parte más costosa del proceso. En las pruebas de Expo, las transformaciones individuales de módulos fueron aproximadamente tres veces más rápidas, y los empaquetados completos en frío, unas dos veces más rápidos. Una aplicación de prueba grande con unos 5,500 archivos pasó de tardar 5.26 segundos a 2.46 segundos.
Puede activarlo mediante una bandera de experimentos en su configuración:
experiments: {
noxcturnalTransformWorker: true
}
Conozca los límites antes de activarlo. Los proyectos que dependen de complementos personalizados de Babel, presets o transformaciones especializadas podrían seguir recurrir a Babel, por lo que la mejora de velocidad depende de cuán estándar sea su configuración. Dado que esta función es experimental, su comportamiento y configuración pueden cambiar entre versiones.
Esta dirección es coherente con el ecosistema más amplio, donde las herramientas de JavaScript críticas desde el punto de vista del rendimiento han ido pasando de JavaScript a Rust durante varios años. Expo está explorando ahora el mismo camino para Metro.
Menos reconstrucciones nativas innecesarias
El comportamiento predeterminado de huella digital en SDK 58 es ahora el preset balanced. La huella digital es un hash de todo lo que afecta a la compilación nativa; cuando este cambia, las herramientas de Expo asumen que se necesita un nuevo binario nativo.
Eso suena aburrido hasta que evita tener que reconstruir la aplicación desde cero por una edición que nunca afectó al código nativo. Dependiendo de la configuración, cambiar algo como la versión de la aplicación en app.json solía modificar el “fingerprint”. La configuración equilibrada intenta ignorar los cambios que no alteran de manera significativa el entorno de ejecución nativo. El resultado cotidiano es sencillo: menos reconstrucciones innecesarias, lo que también implica menos generaciones de binarios no necesarios cuando se utilizan los “fingerprint” para decidir entre una actualización inalámbrica y una nueva versión desde la tienda. Nadie demuestra este tipo de funcionalidad, pero todos se benefician de ella.
Mejoras menores que vale la pena conocer
Más allá de los puntos principales, varias actualizaciones de módulos pueden ser relevantes según su aplicación:
expo-camerapermite el escaneo de documentos de varias páginas, útil para escáneres de recibos, flujos de carga de documentos, verificación de identidad (KYC) y gestión de gastos.expo-fontsoporta fuentes variables en Android, iOS y la web.expo-audioincluye controles en la pantalla de bloqueo que tienen en cuenta las listas de reproducción, además de grabación en formato WAV/PCM.expo-file-systemañade más APIs de hash y soporte nativo para la vista previa.expo-notificationsintroduce nuevos comportamientos, como la entrega de alarmas en Android.- La integración con PostHog permite adjuntar información sobre la compilación y actualizaciones de EAS a los eventos analíticos.
Ninguno de estos elementos define por sí solo la versión lanzada. Juntos, demuestran cuán amplia se ha vuelto la cobertura de la plataforma.
Cambios significativos que deben revisarse antes de actualizar
Las actualizaciones son emocionantes hasta que la aplicación deja de compilarse, así que no pase por alto esta parte. Antes de migrar un proyecto real a SDK 58, verifique lo siguiente.
Importaciones profundas en React Native
Busque en el código este prefijo de ruta:
react-native/Libraries/
Cada coincidencia representa una importación de archivos internos de React Native que la API estricta de TypeScript podría rechazar. También busque en node_modules, o al menos revise las dependencias que fallan, ya que las bibliotecas son una fuente común.
APIs eliminadas de React Native
Asegúrese de que ni su aplicación ni sus dependencias sigan utilizando APIs que fueron eliminadas en React Native 0.87 y 0.88, como InteractionManager.
Código personalizado de AppDelegate
Si el proyecto para iOS contiene personalizaciones del ciclo de vida nativo, revísalas en relación con el ciclo de vida basado en escenas requerido por iOS 27.
Navegación personalizada en Expo Router
Los navegadores personalizados y las importaciones desde expo-router/react-navigation se ven afectados por los cambios en su estructura interna; siga la guía de migración.
Escribimientos en el sistema de archivos
File.write() ahora es asíncrono. El código que espera que el archivo exista en la siguiente línea dejará de funcionar a menos que espere a que finalice la llamada. Si realmente necesita un comportamiento síncrono, cámbielo a:
File.writeSync()
Versión de Node.js
Las versiones de Node.js que soporta Expo han avanzado. Verifique su entorno local y sus imágenes de CI antes de asumir que un fallo en la compilación se debe a un error de Expo.
Una forma segura de probar la actualización
No comience desde la rama principal de producción. Cree una rama de migración dedicada y ejecute allí la actualización:
npx expo install expo@next --fix
La etiqueta expo@next instala la versión beta, y --fix ajusta sus otros paquetes de Expo a versiones compatibles con ella.
Luego pruebe primero los flujos menos llamativos, porque son esos los que los usuarios notan cuando fallan:
- ¿Se inicia la aplicación en absoluto?
- ¿Funcionan el inicio de sesión y la autenticación?
- ¿Pueden los usuarios navegar por las pantallas principales?
- ¿Abren los enlaces profundos el lugar correcto?
- ¿Llegan las notificaciones push?
- ¿Pueden los usuarios subir imágenes y archivos?
- ¿Se completan los pagos?
- ¿Tiene éxito la compilación para Android?
- ¿Tiene éxito la compilación para iOS?
Solo una vez que estos pruebas den resultado vale la pena explorar las nuevas funciones. Prueba nuevas APIs es divertido; las pruebas de regresión son lo que mantiene contentos a sus usuarios.
Hacia dónde se dirige Expo
Si observamos el SDK 58 en su conjunto, la dirección general es más importante que cualquier característica individual. Expo comenzó como una forma de hacer que React Native fuera más fácil de usar, y poco a poco se está convirtiendo en una plataforma completa para aplicaciones:
- Expo Router para la estructura y navegación de las aplicaciones
- Expo Modules para APIs nativas
- EAS Build para la compilación de aplicaciones
- EAS Update para el envío de actualizaciones
- EAS Observe para la supervisión en producción
- Expo UI para componentes de interfaz nativa
- Widgets y App Intents para la integración con el sistema operativo
- Herramientas de agente para un desarrollo asistido por IA
Junto con estas herramientas, Expo sigue invirtiendo en la infraestructura que los desarrolladores utilizan a diario: compilaciones más rápidas, llamadas a funciones nativas más económicas, menos recompilaciones, mejores túneles de conexión, herramientas de simulador mejoradas y posiblemente un empaquetado más rápido. Nada de esto genera capturas de pantalla impresionantes, pero sí mejora el trabajo diario. Para una visión más amplia de cómo esto posiciona a Expo, consulte por qué la salida de Shopify de React Native no representa una amenaza para Expo.
¿Debería actualizar ahora?
Para una aplicación en producción, pruébela antes de hacer el commit. El SDK 58 sigue estando en versión beta, React Native 0.88 se incluye como candidato a lanzamiento, varias de las nuevas APIs son experimentales o de versión alfa, y se esperan más correcciones antes del lanzamiento estable.
Para un proyecto secundario, una herramienta interna o una rama de migración, vale la pena explorarlo ahora, especialmente si necesita soporte para iOS 27 o quiere adelantarse a los cambios en React Native. Los problemas que encuentre durante la versión beta aún pueden reportarse y corregirse antes del lanzamiento estable, lo cual es mucho más fácil que encontrarlos después de que todos los demás hayan actualizado.
La única orden que debe recordar es la misma con la que comienza:
npx expo install expo@next --fix
Ejécutela en una rama, no en producción.
Puntos clave
- Los cambios que con mayor probabilidad pueden afectar negativamente una actualización son las importaciones profundas, las API eliminadas como
InteractionManager, el código personalizado de y los navegadores personalizados de Expo Router. - Con la actualización se obtienen gratuitamente compilaciones más rápidas en Android, llamadas nativas más económicas y menos reconstrucciones desencadenadas por cambios en las características del dispositivo.
- Expo Modules 2.0, la CLI del agente, Device Hub y el transformador Noxcturnal son experimentales o de versión beta; úsalos para pruebas, pero no dependas de ellos por ahora.
expo-app-intentsestá en versión alfa, mientras que los widgets para Android permiten que los equipos multiplataforma tengan funcionalidades en la pantalla de inicio.- Realiza la actualización en una rama dedicada, prueba primero los flujos de usuario críticos y explora las nuevas funcionalidades solo una vez que hayan superado las pruebas.
Lecturas relacionadas
- Por qué la salida de Shopify de React Native no amenaza a Expo — Explica por qué el cambio de Shopify de React Native a Swift y Kotlin nativos no significa el fin del desarrollo multiplataforma con Expo para la mayoría de los equipos.
- Dependencias inestables de useEffect: diagnosticando el gasto de batería en React Native — Ve cómo una dependencia de objeto y un array de dependencias faltante causaron consumo excesivo de batería y problemas en la reproducción de contenido en React Native, cómo analizarlo y las tres soluciones que funcionaron.