Despliegue de aplicaciones React Native en la nube

Por favor, da la bienvenida a Praeten. Praeten. Comencemos. Bienvenido, Praeten.

Para comenzar, un poco sobre mí. Soy un defensor del desarrollador para AppFlow. AppFlow es una plataforma para construir aplicaciones multiplataforma similares a React Native. Pero AppFlow funciona con todo tipo de aplicaciones. Puedes construir aplicaciones Ionic, aplicaciones React Native, aplicaciones Swift, aplicaciones Kotlin. Está diseñado para cualquier tipo de desarrollo. Pero funciona muy bien con aplicaciones multiplataforma en particular, por eso hoy vamos a hablar de aplicaciones React Native. Siéntete libre de conectarte conmigo en Twitter y GitHub. Mi nombre de usuario es Cecilia Creates. También puedes enviarme un correo electrónico a Cecilia en ionic.io.

En realidad, mi experiencia está en el desarrollo web. Fui desarrollador web, también trabajé anteriormente en Cypress, que es un marco de pruebas y RePlay, que es una herramienta de depuración. Ambos son herramientas de desarrollo de código abierto al igual que Ionic. Así que realmente tengo pasión por las herramientas de desarrollo de código abierto y trabajar con desarrolladores. A medida que avanzamos, si tienes alguna pregunta sobre pruebas o depuración, probablemente pueda ayudarte con eso también.

Entonces, sí, eso es todo sobre mí. Como dije, hoy podemos mantener las cosas informales a medida que avanzamos en la agenda. Lo primero que haremos es asegurarnos de que estemos configurados con las aplicaciones que necesitamos construir. Hablaremos sobre la configuración y los requisitos previos que necesitaremos. A medida que avanzo con los requisitos previos, si no tienes todas las cuentas, está bien. Aún puedes obtener algo de esta presentación, y también compartiremos las diapositivas y todos los recursos para que puedas llevarlos contigo y trabajar en tus propias aplicaciones si no tienes todo lo que necesitas hoy.

Luego, nos pondremos en marcha con las compilaciones de depuración. Las compilaciones de depuración son formas rápidas y sencillas de compilar rápidamente tu aplicación con fines de depuración. Después de eso, probablemente haremos un pequeño descanso y veremos cómo vamos de tiempo. Luego pasaremos a las compilaciones nativas en la nube. Así es como puedes compilar tu aplicación para iOS y Android de forma nativa, utilizando el servicio en la nube Outflow. Y luego también veremos cómo desplegar una aplicación en una tienda. Vamos a desplegar en... Tenemos un par de opciones. Tengo las pistas de prueba internas de Google Play, y también tenemos TestFlight de iOS. Entonces, dependiendo de lo que prefieras, probablemente vaya con TestFlight, porque la mayoría de las personas prefieren iOS. Así que comenzaremos con eso y también compartiré las instrucciones para la otra plataforma.

Entonces, sí, comencemos con nuestra configuración. Idealmente, ya tienes un repositorio git de una aplicación React Native. Si no lo tienes, voy a compartir un repositorio en el chat que puedes hacer un fork. Y esta es solo una aplicación básica de React Native-vanilla-cli. En ese commit inicial, me aseguré de que la firma automática estuviera habilitada en Xcode y hice un pequeño cambio en el texto de fondo. Así que es una aplicación muy básica, lista para usar, si necesitas una para usar. Puedes hacer un fork y usarla para construir. Más adelante, deberás actualizar los identificadores de paquete, y hablaremos de eso a medida que avancemos si usas esta aplicación. Así que daré unos minutos para que las personas configuren eso, si es necesario, si necesitan hacer un fork, mientras sigo con el resto de los requisitos previos. También necesitarás Xcode y Android Studio. Ahora, necesitas estos, si quieres pasar por el proceso de generar, como, tus... bueno, sí, tu firma, certificado y todo, para llegar a la parte de compilación nativa. Eso se debe a que necesitarás usar Xcode y Android Studio para generar las credenciales de firma, en su mayoría. Puedes hacerlo de otra manera. Hay algunas otras rutas que puedes usar para obtener tus credenciales de firma.

Pero Xcode y Android Studio son la forma más fácil. Así que si no los tienes instalados en tu máquina, avísame. Estoy encantado de compartirte algunas instrucciones sobre cómo puedes generar esas credenciales de una manera diferente. Tal vez simplemente no lo cubriremos juntos.

Y también crearemos una cuenta de AppFlow como parte de la masterclass de hoy. Es una cuenta gratuita. Viene con compilaciones nativas de iOS y Android para que puedas comenzar. Y luego, si deseas pasar por el proceso de conexión y implementación en las tiendas de aplicaciones, necesitarás una cuenta de desarrollador de Apple. Si deseas crear cualquier tipo de compilación de iOS fuera de las compilaciones del simulador, hay un costo asociado. Es de $99 al año. Nuevamente, puedo demostrarte toda esta funcionalidad sin que tengas que pasar por ella. Y compartiré esos recursos. Es posible que, por ejemplo, tengas una cuenta de la empresa que uses en el trabajo, pero no quieras usarla hoy. Así que eso es algo en lo que puedo guiarte y compartir la pantalla. También necesitarás una cuenta de App Store Connect. Si deseas implementar en TestFlight o en la App Store. Esas son dos cuentas separadas, la cuenta de desarrollador de Apple y App Store Connect, pero están unidas por el mismo ID de la App, el ID de la App Store de Apple. Y también necesitarás una cuenta de Google Play Console si deseas implementar en Google Play para la implementación de la pista de pruebas.

Continuaremos y comenzaremos con la compilación de debug. Así que quiero hablar sobre la compilación de debug. Cuando me refiero a eso, me refiero a tipos de compilación específicos cuando se trata de aplicaciones nativas. Cuando estás construyendo para la web, solo tienes una compilación y tal vez una compilación de prueba o una compilación de preparación, y luego una compilación de producción. Pero tú decides eso como desarrollador cuando implementas tu aplicación. Para aplicaciones móviles, hay tipos de compilación muy específicos que debes elegir. Y hablamos de los tipos de compilación para Android, tenemos compilaciones de debug y de lanzamiento. Debug es básicamente una compilación rápida. No es necesario configurarla por completo y puedes compartirla con tus probadores y partes interesadas internas. Las compilaciones de lanzamiento son necesarias para implementar en Google Play. En el lado de iOS, cuando hablo de compilaciones de debug, me refiero a una compilación del simulador. Una compilación del simulador se puede ejecutar en un simulador y no necesita estar firmada, lo que facilita la compilación desde el principio. También tienes compilaciones de desarrollo que se pueden ejecutar en un dispositivo, típicamente localmente, conectado a tu computadora. Y luego tienes compilaciones ad hoc de la App Store y enterprise, que se utilizan para distribuir a otros usuarios. Cuando hablo de las compilaciones de debug, me refiero principalmente a las compilaciones de debug de Android. Pero también puedes considerar las compilaciones del simulador como una compilación de debug. Entonces, lo primero que haremos es asegurarnos de tener configurado nuestro repositorio de GitHub. ¿Alguien necesita más tiempo para hacer un fork o preparar un repositorio? Si necesitas más tiempo, no dudes en levantar la mano o escribir en el chat.

De acuerdo, genial. Bien, vamos a ir a este enlace, lo compartiré en el chat. Es simplemente nxio.com. Y vamos a crear una cuenta. Esto nos permitirá pasar por el proceso de implementar nuestras aplicaciones y crear compilaciones de datos en la nube. Solo haz clic en este botón de `Comenzar gratis`. Te pedirá que crees una cuenta. Es una cuenta gratuita. No necesitas ingresar una tarjeta de crédito ni nada por el estilo, puedes comenzar con aplicaciones gratuitas. Así que te daré un par de minutos aquí, puedes crear una cuenta con GitHub si quieres, o puedes crear una cuenta con un correo electrónico y una contraseña. Y luego, una vez que hayas creado una cuenta, terminarás en un panel. Se ve más o menos así, tengo muchas aplicaciones allí porque estoy usando mi cuenta, pero tú podrás ver una barra lateral aquí y tendrás algunos bloques, en el medio aquí, con un mensaje de bienvenida. Este es nuestro panel de AppFlow. El panel de AppFlow es básicamente donde importarás tus aplicaciones e iniciarás compilaciones.

