Mac dans le cloud pour Xcode CI/CD : guide pratique GitHub Actions et Jenkins

Pourquoi la chaîne d'outils Apple est liée au matériel macOS

Contrairement à Android avec Gradle dans des conteneurs Linux, la chaîne de livraison iOS et macOS — xcodebuild、codesign、notarytool、App Store Connect API—— exige un système d'exploitation et une puce signés par Apple. Ce n'est pas un problème que l'on contourne en « installant un simulateur » : les chaînes de certificats Archive et App Store, les optimisations du compilateur Swift pour Apple Silicon supposent que vous travaillez sur un vrai Mac.

Toute équipe avec un produit iOS finit par se poser la même question : Qui fournit le Mac sur le long terme ? Trois voies courantes — runners macOS hébergés par GitHub, Mac mini achetés au bureau, machines physiques cloud dédiées — aucune n'est absolument supérieure ; tout dépend de votre tolérance à l'attente, de la fréquence mensuelle des builds et de la présence d'une personne pour maintenir système et certificats. Cet article se concentre sur la mise en œuvre technique de la troisième voie, mais commence par situer les limites des deux autres.

Décomposer le temps CI : attente, compilation, signature

Beaucoup d'équipes se plaignent que « la CI est trop lente » sans découper le temps total en trois segments : attente d'une machine, compilation et liaison locales, signature et envoi. Sur le même commit, nous avons comparé les runners macos-14 hébergés par GitHub à un nœud M4 dédié ZovCloud — des chiffres utiles pour décider.

Les runners hébergés attendent en moyenne 22 minutes aux heures de pointe (UTC 13:00–17:00) avant de démarrer le job ; le xcodebuild archive effectif a duré 5 min 38 s. Nœud M4 dédié sans file d'attente, build Archive complet en 3 min 58 s — la compilation Swift parallèle sur M4 10 cœurs est nettement plus rapide que sur d'anciennes machines CI Intel, 16 GB de mémoire unifiée sans swap lors d'un clean build.

Si votre problème principal est d'attendre une demi-heure après chaque push pour savoir si la compilation a réussi, le goulot est souvent la file d'attente, pas Xcode lui-même. Fixer le runner sur un Mac dédié toujours en ligne est le moyen le plus direct de raccourcir la boucle de retour — à partir de la section 3 : préparer cette machine comme baseline de build reproductible.

Mettre en place une baseline de build Xcode reproductible sur Mac cloud

ZovCloud livre des Mac mini avec macOS complet et droits administrateur. Après provisionnement, connectez-vous par SSH ou VNC navigateur — adoptez une arborescence fixe pour certificats et profils de provisioning, afin que les scripts runner ne cherchent pas chacun leur chemin. Les quatre étapes suivantes constituent notre checklist standard à chaque nouveau nœud.

1. 01
   Installer Xcode et accepter la licence

   Installez Xcode 16.x depuis l'App Store, exécutez sudo xcodebuild -license accept et xcodebuild -runFirstLaunch. Vérification : xcodebuild -version affiche la version attendue ; xcode-select -p pointe vers /Applications/Xcode.app/Contents/Developer.

2. 02
   Importer certificat Distribution et profils

   Transférez le .p12 de façon sécurisée vers ~/certs/, importez avec security import dans le trousseau dédié ~/Library/Keychains/ci.keychain-db ; placez les .mobileprovision dans ~/Library/MobileDevice/Provisioning Profiles/. Configurez la partition list de confiance pour codesign afin d'éviter les pop-ups en build sans surveillance.

3. 03
   Configurer la clé API App Store Connect

   Créez une clé API dans le portail Apple Developer, enregistrez AuthKey_XXXXXX.p8 dans ~/private_keys/. Pour TestFlight, utilisez xcrun altool ou Fastlane pilot upload — sans double authentification Apple ID interactive.

4. 04
   Premier Archive complet et conserver DerivedData

   Clonez le dépôt et exécutez une fois un Archive Release en local pour valider la chaîne de signature. 256 GB suffisent pour un projet moyen ; conserver DerivedData économise environ 30–45 % sur les builds incrémentaux. Pour de nombreuses dépendances Swift Package, cachez avec -clonedSourcePackagesDirPath.

Enregistrement du runner GitHub Actions self-hosted et ciblage workflow

Une fois le runner enregistré, les workflows orientent les jobs vers ce Mac cloud via des labels — le pool public est contourné. Chemin : Repository Settings → Actions → Runners → New self-hosted runner, choisissez macOS ARM64, téléchargez le paquet actions-runner et exécutez :

./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token RUNNER_TOKEN --labels macos-m4,zovcloud,ios-build --unattended

Après enregistrement, installez comme service système pour que le runner redémarre automatiquement : sudo ./svc.sh install → sudo ./svc.sh start。 Spécifiez le label dans le YAML du workflow :

runs-on: [self-hosted, macos-m4]

Chaîne typique d'un job iOS : checkout → déverrouiller le trousseau CI → xcodebuild archive → xcodebuild -exportArchive → Fastlane upload_to_testflight ou altool --upload-app. Sur notre nœud M4, du push au traitement TestFlight (file Apple incluse), en moyenne environ 10 minutes, dont 5–6 minutes pour le build local et l'envoi.

Montage d'un agent Jenkins — points clés du pipeline

Si vous avez déjà un contrôleur Jenkins (par ex. sous Linux), la capacité de build macOS arrive via un agent. Sur le Mac cloud, installez JDK 17, téléchargez agent.jar, exécutez-le en LaunchDaemon permanent, le contrôleur distribue les tâches par SSH ou JNLP.

