Xcode dans le cloud : Mac distant

Quatre étapes pour récupérer les accès à votre Mac dédié

Prévoyez environ 1 minute pour l’inscription, la configuration, le paiement et l’attribution : l’activation prend environ 4 minutes si tout se passe bien. Il s’agit d’une estimation des opérations, pas d’un délai de livraison garanti. La réception des e-mails, la confirmation du paiement et l’attribution système dépendent de l’état affiché dans la console.

Inscrivez-vous et ouvrez la console
Env. 1 min
Préparez une adresse e-mail d’équipe pouvant recevoir un code de vérification. Suivez les instructions à l’écran pour vous inscrire et définir un mot de passe. Utilisez une adresse suivie par l’équipe pour gérer les commandes, les renouvellements et les tickets. Ne transférez pas les codes de vérification dans des journaux de build publics.
Choisissez la configuration, la durée et le nœud
Env. 1 min
Choisissez Push M4 S ou Push M4 L, puis la période de facturation et le nœud. Pour la CI quotidienne d’une seule app, commencez par évaluer la configuration 16 Go ; pour archiver plusieurs targets en parallèle, évaluez celle de 24 Go. La disponibilité réelle est indiquée en temps réel dans la console.
Réglez en dollars US
Env. 1 min
Choisissez USDT-TRC20 ou payez par Visa, Mastercard ou Amex via Stripe. Les moyens disponibles sont ceux indiqués sur la page de paiement. Pour un transfert on-chain, vérifiez le réseau, l’adresse et le montant, puis attendez la confirmation dans la console : un paiement lancé ne signifie pas que le service est activé.
Recevez le Mac et les informations de connexion
Env. 1 min
Une fois le Mac attribué, vérifiez le nœud, l’adresse de connexion, le port et le nom d’utilisateur dans la commande ou les détails de l’instance, puis récupérez les accès SSH/VNC. Pour contacter le support, indiquez le numéro de commande : ne communiquez ni mot de passe ni clé privée.

Gardez les interactions près de l’équipe et les builds près des dépendances

Les cinq nœuds proposent les deux configurations de Mac dédié. Commencez par la localisation des personnes qui utilisent la machine au quotidien, puis vérifiez le chemin réseau entre le dépôt, les sources de dépendances et le stockage des artefacts. Un fuseau horaire pratique facilite les transmissions, mais ne garantit pas une faible latence. Testez séparément l’usage de VNC et le téléchargement des dépendances.

Singapour

À privilégier si la plupart de l’équipe se trouve en Asie du Sud-Est. Testez à la fois votre réseau de connexion à distance habituel et le téléchargement des dépendances.

Fuseau de collaboration : UTC+8

Tokyo

À évaluer en priorité pour les équipes travaillant surtout les jours ouvrés au Japon. Utilisez un libellé de runner fixe pour éviter d’envoyer les tâches vers un autre nœud.

Fuseau de collaboration : UTC+9

Séoul

À évaluer en priorité si les membres de l’équipe en Corée utilisent souvent le bureau à distance. Vérifiez la réactivité de l’interface graphique depuis le réseau de travail habituel.

Fuseau de collaboration : UTC+9

Hong Kong

À évaluer pour les échanges avec le sud de la Chine et l’Asie du Sud-Est. Réservez le bureau à distance aux interactions et SSH aux commandes ; conservez les journaux dans le système de build.

Fuseau de collaboration : UTC+8

Côte est des États-Unis

À privilégier si l’équipe a besoin d’interagir avec la machine pendant la journée en Amérique du Nord. Utilisez UTC pour horodater les transmissions entre régions.

Fuseau de collaboration : UTC−5 / UTC−4

L’heure de la côte est des États-Unis varie selon la saison. Si les équipes des deux régions doivent intervenir souvent, louez un nœud dans chaque région et coordonnez les tâches avec une file CI. Même sur un seul Mac dédié, limitez le nombre de tâches lourdes exécutées en parallèle.

Commencez par SSH, puis ouvrez le bureau macOS