Puedes iniciar implementaciones en las tiendas de aplicaciones. Lo primero que debemos hacer es conectar nuestra aplicación a AppFlow. Verás un nuevo icono aquí, un pequeño botón desplegable, y debes hacer clic en importar aplicaciones existentes. Puedes darle un nombre a tu aplicación. Por ejemplo, si quieres hacerlo como React Summit workshop, seleccionarás la arquitectura móvil. Así que le daremos un nombre aquí, en este caso, será React native. Luego seleccionarás tu aplicación, obtén el host. Ya estoy conectado aquí. Pero si no, deberás hacer clic en conectar para iniciar sesión en tu cuenta de GitHub. Sí. Y luego, una vez que llegues a la pantalla, seleccionarás el repositorio y eso importará automáticamente tu aplicación. Sabrás que fue exitoso porque podrás ver tus commits. Una vez que todos puedan ver sus commits en AppFlow, continuaremos. Correcto. Sí, es una muy buena pregunta. Leon, gracias por eso. Sí. Sí. Así que simplemente seleccionarás el proyecto completo porque estamos importando un proyecto react native. Pudiste crear aplicaciones multiplataforma desde el mismo repositorio. Entonces, nuevamente, react summit workshop, redacted native. Y el repositorio que estoy importando es este app flow RN vanilla, que corresponde a mi repositorio de GitHub. Y como puedes ver, es el proyecto completo de react native que incluye tanto las subcarpetas de Android como de iOS. Pero Appflow se encargará de eso cuando vayamos a compilar. De acuerdo. Y una vez que veas algunos commits, siéntete libre de dar un pulgar hacia arriba. Sé que algunos de ustedes solo están siguiendo, pero les daré unos minutos más para configurarlo. De acuerdo. De acuerdo. Así que, estamos bien aquí. Continuaré. Continuaré. Ahora que hemos importado nuestra aplicación, voy a hacer un recorrido por este panel de Appflow y hablar sobre algunos de estos conceptos relacionados con las compilaciones cloud nativas. Tenemos nuestros commits que se importan de cada uno de estos commits, podemos iniciar una compilación. Y cuando me refiero a una compilación, me refiero a las compilaciones de iOS y Android. Correcto. Y normalmente, cuando estás creando una aplicación multiplataforma, tienes una base de código y puede que tengas diferentes configuraciones, pero en última instancia, estás implementando la misma aplicación exacta, la misma versión en iOS y Android. Así que cuando hablamos de iniciar una compilación desde un commit, estamos tomando la última versión de nuestra base de código. Así que en este caso, actualicé mi estilo de fondo hace aproximadamente una hora. Y estamos diciendo que queremos compilar para iOS o Android. Así que cuando hablamos de compilaciones debug, vamos a elegir el tipo de compilación. Esta es la nueva pantalla de compilación en Appflow. Hemos seleccionado un commit de nuestra base de código para iniciar una compilación. Desde aquí, podemos seleccionar iOS o Android. Voy a comenzar con una compilación debug de Android. Aquí, vamos a seleccionar nuestro stack de compilación. Y siempre dejo esto en `latest`. Cuando hablo de un stack de compilación, me refiero a todas las dependencias que deben instalarse en el entorno antes de poder continuar con la compilación. Así que si alguna vez has hecho esto manualmente, sé que, um, sabemos que estamos hablando de hacer esto en CI-CD.

Debes instalar tu stack de compilación, asegurándote de tener la versión correcta del Android SDK. Si estás compilando para iOS, asegúrate de tener instalada la versión correcta de Xcode y Cocoapods en tu entorno. Es posible que también necesites instalar una versión específica de node. Todo esto se gestiona en AppFlow a través del stack de compilación y nuestro equipo lo actualiza con frecuencia para asegurarnos de cumplir con los últimos requisitos de las tiendas de aplicaciones.

Por ejemplo, en Android, si no estás utilizando una versión suficientemente alta del Android SDK, puedes ser eliminado de las tiendas de aplicaciones porque eso crea un riesgo de seguridad. Por eso actualizamos continuamente los stacks de compilación para ti. Si necesitas una versión específica, como por ejemplo, si tu aplicación solo es compatible con una versión anterior de node, puedes seleccionar una versión anterior y ver qué se incluye en ese stack de compilación. Pero en su mayoría, yo uso el último stack de compilación.

A continuación, debes elegir el tipo de compilación. Para Android, puedes elegir entre compilaciones de depuración o compilaciones de lanzamiento. Vamos a seleccionar una compilación de depuración de Android. Aquí es donde puedes utilizar entornos personalizados o entornos ad hoc para aplicar ciertos pares clave-valor a la compilación en sí. Por ejemplo, para las compilaciones de depuración, si quieres cambiar el nombre del paquete porque es para un equipo específico, puedes pasar esta variable de entorno en el momento de la compilación como un entorno ad hoc para actualizarlo en esta compilación en particular. También puedes crear un entorno que se pueda guardar y utilizar una y otra vez. Por ejemplo, si tienes una API de prueba y una API de producción, y quieres guardarlas, puedes tener tu entorno de prueba con tu punto final de API y su valor, guardarlo y aplicarlo para cada compilación de prueba. Y luego tienes un entorno de producción con tus variables de entorno, con tu punto final de API de producción, lo guardas y se puede almacenar en AppFlow y aplicarlo a ciertas compilaciones. En este caso, vamos a hacer una compilación de depuración de Android, nada especial. Vamos a iniciar esa compilación.

Mientras se está ejecutando, voy a hablar sobre algunos conceptos relacionados con los dispositivos de prueba. Como mencioné antes, tenemos compilaciones de simulador de iOS. Un simulador es un tipo de dispositivo de prueba virtual. Para los dispositivos de prueba, tienes la opción de dispositivos virtuales y dispositivos reales. Aquí en esta diapositiva, tienes simuladores para iOS y lo que se llama emuladores para Android. Hay algunas pequeñas diferencias entre los dos, pero en última instancia, ambos replican un dispositivo real en tu computadora. Aparece en pantalla y puedes interactuar con él. Vamos a echar un vistazo a uno en un momento. Estos vienen preinstalados con Xcode y Android Studio, por lo que no necesitas configurarlos ni instalarlos por separado. Se pueden utilizar para ejecutar pruebas automatizadas en CI/CD. Como vienen preinstalados en Xcode y Android Studio, básicamente puedes ejecutarlos en tus entornos de CI/CD y ejecutar pruebas en ellos. Sin embargo, como verás, lo que diferencia a la web de la aplicación móvil es que en el mundo web tenemos muchas pruebas automatizadas. Es bastante común que tengas pruebas automatizadas y tal vez quieras tener una cantidad mínima de pruebas manuales. En el desarrollo móvil, eso está un poco al revés. Tienes muchas pruebas manuales, principalmente en dispositivos reales. Para ejecutar tu aplicación en dispositivos reales en iOS, debes registrar los EUID de los dispositivos. Puedes hacerlo conectándote a Xcode o agregando esos dispositivos en el programa de desarrolladores de Apple. No tienes que preocuparte por eso en Android. También puedes utilizar dispositivos reales para ejecutar pruebas automatizadas en CI/CD utilizando lo que se llama una granja de dispositivos reales. Cosas como AWS Device Farms, Sauce Labs. Puedes subir tu aplicación a estas granjas de dispositivos y luego ejecutar pruebas automatizadas en dispositivos reales en la nube. Hoy nos vamos a centrar en ambos tipos de dispositivos. Voy a mostrar cómo ejecutar una aplicación de Android en un dispositivo real, pero también echaremos un vistazo a los simuladores.

