Expo vs React Native: Streamlined Development

¿Qué tal, todos? Soy Evan Bacon, y hoy vamos a hablar sobre cómo construir aplicaciones multiplataforma con React y Expo. El desarrollo de aplicaciones nativas puede ser un poco intimidante. Así que voy a describir y explicar de una manera que sea comparable al desarrollo web. Primero, haremos un breve resumen para aquellos que no estén familiarizados con React Native. Cuando quieres construir una aplicación para iOS, usarás Swift y Objective-C, y cuando quieres construir una aplicación para Android, usarás Java y Kotlin. Esto a menudo significa que tendrás dos equipos separados que trabajan prácticamente en silos. Obviamente, eso es menos eficiente que tener un solo equipo. Pero usando React Native, podemos escribir React y JavaScript que se renderiza en cada plataforma utilizando la misma base de código. Esto es muy similar a un navegador móvil, que te permite ejecutar código React DOM en diferentes plataformas, lo cual es por diseño. React es muy intuitivo para construir y escalar aplicaciones front-end grandes. Ahora, las principales diferencias entre React DOM y React Native son que, en lugar de dibujar nuestras vistas en Skia, como lo haríamos en Chrome, React Native utiliza vistas nativas adecuadas. Esto significa que podemos utilizar optimizaciones de la plataforma como desplazamiento suave, gestos y animaciones complejas, que se sabe que son un punto débil en los navegadores móviles. Podemos crear clientes nativos personalizados que expongan funcionalidades nativas adicionales a nuestra aplicación. Piensa en esto como construir un navegador, pero con soporte Bluetooth agregado. Y podemos reutilizar la mayoría del código de nuestra aplicación en diferentes plataformas. Tenemos el potencial de escalar nuestra aplicación para admitir más plataformas en el futuro. Y finalmente, podemos utilizar múltiples hilos diferentes. Por defecto, todo se ejecuta en un hilo de JavaScript, minimizando la cantidad de lógica de negocio que se ejecuta en el hilo principal de la interfaz de usuario. Esta es una arquitectura bastante avanzada que obtienes de forma gratuita simplemente usando React Native. Así que esto es bastante impresionante. Ahora, React Native no está exento de problemas, que van desde molestos hasta muy molestos. Así que hablemos de algunos de ellos. Primero, para obtener una aplicación de Hola Mundo en funcionamiento, solo Hola Mundo, necesitamos crear un tiempo de ejecución nativo. Esto difiere del desarrollo web, donde el tiempo de ejecución nativo ya está construido de antemano y se descarga en tu computadora. Eso sería Chrome o Safari, los navegadores web. Y pueden cargar tu proyecto de JavaScript dentro de ellos. Segundo, las dependencias en React Native son mucho más difíciles de gestionar que en el desarrollo web. En React Native, necesitas instalar el código nativo a través de NPM, mientras que en el desarrollo web, el código nativo ya está construido de antemano en el navegador. Y las API y el código nativo están diseñados por W3C, por lo que están muy bien pensados y bien construidos. Tercero, el tiempo de ejecución de tu aplicación debe distribuirse en la App Store o Google Play Store, con algunas excepciones.

