Implementaciones móviles para desarrolladores web

Hola, bienvenido. Esto es Implementaciones Móviles para Desarrolladores Web. Soy Cecilia Martinez. Soy una defensora del desarrollo para aplicaciones móviles en AppFlow, la plataforma de CI/CD móvil desarrollada por Ionic. No dudes en conectarte conmigo. Estoy en Cecilia Creates en Twitter y GitHub, o también puedes conectarte conmigo en LinkedIn. Búscame por mi nombre, es n slash Cecilia Martinez. Estoy encantada de hablar contigo sobre las implementaciones móviles si tienes alguna pregunta.

La primera pregunta que puedes tener es por qué, como desarrollador web, deberías preocuparte por las implementaciones móviles. Bueno, cada vez más vemos que los usuarios utilizan dispositivos móviles. Esto significa que, como desarrollador web, estás construyendo para la plataforma móvil en términos de una aplicación web móvil o, en algunos casos, aplicaciones nativas reales también. Estamos viendo un aumento en el desarrollo multiplataforma, lo que significa construir desde una única base de código para la web móvil, iOS y Android utilizando herramientas como React Native o Ionic. Y también estamos viendo un aumento en las migraciones de web a móvil. Esto significa utilizar contenido web existente o construir una aplicación web y luego convertirla en una aplicación móvil. Puedes hacer esto con herramientas como Capacitor, que también es desarrollada por Ionic, Native Script o cualquier cosa donde básicamente agregas funcionalidad nativa y luego construyes para la plataforma Android o iOS. También puedes hacer esto utilizando lo que llamamos micro frontends móviles, donde estás incrustando contenido web en una aplicación móvil nativa. Por lo tanto, es posible que llegues a un punto en el que te pidan crear contenido web para una aplicación móvil y también necesites comprender cómo implementarlo. Por lo tanto, comprender lo que hace que el móvil sea diferente es realmente importante cuando se trata de tomar una aplicación web y convertirla en una aplicación móvil. En última instancia, lo que hace que el móvil sea diferente es la plataforma para la que estás construyendo. Cuando construyes una aplicación web, estás construyendo para software o estás construyendo para un navegador. Tu aplicación web interactuará en última instancia con otra pieza de software y se ejecutará en ese navegador. Para una aplicación móvil, estás construyendo para hardware. Estás construyendo para un dispositivo nativo real. Y debido a eso, estás compilando un binario nativo que luego se ejecutará en ese dispositivo en un momento posterior una vez que se haya instalado. Esto es diferente a una aplicación web donde tenemos código interpretado que es realmente dinámico y que se ejecuta en el navegador en tiempo de ejecución. Estas son las diferencias que ocurren entre la web y el móvil que deben tenerse en cuenta. Pero en general, la gran diferencia es que con el móvil, la plataforma establece las reglas. Con una aplicación web, tienes control total sobre cuándo implementas tu aplicación, qué herramientas utilizas para construirla, qué dependencias utilizas. Con el móvil, eso no es así. Ya sea que estés construyendo para iOS, Android o ambos, esas plataformas van a dictar

