GitHub Actions con runners de macOS: xcodebuild, caché y tiempos reales

El primer flujo de macOS que escribe casi todo el mundo funciona a la primera y es, sin saberlo, entre dos y cuatro veces más lento y más caro de lo necesario. No por errores gruesos, sino por tres decisiones tomadas por omisión: dejar que el agente elija la versión de Xcode que le apetezca, cachear el directorio equivocado, y volver a compilar desde cero en cada partición de la suite. Ninguna de las tres se manifiesta como un fallo, y por eso sobreviven años. Esta lección las ataca en orden, con la disciplina de medir antes y después, porque en un runner de macOS cada minuto se factura a una tarifa multiplicada respecto a Linux y eso convierte cualquier descuido en una línea de factura recurrente.

Fijar el agente: la decisión que nadie toma y todo el mundo sufre

Una imagen de macOS gestionada trae varias versiones de Xcode instaladas y una seleccionada por omisión, que cambia sin aviso cuando la imagen se actualiza. Ese cambio mueve a la vez el compilador, el enlazador, los tiempos de ejecución del simulador y el suavizado del texto. El resultado es un día en el que las instantáneas fallan en masa, la suite tarda un veinte por ciento más y nadie ha tocado el código. Fijar la versión de forma explícita es la línea de configuración con mejor relación entre esfuerzo y dolor evitado de todo el fichero.

jobs:
  verificar:
    runs-on: macos-15
    timeout-minutes: 25
    env:
      DEVELOPER_DIR: /Applications/Xcode_26.0.app/Contents/Developer
      DESTINO: 'platform=iOS Simulator,name=iPhone 17,OS=26.0'
    steps:
      - uses: actions/checkout@v4

      - name: Comprobar el entorno
        run: |
          xcodebuild -version
          xcrun simctl list runtimes | grep iOS

La variable DEVELOPER_DIR es preferible a invocar xcode-select porque no requiere permisos elevados y afecta solo a este trabajo. El paso de comprobación parece decorativo y no lo es: cuando dentro de seis meses una ejecución falle de forma extraña, ese registro será lo primero que compares entre la ejecución buena y la mala.

El segundo asunto del entorno es el simulador. Lanzar pruebas contra un dispositivo que aún está arrancando produce un fallo de tiempo agotado en el primer caso, que es exactamente el patrón que luego se describe como inestabilidad misteriosa. Arrancar y esperar de forma explícita cuesta unos segundos y elimina una clase entera de fallos.

xcrun simctl shutdown all || true
xcrun simctl boot 'iPhone 17'
xcrun simctl bootstatus 'iPhone 17' -b
defaults write com.apple.iphonesimulator SlowMotionAnimations -bool NO

Compilar una vez, ejecutar muchas

La estructura que separa build-for-testing de test-without-building es la que hace posible todo lo demás. Compilar es la parte cara y no paralelizable de forma trivial; ejecutar es la parte que se reparte bien. Si cada partición de la suite recompila, se paga la parte cara tantas veces como particiones haya, que es el error más caro y más común de los flujos de iOS.

flowchart LR
a[Trabajo de compilacion] --> b[build for testing]
b --> c[Empaquetar productos y xctestrun]
c --> d[Subir como artefacto]
d --> e1[Particion 1 test without building]
d --> e2[Particion 2 test without building]
d --> e3[Particion 3 test without building]
e1 --> f[Unir resultados]
e2 --> f
e3 --> f
f --> g[Publicar informe en la propuesta de cambio]

  compilar:
    runs-on: macos-15
    steps:
      - uses: actions/checkout@v4
      - name: Compilar para pruebas
        run: |
          set -o pipefail
          xcodebuild build-for-testing \
            -scheme MiApp \
            -destination "$DESTINO" \
            -derivedDataPath .derived \
            -skipPackagePluginValidation \
            -skipMacroValidation | xcbeautify
      - uses: actions/upload-artifact@v4
        with:
          name: productos
          path: |
            .derived/Build/Products
            .derived/Build/Products/*.xctestrun

  probar:
    needs: compilar
    runs-on: macos-15
    strategy:
      fail-fast: false
      matrix:
        particion: [1, 2, 3]
    steps:
      - uses: actions/download-artifact@v4
        with: { name: productos, path: .derived/Build/Products }
      - name: Ejecutar particion
        run: |
          xcodebuild test-without-building \
            -xctestrun .derived/Build/Products/MiApp_iphonesimulator26.0.xctestrun \
            -destination "$DESTINO" \
            -parallel-testing-enabled YES \
            -resultBundlePath resultado-${{ matrix.particion }}.xcresult

Los dos indicadores que omiten validaciones de macros y de complementos de paquete merecen mención aparte: en un agente sin interacción, esas validaciones no aportan nada porque no hay nadie que pueda aprobar el diálogo de confianza, y sí pueden bloquear la ejecución. La alternativa a desactivarlas es fijar la confianza en el propio proyecto, que es lo correcto cuando el equipo controla las macros que usa.

Cachear lo que ahorra y no lo que parece que ahorra

La caché es donde más folclore hay. La regla que ordena el asunto es sencilla: una caché solo compensa si el tiempo de restaurarla es claramente menor que el tiempo de regenerar lo que contiene, y esa comparación depende del ancho de banda del agente, no de la intuición.

      - name: Cachear dependencias de Swift Package Manager
        uses: actions/cache@v4
        with:
          path: |
            .derived/SourcePackages
            ~/Library/Caches/org.swift.swiftpm
          key: spm-${{ runner.os }}-${{ hashFiles('**/Package.resolved') }}
          restore-keys: spm-${{ runner.os }}-

La caché de compilación merece un párrafo honesto. Existe la posibilidad de cachear el resultado de compilar módulos, pero en la práctica el compilador de Swift invalida con facilidad y la ganancia depende mucho de la forma del grafo de módulos: un proyecto modularizado con fronteras estables se beneficia bastante, y un objetivo monolítico casi nada. La secuencia correcta es medir primero cuánto tarda la compilación limpia, después cuánto tarda con caché caliente, y aceptar la complejidad solo si la diferencia es grande y estable a lo largo de varias semanas.

Los tiempos reales y el momento de irse a agentes propios

Los órdenes de magnitud que conviene tener en la cabeza para una aplicación mediana, entendiendo que varían con el tamaño del proyecto pero no tanto en su proporción: la puesta a punto del agente y el clonado se van entre uno y dos minutos; resolver dependencias sin caché puede costar entre uno y tres minutos y con caché baja a segundos; la compilación limpia para pruebas de un proyecto de tamaño medio ronda los ocho o diez minutos, y con paquetes ya resueltos se queda en cinco o seis; arrancar el simulador cuesta cerca de un minuto; y la ejecución de la suite depende por completo del reparto. La conclusión que emerge de esos números es constante: la compilación domina, y por tanto cualquier esfuerzo que no la ataque produce mejoras marginales.

De ahí salen las tres decisiones que de verdad mueven la aguja, en orden de rentabilidad. Primero, no recompilar por partición, que es el patrón de la sección anterior. Segundo, no ejecutar en macOS nada que pueda correr en Linux. Tercero, reducir el trabajo del compilador en el propio proyecto, con fronteras de módulo estables y sin ficheros que fuercen recompilaciones amplias.