Primero, hablaremos sobre cómo crear una aplicación y ejecutarla en tus dispositivos sin tener que realizar compilaciones nativas. Luego, cubriremos el ciclo de desarrollo y la adición de dependencias, luego hablaremos sobre cómo publicar tu aplicación en la tienda para que los usuarios puedan usarla. Y finalmente, hablaremos sobre cómo agregar código nativo, personalizar tu cliente y actualizar fácilmente tu aplicación. Para comenzar con el desarrollo de aplicaciones, solo necesitamos instalar Expo CLI. Este es un moderno CLI de Node.js que nos ayuda a interactuar con el empaquetador, iniciar un servidor de desarrollo y muchas otras tareas de desarrollo. Así que simplemente vamos a instalar globalmente el paquete y luego crear un nuevo proyecto con Expo init. Aquí, generaremos rápidamente un nuevo proyecto. No necesitamos ningún código nativo para comenzar. Cuando se inicializa el proyecto, podemos usar scripts de NPM para iniciarlo instantáneamente en iOS, Android o web, que son las plataformas que son compatibles con Expo de forma predeterminada. Yarn Android inicia el empaquetador Metro y abre el proyecto en Android. Yarn iOS abre el simulador y Web inicia el servidor de desarrollo de Webpack y abre tu proyecto en el navegador. Ahora, Expo en el ciclo de desarrollo de React Native es bastante excelente, incluso al igual que para el desarrollo web. Aquí, abriré la aplicación en iOS y Android al instante. No necesito hacer ninguna compilación nativa para eso. Luego haré algunos cambios para demostrar la actualización rápida, que conserva el estado del componente de React entre las actualizaciones. Como puedes ver, el ciclo de desarrollo es bastante rápido y realmente agradable. A diferencia del desarrollo de React DOM, React Native utiliza primitivas. Entonces, en lugar de div, usarás algo como view. En lugar de image, usarás image. Y en lugar de span, usarás text. Cada uno de estos elementos se renderiza en la vista nativa correcta para cada plataforma. Entonces, en iOS, una vista se renderizará como una UI view, y en web, una vista se renderizará como un div, y así sucesivamente. Y finalmente, estas primitivas se renderizan en algo que generalmente se ve igual en todas las plataformas. React Native solo proporciona un puñado de primitivas básicas. La mayoría de las características complejas provienen de paquetes de la comunidad.

Ahora, un conjunto realmente bueno de paquetes de la comunidad es el SDK de Expo, que es un conjunto de paquetes npm que se versionan juntos y siempre funcionan juntos. Y esto es probablemente lo más cercano que React Native tiene a una especificación tipo W3C en este momento. Cada paquete tiene tipos y admite iOS, Android y web, un sistema de versionado confiable y soporte completo de plataforma. El SDK de Expo actual resuelve eficazmente el problema de dependencia que los usuarios encuentran con frecuencia en React Native. Todo el código nativo se compila de antemano en una aplicación llamada Expo Go. La razón por la que hemos podido abrir instantáneamente nuestra aplicación en iOS y Android sin tener que realizar ninguna compilación nativa es porque estamos utilizando un tiempo de ejecución nativo reutilizable llamado Expo Go. Puedes descargar Expo Go desde la App Store de iOS y Google Play Store, y tiene la mayoría de las API que necesitarás para crear aplicaciones nativas complejas compiladas de antemano. Esto reduce drásticamente la complejidad y el tiempo necesario para pasar de cero a Hola Mundo, haciéndolo tan fácil como el desarrollo web. Cuando ejecutamos Expo Start, la terminal muestra la URL del servidor de desarrollo de nuestro empaquetador en forma de código QR. Podemos escanear esto con la cámara de nuestro teléfono inteligente para evitar tener que ingresar manualmente la URL. Ahora puedes notar que usamos `exp://` en lugar de `http://`. Esto indica al dispositivo que debe usar Expo Go para abrir el enlace en lugar del navegador web. Así que hablemos de lo que está sucediendo detrás de escena. Cuando la aplicación abre la URL, enviará una solicitud al servidor para obtener el manifiesto de la aplicación. Piensa en esto como el índice HTML, pero para aplicaciones React Native donde HTML no es compatible, el servidor devolverá el manifiesto y el cliente lo analizará. El cliente analizará el manifiesto hasta el campo de URL del paquete, que indica dónde se aloja el paquete de JavaScript. Piensa en esto como una etiqueta de script HTML que le dice al navegador dónde descargar activos externos como el paquete de JavaScript. El cliente solicitará la URL y el servidor de desarrollo devolverá los resultados del empaquetador Metro. Después de eso, la aplicación se inicia de inmediato. Y como puedes ver, todo el ciclo es muy similar al desarrollo web y cómo un navegador web interactúa con un servidor de desarrollo local. Y es similar al desarrollo web porque esto solo es para el modo de desarrollo. Debido a las restricciones de la App Store, no puedes usar esto para distribuir aplicaciones de producción a tus usuarios. Toda la distribución debe pasar por la App Store de Apple y Google Play Store.

