CI/CD Xcode sur Mac cloud : de la compilation à TestFlight, guide complet

Pourquoi le build iOS exige un environnement macOS dédié ?

Contrairement à Android, compilable dans un conteneur Linux avec Gradle, la chaîne Apple — xcodebuild, signature de code, notarytool, API App Store Connect — est entièrement liée à macOS et à du matériel Apple Silicon ou Intel. Chaque équipe avec un produit iOS finit par se poser la question : qui fournit cette machine ?

Les difficultés courantes se regroupent en trois catégories : files d'attente des runners publics (quota macOS gratuit rare sur GitHub Actions, workflows pouvant attendre 20–45 minutes aux heures de pointe), machine de dev locale monopolisée par la CI (après un push collègue, Xcode ralentit et les ventilateurs tournent à fond), gestion chaotique des certificats et clés (.p12 importés sur plusieurs machines, expiration ignorée). Un nœud Mac cloud dédié résout les deux premiers points et offre un environnement de confiance unique pour le troisième.

Trois approches CI comparées : laquelle choisir ?

Avant d'installer Xcode, identifiez le profil de votre équipe. Aucune solution n'est universellement supérieure — la différence tient à la tolérance aux files d'attente, au volume mensuel de builds et aux exigences de conformité.

Sur notre projet SwiftUI moyen, un xcodebuild archive complet sur le nœud M4 prend environ 4 min 12 s (compilation et linkage Swift inclus). Sur un runner macOS-14 hébergé par GitHub : 18 minutes d'attente puis 5 min 40 de build — soit près de 24 minutes au total. Pour les équipes qui veulent « push et test », l'attente pèse souvent plus que le build lui-même sur le rythme de livraison.

Initialisation du nœud cloud : Xcode et matériel de signature

Le Mac mini SpinMac est livré avec macOS complet et droits administrateur. Après activation, connectez-vous en SSH ou VNC navigateur et suivez cet ordre pour la préparation CI. Centralisez certificats et profils dans des chemins fixes, référencés uniformément par les scripts workflow.

1. 01
   Installer Xcode et les outils en ligne de commande

   Installez Xcode 16.x depuis l'App Store ou via xcode-select, puis exécutez sudo xcodebuild -license accept et xcodebuild -runFirstLaunch. Vérification : xcodebuild -version doit afficher la bonne version.

2. 02
   Importer certificat de signature et Provisioning Profile

   Transférez le .p12 Distribution et son mot de passe de façon sécurisée vers ~/certs/, importez avec security import dans le trousseau ; placez les .mobileprovision dans ~/Library/MobileDevice/Provisioning Profiles/. En CI, préférez un trousseau dédié avec confiance -T /usr/bin/codesign.

3. 03
   Configurer la clé API App Store Connect

   Créez une clé API dans Apple Developer, stockez AuthKey_XXXXXX.p8 dans ~/private_keys/. Pour TestFlight, utilisez xcrun altool ou fastlane pilot upload et évitez la connexion Apple ID interactive.

4. 04
   Cloner le dépôt et mettre en cache DerivedData

   Après le premier git clone, lancez un Archive local pour valider la chaîne de signature. Conservez DerivedData sur le SSD local (256 Go suffisent pour un projet moyen) — les builds incrémentaux gagnent 30–50 % de temps.

Monter un runner self-hosted GitHub Actions

Une fois le runner dédié enregistré, le workflow peut cibler runs-on: self-hosted ou un label personnalisé (ex. macos-m4) pour diriger les jobs vers ce Mac cloud et contourner le pool public. Étapes validées sur un nœud SpinMac.

Dans le dépôt GitHub : Settings → Actions → Runners → New self-hosted runner, choisissez macOS ARM64, téléchargez et décompressez le paquet actions-runner selon les instructions, puis exécutez :

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

Après l'enregistrement, installez en service système pour que le runner redémarre automatiquement : sudo ./svc.sh install → sudo ./svc.sh start. Dans le YAML workflow, spécifiez le label :

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

Un job iOS type comprend : checkout → déverrouillage trousseau → xcodebuild archive → xcodebuild -exportArchive → xcrun altool --upload-app ou Fastlane upload_to_testflight. Sur notre nœud M4, une lane Fastlane du push au traitement TestFlight (file Apple incluse) prend en moyenne environ 11 minutes, dont un peu plus de 6 minutes en build et upload local.

Points clés pour un agent macOS Jenkins