gran parte del proceso de implementación. Así que echemos un vistazo a ese proceso de implementación y las diferentes etapas y cómo las implementaciones web y móviles son diferentes en cada etapa. Comenzaremos con pruebas. Cuando pensamos en las pruebas para las aplicaciones web, por lo general, estamos probando en un entorno de desarrollo, pruebas o puesta en escena. También se pueden realizar pruebas en producción, pero nos centraremos en las pruebas previas a la producción por ahora. Cuando realizas pruebas en un entorno de desarrollo, pruebas o puesta en escena, puedes probar tu código real utilizando pruebas unitarias, pruebas de integración o pruebas de API. También puedes realizar pruebas de extremo a extremo donde lanzas tu aplicación en un navegador, generalmente de forma invisible, y ejecutas tus pruebas automatizadas. Idealmente, se realizarán pocas pruebas manuales para tu aplicación web. Idealmente, tienes muchas pruebas automatizadas lo que permite una integración continua automatizada. Esto significa que si realizas un cambio en tu código, todas tus pruebas se ejecutan automáticamente y si todo parece correcto, puedes integrar ese cambio en tu código sin necesidad de realizar muchas pruebas manuales. Es muy diferente en el lado móvil. Esto se debe a que necesitas tener una compilación binaria nativa para las pruebas de extremo a extremo. También necesitas poder probarlo en un dispositivo. No puedes simplemente lanzarlo en un navegador y hacerlo en tu entorno de pruebas. Esto significa que debes aprovechar tanto los dispositivos virtuales como los dispositivos reales para las pruebas. Y también se requiere un mayor número de pruebas manuales. Existen marcos de pruebas automatizadas para probar tanto en dispositivos virtuales como en dispositivos reales, pero lo que generalmente veremos es que habrá múltiples rondas de versiones de prueba y se utilizarán probadores manuales y seguimientos de pruebas para probar completamente tu aplicación antes de que se lance a los usuarios. Mencioné que hay varias opciones de dispositivos para las pruebas, por lo que tienes dispositivos virtuales. Estos serán emuladores para Android o simuladores para iOS. Hay algunas pequeñas diferencias técnicas entre los dos, pero en última instancia, lo que hacen es replicar un dispositivo real, pero se ejecuta en tu computadora. Es un dispositivo virtual. Estos pueden ser útiles para ver implementaciones rápidas de tu aplicación o mostrarla a las partes interesadas o realizar algunas pruebas de depuración, pero no replican completamente la experiencia de un dispositivo real. Por eso, generalmente debes realizar pruebas en dispositivos reales en algún momento. Puedes conectar un dispositivo real a tu máquina de desarrollo, conectar tu iPhone o tu dispositivo Android y ejecutar la aplicación que estás construyendo. También puedes instalar manualmente el binario en tu dispositivo. AppFlow, por ejemplo, tiene un código QR de Android donde después de compilar tu aplicación de Android puedes escanear el código QR y se instalará y abrirá en tu dispositivo de pruebas de Android. También puedes cargar el binario en lo que se llama una granja de dispositivos reales. Esto se puede hacer con pruebas automatizadas, por lo que cargas tu compilación de la aplicación que acabas de crear y puedes ejecutar pruebas automatizadas en dispositivos reales en la nube. Algunos de estos incluyen AWS Device Farm, Sauce Labs, hay bastantes opciones. Pero te permiten realizar algunas pruebas en dispositivos reales sin tener que aprovisionar esos dispositivos reales tú mismo.

También existen canales de prueba. Entonces, cuando mencioné anteriormente que la plataforma establece las reglas, eso es de lo que estamos hablando en este ejemplo cuando hablamos de canales de prueba. Tanto Google Play como iOS tienen métodos específicos para lanzar tus aplicaciones a probadores.

En el lado de Google Play, tienes tres pistas de prueba. Tienes la interna, que se utiliza para implementaciones rápidas de hasta 100 usuarios. Puedes implementar aplicaciones que aún no se hayan configurado completamente en pistas de prueba internas. Es bueno para tus probadores de control de calidad, partes interesadas, cualquier cosa que sea interna para tu organización. Debes autorizar a todos en esta lista manualmente con una dirección de correo electrónico. Por lo tanto, no se debe utilizar para lanzar tu aplicación de manera más amplia.

Luego tienes la pista de prueba alfa, que también se llama pista de prueba cerrada. Esto permite implementaciones en una lista más amplia de probadores autorizados. Entonces, si necesitas más de los 100 para la interna, entonces deberás pasar a la pista de prueba beta, que también se llama pista de prueba abierta. Cuando estás en beta, cualquier persona puede instalar y probar tu aplicación. Por lo tanto, debe estar lista para aparecer en la tienda de Google Play y lista para ser visible. Esta es realmente la última etapa de las pruebas antes de lanzar tu aplicación por completo.

En el lado de iOS, tienes lo que se llaman lanzamientos ad hoc. Los lanzamientos ad hoc se pueden utilizar para implementar aplicaciones en hasta 100 dispositivos al año. Entonces, Google Play se basa en usuarios. Apple ad hoc se basa en dispositivos. Cada dispositivo de prueba debe agregarse manualmente a tu perfil de aprovisionamiento y tú construyes tu aplicación. Por lo tanto, nuevamente, es útil para las pruebas internas, tus pruebas de control de calidad, solo tus partes interesadas. Si necesitas implementar en más dispositivos de prueba, o si estás listo para compartirlo de manera más amplia, entonces está Apple TestFlight. Apple TestFlight es un programa proporcionado por la App Store de Apple que te permite invitar hasta 10,000 probadores utilizando direcciones de correo electrónico o también puedes compartir un enlace público. Lo bueno de TestFlight es que tiene herramientas integradas para recopilar comentarios, como informes de errores, envío de capturas de pantalla, cosas que facilitan la obtención de comentarios de tus probadores mientras está en el programa. Debes tener una compilación de la tienda de aplicaciones para implementar en TestFlight, por lo que tu aplicación debe estar configurada y lista para eso.