Ahora hagamos eso ahora mismo. Tradicionalmente, implementar aplicaciones móviles es muy difícil y propenso a errores. Pero con una nueva herramienta llamada Expo Application Services, o EAS, podemos enviar nuestra aplicación con un solo comando. Como nota adicional, EAS todavía está en beta y debería salir de beta a principios de noviembre de 2021, por lo que cuando estés viendo esto, habrá pasado aproximadamente una semana. EAS build funciona iniciando automáticamente la firma de código nativo de tu aplicación y realizando otras validaciones localmente, luego enviando el código fuente a los servidores de EAS build. Esto es útil porque las compilaciones nativas requieren muchos recursos locales, que son difíciles de validar y configurar correctamente. También hemos descubierto que muchos desarrolladores simplemente no tienen máquinas macOS, que es necesario para compilar aplicaciones iOS.

Esto abre la puerta para realizar desarrollo de iOS en cualquier dispositivo. Y después de que se complete la compilación, los servidores de CI pueden devolver los archivos binarios o pueden enviarlos automáticamente a las tiendas. Todo lo que necesitas hacer es configurar un poco de metadatos y enviarlo para su revisión.

Todo lo que necesitamos hacer es instalar EAS CLI globalmente con npm o yarn y luego ejecutar un solo comando, que es EAS build --auto-submit. El indicador de auto-submit es realmente nuevo, por cierto, y esto reduce de dos pasos, EAS build, EAS submit, a solo un paso, lo cual es muy emocionante. Es tan fácil como el desarrollo web ahora.

La CLI te pedirá que inicies sesión en tu cuenta de desarrollador de Apple, luego procederá a configurar automáticamente tu aplicación para la tienda en función del estado de tu proyecto. Cuando haya terminado, tu código se cargará. Ahora, un paso relativamente nuevo, del que estoy hablando por primera vez aquí, es la Firma de Capacidades de Apple. Las capacidades son API proporcionadas por Apple. Se utilizan para cosas como pagos, notificaciones, health kit, etc., y si no se configuran correctamente con los servidores de Apple, tu aplicación no se compilará, lo cual es un momento muy extraño para fallar.

Este tipo de error de compilación solía ser muy común y muy molesto. Por ejemplo, para habilitar los pagos, necesitas crear un ID de comerciante, debes habilitar la funcionalidad de pagos en tu ID de paquete. Todo esto se realiza a través del sitio web de desarrolladores de Apple, por cierto. Debes hacer todo esto manualmente a través de una interfaz de usuario. Luego, debes registrar ese ID de paquete, registrar el ID de comerciante en el ID de paquete. Y finalmente, debes regenerar todos tus perfiles y volver a firmar tu aplicación. Un montón de términos extraños que requieren mucha atención para hacerlo bien, pero dado que React y Expo están profundamente integrados con EAS build, solo necesitas definir el ID de comerciante y luego reconstruir tu aplicación. Todo el proceso que acabo de especificar está completamente automatizado. Por lo tanto, se elimina por completo esta clasificación de errores de compilación de tu ciclo de desarrollo, lo cual es muy emocionante.

Cuando se completa el envío de compilación, puedes descargar el archivo binario si lo deseas y puedes consultar la entrada de la aplicación en la tienda. Apple procesará el binario durante un tiempo después de que esté completo. Luego, solo necesitas completar algunos metadatos y puedes enviar la aplicación para su revisión. También puedes descargarla usando Test Flight. Y nuevamente, todo esto sucedió con un solo comando. Así que cosas bastante emocionantes.

Ahora, una de las características más innovadoras en React y Expo son las actualizaciones por aire. Entonces, si deseas actualizar tu JS y activos en tu aplicación, puedes hacerlo al instante a través de Expo CLI. Al ejecutar Expo Publish, tu JS se empaquetará y se enviará a un servicio de alojamiento, que tu tiempo de ejecución está programado para verificar. Cuando envías tu actualización al servidor, espera a que el usuario abra la aplicación nuevamente.

Cuando lo hacen, la actualización se descarga en segundo plano, mientras que el paquete inicial se presenta de inmediato al usuario. Luego, la próxima vez que abran la aplicación, se mostrará la versión en caché v2. Esto es muy similar a la política de caché de obsoleto mientras se vuelve a validar en un trabajador de servicio web.

La razón por la que utilizamos esta política de caché específica es porque está optimizada para Offline First y para un TTI muy rápido, que son dos cosas que esperas cuando usas una aplicación nativa.