Utilisez l’adresse, le port et le nom d’utilisateur indiqués dans la console ; ne réutilisez pas les accès d’une autre commande. Les commandes ci-dessous vous demanderont les valeurs réelles. Vérifiez d’abord que votre ordinateur dispose d’un client SSH.

SSH : vérifiez l’accès en ligne de commande

Exécutez la commande dans votre terminal local. Lors de la première connexion, vérifiez l’empreinte de l’hôte. Si la console ne fournit aucune information permettant de la vérifier, demandez confirmation via un ticket au lieu d’ignorer le contrôle d’identité de l’hôte.

printf 'Adresse de connexion : '
read -r MAC_HOST
printf 'Port SSH : '
read -r MAC_PORT
printf 'Utilisateur : '
read -r MAC_USER
ssh -p "$MAC_PORT" "$MAC_USER@$MAC_HOST"

Après la connexion, exécutez whoami et sw_verspour vérifier l’utilisateur et les informations système. Lorsque vous configurez des clés SSH, ne téléversez que la clé publique ; conservez la clé privée sur votre appareil ou dans le gestionnaire de secrets de votre CI.

VNC : vérifiez l’accès au bureau

Connectez-vous à la console et ouvrez les informations de connexion de l’instance livrée.
Connectez-vous au bureau à distance selon les instructions de l’instance, puis vérifiez l’adresse et les identifiants.
Dans macOS, vérifiez le clavier, l’affichage et le réseau, puis définissez le mot de passe VNC conformément aux règles de l’équipe.
Terminez les étapes du premier lancement de Xcode et les autorisations liées au trousseau, puis revenez à SSH pour lancer le build.

Utilisez le bureau pour les autorisations nécessitant une interface graphique et la ligne de commande pour exécuter des scripts reproductibles. En cas de délai de connexion, vérifiez le port, l’état de l’instance et votre réseau local avant d’ouvrir un ticket. Changer plusieurs fois le mot de passe ne permet pas de diagnostiquer un problème réseau.

Conservez une trace reproductible de l’archive

Le premier build comporte quatre vérifications : chaîne d’outils, projet, signature et export. Les commandes ci-dessous conviennent aux projets iOS utilisant un workspace. Pour un projet utilisant uniquement un project, remplacez -workspace par -projectet utilisez le nom de fichier propre au projet.

Vérifiez la chaîne d’outils active

Vérifiez d’abord le Xcode réellement sélectionné par le système, et pas seulement les versions installées dans le dossier Applications. Si plusieurs versions coexistent, sélectionnez le chemin de l’app convenu pour le projet, puis vérifiez à nouveau la version et le SDK.

xcode-select -p
xcodebuild -version
xcodebuild -showsdks
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer

Clonez le dépôt et repérez le scheme partagé

Saisissez l’adresse du dépôt avec un accès en lecture. Authentifiez-vous avec une clé SSH ou un gestionnaire d’identifiants sécurisé ; n’incluez pas de jeton d’accès dans la commande. Préparez les dépendances selon les consignes du projet, puis affichez les workspaces et les schemes.

printf 'Adresse du dépôt : '
read -r REPOSITORY_URL
git clone "$REPOSITORY_URL" app
cd app
git rev-parse HEAD
find . -name '*.xcworkspace' -prune
xcodebuild -list -workspace MyApp.xcworkspace

Utilisez un chemin fixe pour créer l’archive

Remplacez MyApp.xcworkspace et MyApp par les noms exacts vérifiés à l’étape précédente. Pour un build signé destiné à un appareil, importez de manière sécurisée le certificat correspondant et le profil de provisioning, puis vérifiez que le processus de build peut accéder au trousseau.

mkdir -p build
xcodebuild \
  -workspace MyApp.xcworkspace \
  -scheme MyApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -derivedDataPath build/DerivedData \
  -archivePath build/MyApp.xcarchive \
  archive

Générez les livrables avec la configuration d’export du projet

ExportOptions.plist doit correspondre à la configuration de signature et de distribution définie pour le projet ; ne reprenez pas celle d’une autre équipe. La réussite de l’archive ne garantit pas celle de l’export. Conservez séparément le code de sortie et les journaux de chaque étape.

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