De acuerdo, voy a abrir aquí una compilación que se realizó un poco antes. Esta es una compilación de iOS y es una compilación de simulador. Una vez que la compilación se ha completado en AppFlow, tenemos nuestro registro de compilación.

Puedo ver el ID de compilación que se utilizó en la plataforma. Puedo ver el ID de compilación que se utilizó en la plataforma. Sí, así es. Buena pregunta, Jerry, gracias por eso. Por defecto, el stack de compilación incluye esas versiones de NPM o Yarn, puedes elegir un stack de compilación más nuevo si no ves la versión que necesitas, o también puedes manipular el comando de instalación para incluir la instalación de paquetes adicionales. Así que vamos a ejecutar el comando de instalación y luego puedes usarlo para instalar una dependencia diferente en tu entorno.

Entonces, hay un stack de compilación predeterminado, pero si necesitas instalar un administrador de paquetes diferente o una versión diferente, también puedes hacerlo como parte de la ejecución en sí. Sí, gran pregunta. Volviendo al registro de compilación aquí, puedes ver el registro de compilación. También puedes ver toda la información sobre la compilación en sí, como qué stack de compilación se utilizó, qué commit la activó, quién la activó, puedes volver a ejecutarla si tienes algún problema. Y aquí también puedes descargar los artefactos. Puedes descargar el Xarchive y el appfile. Cualquier persona que tenga acceso a la cuenta puede entrar y descargar el paquete en sí. Esto abrirá el archivo zip y voy a tomar esto aquí y puedes ver cómo tengo mi pequeña aplicación aquí. Así que voy a abrir mi simulador ahora. Estoy abriendo mi simulador, que viene preinstalado en Xcode y dejando que se inicie. Y esto es lo que quiero decir cuando hablo de un simulador, es básicamente como un teléfono falso en tu computadora y puedes interactuar con él de la misma manera que lo harías con un iPhone 14 Pro, que personalmente no tengo. Así que es agradable poder ver uno, al menos en un entorno simulado. Y puedes ver que tengo mis pequeñas aplicaciones de demostración aquí que he estado arrastrando, pero voy a arrastrar el archivo de la aplicación y eso lo voy a instalar en el simulador y una vez que esté instalado, puedo abrirlo y boom, puedo ver mi aplicación. Así que nuevamente, esta es una aplicación muy simple, solo para poder construir, pero así es como puedes ejecutarla en un simulador. Básicamente, solo arrastras el archivo de la aplicación, lo siento, arrastras el archivo de la aplicación para Android, son apks, y puedes interactuar con él en el simulador. Si no tuviera nada más que hacer en esta aplicación, podría hacer clic y trabajar con ella. Ahora echemos un vistazo a nuestra compilación de Android aquí. Para nuestra compilación de Android, nuevamente, esta es nuestra compilación de depuración, vamos a tener nuestro aab y nuestro apk. Estos son los artefactos asociados con una compilación de Android. En AppFlow, verás que tienes este código QR que aparece. Entonces, si quieres ejecutar esto en un dispositivo real, puedes escanear ese código QR con un dispositivo Android y abrirlo en tu teléfono. Así que voy a hacer eso ahora. A veces tengo problemas porque tengo una pantalla curva, así que a mi teléfono no le gusta el código QR. Sí, déjame intentarlo. Voy a mover esto a mi otra ventana donde tengo una pantalla plana. Y voy a hacer clic en el código QR que aparece. La URL lo que hace es que básicamente me lleva a un bucket de S3 de AWS donde se instala el APK. Va a preguntar si quieres descargarlo. Sí o no. Así que vas a descargar eso. Luego puedes abrirlo. Va a pedirte que omitas la función de seguridad. Así que obviamente solo debes hacer esto con aplicaciones cuyo código base conozcas. Y luego se abrirá en el dispositivo Android y podrás ver e interactuar con tu aplicación en un dispositivo real también. Así que vamos a ver aquí que nuestra compilación de Android de depuración está completa. Así que puedo hacer esto nuevamente con nuestra versión más nueva. No sé si puedes verlo, pero esta versión antigua tiene algo extraño en el estilo en el fondo, hay una línea extraña aquí. Así que esa es la versión anterior que tenía. Voy a actualizar a la versión más nueva escaneando nuevamente el código QR en mi pantalla plana. Pensé que una pantalla curva se veía genial cuando la conseguí, pero me está dando problemas. Y luego, nuevamente, solo tomará unos segundos para descargar e instalar ese archivo y podré ver la versión actualizada.

Entonces, para Android, solo necesitas una clave de carga para generar tu paquete firmado. Esa es la versión firmada de lo que acabamos de hacer. En el lado de iOS, necesitarás dos credenciales. Necesitas un certificado de firma. Un certificado de firma valida tu identidad y que estás autorizado para crear el paquete firmado. Un perfil de aprovisionamiento es una especie de colección de toda la información que necesitas para generar el paquete firmado. Incluye qué certificado de firma se está utilizando. Incluye en qué dispositivos puede ejecutarse la aplicación. Incluye el ID de la aplicación y también incluye un nombre y para generar la firma del paquete firmado. Entonces, para iOS, necesitas ambas credenciales para generar un paquete firmado y deben estar en tu entorno cuando compiles tu aplicación.

Entonces, si estás compilando localmente en Android Studio, puedes generar un APK, y Android te guiará a través del proceso para hacer esto y puedes hacerlo en tu máquina. Pero si quieres hacer esto en la nube o compartirlo entre equipos o no quieres que alguien ejecute tu compilación, ahí es donde es más importante saber qué está sucediendo bajo el capó con esa clave. Sé que hablamos de EIS antes, pero creo que en EIS es un comando que puedes ejecutar para generar credenciales. Crea la clave por ti y la almacena en sus servidores. Entonces, esto es lo que está sucediendo bajo el capó, en realidad está creando este archivo de almacén de claves. También hablaremos de esto, voy a omitir esto aquí. Entonces, para iOS, hay algo llamado firma automática que habilitas en Xcode. Quieres asegurarte de que esté habilitado. Lo que hace es permitir que Xcode administre tus activos de firma por ti. Debes conectar tu cuenta de desarrollador de Apple a Xcode y luego creará tus certificados de firma y los dispositivos que conectes en Xcode, y creará tus ID de aplicación, administrará tus perfiles de aprovisionamiento. De hecho, debes mantener esto marcado incluso si vamos a usar App Flow porque eso es lo que permite que App Flow administre las credenciales de firma por ti. Pero nuevamente, vamos a seguir el proceso de generar tu certificado de firma y tu perfil de aprovisionamiento para que estén en el entorno de Apple que necesita estar para crear tus compilaciones. De acuerdo. Para mostrarte cómo se ve eso en App Flow, voy a cambiar a otra aplicación aquí. Y te mostraré cómo se ve una vez que se haya completado y luego seguiremos el proceso juntos. Esta es otra aplicación similar a React Native que tengo en App Flow. Y en certificados de firma de compilación, aquí es donde he cargado mis credenciales de firma para usar en mis compilaciones en la nube. Tengo una credencial de desarrollo. Y luego tengo mi credencial de producción. Así que mencioné que para iOS, hay una compilación de desarrollo que puedes hacer para ejecutar en un dispositivo en modo de desarrollo. He subido mi certificado y mi perfil de aprovisionamiento aquí, y ahora Apple tiene acceso a ellos para aplicarlos automáticamente cada vez que creo una compilación. Lo mismo ocurre con mi versión de lanzamiento, tengo mi perfil de distribución y mi certificado, también en el lado de Android tengo mi archivo de almacén de claves. Eso significa que cuando creo compilaciones de lanzamiento, compilaciones de producción, como esta, puedo hacerlo para implementar en la App Store, se almacenarán en App Flow, no tengo que preocuparme por instalarlos manualmente en mi entorno. Porque si quieres instalar manualmente en tu entorno, así es como se ve ese proceso. Entonces. Este es un ejemplo de una acción de GitHub para una compilación de debug de Android. Estoy configurando mi stack de compilación en este paso. Estoy instalando mis dependencias. Aquí estoy empaquetando mi aplicación y luego ejecuto el comando de compilación de debug con Gradle. Y luego subo mi artefacto de compilación. Entonces, esto está replicando lo que acabamos de hacer en App Flow pero en GitHub Actions. Si quieres hacer una compilación firmada, debes actualizar la configuración de firma en tu archivo build.gradle para obtener variables de entorno almacenadas en GitHub Actions y usar secretos. También necesitas debug o descodificar el archivo de almacén de claves para instalarlo en el entorno.