El servicio alojado de Exynos es capaz de enviar paquetes de JS y activos estáticos por aire a tu aplicación al instante, lo cual es muy similar a los servicios de alojamiento web. Sin embargo, no es capaz de enviar el código nativo de tu proyecto. Debido a las restricciones de la App Store, toda la aplicación de iOS debe enviarse a través de la App Store de iOS y todo el código de Android debe enviarse a través de Google Play Store, lo cual EAS build puede automatizar por ti por lo que es esencialmente parte del conjunto de herramientas para todo.

Ahora que hemos hablado sobre la implementación, hablemos un poco sobre el código nativo. Hasta este punto, solo hemos cubierto el código de React y no hemos tenido que interactuar con ningún módulo nativo personalizado, pero eventualmente puedes necesitar algún código personalizado o una biblioteca de terceros que no esté disponible en Expo Go o en el SDK de Expo.

Para esto, podemos crear fácilmente un cliente de desarrollo personalizado, que es como Expo Go, pero con un conjunto especial de funciones nativas. El cliente de desarrollo se encuentra entre el sistema operativo y la aplicación de React. Así que piénsalo como un navegador web, pero especial y nativo.

Para agregar código nativo personalizado, muy sencillo, todo lo que tienes que hacer es instalar cualquier módulo de React Native en tu proyecto y luego reconstruir la aplicación. Así que como usuario, aún no verás directamente el código nativo. El código nativo se vincula a nuestro proyecto utilizando tres herramientas distintas. La primera es el auto-linking, que vincula el código nativo de iOS y Android que se encuentra en el módulo de nodo con tu código local de iOS y Android. Y esto ocurre durante la instalación del administrador de dependencias nativas. Puede ser Cocoapods o Gradle. Luego tenemos los config plugins, que son funciones simples de JavaScript que se utilizan para configurar valores estáticos como mensajes de permisos. Por ejemplo, si instalas una biblioteca de cámara, es posible que desees establecer qué dice el mensaje de permiso de la cámara. Y todo esto se genera y evalúa durante el paso de pre-compilación de Expo. Por último, tenemos los módulos de Expo, de los que hablaremos un poco más adelante. Pero es una API que se utiliza para interactuar con mecanismos de toda la aplicación como detectar cómo se abrió tu aplicación, si se abrió a través de un enlace o al presionar una notificación. Y todo esto se ejecuta durante el tiempo de ejecución.

Ahora, todos estos mecanismos se ejecutan automáticamente y se utilizan al compilar tu aplicación con Expo CLI o EAS build para crear el código nativo para tu proyecto de JavaScript. Podemos reconstruir nuestro cliente nativo localmente con Expo CLI o de forma remota con EAS CLI. Ya hemos hablado un poco sobre EAS build, así que hablemos de las compilaciones locales. Para compilar tu aplicación localmente, necesitas tener las herramientas de compilación nativas instaladas en tu computadora. Esto significa que necesitas Xcode para iOS y Android Studio para Android. Estas herramientas son muy complejas y tienen poco en común, por lo que su uso puede ser bastante confuso y diferente. Dado que solo necesitamos utilizar la funcionalidad de compilación de estas herramientas, hemos creado comandos para facilitar la interacción con ellas. Estos son los comandos exporun.ios y exporun.android.

Estas herramientas están diseñadas para que las compilaciones de iOS y Android sean muy familiares para los desarrolladores de Node.js. Por ejemplo, Xcode no conoce los módulos de Node. Solo ve más archivos de proyecto. Por lo tanto, exporun.ios es capaz de contextualizar la información y solo mostrarte registros y advertencias que provienen del código de la aplicación y de cosas en las que realmente puedes realizar cambios significativos, lo que significa que tu compilación básica no tiene advertencias en lugar de las 538 que normalmente mostraría Xcode. Ahora, estos comandos también hacen muchas otras cosas para facilitarte la vida, pero no tenemos tiempo para entrar en todo.

Quiero cubrir rápidamente la construcción de clientes de desarrollo en la nube. Hay un problema fundamental que debe abordarse. Y es que las aplicaciones de React Native tienen esta URL codificada. Ahora, esa URL codificada está básicamente definida por la red en la que se encuentra tu computadora cuando construyes la aplicación. Entonces, si estás haciendo esto en la nube, esa IP no coincidirá con la IP que estás usando localmente. Entonces hará una solicitud al servidor de desarrollo y esa URL no coincidirá con dónde está alojado el servidor de desarrollo.

