Pourquoi GitHub Actions iOS CI est si lent sur Mac ? Le vrai gain, c'est le self-hosted runner

Allons droit au but : si votre iOS CI est lent sur GitHub Actions, ce n'est généralement pas un problème de code applicatif, mais un problème d'environnement de build macOS. Pods, Xcode, signature, export IPA, upload TestFlight... toute la chaîne a besoin d'un Mac stable et persistant. C'est pour ça qu'un runner self-hosted reste la vraie solution quand on veut de la vitesse régulière. Pour creuser : TCO des runners macOS, Flutter iOS CI, Xcode lent en cloud, et le contexte infra via la guerre des infrastructures IA.

1) Pourquoi GitHub Actions est lent pour iOS CI ?

Le pipeline iOS dépend d'une stack lourde et sensible au cache. Sur des runners hébergés, l'environnement est souvent re-créé, donc les gains cumulatifs sont faibles. Résultat : même workflow, durées irrégulières. Un jour ça passe en 15 minutes, le lendemain en 26.

2) Où part le temps dans un build iOS CI ?

3) Architecture recommandée : Linux pour CI générique, Mac pour iOS

4) Setup self-hosted runner qui tient la route

1. Machine dédiée et chemins stables : indispensable pour un vrai cache hit.
2. Versions figées : Xcode, CocoaPods, Ruby, sinon variabilité garantie.
3. Concurrence limitée : 1 à 2 jobs iOS max par Mac.
4. Ops lourdes séparées : sortir pod repo update du workflow release.
5. Hygiène disque : purge régulière des archives et de DerivedData.

Références utiles : doc GitHub self-hosted runners et notes Apple Xcode Release Notes.

5) Avant / Après : hosted vs self-hosted

6) Exemple de workflow iOS

name: release-ios
on:
  push:
    branches: [main]
    tags: ['v*']

jobs:
  ios:
    runs-on: [self-hosted, macos, ios]
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: |
          bundle install
          cd ios && pod install && cd ..
      - name: Archive
        run: xcodebuild -workspace App.xcworkspace -scheme App -configuration Release archive
      - name: Export IPA
        run: xcodebuild -exportArchive -archivePath build/App.xcarchive -exportOptionsPlist ios/ExportOptions.plist -exportPath build

Si vous êtes sur Flutter, la logique est identique. Exemple pratique : pipeline Flutter iOS CI.

7) Checklist d'exploitation (performance + fiabilité)

• Signature maîtrisée : certificats/profils centralisés et tracés.
• Compte runner dédié : éviter les modifications manuelles parasites.
• Retry intelligent : rejouer uniquement les étapes réseau/upload.
• Calcul TCO complet : coût machine + coût d'exploitation + coût d'attente équipe.

Pour comparer vos options : analyse TCO et tarifs Mac mini.

8) Quand passer au self-hosted ?

Contexte macro : guerre des infrastructures de calcul IA.

9) FAQ (8 questions terrain)

Q1 : Un seul projet iOS, self-hosted utile ?
Pas forcément tout de suite. Mais dès que l'attente CI ralentit l'équipe, ça devient pertinent.

Q2 : Quel levier donne le plus de gain d'abord ?
CocoaPods + DerivedData. C'est généralement le meilleur retour immédiat.

Q3 : C'est lourd à maintenir ?
Le bootstrap demande un effort, ensuite c'est gérable avec des versions figées.

Q4 : Et les erreurs exit code 65 ?
Souvent un décalage de version ou un cache corrompu. Vérifiez versions puis nettoyez.

Q5 : Fastlane obligatoire ?
Non. Build stable + upload propre suffit pour démarrer.

Q6 : Mac au bureau ou en cloud ?
Pour une équipe distribuée, le cloud est souvent plus simple et plus fiable.

Q7 : Risques sécurité ?
Oui, donc droits minimaux, gestion stricte des secrets et logs d'audit.

Q8 : Premier pas concret ?
Faites un test A/B une semaine (hosted vs self-hosted) sur votre pipeline iOS principal.