Hablando de compilaciones de la tienda de aplicaciones, hablemos del proceso de compilación a continuación. Cuando estás construyendo para la web, técnicamente no necesitas una compilación real. Esto es un requisito del desarrollo web moderno, donde estamos utilizando cosas como frameworks y transpiladores en paquetes para optimizar o minimizar HTML, CSS, JavaScript y nuestros activos estáticos para la web. Es muy fácil realizar actualizaciones de forma dinámica en la web. Las compilaciones web no deberían llevar mucho tiempo. Podemos implementar actualizaciones muy rápidamente cuando hablamos de construir nuestras aplicaciones web.

En el lado móvil, como mencioné anteriormente, estás creando un binario ejecutable para tu plataforma nativa. Esto también significa que debes tener requisitos de infraestructura muy específicos en el entorno en el que vas a construir. Ya sea que lo hagas localmente, manualmente en tu computadora Mac, o en un entorno de CI/CD, necesitarás hardware Mac para las compilaciones de iOS. También necesitarás tener instaladas versiones específicas de Xcode y Android SDK en tu entorno para poder construir tu aplicación móvil.

Hay tipos de compilación muy específicos entre los que debes seleccionar, y debes asegurarte de versionar cada compilación correctamente, porque se requieren diferentes versiones a medida que actualizas tu aplicación. Y querrás poder hacer un seguimiento de qué versión de la aplicación estás construyendo y cómo se relaciona con la versión de tu base de código. La mayor diferencia, sin embargo, cuando se trata de construir tu aplicación móvil, será el proceso de firma de código. Mencioné los tipos de compilación. Para Android, hay tipos de compilación de depuración y lanzamiento. Para iOS, hay simulador, desarrollo, ad hoc, App Store y empresa. En última instancia, necesitarás una compilación de la App Store para poder lanzarla en TestFlight o en la App Store. En Android, necesitarás una compilación de lanzamiento si quieres lanzarla en las pistas de prueba beta o producción, y luego también lanzarla. De lo contrario, los otros tipos de compilación son útiles para varios tipos de pruebas y desarrollo.

Mencioné la firma de código. Lo que hace es validar la identidad del firmante, así como en qué dispositivos puede ejecutarse, y desde una perspectiva de seguridad, garantiza que el binario de la aplicación no se haya modificado desde el momento en que se firmó. La firma de tu aplicación de Android implica dos credenciales. Tienes una clave de carga que se genera localmente en tu máquina, y lo que hace es utilizarse durante el proceso de compilación para generar lo que se llama un paquete firmado. Este es un archivo .keystore o .jks. También hay una clave de firma de la aplicación, y esta suele generarse por Google y se utiliza para firmar tu aplicación después de haberla subido a la tienda de aplicaciones, pero antes de que se entregue a los usuarios. No necesitas esto en tu entorno de compilación, por lo que no es necesario si estás utilizando un pipeline de CI/CD para tu compilación. Esto es algo que ocurre dentro del proceso de Google Play. Lo menciono porque se llama clave de firma de la aplicación, por lo que algunas personas piensan que necesitas tenerla durante el proceso de compilación. Para iOS, tienes dos credenciales, un certificado de firma, que valida la identidad de quien generó esa compilación autorizada, y también un perfil de aprovisionamiento que indica en qué dispositivos puede ejecutarse un paquete firmado. Si estás haciendo una compilación para la App Store y tienes lo que se llama un perfil de aprovisionamiento de distribución, lo que significa que la aplicación puede ejecutarse en cualquier dispositivo, pero como mencioné, para esas compilaciones ad hoc, debes especificar en qué dispositivos puede ejecutarse, y es entonces cuando necesitarás tener un perfil de aprovisionamiento específico que enumere todos esos dispositivos. Todas estas credenciales, en realidad todas estas credenciales, deben estar en tu entorno cuando vayas a construir tu aplicación.

Una vez que tu aplicación se ha construido y firmado, está lista para su implementación. Cuando hablamos de implementación, hablamos del proceso de llevar realmente la aplicación a los usuarios, ¿verdad? Para la web, lo único que tienes que hacer es colocar los archivos en el servidor. Eso es todo. Recuerdo que solía usar FTPZilla en el pasado y simplemente arrastraba la nueva carpeta de archivos de compilación y la reemplazaba por la anterior, y una vez que eso se completaba, todos tus usuarios