También puede haber otros factores como cambios de puerto o tal vez tienes una VPN. Pueden ocurrir muchas cosas y luego el cliente de desarrollo no se conectará. Entonces, el servidor de desarrollo devolverá efectivamente un error 404 y tu aplicación no podrá cargarse. Ahora, para solucionar esto, creamos una biblioteca llamada ExpoDevClient que puedes instalar en tu proyecto. Por defecto, los clientes personalizados son muy similares a lo que realmente enviarás a la tienda de aplicaciones en el sentido de que no tienen todas las excelentes herramientas de experiencia de desarrollo que puedes usar para facilitar tu experiencia de desarrollo. El principal que estamos describiendo aquí y hablando de él es que la barra de URL no está presente. Entonces realmente no puedes cambiar entre diferentes aplicaciones y no puedes conectarte a diferentes redes. Para solucionar esto, creamos ExpoDevClient que es un paquete que puedes instalar para recuperar todas estas herramientas de interfaz de usuario en tu aplicación. Entonces tu cliente de desarrollo es muy similar a Expo Go en modo de desarrollo. Con esto, podemos seleccionar la URL que realmente funciona. Podemos hacer una solicitud a nuestro servidor de desarrollo y el servidor de desarrollo puede devolver el manifiesto que carga nuestra aplicación como se espera. Y, por supuesto, todo este código adicional se elimina de tu aplicación cuando la construyes para producción.

Ahora, por último, quiero hablar sobre los flujos de trabajo en Expo. Expo tiene dos flujos de trabajo principales. El flujo de trabajo administrado y el flujo de trabajo básico. En resumen, el flujo de trabajo administrado nos permite evitar en su mayoría tener que trabajar directamente con código nativo. También maximiza la configuración multiplataforma mientras que el flujo de trabajo básico nos permite tener control total sobre todo en nuestro proyecto. La principal compensación es que si quieres hacer algo como cambiar el nombre de tu aplicación o actualizar el ícono, debes hacerlo para cada proyecto nativo individualmente. Para explicarlo mejor, veamos un proyecto básico. Un proyecto de flujo de trabajo básico es prácticamente igual que un proyecto de React Native sin Expo en el sentido de que tienes estos dos proyectos nativos que tienen mucha complejidad en ellos y eres responsable de todo lo que hay dentro de ellos. Y esto es genial porque tienes control total sobre todos los aspectos y puedes hacer que funcione como quieras. Pero una gran desventaja de esto es cuando quieres actualizar tu aplicación. Entonces, React Native tiene actualizaciones frecuentes. Espero que estas versiones sigan siendo correctas cuando estés viendo esto donde si intentas pasar de React Native 65 a React Native 66, la línea entre ellos es muy larga.

Primero, debes validar las versiones de tus paquetes. Cada paquete que estés utilizando debes asegurarte de que funcione con la última versión de React Native. Luego debes actualizar todos tus paquetes. Y luego debes actualizar toda la configuración nativa. Entonces, si has realizado alguna configuración nativa personalizada y cosas como tu Info.plist, tu Android Manifest, debes ir manualmente y asegurarte de que funcione con la última versión de React Native. Luego, y esta es la parte muy difícil, debes mezclar los cambios nativos de la nueva versión de React Native con tu versión actual. Entonces, cuando generas tu proyecto de React Native, generalmente, es como configurarlo y olvidarlo. Pero cuando actualizas debes estar bastante familiarizado con todos los detalles de tus archivos de plantilla. Y finalmente reconstruyes la aplicación y esperas que todo funcione como se esperaba. Y este escenario ha creado efectivamente uno de los problemas más difíciles en React Native, que es la actualización frecuente. Es muy difícil de hacer.