Debes hacer lo mismo para iOS. Estos son los documentos de GitHub Actions para instalar tu certificado en ejecutores de Mac OS. Como puedes ver, debes almacenar el certificado de compilación y el perfil de aprovisionamiento como un archivo codificado en base64. Luego, necesitas crear rutas temporales para almacenar esos archivos. Los importas desde tus secretos. Lo siento, desde tus secretos. Luego, debes instalarlos en esas rutas temporales y asegurarte de que se apliquen a las rutas correctas para asegurar que estén en el entorno. Al cargar en AppFlow, estamos abstrayendo esta parte. Sí. Sí, compartiré las diapositivas. De hecho, incluso puedo ponerlas en el chat ahora mismo. Entonces, las diapositivas que te estoy mostrando aquí, son las diapositivas de envío de React Native que están en la página de Recursos. Así que puedo compartir estas diapositivas contigo. Veamos, enlace solo para ver, copiar. Así que lo pondré en el chat ahora mismo, para que puedas seguir. Y luego nuevamente, estas diapositivas de la aplicación de envío de React Native enlazarán a las diapositivas más detalladas aquí también. Muy bien. Entonces, sigamos adelante y ahora vamos a pasar por el proceso de generar nuestras claves de firma. ¿Alguien quiere hacer un descanso antes de hacer eso o están listos para seguir adelante? Tal vez pulgares arriba si están bien para seguir adelante. ¿Todos están bien? De acuerdo. Genial. Muy bien. Entonces, como dije, creo que la forma más fácil de generar tu clave de carga para Android es en Android Studio. Así que vamos a abrir Android Studio. Y lo vamos a dejar abierto. Y voy a abrir el proyecto aquí. Entonces, nuevamente, puedes usar key tool, que es una herramienta de línea de comandos CLI. Pero creo que eso es un poco más complejo. Tienes que usar los comandos RSA. Solo para mostrarte cómo se ve eso. Estará en las diapositivas aquí. Veamos. Sí. Entonces, si estás usando key tool, será, no tengo las diapositivas para key tool. Las compartiré más tarde. Me aseguraré de compartirlas. Permíteme abrir eso aquí, en realidad. Puedo cubrir eso en mi presentación. Entonces, si estás usando key tool, esto es cómo se ve. Es un comando CLI que ejecutas y pasas algunos comandos. Me aseguraré de compartirlos también. Pero para Android Studio, vamos a abrirlo aquí. Tenemos nuestro proyecto abierto. Deberías haber podido seleccionarlo. El mío estaba en lo reciente. Ahora, si el tuyo no estaba. Si no lo puedes ver, simplemente puedes hacer clic en abrir y luego ir a donde está almacenado. Y en ese caso, en realidad vas a seleccionar la parte de Android. Entonces, mira cómo es mi ruta React Native tests slash Android.

Entonces, cuando vayas a abrirlo en Android Studio, selecciona la opción de Android y se abrirá. Voy a abrirlo desde mi compromiso aquí. ¿Alguna pregunta sobre cómo abrirlo en Android Studio?

De acuerdo. Entonces, vamos a construir y vamos a generar los paquetes de firma y vamos a elegir cuál de ustedes es eso. Veamos... Android SDK Java. De acuerdo, sí, ¿está diciendo que no puede encontrar tu como Japan Home o tu versión del SDK de Android porque eso es algo que surge y no lo has hecho, sí, de acuerdo. Y sucede si no has configurado tu entorno local, tienes que establecer esa variable en tu lote. Pero está bien, eso es. Sí. Entonces, si sabes cómo solucionar eso, podemos seguir adelante. Pero sí, vamos a construir y luego generar el paquete de firma APK. Y nuevamente, esto será como el lado que vimos antes. Así que el paquete de la aplicación de Android, esto es lo predeterminado a partir de ahora para las compilaciones de la tienda de aplicaciones. Y luego vamos a hacer clic en siguiente. Y aquí, donde dice ruta del almacén de claves, así es como vas a generar tu archivo de almacén de claves. Haz clic en Crear nuevo. Y selecciona tu ruta. Me gusta mantener un archivo de almacenes de claves. Y luego lo voy a guardar aquí por ahora y hacer clic en Guardar. Oh. Almacenes de claves. Y guardar como. Vamos a llamar a esto app flow React Native Vanilla, para que coincida con esto aquí. Y guardar eso. Y eso se guardará en la ruta donde lo guardaste, tu almacén de claves. Vas a necesitar establecer una contraseña y confirmar tu contraseña del almacén de claves. Y querrás asegurarte de anotar esto en algún lugar. Guárdalo en una contraseña si solo lo haces en la masterclass, escríbelo. Pero establecerás una contraseña. Lo anotaré, porque lo olvidaré de inmediato. No tengo memoria a corto plazo en absoluto. Y también establecerás un alias. Así que voy a poner App Flow o App Native Manila. Y también establecerás una contraseña de clave. Puede ser la misma. Establecerás la validez, que es básicamente una fecha de vencimiento para el almacén de claves. Y aquí es donde completas la información de tu certificado. Recuerda, el almacén de claves y el propósito de la clave es decir, soy quien soy. Y esto es quien está creando el paquete de firma. Así que debes ingresar tu información interna aquí. Oh, sí. Entonces, relaciones con desarrolladores. Ionic. Estoy en Atlanta. Estoy en Georgia. Y tengo U.S. como código de país. Una vez que hayas seleccionado toda esta información, nuevamente asegúrate de anotar tu alias,

Porque nuevamente, una vez que estoy haciendo esto localmente, todo sucede en Xcode. Pero no importa qué proveedor esté usando, si quiero construir en la cloud, necesitaré estas credenciales. Así que vamos a ir a Xcode y luego a Configuración. Y luego vamos a hacer clic en esta pestaña de cuenta, puede que aparezca automáticamente. Pero aquí es donde verás tus ID de Apple que están conectados, así como cualquier cuenta de control de origen si estás conectado a GitHub, por ejemplo. El ID de Apple que estoy usando es mi ID de ionic. Y puedo ver mis equipos aquí. Tengo un equipo personal y luego tengo mi equipo de organización. Y aquí hay un botón para gestionar los certificados. Los certificados maestros son cómo puedo crear nuevos certificados de firma. Así que hago clic en este pequeño desplegable aquí. Y debido a que este es mi equipo personal, solo puedo crear un certificado de desarrollo. Así que si tengo un equipo de gestión aquí, aquí es donde puedo ver mis certificados existentes y también crear nuevos certificados de desarrollo o distribución. Una nota sobre la diferencia, un certificado de desarrollo será para construcciones de desarrollo. Eso es si estás haciendo una construcción de desarrollo para poder ir localmente y ponerla en un par de dispositivos. Un certificado de distribución es lo que se requiere para construir para las tiendas de aplicaciones. Así que si estás haciendo una construcción para la tienda de aplicaciones, eso es lo que necesitarás, el tipo de certificado de distribución. No voy a crear ninguno nuevo porque ya tengo algunos aquí. Pero una vez que crees eso, puedes hacer clic derecho y seleccionar exportar certificado y eso te permitirá guardarlo con un nombre y darle una contraseña. Quieres la contraseña y nuevamente, asegúrate de anotarla en algún lugar. Así que lo guardarás con un nombre y luego le darás una contraseña. Una vez que hagas eso, luego iré a mis almacenes de claves. Nunca guardé recientemente aquí. De acuerdo. Y aquí es donde verás el certificado, será un archivo P-12. Así que tengo mi Certificado de Desarrollo y tengo mi Certificado de Distribución y ambos son archivos P-12 que se exportan. Así que nuevamente, si es más fácil para ti verlo de esta manera también, lo estás guardando con el nombre de tu certificado de Distribución y le estás dando una contraseña segura. Si alguien tiene alguna pregunta o si alguien no puede generar ese certificado de firma, solo denme un pulgar hacia arriba cuando estén listos para continuar.