Si l'équipe a déjà un contrôleur Jenkins (souvent sous Linux), la capacité de build macOS passe par un agent. Sur le Mac SpinMac en cloud, installez JDK 17 et agent.jar Jenkins en LaunchDaemon permanent ; le contrôleur récupère les tâches via SSH ou JNLP.

Jenkins brille par les pipelines visuels et l'écosystème de plugins : Xcode, Credentials Binding, logs AnsiColor, archivage des artefacts, etc. Pipeline type : stage('Archive') avec sh 'xcodebuild ...', stage('Upload') avec Fastlane ou altool. Fixez DEVELOPER_DIR à /Applications/Xcode.app/Contents/Developer pour éviter la confusion entre versions Xcode.

Par rapport à GitHub Actions, Jenkins convient mieux aux flux internes multi-branches, multi-environnements, avec validations manuelles. Un Mac cloud loué à la journée sert d'« agent élastique » : activez le nœud en semaine de release, libérez-le en creux — sans maintenir une machine en salle serveur 365 jours par an.

Archive, signature et envoi TestFlight — mise en pratique

Quel que soit l'outil CI, la chaîne de livraison est la même : Archive → .xcarchive, Export → .ipa, upload App Store Connect. La voie ligne de commande (sans GUI Xcode) est la norme en CI.

Exemple Archive (configuration Release, scheme et chemin de sortie spécifiés) :

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), puis :

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

Pour TestFlight, privilégiez la clé API afin d'éviter le blocage 2FA en environnement sans surveillance :

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

Sur un projet moyen, les 10 cœurs du M4 accélèrent nettement la compilation Swift concurrente par rapport aux anciennes machines Intel CI ; 16 Go de mémoire unifiée laissent de la marge sur un clean build complet sans swap. Avec beaucoup de dépendances Swift Package, activez le cache -clonedSourcePackagesDirPath pour raccourcir les builds suivants.

Pas de salle serveur au bureau — comment faire tourner une CI iOS stable ?

Le dilemme de nombreux indépendants et petites équipes : il faut macOS pour builder, mais pas envie de louer un bureau, tirer des câbles et gérer coupures et mises à jour pour une seule machine CI. Les VM cloud publiques ne suffisent pas (pas de macOS complet ni chaîne de signature Apple) ; un Mac mini d'occasion à la maison pose bande passante montante instable, IP changeante et arrêts accidentels.

SpinMac propose un Mac mini M4 physique dédié : pas de virtualisation, pas de survente, 16 Go de RAM et 1 Gbps dédié par machine, activation automatique 1–5 minutes après paiement. Cinq régions (Singapour, Japon, Corée du Sud, Hong Kong, côte Est des États-Unis) selon votre audience — par ex. Tokyo pour une app ciblant le Japon, afin de réduire la latence transfrontalière vers TestFlight.

Tarification : à partir de 21,2 $/jour, 57,3 $/semaine, 106,1 $/mois, sans engagement long terme. Activez un nœud runner la semaine de release, libérez-le en maintenance — souvent plus rentable qu'une machine achetée toute l'année plus l'électricité. Pour des builds parallèles multi-machines, le service parallèle Thunderbolt 5 forme un cluster 80 Gbps, adapté aux gros monorepos ou matrices multi-apps en Archive simultané.

1. 01
   Choisir un nœud et activer sur SpinMac

   Connectez-vous à la console, choisissez région et durée ; identifiants SSH et accès VNC sont envoyés automatiquement après paiement. Voir le centre d'aide.

2. 02
   Suivre la section 3 pour Xcode et la signature

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

3. 03
   Enregistrer le runner et lancer le premier pipeline

   Validez d'abord un build Debug, puis passez à Release Archive + TestFlight, et figez Fastlane ou vos scripts natifs dans le dépôt.

Coût et choix : synthèse en un tableau

Le vrai défi de la CI/CD iOS n'est pas Xcode en soi, mais une puissance macOS stable + un environnement de signature reproductible. Les runners publics conviennent aux builds peu fréquents ; le serveur sur site aux équipes matures avec ops ; le Mac cloud dédié comble l'entre-deux — pas envie d'attendre ni d'acheter une machine : facturation à la journée, performances physiques prévisibles, déploiement proche via les nœuds mondiaux. Une fois compilation et signature dans le cloud, le MacBook local sert à coder, pas à se faire voler ventilateurs et mémoire par la CI la nuit.