Tienes control sobre cuándo se implementa tu aplicación. La plataforma establece las reglas. Debes enviar tu aplicación para su aprobación en la tienda antes de que pueda ser implementada para los usuarios. Hay algunas formas de hacer que las aplicaciones lleguen a los usuarios, evitando las tiendas de aplicaciones, pero es muy, muy raro y, sinceramente, la mayoría de los usuarios no instalarán una aplicación que no provenga de la tienda, y con razón. Las tiendas de aplicaciones establecen políticas específicas de privacidad y seguridad para garantizar la calidad de las aplicaciones, por lo que también debes crear una lista en la tienda. Necesitarás tener todos los detalles y activos en esa lista, como el ícono de la aplicación, capturas de pantalla y vistas previas, y también deberás establecer tus acuerdos de privacidad y datos. Cuando usas una aplicación móvil y esta solicita acceso a tus fotos o ubicación, estas son solicitudes de acceso a datos que deben especificarse en la lista de la tienda, al igual que el código de tu aplicación y los permisos que necesitas, y esto puede hacer que tu aplicación sea rechazada si no se configuran correctamente. El proceso de aprobación puede llevar hasta una semana o más. No te dan un número específico y, si te rechazan, debes pasar por un proceso de reenvío que puede llevar aún más tiempo. Debido a esto, no tienes tanto control sobre el proceso de implementación y estás a merced de las tiendas de aplicaciones. Por eso es muy importante comprender las pautas de aprobación de la tienda y qué puede causar el rechazo de tu aplicación. Estas son las razones proporcionadas por Apple, las razones más comunes por las que se rechazan las aplicaciones. Incluyen cosas como no poder tener fallas o errores en tu aplicación, ni enlaces rotos ni información de marcador de posición. Mencioné específicamente el problema de la política de privacidad y las solicitudes de acceso a datos poco claras, eso definitivamente es un gran problema. Tampoco puedes tener una interfaz de usuario deficiente. La documentación de Apple proporciona algunos ejemplos de capturas de pantalla de lo que consideran una interfaz de usuario deficiente. Esto me hace reír un poco porque si no permitiéramos interfaces de usuario deficientes en las aplicaciones web, muchas de ellas no estarían en producción. El contenido web estático, esto no significa que no puedas usar contenido web en tu aplicación nativa, solo significa que la aplicación nativa debe tener una razón para ser nativa. Si tomas un blog existente, por ejemplo, y lo conviertes en una aplicación móvil nativa sin hacer cambios, eso es algo que podría ser rechazado porque no necesita existir como una aplicación. Además, tu aplicación puede ser rechazada por no tener suficiente valor duradero. Por eso es importante comprender cuáles son estos posibles obstáculos para que puedas implementar rápidamente. Esto se debe a que necesitarás poder mantener tu aplicación a medida que avanza, ¿verdad? Cuando hablamos de mantener aplicaciones web, como mencioné antes, tenemos control sobre nuestras propias implementaciones y todos los usuarios tienen la misma versión de la aplicación al mismo tiempo. A excepción de las banderas de funciones o las pruebas A-B, una vez que el usuario accede al servidor, obtiene la misma versión de tu aplicación. Con las aplicaciones web, es posible que debas mantener algunas dependencias. Pero en última instancia, puedes elegir qué dependencias necesitas y cuándo actualizarlas. Por lo tanto, tienes un control total sobre tus lanzamientos. Y puedes corregir errores críticos o actualizar cuando sea necesario. No es fácil corregir errores en dispositivos móviles. Tampoco es fácil actualizar y mantener tu aplicación en dispositivos móviles. Esto se debe a la larga lista de versiones de aplicaciones que se deben admitir.