De acuerdo, genial. Y solo para confirmar, ¿alguno de ustedes realmente va a seguir el siguiente proceso en el programa de desarrolladores de Apple? Si no, lo explicaré bastante rápido.

De acuerdo, sí, lo explicaré rápidamente. De hecho, probablemente lo haga aquí. Este es el programa de desarrolladores de Apple. Aquí es donde puedes ver, tengo que iniciar sesión. Me cerró la sesión. De acuerdo, así que voy a hacer esto usando las diapositivas, en lugar de pasar por el proceso de iniciar sesión nuevamente. El programa de desarrolladores de Apple es donde tienes todos tus certificados, identificadores, dispositivos, perfiles, claves, servicios. Como puedes ver, tengo mi equipo conectado en Xcode. Todo se está sincronizando a medida que avanzo.

Lo que hago es, en perfiles, voy a hacer clic en este pequeño ícono de más, y eso me guiará a través del proceso de crear un nuevo perfil de aprovisionamiento. Lo primero que harás es seleccionar el tipo. Nuevamente, si estás haciendo un desarrollo, será desarrollo de aplicaciones iOS aquí. Si estás haciendo una distribución, será App Store. Luego seleccionarás tu ID de aplicación. El ID de la aplicación también está registrado en el programa de desarrolladores de Apple. Lo más probable es que solo tengas uno o dos ID de aplicaciones. Tenemos tiempo porque lo usamos para todas nuestras aplicaciones que estamos lanzando y probando. Pero selecciona tu ID de aplicación. Tienes 183 ID de aplicaciones, probablemente no sea tu caso. Luego seleccionarás los certificados asociados con tu ID de aplicación. Luego seleccionarás los certificados asociados con este perfil de aprovisionamiento. Si estás haciendo un perfil de aprovisionamiento de desarrollo, puedes tener varios certificados de firma asociados con él. Pero si estás haciendo un perfil de aprovisionamiento de distribución, seleccionarás un certificado de distribución asociado con tu equipo de firma. Luego seleccionarás los dispositivos. Esto solo es necesario si estás haciendo desarrollos o lanzamientos ad hoc. Los desarrollos y lanzamientos ad hoc requieren que tengas UUID específicos registrados. Para lanzamientos de distribución en App Store, no tendrás que pasar por este paso. Finalmente, revisarás y guardarás. Y una vez que se haya guardado, será un archivo .mobile-provision. Nuevamente, yendo a mis almacenes de claves, puedo ver aquí, he pasado por este proceso antes, y tengo, por ejemplo, para mi aplicación ReactiveNativeTest, tengo un archivo .mobile-provision que se genera. Y entonces, oh, en realidad, lo siento. Eso no está guardado en mi almacén de claves. Lo guardé en otro lugar porque lo descargué desde ADP. Pero de todos modos, una vez que haya generado eso, eso es lo que se carga en App Glow. Entonces, nuevamente, solo para explicarte lo que ya se ha hecho. Dado que muchos de ustedes probablemente no lo están haciendo ustedes mismos durante esta parte, este es el certificado, el archivo P12 que se ha cargado, y automáticamente extraerá esta información. Pero te pedirá la contraseña. Entonces, la contraseña que creaste cuando exportaste tu aplicación, debes ponerla aquí, y por eso es importante anotarla en algún lugar seguro. Lo mismo ocurre con tu perfil de aprovisionamiento, será un archivo .mobile-provision, y puedes ver cómo extrae tu identificador de paquete. Por eso necesitas tener un identificador de paquete único. Este es tu ID de equipo y es el identificador de paquete que se establece en Xcode. Por lo tanto, debe ser único y debe estar configurado para poder realizar esa compilación. Entonces, una vez que tengamos eso, podremos hacer compilaciones para App Store, hacer compilaciones de lanzamiento para Android y configurarlo. Algunas cosas que quería mencionar en este proceso es que hablé un poco sobre la versión de la aplicación, pero quiero profundizar un poco más en esto. Entonces, ya te mostré en Xcode dónde actualizar esa cadena de compilación en Xcode. También debes asegurarte de que cada nueva compilación que hagas, actualices el número de versión. Hay una manera fácil de hacer esto en App Flow, usando una herramienta llamada Trapeze, que hará coincidir automáticamente el ID de compilación con el número de versión, para que siempre tengas una nueva versión y siempre esté vinculada a tu compilación y App Flow. En el lado de Android, en realidad hay un par de lugares diferentes en los que debes actualizarlo, hay varios archivos. Si estás usando Expo, puedes pasar esto a tu app.json, y simplemente puedes establecer el nombre del paquete para Android y el nombre del paquete para iOS, y se actualizará en tus archivos nativos porque no tienes acceso a tus archivos nativos.

Para aplicaciones básicas, debes actualizar el ID de la aplicación, y también necesitas establecer las versiones de tu SDK. Estas son las versiones mínima y máxima de Android Studio que corresponden a tu compilación. Solo quería asegurarme de mencionarlo y tenerlo en cuenta, porque si no lo actualizas, nuevamente, debe ser único, y debe actualizarse en varios lugares dentro de las aplicaciones de React Native. Y luego hablamos sobre la firma de código y ahora estamos listos para hablar sobre los despliegues en la App Store.

De acuerdo. Y entonces, no creo que alguno de ustedes, algunos de ustedes hayan trabajado en el uso de aplicaciones de la App Store que se hayan desplegado en la App Store pero que en realidad no hayan sido dueños de ese proceso ustedes mismos. Así que voy a repasar algunas notas aquí, solo hablando de cómo se ve este proceso. Entonces, cuando hablamos de actualizar, subir a las tiendas de aplicaciones, en realidad no solo subes y luego lo publicas inmediatamente en la tienda. Eso realmente no sucede. Como mencioné, hay una testing manual que se lleva a cabo antes de llegar a ese punto. Entonces, para Google Play, ya sabes, debes tener una cuenta en la consola de Google Play. Cuesta $25 para configurarlo. Y es un pago único. Para Apple, tienes App Store Connect, que es una URL diferente a la del programa de desarrolladores de Apple, pero están vinculados a tu ID de Apple. Y luego vas a subir principalmente con, o es como, inicialmente se llamaba Pistas de Prueba. Entonces, para las Pistas de Prueba, en el lado de Android, dentro de Google Play, tienes tres pistas de prueba. Tienes la prueba interna, que te permite subir la aplicación y compartirla con hasta 100 personas. Esto es bueno para tus equipos de control de calidad, partes interesadas internas, te permite desplegar, y configuras a esas personas de antemano por dirección de correo electrónico. Después de eso, tienes la prueba alfa o cerrada, que te permite compartir con un grupo más amplio. Tu aplicación debe estar configurada y lista en este punto para la prueba interna. No tiene que estar completamente configurada todavía. Y finalmente, tienes lo que se llama beta, o prueba abierta. En este punto, tu aplicación está en la tienda de aplicaciones, por lo que debería estar completamente lista para los usuarios. Pero está marcada como beta, por lo que se entiende que todavía está en esa fase de testing. En el lado de iOS, tienes lo que se llaman compilaciones ad hoc. Puede que haya mencionado esto antes en los tipos de compilación. Pero esto te permite distribuir hasta 100 dispositivos de prueba al año. No basado en usuarios, sino en dispositivos. Y debes registrar esos ID de dispositivos. Entonces, lo que puede ser una mejor opción es usar TestFlight. Entonces, TestFlight está integrado en App Store Connect. Te permite, nuevamente, crear una lista de direcciones de correo electrónico que puedes compartir. Las personas descargan una aplicación llamada TestFlight en su teléfono. Y luego desde TestFlight, pueden acceder a esas versiones beta de esas compilaciones de prueba de tu aplicación. También puedes usar un enlace, como un, ya sabes, como un enlace enviado para compartirlos también. Lo bueno de TestFlight es que tiene herramientas integradas para proporcionar comentarios de tus probadores para que puedan enviar capturas de pantalla, informes de errores, etc. Entonces, en el lado de iOS, normalmente usarás TestFlight en lugar de compilaciones ad hoc. Así que vamos a repasar el proceso de configuración. Entonces, para, comenzaremos con Google con Android. Entonces, al comenzar con la Consola de Google Play, vas a tener todas tus aplicaciones, tenemos aplicaciones existentes, probablemente no las tengas, pero vas a pasar por el proceso de crear una aplicación. Le darás un nombre a la aplicación. Entonces, ya sabes, Taller de React Summit. Así es como aparecerá tu aplicación en Google Play. Vas a crear tu aplicación. Seleccionas si es una aplicación o un juego, si es gratuita o de pago, y tienes que hacer algunas declaraciones aquí. Y luego vas a crear tu aplicación. Una vez que lo hagas, te dará una lista realmente, realmente grande de preguntas que debes completar. Toma mucho tiempo, es muy complejo. De hecho, puedo mostrarte cómo se ve esto en tal vez otro existente aquí. Entonces, por ejemplo, este es el cuestionario.

