Dans le cycle de développement iOS, l’archivage et la distribution des builds restent souvent l’étape la plus chronophage et la plus contraignante pour les équipes. Construire en local sur sa machine de développement monopolise les ressources, ralentit le poste de travail et complique la standardisation des environnements au sein d’une équipe. Utiliser un Mac mini distant pour héberger un GitLab Runner et faire tourner une pipeline CI/CD dédiée est devenu une solution de référence pour les équipes iOS modernes. Ce guide vous accompagne pas à pas dans la mise en place de cette configuration performante.
Pourquoi choisir un Mac mini distant pour l’automatisation iOS ?
Lorsque l’on réfléchit à l’automatisation des builds iOS, les équipes comparent généralement trois options : la compilation locale manuelle, les services cloud partagés type SaaS, et l’utilisation d’un Mac dédié (souvent un Mac mini) hébergé à distance. Chaque approche a des implications directes sur la productivité, la reproductibilité des builds et la collaboration.
| Critère | Build local (manuel) | Mac mini distant (CI/CD) |
|---|---|---|
| Productivité | Faible (bloque le poste de dev) | Élevée (exécution en arrière-plan) |
| Cohérence des environnements | Variable (dépend de chaque machine) | Excellente (environnement unique et reproductible) |
| Vitesse de build | Dépend du matériel local | Optimale (machine dédiée haute performance) |
| Collaboration | Peu partageable | Déclenchement centralisé, visible par toute l’équipe |
En centralisant les builds sur un Mac mini distant, vous libérez votre machine de développement pour le code et les tests, tout en offrant à l’équipe un point d’entrée unique et traçable pour les archives et les déploiements vers TestFlight ou l’App Store. C’est dans ce contexte que des plateformes comme VNCMac apportent une vraie plus-value : elles mettent à disposition des Mac physiques (notamment équipés de puces M4) accessibles par VNC ou écran partagé, parfaitement adaptés à l’exécution de GitLab Runner et de Fastlane.
Étapes de configuration
La première étape consiste à accéder à votre Mac distant. Avec les instances cloud VNCMac, vous vous connectez en quelques secondes via le partage d’écran intégré à macOS ou un client VNC. Ce mode « headless » permet de configurer l’environnement comme sur une machine locale, sans moniteur physique. Les modèles M4 proposés par VNCMac offrent une latence très faible et une synchronisation d’écran fluide, ce qui rend la configuration et le débogage à distance confortables au quotidien.
Sur le Mac mini, ouvrez le Terminal et installez GitLab Runner via Homebrew. Cette méthode garantit une installation propre et facilement mise à jour :
brew install gitlab-runner
gitlab-runner install
gitlab-runner startUne fois le service installé et démarré, le Runner est prêt à être enregistré auprès de votre projet GitLab.
Récupérez le token d’enregistrement dans votre projet GitLab, sous Settings > CI/CD > Runners, puis exécutez dans le Terminal :
gitlab-runner registerLors des questions interactives, indiquez l’URL du dépôt GitLab et le token. Pour l’Executor, choisissez impérativement shell : les builds iOS ont besoin d’appeler directement Xcode, les outils de signature et les certificats système, ce que l’exécuteur shell permet sans couche supplémentaire.
Fastlane est l’outil incontournable pour automatiser la compilation, la signature et la distribution des applications iOS. À la racine de votre projet, initialisez Fastlane puis définissez vos lanes (par exemple une lane beta pour l’archivage et l’envoi vers TestFlight) :
fastlane initDans le Fastfile, une lane typique incrémente le numéro de build, lance l’archive Xcode et envoie l’IPA vers App Store Connect. En couplant cette lane à un job GitLab CI, chaque merge ou push sur la branche cible déclenche un build complet sans intervention manuelle.
Définir la pipeline dans .gitlab-ci.yml
Pour lier le dépôt Git à votre Runner et à Fastlane, créez un fichier .gitlab-ci.yml à la racine du projet. Ce fichier décrit les étapes (stages) et les jobs à exécuter sur le Mac mini. Exemple minimal pour un build et déploiement beta :
stages:
- build
build_ios:
stage: build
tags:
- ios
script:
- bundle install
- bundle exec fastlane beta
only:
- main
Le tag ios doit correspondre à celui configuré lors de l’enregistrement du Runner. Ainsi, seuls les Runners marqués « ios » (votre Mac mini) prendront en charge ces jobs, ce qui assure que les builds s’exécutent toujours sur un environnement macOS dédié à Xcode.
Certificats et profils de provisionnement : éviter les pièges
La gestion des certificats et des profils de provisionnement est souvent la source de blocages en CI/CD iOS. Une approche robuste consiste à utiliser Fastlane Match, qui centralise certificats et profils dans un dépôt Git privé. Chaque développeur et chaque machine (y compris le Mac mini distant) exécute fastlane match readonly pour synchroniser l’environnement de signature sans avoir à exporter ou importer manuellement les identités. Cela garantit que le Runner dispose des bons certificats et profils à chaque build, et évite les erreurs du type « no signing certificate found » ou « provisioning profile doesn’t include the signing certificate ».
« Avec un Mac mini distant dédié et Fastlane Match, nous avons réduit le temps entre un merge et une build TestFlight de plus de 30 minutes à quelques minutes. » — Retour d’équipe iOS, approche CI/CD
En résumé
Configurer un GitLab Runner sur un Mac mini distant vous permet de découpler complètement le build de votre poste de développement : les archives et déploiements s’exécutent en arrière-plan, dans un environnement reproductible et partagé. En s’appuyant sur des instances Mac physiques hautes performances (comme les M4 proposés par VNCMac), les temps de compilation Xcode chutent nettement et les pipelines deviennent prévisibles. Que vous partiez de zéro ou que vous rationalisiez un processus déjà partiellement automatisé, cette architecture est un investissement rentable pour toute équipe iOS soucieuse de livrer souvent et sans friction.
Si vous n’avez pas encore déployé de CI/CD iOS dans le cloud, c’est le bon moment pour le faire : en quelques dizaines de minutes de configuration, vous gagnez en sérénité, en vitesse et en cohérence d’équipe.