Ahora, en un proyecto administrado de Expo, tus carpetas de iOS y Android son gestionadas por Expo CLI y se configuran mediante el archivo de configuración app.json. Me gusta explicar esto usando NPM, porque las personas están muy familiarizadas con NPM. NPM tiene una CLI y tiene un archivo de configuración, el package.json. Y luego tiene una carpeta generada llamada node-modules. Y debido al sistema, puedes agregar fácilmente muchos módulos complejos y simplemente eliminarlos y puedes eliminarlo, no tienes que hacer un commit de Git de eso y realmente reduce drásticamente la complejidad de tu proyecto a medida que escala hacia arriba. Y luego, cuando quieras cambiar algo, simplemente puedes ejecutar npm install y eliminará la carpeta node-modules y la regenerará efectivamente y aplicará los nuevos cambios. Ahora, expo-cli funciona de manera muy similar donde tienes un archivo de configuración app.json que configura expo-cli para que puedas ejecutar un comando llamado expo-prebuild para eliminar y luego regenerar tus proyectos de iOS y Android en función del estado de tu app.json, tu package.json y cosas así. Esto hace que actualizar tu aplicación de React Native sea tan fácil como actualizar cualquier proyecto de React. Simplemente cambias algo de código JS y regeneras todo. Y, por supuesto, si alguna vez necesitas escribir código nativo personalizado, simplemente puedes acceder a la carpeta de iOS y Android de manera similar a cómo accedes a la carpeta node-modules y personalizar todo localmente. La desventaja de esto es que no puedes utilizar de manera segura el comando expo-prebuild de la misma manera que no puedes ejecutar de manera segura npm install después de modificar manualmente la carpeta node-modules. Así que hay un compromiso. Hemos elegido mantener esto como una opción de primera clase mientras que modificar la carpeta node-modules no es realmente una buena práctica en absoluto porque la carpeta de iOS y Android tiene tanta complejidad interna y no queremos que nadie se sienta atrapado. Entonces, si algo no funciona, tienes la tranquilidad de que siempre puedes acceder al código nativo, tomar el control esencialmente y configurar las cosas como desees.

Ahora, volviendo a nuestros problemas de React Native, como puedes ver, Xbort proporciona soluciones para cada uno de ellos. En lugar de tener que instalar Xcode para que aparezca hello world en tu teléfono, simplemente puedes instalar Xbort Go. En lugar de tener que averiguar si los paquetes funcionan juntos en la misma versión, el SDK de Xbort es muy confiable en ese sentido y cuando quieras implementar tu aplicación, puedes hacerlo con un solo comando. Es bastante genial, y cuando quieras actualizar tu código, puedes hacerlo tan fácilmente como cualquier proyecto de Node.js. Así que, muy impresionante.

Y ahora, con el tiempo que me queda, quiero mostrarles algunas cosas nuevas increíbles que tenemos en Xbort en un futuro cercano. Al igual que un proyecto de Node.js, si deseas agregar paquetes personalizados, deberás configurar un monorepo o actualizar tu proyecto a un monorepo, que puede vincular módulos locales de Node a una o más aplicaciones, y estoy muy orgulloso de anunciar que con Xbort SDK 43, que se lanzó en octubre, por lo que a principios de este mes, tiene soporte inicial para monorepos. Esto significa que básicamente puedes escribir código nativo en un módulo de Node y vincularlo directamente a tu proyecto de flujo de trabajo administrado. Muy, muy ilimitado y muy fluido desarrollo nativo allí. Esto agrega soporte de primera clase para workspaces de yarn, una forma de mantenerte esencialmente en el flujo de trabajo administrado mientras escribes código nativo para tu proyecto y también te permite vincular muchos proyectos diferentes como desees. Así que estoy súper emocionado de que ahora tengamos esto en React Native a través de Xbo.