Entonces, hay 11 secciones que debes completar en relación a qué tipo de acceso la aplicación solicitará a tus data. Si tienes anuncios, tu público objetivo, si está dirigida a niños o no. Debes responder todas estas preguntas antes de poder comenzar las pruebas internas. Una vez que hayas completado eso, tu aplicación estará lista para las pruebas internas, y puedes continuar y crear tu pista de pruebas internas. Aquí tengo eso bajo pruebas internas, y aquí puedo ver a mis probadores. Hasta cien probadores pueden unirse a las pruebas internas, y esto se hace utilizando listas. Puedes crear una lista de correos electrónicos y agregar personas, también puedes cargar un archivo CSV. Tengo una lista muy, muy exclusiva llamada Facilia, y solo yo, soy el único que puede probar mis aplicaciones. Pero una vez que hayas creado la lista de probadores e implementes los lanzamientos aquí, podrás ver que en este momento, la versión 1.0 está disponible para los probadores y puedes ver cuál es el código de versión, puedes ver en qué dispositivos Android es compatible según el SDK objetivo y cualquier cosa que esté en la aplicación. Y luego, si quisieras, también podrías promocionar el lanzamiento ya sea a pruebas cerradas, pruebas abiertas, que es esa prueba beta a la que me refería, o producción. Entonces, este es el lugar donde realizas tu ronda inicial de testing, luego pasarás a las pruebas abiertas o a las pruebas cerradas y luego a las pruebas abiertas. Y finalmente, estará listo para ser lanzado en la tienda de Google Play. ¿Alguna pregunta sobre las pistas de pruebas o los lanzamientos en Google Play? Muy bien.

Entonces, una nota rápida sobre App Store Connect. Lo siguiente de lo que quiero hablar es cómo configurar tu destino en App Flow. En la sección de implementación, tenemos los destinos. Y aquí es donde conectas tu Google Play y tu Test Flight.

Entonces, cuando lo seleccionas, vas a conectarlo utilizando lo que se llama un archivo de clave JSON para Android. Le das un nombre, será Google Play, aquí es donde seleccionas el tipo de pista. Aquí es donde seleccionas si estás implementando en tu versión interna, alfa, beta o producción. Por defecto, lo tengo configurado como interno, pero podrías tener uno para cada uno y luego implementarlos individualmente o promocionar esa versión directamente en Google Play.

Gracias, Leon. Gracias por estar aquí. Aquí también listarás el nombre del paquete, el formato de publicación y luego cargarás tu archivo de clave JSON. Tu archivo de clave JSON se crea en tu ID de Google. Y así es como se ve esa parte, solo porque ya he realizado este proceso antes, así que no quiero crear uno nuevo. Pero tu archivo de clave JSON se crea en la Consola de Google Play y luego en tu acceso a la API. Básicamente, crearás una cuenta de servicio. Y eso te permitirá exportar un archivo de clave JSON. Este archivo de clave JSON te permitirá interactuar con tu cuenta de Google Play. Y así es como implementamos en Google Play en tu nombre.

En el lado de Apple App Store, es un poco diferente. No utilizamos el archivo de clave JSON. En su lugar, configurarás tu ID de Apple, una contraseña específica de la aplicación, tu ID de la aplicación y luego el ID del equipo. Y nuevamente, así es como se ve en el panel de control. Aquí tenemos nuestro ID de Apple, una contraseña específica de la aplicación, nuestro ID de la aplicación y luego nuestro ID de equipo. Para crear una contraseña específica de la aplicación, iniciarás sesión en Apple ID. Es Apple ID.apple.com. Iniciarás sesión. Voy a iniciar sesión rápidamente fuera de pantalla. Y luego puedo mostrarte cómo se ve esa parte. Cierra la sesión rápidamente, acabo de iniciar sesión. Security. Two-Factor Authentication. Bien, una vez que hayas iniciado sesión, estas contraseñas específicas de la aplicación, aquí es donde generarás una contraseña específica de la aplicación. Eso se pasará aquí en tu contraseña específica de la aplicación. Tu ID de Apple es como tu dirección de correo electrónico para tu ID de Apple. Tu ID de aplicación proviene de App Store Connect. Por lo tanto, eso se encontrará en App Store Connect en tu propia aplicación. Tengo que iniciar sesión nuevamente. Dame un segundo aquí. Bien, en App Store Connect, en la información de tu aplicación, aquí es donde verás tu ID de aplicación de Apple, así que eso es lo que configurarás aquí. Entonces, tenemos nuestro ID de Apple, nuestra contraseña específica de la aplicación, nuestro ID de aplicación y luego nuestro ID de equipo, que está disponible en tu cuenta de desarrollador de Apple en Detalles de Membresía. Y lo bueno es que todos estos son enlaces aquí, por lo que cuando agregues el destino, puedes hacer clic en esto y te llevará directamente a tus Detalles de Membresía y te dará ese ID de equipo una vez que hayas iniciado sesión. Una vez que se hayan agregado esos destinos, podemos comenzar nuestras implementaciones en nuestras tiendas de aplicaciones. Lo que podemos hacer es tomar cualquiera de nuestras versiones de lanzamiento. Entonces, aquí, por ejemplo, tenemos una versión de lanzamiento de Android. Y una vez que hayamos completado eso, podemos implementar este binario. Seleccionamos nuestra versión interna de Google Play y podemos hacer clic en Implementar. Eso iniciará una carga a Google Play Interno. También podemos hacer todo esto automáticamente, como parte de un flujo único, simplemente siguiendo cada paso individualmente. Una vez que se haya completado eso, esto es lo que se verá en Google Play, nuevamente, si voy aquí a mi aplicación de React Native, se cargará la versión más reciente en mi testing interno. Y luego en mi Test Flight, sucederá lo mismo.

Y luego, bajo mi Test Flight, sucederá lo mismo. App Store Connect, Test Flight. Veré la última versión que aparecerá aquí una vez que realice mi implementación.

