Guida

Una pipeline CI/CD iOS sulla tua macchina

Quasi tutti i consigli sulla CI iOS ottimizzano la cosa sbagliata. Lo step di build raramente è dove finiscono i minuti. Ecco cosa conta davvero in una pipeline reale, e come l’hardware dedicato cambia i conti.

Dove finiscono davvero i minuti

Su un runner ospitato, un tipico job iOS passa gran parte del tempo prima di compilare una sola riga del tuo codice. Risolve e scarica le dipendenze, riempie una cartella DerivedData vuota, installa gli strumenti e avvia un simulatore. Questo lavoro si ripete a ogni esecuzione, perché poi la macchina viene distrutta.

Su una macchina dedicata quel lavoro è quasi tutto già fatto. Nel nostro benchmark con l’app iOS di Wikipedia, una build pulita su un M6 mini è stata più veloce del 53 percento rispetto al runner standard di GitHub. Un tipico job CI è passato da 269 secondi a 27. Il Mac dedicato aveva tenuto la cartella di build e ha ricompilato solo ciò che era cambiato.

Una pipeline da copiare

Dividi il lavoro. Lint, test dei pacchetti Swift condivisi e automazione dei rilasci possono girare su Linux. Sul Mac metti solo il lavoro su simulatore e dispositivo.
Metti in cache i percorsi giusti. DerivedData, SwiftPM, CocoaPods e Gems. Su una macchina dedicata restano senza costi.
Usa fastlane per le parti noiose. Le lane di build, test, screenshot e upload ti danno gli stessi comandi in locale e in CI.
Rendi la firma prevedibile. fastlane match con un repository privato dei certificati è ancora l’approccio più affidabile. MacRun non gestisce la firma per te, e quindi non ti riserva sorprese.
Riduci la matrice. Le matrici complete di dispositivi e versioni del sistema vanno su main e nelle build notturne, non su ogni pull request.

Workflow di esempio

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 test

Il runner è dedicato, quindi qui non c’è uno step di ripristino della cache. Le dipendenze e la DerivedData dell’esecuzione precedente sono già sul disco.

Cosa non risolve

L’hardware dedicato non sistema una suite di test lenta, un grafo di moduli che forza ricompilazioni complete o test instabili sul simulatore. Elimina la tassa della configurazione ripetuta e il contatore al minuto. Il resto resta lavoro di ingegneria da parte tua.

Domande frequenti

Come rendo più veloci le build iOS in GitHub Actions?

Prima di ottimizzare la compilazione, taglia la configurazione ripetuta. Conserva le cache di DerivedData, SwiftPM e CocoaPods, sposta su runner Linux il lavoro che non richiede un Mac, riduci le matrici di dispositivi sulle pull request e fissa una sola versione di Xcode. Su hardware dedicato le cache restano tra un’esecuzione e l’altra in automatico.

Posso usare fastlane su un runner macOS self-hosted?

Sì. fastlane, CocoaPods, Ruby e Node sono preinstallati sulle macchine MacRun, e li usi esattamente come in locale. La firma con fastlane match funziona come su qualsiasi Mac.

MacRun gestisce la firma del codice per me?

No, ed è una scelta voluta. Tieni tu il controllo di certificati e profili di provisioning, di solito con fastlane match su un tuo repository privato. Noi forniamo la macchina, non un servizio di firma gestito.

Posso eseguire i test UI di iOS su un runner dedicato?

Sì. I simulatori funzionano normalmente. La macchina non viene riciclata, quindi lo stato di avvio del simulatore e la derived data restano caldi tra un’esecuzione e l’altra. Di solito questo toglie diversi minuti a un job di test UI.