Hablando de escribir módulos, estoy extremadamente emocionado acerca de los módulos de Xbo. Ahora, esta es una versión pública del sistema que usamos internamente para escribir el SDK de Xbot. Simplifica drásticamente la escritura de código nativo para tu aplicación de React y proporciona muchas características para hacer que tus módulos sean más autocontenidos y poderosos. Para explicar esto, veamos cómo funciona el React Native moderno. Si deseas escribir una función simple para sumar dos números, debes usar lenguajes complejos como Objective-C y Java, que luego instalan características en el JS global utilizando algo llamado JSI. Esto los hace efectivamente disponibles para React. Esto también se dificulta enormemente por la falta de una documentación clara sobre cómo escribir un módulo JSI. Entonces, Expo Modules Core se encuentra entre JSI y tu código para proporcionar un DSL, francamente, hermoso donde puedes escribir Swift y Kotlin como lenguajes de primera clase. También habrá documentación y estos se vincularán directamente al objeto JavaScript a través de JSI. Como puedes ver aquí a la izquierda, tenemos un módulo React Native actual escrito en Objective-C y aquí a la derecha, tenemos uno escrito en Swift. Y como puedes notar, si estás familiarizado con los aspectos internos de React Native, esto no es como una solución chapucera en Swift donde tenemos macros que se vinculan a encabezados en Objective-C y luego tienes que escribir algo de Objective-C para escribir algo de Swift. Esto es todo soporte de primera clase para Swift. Es un DSL muy moderno y simplemente hace que trabajar en el lado nativo de React Native sea súper, súper intuitivo y agradable.

Ahora, aunque esto es bastante genial, hay una parte muy agradable y es que la arquitectura que usamos en Expo Modules es muy rápida. Lo usamos para nuestro SDK para que los módulos locales de iOS se compilen súper rápido. Como puedes ver aquí, tenemos Expo Camera en comparación con la versión de la comunidad de React Native 4 de Expo Camera. Compilamos de antemano en comparación con que todos compilen localmente cuando obtienen el módulo. Así que digamos que es, quiero decir, aquí mismo son 35 segundos. Eso es mucho, ni siquiera necesita sumarse. Y no solo estoy criticando ese módulo. Aquí está Expo Updates frente a la versión de la comunidad. Aquí está Expo Location y aquí está Expo File System. Así que como puedes ver, estos son muy, muy rápidos. Esto ahorra mucho tiempo, mucho dinero, especialmente si estás utilizando servidores de CI.

Estoy súper emocionado de que estemos avanzando hacia hacer esto público para que las personas en la comunidad ahora puedan tener una base mucho más sólida y bien documentada para construir módulos muy rápidos y alcanzar el nivel de calidad del SDK de Expo. Tamash, quien creó la API, escribió una publicación de blog realmente buena explicando y yendo más a fondo sobre esto, así que si estás interesado, te recomiendo encarecidamente que lo revises.

Y eso es todo lo que tengo para ustedes hoy. Muchas gracias por ver. Si tienes alguna pregunta o comentario, no dudes en contactarme en Twitter en Baconbricks o en Expo. También tenemos un foro y Discord para preguntas de la comunidad. Nuevamente, muchas gracias y nos vemos en línea.

Evan, gracias por unirte a nosotros. Es bueno verte. ¡Hola, qué tal? Hola. Sí, puedo escucharte. Bien, bien. Antes de comenzar las preguntas y respuestas, quería decir que he visto tus Legos y son increíbles. No sé cómo tienes tiempo para esto después de un trabajo a tiempo completo, pero se ven geniales. Y todos los que no saben de qué estoy hablando y están viendo esto, busquen Evan Bacon Lego y quedarán asombrados.

Así que tenemos algunas preguntas del público y la primera pregunta es de Alice. ¿Es Bare Expo lo mismo que una aplicación expulsada? Sí, en los dos últimos SDK hemos eliminado la necesidad de expulsar, ya no es algo que necesites hacer, mientras que antes solo teníamos el flujo de trabajo administrado y luego Bare era como una especie de versión paralela donde te expulsabas de él como crear una aplicación React, pero ahora lo hemos reestructurado de manera que el flujo de trabajo administrado se basa en Bare y luego puedes ir quitando capas para acercarte lo más posible al código nativo según lo desees, también puedes volver a agregar capas y ahora es mucho más fluido y flexible. Genial, gracias. Y una pregunta más. ¿Los módulos de Expo estarán disponibles para las aplicaciones con flujo de trabajo Bare? Sí, los módulos de Expo estarán disponibles en todas partes para cualquier tipo de aplicación de React Native y son realmente emocionantes. De hecho, los lanzamos ayer o lanzamos la primera versión beta. Es muy emocionante. Muy bien, genial. Bueno, Evan, muchas gracias por unirte a nosotros y compartir tus conocimientos. Espero verte de nuevo pronto. Sí, ¡gracias por tenerme! Muy bien, adiós.