Growing Pains: Disminuyendo los tiempos de compilación en iOS

Introducción: La amenaza fantasma

Como programadores siempre nos toca lidiar con la espera en la compilación de nuestro código, principalmente con el correr del tiempo cuando el proyecto va creciendo. PedidosYa, no es ajeno a esto, ya que tomando en cuenta que se creó el proyecto hace mas de 10 años y al pasar el tiempo la app aumentó sus funcionalidades en igual relación al tiempo de compilación de ella.

Este tiempo afecta principalmente en la productividad del desarrollador que el producto necesita para facilitar y administrar funcionalidades a los usuarios que la utilizan. Si contamos el tiempo que cada desarrollador utiliza en la espera en la compilación de la aplicación principal, cualquier project manager se podría llegar a asustar.

En esta oportunidad vamos a enfocarnos en lo que logramos sobre la aplicación de iOS para atacar este problema

Historia: Nacimiento de la fuerza

El proyecto empezó de cero utilizando Objective-C, con su código contenido en un mismo repositorio y utilizando CocoaPods para la integración de librerías de terceros. Como toda empresa en crecimiento, la aplicación necesitó expandir e integrar nuevas funcionalidades que se les ofrecen a los usuarios modificando su código de forma ágil. Este crecimiento exponencial también se vio reflejado, para peor, en el tiempo que cada funcionalidad necesitaba para su desarrollo e integración a la aplicación. Para solucionar dichos problemas se fue a un enfoque de separar el código en módulos y utilizando una comunicación por deeplinks entre los módulos.

Este proceso de desacople aún no ha terminado, ya que cierta parte de nuestro flujo principal esta aún contenido en el proyecto monolítico y sigue su proceso de modularización, lo cual lleva a los desarrolladores a compilar y probar la aplicación principal teniendo día a día que esperar a la compilación del proyecto completo.

Para disminuir el tiempo de compilación existen varios métodos como utilizar módulos como binarios, uso de SPM, terminar el desacople a módulos, crear módulos con interfaces para módulos core, implementación de modulo de DI, etc. Una de las soluciones más importantes que notamos fue el cambio de Intel a M1 donde básicamente este cambio llevó a compilaciones del monolito a la mitad de tiempo, sin duda una mejora de performance impresionante. El cambio de todas las macs a M1 para todos los desarrolladores está en proceso.

Dentro de todas las posibilidades se buscan quick wins que cumpla con:

• impactar a la mayor cantidad de devs
• afectar el producto lo mínimo posible
• permitir desarrollar, compilar y testear de forma ágil

Solución: Una nueva esperanza

Como rescate a nuestros problemas apareció Rugby, una librería que nos permite cachear todas las librerías de CocoaPods compiladas, recompilando solamente cuando alguna de ellas es modificada y en base a esas libs, modifica el proyecto generado de Pods para utilizarlas.

Dadas las posibilidades que Rugby nos presenta, creamos nuestro plan de ejecución y ejecutándolo obtenemos este quick win que estábamos buscando.

Corrimos un script que nos permite comparar los dos tiempos, utilizando Rugby y sin usarlo y demuestra que el tiempo de compilación se reduce más de un 50%. En el siguiente caso se bajó aproximadamente 9 minutos de compilación, desde un clean y build de la aplicación

Xcode 13.1
Hardware Overview
 Model Name: MacBook Pro
 Model Identifier: MacBookPro15,1
 Processor Name: 6-Core Intel Core i7
 Processor Speed: 2,2 GHz
 Total Number of Cores: 6
✅ PedidosYa has completed on default
 — Build Time (956 Seconds)
🏈 PedidosYa has completed with Rugby
 — Build Time (412 Seconds)

En base a estos números exitosos, no nos quisimos quedar ahí y analizamos agilizar nuestros procesos de deploy de los módulos al proyecto principal. Explicamos más sobre el proceso de deploy en el post Desacople de Apps Móviles para Agilizar el Desarrollo. Dicho pipeline modifica el Podfile con la nueva versión del módulo a integrar y corre unos steps de validaciones para comprobar que todo funciona correctamente y sube el cambio al repositorio principal del proyecto.

Conclusión

Encontramos una solución que nos ayuda a disminuir los tiempos de espera en la compilación del proyecto principal, pero debemos continuar indagando, desarrollando y mejorando el proyecto y los módulos desacoplados para que dicho tiempo sea aun menor. Hay que ir por todas las soluciones planeando y analizando cuál es la siguiente a realizar y mejorar la aplicación en un todo. Que te parece esta solución? Los leemos en los comentarios