Un pipeline de CI/CD para iOS en tu propia máquina
Casi todos los consejos sobre CI para iOS optimizan lo que no es. El paso de compilación rara vez es donde se van los minutos. Esto es lo que de verdad cambia las cosas en un pipeline real, y cómo el hardware dedicado cambia las cuentas.
Adónde se van de verdad los minutos
En un runner alojado, un job típico de iOS pasa gran parte del tiempo antes de compilar una sola línea de tu código. Resuelve y descarga dependencias. Calienta una carpeta DerivedData vacía. Instala herramientas y arranca un simulador. Ese trabajo se repite en cada ejecución porque la máquina se destruye después.
En una máquina dedicada, ese trabajo ya está casi todo hecho. En nuestro benchmark con la app de Wikipedia para iOS, un build limpio en un mini M6 fue un 53 por ciento más rápido que en el runner estándar de GitHub. Un job de CI típico pasó de 269 segundos a 27. El Mac dedicado conservaba su carpeta de build y solo recompilaba lo que había cambiado.
Un pipeline que vale la pena copiar
- Reparte el trabajo. El lint, los tests de paquetes Swift compartidos y la automatización de releases pueden ir en Linux. Deja en el Mac solo el trabajo con simulador y dispositivo.
- Guarda en caché las rutas correctas. DerivedData, SwiftPM, CocoaPods y Gems. En una máquina dedicada se conservan sin coste.
- Usa fastlane para lo aburrido. Con lanes de build, test, capturas y subida tienes los mismos comandos en local y en CI.
- Haz que la firma sea predecible. fastlane match con un repositorio privado de certificados sigue siendo lo más fiable. MacRun no gestiona la firma por ti, así que tampoco hay sorpresas.
- Recorta la matriz. Las matrices completas de dispositivos y versiones van en main y en las ejecuciones nocturnas, no en cada pull request.
Workflow de ejemplo
name: iOS
on: [pull_request]
jobs:
test:
runs-on: [self-hosted, macOS, macrun-unit-01]
steps:
- uses: actions/checkout@v4
- run: sudo xcodes select 26.6
- run: bundle install
- run: bundle exec fastlane testComo el runner es dedicado, aquí no hay paso de restaurar caché. Las dependencias y DerivedData de la ejecución anterior ya están en el disco.
Lo que esto no resuelve
El hardware dedicado no arregla una suite de tests lenta, un grafo de módulos que obliga a recompilarlo todo ni unos tests de simulador inestables. Elimina el peaje de preparación repetido y el contador por minuto. Lo demás sigue siendo trabajo de ingeniería por tu parte.
Preguntas frecuentes
¿Cómo acelero los builds de iOS en GitHub Actions?
+
Recorta la preparación repetida antes de optimizar la compilación. Conserva las cachés de DerivedData, SwiftPM y CocoaPods. Pasa a runners de Linux lo que no necesite Mac, recorta las matrices de dispositivos en las pull requests y fija una versión de Xcode. En hardware dedicado las cachés se conservan solas entre ejecuciones.
¿Puedo usar fastlane en un runner de macOS self-hosted?
+
Sí. fastlane, CocoaPods, Ruby y Node vienen preinstalados en las máquinas de MacRun, y los usas igual que en local. La firma con fastlane match funciona como en cualquier Mac.
¿MacRun se encarga de la firma de código?
+
No, y es a propósito. Tú controlas tus certificados y perfiles de aprovisionamiento, normalmente con fastlane match y tu propio repositorio privado. Nosotros ponemos la máquina, no un servicio de firma gestionado.
¿Puedo ejecutar tests de UI de iOS en un runner dedicado?
+
Sí. Los simuladores funcionan con normalidad. Como la máquina no se recicla, el estado de arranque del simulador y los datos derivados siguen en caliente entre ejecuciones. Eso suele ahorrar varios minutos en un job de tests de UI.