Cómo Posh logró la entrega continua en desarrollo móvil usando Expo
En el ecosistema del desarrollo móvil, uno de los desafíos más persistentes para los equipos de ingeniería es la cadencia de lanzamiento de aplicaciones. A diferencia del desarrollo web, donde los deploys pueden ocurrir múltiples veces al día, las aplicaciones móviles históricamente han estado sujetas a ciclos de revisión en tiendas como App Store y Google Play que pueden durar días o incluso semanas. Posh, una plataforma de gestión y descubrimiento de eventos con millones de usuarios activos, no era la excepción a esta realidad, y su equipo técnico decidió enfrentarla de frente mediante una reestructuración completa de su pipeline de CI/CD mobile.
El estado inicial: un cuello de botella llamado release manager
Antes de la transformación, el proceso de lanzamiento en Posh dependía casi íntegramente de un único gestor de lanzamientos —una persona o rol centralizado responsable de coordinar, validar y ejecutar cada publicación en las tiendas de aplicaciones. Este modelo, aunque funcional en etapas tempranas del producto, comenzó a mostrar sus limitaciones a medida que el equipo de ingeniería creció y la frecuencia de cambios se incrementó. El ciclo era rígido: lanzamientos semanales, procesos manuales y una cadena de dependencias humanas que hacía que cualquier imprevisto —una ausencia, un error de configuración, una prueba fallida— bloqueara por completo la entrega de valor al usuario final.
A esto se sumaban problemas estructurales en la infraestructura de automatización existente. Las GitHub Actions configuradas para el proyecto mostraban comportamientos inestables, con ejecuciones que fallaban de manera intermitente sin razones claras, lo que erosionaba la confianza del equipo en el pipeline automatizado. Las pruebas end-to-end (E2E) se ejecutaban de forma manual, consumiendo tiempo valioso de ingenieros senior que debían validar flujos críticos antes de cada release. Adicionalmente, rastrear qué cambios nativos introducía cada Pull Request era prácticamente imposible sin una convención o herramienta específica para ello, lo que generaba incertidumbre sobre el impacto real de cada merge en la capa nativa de la aplicación.
La arquitectura de la solución: EAS Workflows, Fingerprinting y Expo Updates
La solución implementada por el equipo de Posh se construyó sobre tres pilares tecnológicos fundamentales dentro del ecosistema de Expo. En primer lugar, adoptaron EAS Workflows, el sistema de orquestación de CI/CD nativo de Expo Application Services, que permite definir flujos de trabajo reproducibles y declarativos directamente integrados con el sistema de builds en la nube de EAS. Esto eliminó la dependencia de GitHub Actions para las tareas más críticas del pipeline mobile, sustituyendo una solución genérica por una específicamente diseñada para las particularidades del desarrollo con React Native y Expo.
El segundo componente clave fue el fingerprinting de la aplicación, una técnica que consiste en generar un hash o huella digital del estado nativo del proyecto —incluyendo dependencias nativas, configuraciones de plugins y archivos relevantes de la capa nativa— para determinar con precisión si un cambio requiere o no un nuevo build nativo. Esto resolvió directamente el problema de rastrear cambios nativos en Pull Requests: el sistema ahora puede comparar el fingerprint de una rama con el de producción y decidir automáticamente si es necesario compilar un nuevo binario o si la actualización puede entregarse exclusivamente mediante JavaScript. Por último, Expo Updates habilitó las actualizaciones Over-The-Air (OTA), permitiendo publicar nuevas versiones del bundle JavaScript directamente a los dispositivos de los usuarios sin pasar por el proceso de revisión de las tiendas.
Resultados cuantificables: de ciclos semanales a entregas continuas
El impacto de esta nueva arquitectura fue inmediato y medible. Las publicaciones en App Store y Google Play, que antes ocurrían semanalmente de forma manual, se redujeron a una vez al mes. Este cambio no implicó una disminución en la velocidad de entrega de funcionalidades, sino todo lo contrario: al desacoplar los lanzamientos nativos de las actualizaciones JavaScript, el equipo pudo habilitar múltiples actualizaciones OTA por semana, llevando nuevas funcionalidades, correcciones de bugs y mejoras de experiencia directamente a los dispositivos sin fricción. La siguiente lista resume los cambios más relevantes en el flujo de trabajo:
- Eliminación del rol de release manager como dependencia crítica del proceso
- Automatización completa de las pruebas E2E dentro del pipeline de EAS
- Detección automática de cambios nativos mediante fingerprinting en cada PR
- Optimización de la ejecución de builds al evitar compilaciones nativas innecesarias
- Notificaciones automatizadas al equipo cuando un nuevo release está disponible
- Vistas previas de la aplicación mediante códigos QR generados en cada Pull Request
Este último punto merece especial atención desde una perspectiva de developer experience. La generación automática de un código QR en cada PR permite que cualquier miembro del equipo —ya sea un ingeniero, un diseñador o un product manager— pueda instalar y probar la versión exacta de la aplicación correspondiente a esa rama directamente desde su dispositivo físico, sin necesidad de configurar entornos locales ni solicitar builds manualmente. Esta capacidad transformó las revisiones de código y de producto en un proceso significativamente más ágil y confiable.
El entorno de staging como pieza central del nuevo modelo
Otro componente fundamental de la nueva arquitectura es la implementación de un entorno de staging robusto integrado en el pipeline de EAS. Antes de que cualquier cambio llegue a producción, el sistema despliega automáticamente una actualización OTA al canal de staging, donde puede ser validada en condiciones lo más cercanas posible al entorno productivo. Esto aplica tanto para actualizaciones puramente JavaScript como para aquellos casos en que el fingerprinting detecta cambios nativos y se genera un nuevo build, el cual también pasa por staging antes de ser promovido. Este flujo garantiza que la entrega continua no sacrifique la estabilidad de la aplicación en producción.
La combinación de fingerprinting, EAS Workflows y Expo Updates no solo automatizó el proceso de lanzamiento en Posh, sino que redefinió qué significa "lanzar" una aplicación móvil: ya no es un evento semanal bloqueante, sino un flujo continuo y seguro de valor hacia el usuario.
Lecciones aplicables para equipos de desarrollo móvil
El caso de Posh ofrece un conjunto de principios replicables para cualquier equipo que enfrente los mismos desafíos estructurales en el desarrollo móvil. La clave no está en adoptar herramientas específicas de manera aislada, sino en construir una arquitectura coherente que aborde simultáneamente la detección inteligente de cambios, la automatización del pipeline y la habilitación de múltiples canales de entrega. El fingerprinting como mecanismo de decisión —build nativo completo versus actualización OTA— es quizás el insight más transferible de esta experiencia, ya que optimiza radicalmente el uso de recursos de CI/CD sin comprometer la integridad de la aplicación.
En un mercado donde la velocidad de iteración es una ventaja competitiva directa, transformar el ciclo de lanzamiento móvil de una cadencia semanal con dependencias humanas a un flujo continuo automatizado representa no solo una mejora operativa, sino un cambio de paradigma en cómo los equipos pueden responder a las necesidades de sus usuarios. La experiencia de Posh demuestra que la entrega continua en mobile, históricamente considerada difícil o imposible por las restricciones de las tiendas de aplicaciones, es alcanzable con las herramientas y la arquitectura correctas.