Les atouts de Jenkins : pipelines visuels et écosystème de plugins — injection du mot de passe trousseau via Credentials Binding, logs AnsiColor, archivage des artefacts vers Artifactory, etc. Pipeline type : sh 'xcodebuild ...' dans stage('Archive'), Fastlane dans stage('Upload'). Par rapport à GitHub Actions, Jenkins convient mieux aux flux internes multi-branches, multi-environnements, avec validation manuelle.

La location journalière d'un Mac cloud comme « agent élastique » : activez un nœud en semaine de release et branchez-le à Jenkins, libérez-le en période creuse — pas besoin d'exploiter un Mac en salle serveur toute l'année. Fixer DEVELOPER_DIR pour éviter le chaos des versions Xcode multiples — détail de stabilité Jenkins souvent négligé.

Boucle en ligne de commande Archive → Export → TestFlight

Que ce soit GitHub Actions ou Jenkins, la chaîne finale est la même : Archive produit un .xcarchive → Export un .ipa → envoi vers App Store Connect. La ligne de commande est la norme en CI — sans interface graphique Xcode.

Exemple Archive (Release, scheme fixe) :

xcodebuild archive -workspace MyApp.xcworkspace -scheme MyApp -configuration Release -archivePath build/MyApp.xcarchive CODE_SIGN_STYLE=Manual PROVISIONING_PROFILE_SPECIFIER="MyApp AppStore"

L'export nécessite un ExportOptions.plist (method app-store) :

xcodebuild -exportArchive -archivePath build/MyApp.xcarchive -exportPath build/export -exportOptionsPlist ExportOptions.plist

Envoi TestFlight (clé API, adapté au sans surveillance) :

xcrun altool --upload-app -f build/export/MyApp.ipa -t ios --apiKey KEY_ID --apiIssuer ISSUER_ID

Le CPU 10 cœurs du M4 accélère nettement la compilation Swift parallèle par rapport aux anciennes machines CI Intel ; si le projet comporte de nombreuses dépendances Swift Package, mettez en cache dans le workflow ~/Library/Developer/Xcode/DerivedData et le répertoire SourcePackages — à partir du deuxième build, le temps peut encore baisser d'environ un tiers.

Trousseau et signature en environnement sans surveillance

En SSH ou sur un runner headless, l'échec de codesign est presque toujours lié au trousseau, rarement à un certificat expiré. En début de script de build, déverrouillez et autorisez de façon systématique :

security unlock-keychain -p "$KEYCHAIN_PASSWORD" ~/Library/Keychains/ci.keychain-db

security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k "$KEYCHAIN_PASSWORD" ~/Library/Keychains/ci.keychain-db

Injectez le mot de passe via GitHub Secrets ou Jenkins Credentials — ne jamais l'écrire en clair dans le dépôt. En cas d'erreur errSecInternalComponent, vérifiez que le trousseau est par défaut et que codesign est dans la liste de confiance. Si altool bloque à l'authentification, vérifiez l'Issuer ID de la clé API, le nom du fichier .p8 et que la clé conserve le rôle « Developer ».

Piège fréquent : profil de provisioning et Bundle ID incohérents — pas d'erreur à l'Archive, échec à l'Export. Ajoutez en CI une étape security cms -D -i profile.mobileprovision pour afficher l'UUID, et croisez avec PROVISIONING_PROFILE_SPECIFIER dans le projet Xcode.

Capacité de build macOS élastique : quand placer le runner sur un nœud cloud dédié

Les indépendants et petites équipes sont souvent pris entre deux feux : besoin de builds macOS, mais pas envie de louer un bureau, tirer une ligne dédiée et gérer coupures et mises à jour pour une machine CI. Les VM Linux du cloud public ne suffisent pas (pas de macOS complet ni de chaîne de signature Apple) ; un Mac mini à domicile expose à une montée en débit instable, des IP changeantes et des arrêts accidentels.

ZovCloud propose des Mac mini M4 physiques dédiés : pas de virtualisation, pas de survente, 16 GB de mémoire et 1 Gbps de bande passante dédiée par machine, provisionnement automatique 1–5 minutes après paiement. Cinq régions — Singapour, Japon, Corée, Hong Kong, Côte Est US — selon la répartition de vos utilisateurs ; pour une app ciblant le Japon, le nœud Tokyo réduit la latence d'envoi TestFlight.

Facturation dès $19,8/jour, $53,5/semaine, $99,1/mois — sans contrat long terme. Louez un nœud la semaine de release intense, libérez-le en maintenance — souvent plus rentable qu'une machine achetée toute l'année plus l'électricité. Pour des Archives parallèles, ajoutez le cluster Thunderbolt 5 à 80 Gbps — adapté aux grands monorepos ou matrices multi-apps.

1. 01
   Choisir un nœud et provisionner sur ZovCloud

   Dans le tableau de bord, choisissez région et durée — identifiants SSH et accès VNC livrés automatiquement après paiement. Tutoriel dans le Centre d'aide.

2. 02
   Finaliser la baseline Xcode et signature (section 3)

   Inscrivez les chemins trousseau et clé API dans les variables d'environnement pour GitHub Actions / Jenkins.

3. 03
   Enregistrer le runner et valider le premier pipeline

   D'abord un build Debug, puis Release Archive + TestFlight — figez la lane Fastlane dans le dépôt.

Le seuil de la CI/CD iOS n'est pas la barre de menus Xcode, mais une capacité macOS stable et prévisible + un environnement de signature unique et fiable. Les runners publics conviennent aux builds peu fréquents ; le matériel en propre aux équipes matures avec ops ; le Mac cloud dédié comble l'entre-deux « pas de file, pas d'achat de machine ». Une fois la compilation dans le cloud, votre MacBook peut se consacrer au code au lieu de céder ventilateur et mémoire à la CI la nuit.