En Web, todos tienen la misma versión de tu aplicación, pero en móvil, eso no es así, ¿verdad? Puede que tengas tu aplicación configurada para actualizarse automáticamente en la tienda de aplicaciones, o puede que tengas una versión muy antigua de una aplicación en tu teléfono porque nunca la has actualizado manualmente. Si realizas cambios en tu API, tal vez agregues nuevas características, debes asegurarte de que tu aplicación siga funcionando incluso en las versiones más antiguas que están en uso. También debes cumplir con los requisitos de la tienda de aplicaciones. Tanto iOS como Android actualizan sus requisitos de seguridad y el SDK mínimo necesario para construir tu aplicación. Si no cumples con estos requisitos, puedes ser eliminado de la tienda de aplicaciones. También debes pensar en cuál será tu estrategia de actualización, ya que las correcciones de errores y las actualizaciones son difíciles de implementar. Si estás construyendo una aplicación multiplataforma o una aplicación que utiliza contenido web, una opción para las correcciones de errores es utilizar implementaciones en vivo, o lo que llamamos implementaciones por aire. Esto te permite actualizar el contenido web de tu aplicación sin lanzar una nueva versión de la tienda de aplicaciones. No puedes utilizar esto para cambios nativos y tu aplicación debe estar preconfigurada. Pero existen diversas herramientas disponibles que te permiten enviar nuevos cambios a ese contenido web y evitar una nueva versión nativa. Tenlo en cuenta como una posible estrategia de actualización. Hay beneficios al automatizar este proceso, ¿verdad? Automatizar el proceso de implementación. Y serán similares a los beneficios de la automatización en la web. Tienes una reducción de los silos de conocimiento y varias personas en el equipo pueden implementar. También puedes gestionar las credenciales compartidas, por lo que no necesitas generar individualmente los certificados de inicio de sesión y los perfiles de aprovisionamiento. Obviamente, tienes una mayor velocidad de lanzamiento si puedes automatizar algunos de estos pasos y poner tu aplicación en manos de los probadores más rápidamente. También tienes una mejor visibilidad del proceso de implementación. Puedes ver quién generó una compilación, a qué confirmación de código correspondió, qué versión corresponde en la tienda de aplicaciones tanto para iOS como para Android, todo en un mismo lugar. Tienes algunas opciones de herramientas cuando se trata de automatizar tus compilaciones. Algunas de ellas serán específicas de la plataforma, es decir, solo para iOS o Android. Algunas de ellas serán específicas del marco de trabajo, es decir, solo para React Native o solo para Capacitor. O algunas de ellas serán generales, en el sentido de que se pueden utilizar para varias plataformas y varios marcos de trabajo. También hay herramientas para integrarse con tu plataforma CICD existente, o utilizar algo específico para móvil, pero dedicado a tus implementaciones móviles. Cuando hablamos de herramientas CICD, hay algunas que tienen una sola función, es decir, solo realizan la compilación, solo la distribución, solo la configuración, pero lo más probable es que veas herramientas multifunción. Estas son cosas como Fastlane, que es desarrollado por Google, que te permite gestionar la versión, la compilación, la carga y la publicación de diferentes fases de tus implementaciones CICD. También hay interfaces de línea de comandos y APIs de servicios en la nube, como AppFlow, CodeMagic, Bitrise y AppCircle, que ofrecen múltiples funcionalidades relacionadas con las implementaciones móviles. Si no tienes una plataforma CICD existente o no quieres utilizarla para móvil, también puedes obtener una plataforma CICD específica para móvil. Por lo general, estas tienen una interfaz gráfica de usuario que te permite crear flujos de trabajo y gestionar tus certificados de inicio de sesión y tus entornos en un entorno en la nube. Nuevamente, estas pueden ser específicas de la plataforma, como Xcode Cloud, específicas del marco de trabajo, como EIS para aplicaciones Expo de React Native, o de múltiple soporte, como AppFlow y Bitrise. Al decidir qué tipo de herramientas utilizar, debes tener en cuenta la experiencia en DevOps de tu equipo. También debes pensar en la infraestructura existente que tienes. Por ejemplo, si ya tienes un equipo de DevOps dedicado con una infraestructura CICD tradicional sólida, entonces es posible que desees utilizar herramientas de manera fragmentada para integrar la funcionalidad móvil. Sin embargo, si no tienes un equipo de DevOps dedicado y alguien del equipo móvil será responsable de sus propias implementaciones, y no tienes esa infraestructura existente, es posible que desees utilizar algo que sea un servicio completo, una herramienta multifunción. También debes pensar en las plataformas que admites y los marcos de trabajo que utilizas para construir, y debes pensar en cómo protegerlos en el futuro. Ahora mismo, es posible que solo estés construyendo para una plataforma, por lo que una solución para una sola plataforma puede ser una buena opción, pero ¿tienes planes de expandirte en el futuro? Debes tener en cuenta todas estas cosas al decidir qué herramientas quieres utilizar para tus implementaciones móviles. Y si deseas obtener más información, tenemos un libro electrónico gratuito llamado Solving Mobile CICD with AppFlow, puedes escanear el código QR o visitar el enlace para recibirlo y obtener más información sobre CICD e implementaciones móviles en general. O siempre puedes comunicarte conmigo si tienes alguna pregunta. Nuevamente, me encuentro en ceciliacreates en Twitter, en GitHub. O también puedes enviarnos un correo electrónico a appflow.io. Muchas gracias.