Bien, entonces, aquí está la cosa. Esto es por qué esto es realmente útil de ver. Esta falla al cargar en Play Store falló porque nuestro APK especifica un código de versión que ya se ha utilizado. Mencioné anteriormente que el identificador de paquete debe ser único, y lo mismo ocurre con el código de versión. Cada nueva compilación debe tener un nuevo ID de versión. Esto puede ser realmente tedioso de hacer manualmente, ¿verdad? Porque estamos enviando confirmaciones, estamos enviando confirmaciones, y luego estamos listos para hacer una carga. Entonces, lo mejor que puedes hacer en realidad es incrementar automáticamente el número de compilación, como mencioné antes, en función de lo que sucede en el ID de compilación en AppFlow. Entonces, ¿cómo podemos hacer eso? Echemos un vistazo a la configuración automática de nuestro número de compilación. Esto utiliza una herramienta llamada trapeze. Un segundo. Trapeze es una herramienta de código abierto gratuita para configurar tus aplicaciones móviles. Lo que tenemos es un archivo YAML. Este es un archivo ci.yaml que hemos nombrado donde básicamente decimos, en el momento en que ejecutamos este archivo, anula el número de compilación de iOS y el código de versión de Android con la variable de entorno del número de compilación de CI que obtenemos de nuestro CI/CD. La mayoría de los proveedores de CI/CD, prácticamente todos ellos expondrán una variable de entorno que se llama número de compilación. Y eso corresponde al número de compilación en tu CI/CD. Lo que luego sucede es que como parte de nuestros scripts de package.json, tendremos un comando de configuración de CI que podemos ejecutar. En AppFlow, AppFlow detectará automáticamente tu trapeze. Pero ejecutaremos trapeze, luego ejecutaremos ese archivo CI.yaml pasando un archivo de Android o un archivo de iOS. Y luego, cuando eso ocurra, obtendremos ese número de compilación de CI y lo anularemos con el número de compilación en el código de versión. Entonces, si tenemos esto en nuestra aplicación en nuestra base de código, no tenemos que actualizar manualmente nuestro número de versión cada vez que creamos una nueva compilación. Se actualizará automáticamente. Y la mejor parte es que automáticamente se corresponderá con ese registro. Entonces, si algo se rompe o hay algún problema, podemos vincular inmediatamente esa versión con una compilación específica y ver qué está sucediendo allí.

Entonces, una vez que hayamos logrado implementar con éxito en nuestras tiendas de aplicaciones, y hayamos pasado por ese proceso de testing. Te mostré cómo promocionar a un lanzamiento y a Test Flight en AppStore Connect. Sabes, esto está listo para enviar. También puedes configurar toda la información de tu tienda de aplicaciones aquí. Entonces, esto te permitirá preparar tu aplicación para su envío. Aquí es donde actualizarás tus vistas previas, tus capturas de pantalla, tu texto promocional, tu descripción, tus palabras clave, tus URL, todo lo que necesitas para tu listado en la tienda de aplicaciones. Luego, una vez que esté listo, es un poco diferente porque en lugar de promocionar a lanzamiento como lo haces en Google Play, agregarás para revisión. Ahora, Google Play y App Store tienen ambos un proceso de revisión. La terminología es un poco diferente. Entonces, agregas para revisión y eso lo llevará al proceso de revisión de la aplicación. Una vez que esté en revisión de la aplicación, puedes verlo aquí y luego puedes ver el estado del proceso de revisión hasta ahora. El envío de tu aplicación a las tiendas de aplicaciones no es instantáneo. La respuesta oficial de Apple es que puede llevar hasta una semana o más, lo cual es un número muy científico. Es realmente difícil trabajar con eso. Por lo tanto, comprender algunas de las razones por las que las aplicaciones son rechazadas o necesitan ser reenviadas puede ser realmente útil para asegurarte de tener un proceso de lanzamiento sin problemas. Echemos un vistazo a algunas de esas razones. Estas son las razones más comunes por las que tu aplicación puede ser rechazada en la App Store de Apple. Google Play también tiene su propio proceso de revisión, pero la mayoría de las personas con las que hablo, y la mayoría en mi experiencia ha sido que Apple es más tedioso o más difícil de ser aceptado. Casi todo el mundo es rechazado la primera vez. Sí, recientemente estuve en un evento, y había como cientos de personas, y yo pregunté, ¿quién aquí ha sido rechazado por la App Store de Apple, y casi todos levantaron la mano. Por lo tanto, si te sucede a ti, es un rito de paso, pero comprender algunas de estas razones principales puede ayudar a limitar ese proceso. Por lo tanto, los bloqueos y errores, asegurarse de que tu aplicación esté completamente probada antes de promocionarla para su lanzamiento. Si hay enlaces rotos o información incompleta o imágenes de titular de privacidad, eso puede provocar un rechazo inmediato. Los dos siguientes son problemas de política de privacidad y solicitudes de acceso a datos poco claras.

Entonces, mencioné que en el lado de Google Play, debes pasar por ese gran cuestionario. En iOS, debes declarar específicamente cada tipo de solicitud de datos que realizarás. Por ejemplo, si solicitas la ubicación de alguien, acceso a sus archivos o fotos, debes declararlo explícitamente y también dar una descripción que aparecerá cuando realices esa solicitud para explicar al usuario por qué estás solicitando esos datos. Si algo de eso no está configurado correctamente o no está claro, puedes ser rechazado y tener que volver a enviarlo.

También, una interfaz de usuario deficiente. Los documentos de desarrollo de Apple realmente te dan algunos ejemplos de capturas de pantalla de cómo se ve una interfaz de usuario deficiente. Y esto me hace reír porque si hiciéramos eso en el mundo web, aproximadamente el 60% de las aplicaciones no estarían en la web si pudieran ser rechazadas por una interfaz de usuario deficiente. Pero esa es una razón por la que puedes ser rechazado.

El siguiente es el contenido web estático. El contenido web estático no significa que no puedas tomar contenido web existente y convertirlo en una aplicación nativa. Lo que significa es que una aplicación nativa debe tener una razón para existir. Por ejemplo, si tomas un blog, como un blog web estático, y tratas de convertirlo en una aplicación nativa sin agregar ninguna funcionalidad nativa, eso puede ser rechazado porque no hay razón para que exista como una aplicación. Puede existir como un sitio web estático, ¿verdad? Absolutamente puedes tomar contenido web existente y reutilizarlo. Muchas personas hacen eso, por ejemplo, con aplicaciones Ionic y Capacitor. Pero no necesita tener una razón para existir como una aplicación nativa.

Y por último, pero no menos importante, no hay suficiente valor duradero. Esto se refiere tanto a aplicaciones de nicho que son muy específicas en su caso de uso, como a aplicaciones basadas en el tiempo. Entonces, si tu aplicación realmente solo necesita existir durante una semana o algo así, es posible que tengas problemas para ser aceptado en la tienda de aplicaciones porque no será algo que necesite existir continuamente. Es por eso que a veces verás, si tienes una aplicación muy específica en cuanto al tiempo, verás servicios que la envuelven en un tipo diferente de servicio. Por lo tanto, eso es algo en lo que debes pensar, si necesita existir en la tienda de aplicaciones o existirá durante un período de tiempo y tiene un valor duradero.