test -d build/MyApp.xcarchive
find build/export -maxdepth 1 -type f -print

Consignez quatre éléments de transmission, jamais de secrets

Notez le SHA du commit, la version de Xcode, le scheme utilisé et le chemin des artefacts. En cas d’échec au premier essai, examinez la première erreur : pour un problème de résolution des dépendances, vérifiez le réseau et les versions verrouillées ; pour une erreur de signature, vérifiez le certificat et le profil de provisioning ; pour un échec d’export, vérifiez la configuration d’export. Ne changez pas simultanément le nœud, les outils et la signature lors d’une même nouvelle tentative.

Confiez à votre CI les commandes déjà vérifiées

Faites d’abord fonctionner le build manuellement sous le même compte que celui qui l’exécutera, puis enregistrez le runner auto-hébergé. Une disponibilité continue assure l’alimentation et l’hébergement de la machine ; le démarrage automatique du runner, la validité des certificats et les tâches bloquées dans la file restent à configurer et à vérifier par l’équipe.

Enregistrez le runner et orientez les tâches

Récupérez les instructions d’installation d’un runner macOS ARM64 dans les paramètres du projet ou de l’organisation de votre plateforme CI. Utilisez les informations d’enregistrement du projet actuel, sans réutiliser de jeton expiré. Les libellés doivent préciser le nœud, l’architecture et l’usage.

GitHub Actions : générez les instructions d’enregistrement dans Self-hosted runners et vérifiez la portée des autorisations du dépôt.
GitLab Runner : enregistrez le runner avec l’adresse et le jeton fournis par le projet, puis choisissez l’exécuteur adapté aux tâches Xcode.
Réservez l’accès aux éléments de signature aux pipelines de confiance. N’exécutez pas de code non vérifié sur un Mac dédié contenant des clés.

Pour la première intégration, ne lancez qu’un seul build. Surveillez la mémoire, le disque et la durée avant d’augmenter la concurrence ; un Mac dédié ne justifie pas de lancer toutes les archives en même temps.

Activez le démarrage automatique et vérifiez le service en arrière-plan

Après avoir décompressé et enregistré le runner GitHub Actions, vous pouvez utiliser le script de service fourni dans son répertoire d’installation. Les commandes ci-dessous ne téléchargent ni n’enregistrent le runner : suivez d’abord les instructions de la plateforme CI.

./svc.sh install
./svc.sh start
./svc.sh status

Vérifiez que le script indique que le service est en cours d’exécution et que le runner apparaît en ligne dans la plateforme CI. Un LaunchAgent dépend généralement de la session ouverte par l’utilisateur. Pour un démarrage sans intervention, configurez et vérifiez le mécanisme pris en charge officiellement par le runner ; l’installation du service ne garantit pas à elle seule qu’un build fonctionnera après un redémarrage.

Dernière validation : produire un build sans le terminal ouvert

Fermez le terminal ayant servi à lancer le runner manuellement, puis déclenchez une tâche contrôlée depuis la CI. Vérifiez l’utilisateur d’exécution, la version de Xcode sélectionnée, l’accès au trousseau, les répertoires de cache et l’envoi des artefacts. Pour un nœud destiné à fonctionner sans surveillance, vérifiez aussi l’état du runner après son rétablissement. Avant tout redémarrage, assurez-vous qu’aucune autre tâche n’est en cours.

Un Mac dédié peut conserver DerivedData et les caches de dépendances. Les clés de cache doivent au minimum distinguer la chaîne d’outils, le fichier de verrouillage des dépendances et la configuration de build. Définissez des règles de nettoyage avant de conserver les artefacts, afin que les caches ne saturent pas le disque système.

Pour le prochain push, repartez de cette trace

Une fois la connexion et le premier build validés, consignez le nœud, la chaîne d’outils et les commandes de build dans les notes de transmission de l’équipe. Pour les détails sur le changement de version et les caches, consultez le guide ; pour augmenter la capacité de build, vérifiez d’abord les configurations disponibles.

Consulter le guide d’utilisation Choisir une configuration de Mac dédié

Reliez un push de codeà un Mac en centre de données