Au 5 septembre 2026, la documentation GitLab liste des images Hosted macOS Runner avec macOS 15/Xcode 16 et macOS 26/Xcode 26, mais pas d’image Xcode 27 (matrice officielle des images macOS). Apple publie déjà la série Xcode 27 Beta dans ses notes de version (notes Apple sur Xcode 27). La décision est donc nette : ne migrez pas toute votre production vers GitLab Hosted macOS Runner pour Xcode 27 ; utilisez provisoirement un double circuit, avec le Runner hébergé pour les outils stables et les validations non sensibles, et un Mac dédié autogéré pour Xcode 27, le réseau privé et la signature de production.
À qui s’adresse ce guide ?
Vous êtes responsable de l’efficacité de développement et devez planifier l’adaptation à Xcode 27 sans confondre disponibilité d’une version et promesse de support.
Vous dirigez l’IT, la sécurité ou les achats et devez vérifier la signature, les dépendances privées, la capacité de compilation et le coût total avant de choisir vos nœuds Mac.
Point de contrôle temporel : la date de disponibilité d’une image Xcode 27 n’est pas annoncée dans les sources officielles consultées. Ne remplacez pas cette absence d’information par une date issue d’un forum ou d’une rumeur.
SECTION 01 Ce que la version disponible permet réellement de décider
Le terme « macOS Runner hébergé » recouvre plusieurs états qu’il faut séparer dans votre dossier d’architecture :
- le service Hosted Runner est documenté comme étant en bêta ;
- chaque image macOS possède son propre cycle de disponibilité et de retrait ;
- Xcode 27 possède un état distinct, actuellement documenté par Apple dans la série Beta ;
- un Runner autogéré dépend encore de l’installation locale de l’application GitLab Runner et de votre propre administration (documentation d’installation sur macOS).
Cette distinction répond déjà à la question du calendrier. GitLab n’indique pas, dans la documentation vérifiée au 5 septembre 2026, quand une image Xcode 27 sera ajoutée. Vous pouvez donc préparer vos fichiers .gitlab-ci.yml, mais vous ne pouvez pas traiter l’arrivée de l’image comme une date de migration garantie.
Une chronologie de décision plutôt qu’une promesse de disponibilité
| Jalon vérifié | État à prendre en compte | Conséquence pour votre équipe |
|---|---|---|
| 5 septembre 2026 | Images publiques documentées jusqu’à macOS 26/Xcode 26 | Le pipeline de référence ne doit pas dépendre d’un Xcode 27 hébergé |
| Même date | Xcode 27 est documenté dans une série Beta par Apple | Les tests d’adaptation doivent utiliser un environnement contrôlé séparément |
| Prochaine modification officielle | Nouvelle image ou changement d’état du service | Réévaluer la matrice avant toute migration de production |
| Passage de Xcode 27 à une version stabilisée | À confirmer dans les notes Apple | Rejouer les tests de compilation, de signature et de publication |
La bonne pratique consiste à surveiller simultanément la page des images GitLab et les notes de version Apple. Une annonce concernant Xcode 27 ne signifie pas automatiquement qu’un Runner hébergé l’exécute ; inversement, l’ajout futur d’une image ne prouvera pas que vos dépendances privées, certificats et scripts sont prêts.
SECTION 02 Le contrôle de l’environnement et la reproductibilité des builds
Le choix entre GitLab Hosted macOS Runner et un Mac autogéré ne porte pas seulement sur la présence d’Xcode. Il concerne aussi le niveau de contrôle sur le simulateur, les outils annexes, les caches et la fenêtre de mise à jour.
Une image hébergée peut fournir une base rapidement exploitable, mais votre équipe ne décide pas seule du moment où l’image évolue, du moment où elle est retirée ni de chaque outil préinstallé. Le catalogue d’images permet de connaître un périmètre public ; il ne transforme pas ce périmètre en environnement figé à vie.
Avec un Mac autogéré, vous pouvez installer Xcode 27 Beta, conserver plusieurs versions, ajouter les runtimes Simulator nécessaires et verrouiller les versions de CocoaPods, Swift Package Manager ou d’autres utilitaires. Cette liberté crée toutefois une obligation : consigner chaque changement et reconstruire l’image de manière répétable. Un poste qui accepte une installation manuelle n’est pas, par lui-même, un environnement homogène.
Pour votre chaîne GitLab CI/CD, imposez une fiche d’outillage contenant :
- la version exacte de macOS et de Xcode ;
- les runtimes Simulator présents ;
- la version des outils de dépendances et de génération ;
- l’identifiant du nœud et son groupe de tags ;
- la date de dernière modification ;
- le résultat d’un build répété à partir du même commit.
Le dernier point est déterminant. Deux exécutions réussies ne prouvent pas encore que le résultat est reproductible si elles ont utilisé des caches différents ou des nœuds différents. Conservez les journaux, les artefacts et les empreintes des dépendances, puis comparez une compilation propre avec une compilation utilisant le cache.
Première étape : créer une matrice d’outillage avant le pilote
Ne commencez pas par acheter plusieurs machines. Définissez d’abord les combinaisons que vos produits doivent réellement supporter : version stable actuelle, Xcode 27 Beta, simulateur requis, type de test et mode de distribution. Pour chaque combinaison, indiquez si elle peut fonctionner sur une image hébergée, si elle nécessite un Mac autogéré et si une validation humaine est requise.
Cette matrice répond aussi à la question de savoir s’il faut créer un Runner séparé avant la mise en production de Xcode 27. Oui, si la version Beta exige des dépendances, des autorisations ou un cycle de mise à jour incompatibles avec le Runner stable. Non, si vous ne faites qu’exécuter une validation isolée sur une machine déjà contrôlée et que les règles de sécurité séparent clairement ses tâches.
Un même pool ne doit pas mélanger, sans règle de routage, les archives de production, les tests expérimentaux et les tâches de design ou d’audio/vidéo. Les projets de montage vidéo, de prévisualisation graphique ou de traitement audio peuvent demander des outils et des volumes temporaires très différents d’un simple test unitaire iOS. Les tags de Runner doivent exprimer cette différence plutôt que laisser GitLab affecter les tâches au premier nœud disponible.
SECTION 03 La signature de production et la séparation des tâches sensibles
Pour une application destinée à l’App Store, la compilation et la signature ne présentent pas le même niveau de sensibilité. Le build ordinaire peut être distribué à un pool hébergé si le code, les dépendances et les artefacts respectent vos règles. La signature de production, elle, doit rester sur un nœud approuvé par votre politique de sécurité et validé par l’équipe compétente.
La documentation GitLab décrit le fonctionnement et l’isolation des Hosted Runner, mais cette isolation ne vaut pas automatiquement approbation pour vos certificats, profils, comptes de publication ou exigences d’audit (présentation officielle des Hosted Runner). Vous devez vérifier le cycle de vie du système de fichiers, les privilèges disponibles, l’injection des secrets, le nettoyage de l’espace de travail et la conservation des journaux.
Sur un Mac autogéré dédié, vous assumez davantage de responsabilités :
- protéger le trousseau et les clés privées ;
- limiter les comptes et les groupes capables de lancer une archive ;
- séparer les profils de développement des profils de distribution ;
- effacer les espaces de travail et les artefacts temporaires ;
- contrôler les accès SSH, VNC ou console ;
- documenter les redémarrages, mises à jour et opérations d’urgence.
La conclusion opérationnelle est simple : affectez les compilations et tests non sensibles au pool hébergé lorsque la version convient ; affectez la signature de production à un nœud de confiance, isolé et audité. Ne déduisez pas qu’un Runner peut signer en production uniquement parce qu’il peut compiler le projet.
SECTION 04 Quel réseau et quelles données votre pipeline doit-il réellement atteindre ?
Le fait qu’un Runner puisse récupérer le dépôt ne signifie pas qu’il peut atteindre l’ensemble de vos dépendances. Cette confusion est fréquente lorsque le pipeline fonctionne sur une branche simple, puis échoue au moment de télécharger un paquet privé, d’interroger un service interne ou d’envoyer un artefact vers une destination protégée.
Avant de choisir un pool, dessinez les flux suivants :
- récupération du dépôt et des sous-modules ;
- accès au registre privé de paquets ;
- téléchargement des dépendances ;
- communication avec les services de test internes ;
- accès au stockage d’artefacts ;
- transmission éventuelle vers un service de distribution ;
- sorties Internet et résolution DNS.
Ajoutez pour chaque flux l’adresse ou le domaine, le port, le mode d’authentification, la liste blanche attendue et la preuve de réussite. Si votre politique impose une adresse de sortie fixe, un proxy, un accès exclusivement privé ou une exigence de résidence des données, le Runner hébergé doit être évalué contre cette contrainte précise, et non contre une impression générale de connectivité.
Un Mac autogéré dans un réseau autorisé peut mieux convenir aux dépendances internes, mais il devient alors un point d’entrée supplémentaire. Votre dossier doit contenir le schéma réseau, la liste des terminaux, les journaux d’échec et la validation écrite de l’équipe sécurité. Une route fonctionnelle n’est pas une preuve de conformité.
SECTION 05 Comment comparer la capacité, la file d’attente et la reprise ?
La capacité ne se déduit ni du nombre de cœurs annoncé ni d’un build propre exécuté une seule fois. Mesurez un mélange représentatif de demandes de fusion, tests, compilation incrémentale, archive et export. Incluez les périodes de pointe ainsi que les échecs nécessitant une reprise.
Pour le service hébergé, séparez au minimum le temps d’attente, le temps d’exécution et l’unité de calcul facturée selon la règle applicable à votre offre. Les règles de calcul GitLab doivent être reprises depuis la documentation officielle, plutôt que d’être remplacées par un taux approximatif (règles officielles des Compute Minutes).
Pour un Mac autogéré, mesurez la capacité utile, et non le temps pendant lequel la machine est allumée. Intégrez les mises à jour, les nettoyages, les installations de certificats, les redémarrages, les incidents et le temps d’intervention. Le tableau de supervision doit faire apparaître les exécutions, les files et les groupes de Runner ; la documentation GitLab du tableau de bord de flotte peut servir de référence pour cette visibilité (Runner Fleet Dashboard).
| Indicateur | Runner hébergé | Mac autogéré | Preuve à conserver |
|---|---|---|---|
| Version Xcode | Dépend de l’image publiée | Choisie et maintenue par votre équipe | Matrice d’image et inventaire local |
| File d’attente | Dépend de la capacité disponible du service et de votre usage | Dépend du nombre de nœuds et du routage | Journaux de pipeline et tableau de flotte |
| Dépendances privées | À vérifier flux par flux | Possible si le réseau et les contrôles l’autorisent | Schéma, tests réseau et validation sécurité |
| Secrets de signature | À évaluer selon votre politique | Sous votre responsabilité directe | Registre des accès et audit du trousseau |
| Reprise après incident | Dépend du service et de la relance du job | Dépend du spare, de l’accès et de l’administration | Historique de redémarrage et procédure testée |
| Coût | Calcul selon l’usage et la règle GitLab | Machine, stockage, réseau, maintenance et sécurité | Facture, inventaire et temps d’exploitation |
SECTION 06 Quelle architecture hybride et quel TCO retenir ?
Un calcul sérieux doit réunir les coûts visibles et les coûts de responsabilité. Pour le Runner hébergé, utilisez votre consommation réelle, les règles de Compute Minutes et les éventuels coûts liés à la durée des jobs. Pour le Mac autogéré, additionnez la location ou l’achat de la machine, le stockage, la connectivité, les sauvegardes, la supervision, les remplacements, le temps d’administration et la gouvernance des secrets.
Vous pouvez utiliser ce modèle sans préremplir de chiffre non vérifié :
TCO hébergé = consommation de calcul + stockage éventuel + coûts de réseau + coût des reprises + coût du temps d’attente lors des pics.
TCO autogéré = ressource Mac + réseau + stockage + supervision + maintenance + sécurité + capacité de secours + coût des interruptions.
TCO hybride = pool stable hébergé + nœud Xcode 27 dédié + gouvernance de signature + réserve de capacité selon les pics.
Ne comparez donc pas une ligne de facture hébergée à un simple prix d’achat. Un Mac inutilisé la nuit peut sembler coûteux si vous ne valorisez que le temps de compilation, tandis qu’un service à l’usage peut devenir défavorable si vos archives lourdes occupent continuellement le pool. La décision doit s’appuyer sur vos journaux de pipeline, votre facture et votre politique de publication.
La matrice de choix à appliquer à chaque type de tâche
- Si la tâche utilise une version déjà disponible dans l’image GitLab, ne contient pas de secret de production et ne dépend pas d’un service privé, alors choisissez le Runner hébergé.
- Si la tâche exige Xcode 27 avant la publication d’une image officielle, alors choisissez un Mac autogéré dédié pour le pilote.
- Si la tâche signe ou exporte une archive destinée à la production, alors routez-la vers un nœud de confiance audité, même si la compilation précédente a été hébergée.
- Si la tâche requiert une liste blanche, un proxy ou un registre interne, alors choisissez l’environnement dont les flux sont démontrés et approuvés.
- Si la file d’attente dépasse votre seuil opérationnel pendant les pics, alors ajoutez de la capacité après avoir mesuré la durée réelle des jobs, au lieu de déduire le nombre de nœuds depuis les seules caractéristiques matérielles.
- Si Xcode 27 devient officiellement disponible dans une image hébergée, alors rejouez la matrice de versions, de signature, de réseau et de reproductibilité avant de déplacer la production.
Pour suivre les étapes de validation d’un Mac distant, vous pouvez aussi consulter le guide de travail sans droits administrateur sur un Mac distant. Si le pilote confirme qu’un nœud dédié est nécessaire, examinez ensuite les options de location de Mac de VPSNIX, en conservant vos critères techniques avant de comparer les offres.
SECTION 07 Que devez-vous faire cette semaine ?
Commencez par figer la matrice des tâches : compilation, tests, archive, signature, accès privé et opérations audio/vidéo ou design. Ensuite, associez chaque ligne à un tag de Runner et à une preuve attendue.
La séquence de travail recommandée est la suivante :
- relever les versions Xcode et macOS actuellement utilisées ;
- vérifier les images publiées dans la documentation GitLab ;
- isoler Xcode 27 sur un nœud qui n’exécute pas la signature de production par défaut ;
- tester les dépendances privées et les flux réseau ;
- répéter les mêmes commits avec et sans cache ;
- exécuter un lot réaliste de demandes de fusion, tests et archives ;
- consigner l’attente, l’exécution, les échecs et la reprise ;
- faire valider la matrice par l’IT, la sécurité et les responsables de publication.
GitLab Hosted macOS Runner n’a pas, à la date vérifiée, le niveau de disponibilité nécessaire pour devenir votre unique base Xcode 27. Un Runner séparé n’est pas un doublon inutile : c’est une frontière qui empêche une Beta, une dépendance privée ou une clé de signature de modifier le chemin de production sans contrôle.
Si votre environnement actuel repose uniquement sur des postes locaux, il présente généralement trois faiblesses : versions difficiles à aligner, accès réseau inégal et capacité imprévisible lorsque plusieurs archives arrivent en même temps. Un Mac distant loué par VPSNIX ne remplace pas l’audit ni la gouvernance des secrets, mais il peut fournir un nœud dédié et accessible pour le pilote, sans vous obliger à acheter immédiatement une machine pour chaque développeur. Pour une charge stable et lourde, ou pour un besoin de ports physiques et de contrôle matériel direct, l’achat ou l’hébergement interne peut rester plus pertinent ; pour une adaptation Xcode 27 temporaire, une capacité de secours ou un pool qui doit évoluer avec les projets, la location mérite une comparaison TCO documentée.
Consultez les règles de votre organisation, marquez séparément Xcode 27, la signature et le réseau privé, puis lancez le PoC sur un seul nœud. Étendez le pool uniquement lorsque les résultats réels de compilation, de file d’attente et de reprise justifient cette décision.