Otra cosa a tener en cuenta en términos de lanzamientos es que debes tener un soporte continuo para tus lanzamientos. Nuevamente, con las aplicaciones web, una vez que tienes una nueva versión y la lanzas, todos están en la misma versión de tu aplicación, excepto por las banderas de características o las pruebas A/B. Con las aplicaciones móviles, eso no es así, ¿verdad? Por lo tanto, debes pensar en la compatibilidad con versiones anteriores cada vez que realices cambios. Puedes descargar una versión de la aplicación y nunca actualizarla y aún existirá. Eso es lo que llamamos la larga cola de versiones de aplicaciones que debes admitir. Siempre que realices un cambio en tu backend, una API o algún servicio de terceros que estés utilizando, debes asegurarte de que siga funcionando con las versiones que aún están en uso. Tienes lo que se llama actualizaciones forzadas como mecanismo. Puedes ver esto con mucha frecuencia en aplicaciones bancarias, por ejemplo, donde intentas iniciar sesión y dice que hay una nueva versión disponible, actualízala para continuar y te lleva a la tienda de aplicaciones, ¿verdad? Por lo tanto, puedes obligar a los usuarios a utilizar una versión más nueva si tienes cambios que rompen la compatibilidad, pero debes pensar en cómo eso puede afectar la experiencia del usuario. También mencioné anteriormente que debes tener dependencias nativas específicas que estés admitiendo. Si tienes una versión antigua de tu aplicación y no la has actualizado en mucho tiempo, no has necesitado realizar nuevos cambios, pero se requiere un nuevo SDK, entonces debes asegurarte de que la aplicación se reconstruya y se publique con esa nueva versión del SDK. Por lo tanto, hay algunas cosas que debes tener en cuenta una vez que lanzas una versión, está ahí afuera y debes poder admitirla indefinidamente. Una cosa interesante es que, nuevamente, puedes ver todas las versiones que se han implementado en tu historial de implementación y tener una idea de cuál es la versión más reciente para cada implementación que se realiza. También puedes ver el número de compilación correspondiente. También puedes ver con qué confirmación está vinculado. Por lo tanto, tienes una idea de cuál es la versión más reciente que se ha implementado. Además, siempre puedes encontrar esta información en App Store Connect o Google Play también.

Estas diapositivas son muy específicas para el proceso de firma de código de React Native. Y esto incluye las instrucciones para generar certificados utilizando KeyTool para Android Studio y también en el lado de iOS, si quieres generar tu certificado utilizando la herramienta de asistencia de certificados, esto está fuera de Xcode. Entonces, si no tienes Xcode en tu máquina, esta es la forma en que puedes crear un nuevo certificado. Y es un poco más complejo. Y tiene todos los perfiles de aprovisionamiento de capturas de pantalla e información, así como también cómo puedes tener la firma automatizada utilizando la acción de GitHub que mencioné. Así que todo eso está aquí en las diapositivas para ti.

Y luego, como última nota, también tenemos un libro electrónico sobre CI/CD móvil con AppFlow. Este es un libro electrónico más conceptual de alto nivel que cubre las mejores prácticas para implementar un pipeline de CI/CD. Así que si estás interesado en eso, el enlace también está ahí.

Entonces, muy bien, genial. Bueno, en el tiempo que nos queda, ¿hay alguna pregunta que pueda responder sobre algo de lo que hemos cubierto hoy? Estoy feliz de demostrar cualquier otra cosa y también echar un vistazo a cualquier otra cosa.

De acuerdo, personalmente no he usado Microsoft App Center, pero he hablado con personas que lo han usado. Entonces, es similar en eso, típicamente el caso de uso que veo que la gente usa App Center es para la distribución. Entonces, subirán sus binarios para distribuirlos a los probadores de QA, los interesados internos, pero es muy similar en eso, tienes la opción de hacer compilaciones en la nube, también tienes la opción de hacer cargas también. Diría que una de las diferencias es que AppFlow fue diseñado inicialmente para desarrolladores de Capacitor, para desarrolladores de Ionic y Capacitor. Entonces está diseñado para ser muy fácil de usar para desarrolladores web que se están adentrando en el mundo móvil y en la plataforma cruzada por primera vez. Como puedes ver, nuestra interfaz gráfica de usuario es bastante sencilla. Es como un formulario, son como menús desplegables, como arrastrar y soltar, tratando de hacerlo lo más simple posible. Dicho esto, la razón por la que está diseñado de esa manera es porque está diseñado para hacer esas dos cosas muy bien. Está diseñado para hacer las compilaciones en la nube, el despliegue, la carga a las tiendas de aplicaciones y las automatizaciones, de la forma más eficiente y sencilla posible. Entonces, hay diferentes herramientas de CI/CD que pueden tener más complejidades pero también más características incorporadas. Así que dependiendo de cuál sea tu caso de uso, si necesitas tipos de flujos de trabajo muy específicos o si necesitas diferentes configuraciones, entonces es posible que desees una herramienta que sea más basada en YAML o que tenga una interfaz gráfica de usuario más compleja. Por ejemplo, mucha gente pregunta por comparaciones, como con Bitrise, y Bitrise tiene como 300 pasos de flujo de trabajo y un constructor de flujos de trabajo, pero se vuelve más complejo de esa manera debido a todas las características que tiene. Así que depende de cuál sea tu caso de uso. Entonces, AppFlow, la interfaz gráfica de usuario está diseñada para ser muy sencilla y simple. También tenemos una CLI que puedes integrar con CI/CD existente, pero eso es lo que he escuchado al respecto.

Sí, se puede activar desde el CI/CD de GitLab. Entonces aquí mencioné que tenemos una CLI. Nuestra CloudCLI, básicamente, lo instalas en tu pipeline, tarda menos de un segundo, lo he hecho yo misma antes en GitHub Actions, y luego puedes interactuar con él para activar compilaciones y cargas. Así que este es un ejemplo de GitLab, y puedo ponerlo en el chat, pero básicamente lo que estás haciendo es pasar tu, como un token de Appflow de Ionic, y luego estás activando tu compilación. Luego lo estás desplegando aquí en la App Store. Ahora, estás activando esto desde un runner de GitLab, pero estás usando nuestras máquinas. Entonces no necesitas tener una Mac, no necesitas aprovisionar un hardware de Mac o una máquina Mac, no necesitas instalar ninguna de esas dependencias, porque lo que estás haciendo es desde el runner de GitLab como parte de un flujo de trabajo existente, le estás diciendo a Appflow, oye, usa este commit shaw, haz una compilación de este tipo de compilación, luego devuélveme el binario, de esa manera puedo hacer lo que quiera con él. Por ejemplo, luego puedes subirlo a Sauce Labs para testing, o simplemente puedes subirlo a Microsoft App Center si quieres, o también puedes usar la CLI de Appflow para subirlo a Test Flight o subirlo a Google Play. Así que este es el ejemplo de GitLab. También he creado un ejemplo para GitHub Actions. Así que esta es la versión de GitHub Actions. Similar, solo tienes tus secretos, tienes tu token, tu ID de la aplicación, el tipo de firma que quieres usar, y luego tu destino. Y luego instalas la CLI. Lo estás compilando, nuevamente, todo esto en Ubuntu, pero podrías estar haciendo compilaciones en Mac, lo que sea que quieras, no necesitas instalar tus credenciales. Todo se hace en nuestros servidores. Y luego el AAB se envía de vuelta. Ni siquiera necesitas hacer eso. También puedes simplemente activar la carga utilizando el ID de compilación porque nuevamente todo está sucediendo en los servidores de Apple. Pero personalmente me gusta subir el AAB también en GitHub Actions, así tengo el artefacto en ambos lugares, pero eso es opcional. Y también aclarar, mencionaste específicamente GitLab CI/CD, pero también admitimos GitLab como proveedor de Git. Entonces, si no usas GitHub sino GitLab, puedes hacerlo, básicamente tenemos GitHub, GitHub enterprise, GitLab, Bitbucket, Azure DevOps, y luego algo llamado Ionic Remote, pero eso es si no tienes un proveedor de Git, pero recomendamos tener un proveedor de Git. Buenas preguntas, como dije, si surge algo, no dudes en contactarme. Estoy en Cecilia Creates en Twitter, GitHub, también es solo Cecilia en Ionic.io es mi correo electrónico. Así que si tienes algún comentario sobre AppFlow mientras lo estás probando o revisando, avísanos. Sí, las diapositivas están publicadas, así que no deberían desaparecer. Genial, bueno, gracias a todos por su participación, espero que esto les haya sido útil y sí, avísenme si tienen alguna pregunta. Y sí, honestamente, viniendo de un fondo web y aprendiendo móvil, es mucho. Así que llevará tiempo, te rechazarán, sucederá y es parte del proceso. Pero sí, en fin, fue genial conocerlos a todos y gracias nuevamente por las excelentes preguntas y participación y espero que podamos conectarnos pronto también, saludos.