Un Mac dédié · deux modes d’accès

Builds en SSH,
Xcode en VNC

La ligne de commande et le bureau graphique se connectent au même Mac mini physique. Laissez le runner exécuter les tâches en continu, puis ouvrez le partage d’écran lorsque vous devez vérifier Xcode, un simulateur ou la configuration des certificats.

Louer un Mac dédié Suivre les étapes

Apple Silicon M4 · 2 configurations · dès $20/jour. La machine entière est attribuée à un seul client ; ce n’est pas une machine virtuelle.

Espace dédié à l’équipe

Les tâches continuent, le bureau s’ouvre à la demande

SSHAutomatisation
  1. Synchroniser le projet
  2. Lancer les tests
  3. Archiver les artefacts
VNCVérifications interactives
  1. Ouvrir Xcode
  2. Vérifier le simulateur
  3. Confirmer la signature

Le projet, le disque et la chaîne d’outils sont partagés : vous n’avez pas deux machines à configurer. L’utilisation du bureau mobilise elle aussi les ressources de la machine.

Définissez les rôles, puis connectez-vous

L’automatisation en ligne de commande, les vérifications sur le bureau

Les deux modes peuvent coexister. Choisissez en fonction du besoin d’une interface graphique, et non de la présence d’une personne devant l’ordinateur.

SSH : pour les tâches répétitives

Utilisez SSH pour compiler et tester avec xcodebuild, enregistrer les runners, consulter les logs et synchroniser les fichiers avec scp ou rsync. Les logs de build sont du texte : inutile de transmettre en continu l’image du bureau.

  • Intégrez l’installation des dépendances, les tests et l’archivage au pipeline pour réduire les manipulations manuelles.
  • Vérifiez le processus du runner, le répertoire de travail, l’espace disque disponible et les logs d’échec.
  • Gérez le runner comme un service afin de ne pas lier les tâches de longue durée à une seule session SSH.

Idéal pour : vérifications de PR, builds nocturnes, packaging par lots et synchronisation des artefacts.

VNC : pour les tâches avec interface graphique

Utilisez VNC pour l’interface de Xcode, les simulateurs, le trousseau et la configuration des certificats. Le partage d’écran intégré à macOS ou tout client VNC compatible convient pour vous connecter.

  • Vérifiez les targets du projet, les réglages de build et la configuration de signature tels qu’ils apparaissent réellement.
  • Ouvrez un simulateur pour reproduire un problème d’interface et vérifier le runtime ainsi que le type d’appareil.
  • Effectuez les réglages qui nécessitent une confirmation interactive, puis automatisez les étapes reproductibles dans un script.

Idéal pour : l’initialisation de l’environnement, le débogage graphique et les vérifications manuelles avant publication.

Première connexion

Vérifiez les identifiants une fois, puis testez chaque accès

Connectez-vous au portail et ouvrez la fiche de l’instance concernée. Utilisez les valeurs affichées pour l’adresse, le nom d’utilisateur, le port et le mode d’authentification. Ne confondez pas le port SSH avec celui de VNC.

  1. 01

    Récupérez les identifiants de l’instance

    Vérifiez l’ID de l’instance et le nœud, puis notez séparément les informations de connexion SSH et VNC. Avant la première connexion, vérifiez que l’instance est disponible. Si le portail n’affiche pas encore les identifiants, conservez les informations de commande et ouvrez un ticket depuis le portail ; ne tentez pas de deviner l’adresse ou le mot de passe.

  2. 02

    Testez l’accès en ligne de commande

    Connectez-vous avec le port et le nom d’utilisateur fournis pour l’instance. À la première alerte sur l’empreinte de l’hôte, vérifiez-la avant de continuer. Si l’empreinte change soudainement pour une même adresse, interrompez la connexion et vérifiez si l’instance a été réattribuée.

    ssh -p "$SSH_PORT" "$MAC_USER@$MAC_HOST"
sw_vers
uname -m
xcode-select -p
df -h

    Définissez d’abord les variables dans votre terminal local à partir des valeurs affichées dans le portail. Une fois connecté, vérifiez macOS, l’architecture, le répertoire développeur et l’espace disque.

  3. 03

    Ouvrez le partage d’écran

    Sur votre Mac, ouvrez « Partage d’écran », puis saisissez l’adresse et le port VNC indiqués pour l’instance. Sur un autre système, utilisez un client compatible. Connectez-vous avec le mode d’authentification de l’instance. Vérifiez que le bureau s’affiche et que vous pouvez utiliser la souris avant d’ouvrir Xcode. En cas d’échec, vérifiez dans l’ordre l’adresse, le port, les informations d’authentification et les restrictions de votre réseau local.

  4. 04

    Limitez les accès

    Après la première connexion, modifiez les identifiants initiaux selon la méthode prise en charge par l’instance et gérez une clé SSH par membre de l’équipe. Ne stockez pas les mots de passe dans le dépôt. Attribuez au runner un jeton d’enregistrement aux permissions minimales nécessaires ; gérez les identifiants, certificats et clés privées dans un processus contrôlé. Lancez un build minimal avant d’activer le pipeline de production.

Connectez-vous au portail pour voir vos identifiants

5 nœuds · repères réseau

Pour le bureau, regardez l’aller-retour ; pour les builds, le chemin des données

La réactivité des clics en VNC dépend de la latence aller-retour. Pour les builds en continu, l’emplacement du dépôt, des sources de dépendances et du stockage des artefacts compte davantage. Les plages ci-dessous sont des repères par nœud, pas des mesures depuis votre emplacement ni une garantie de latence.

Nœud, zone desservie et plage aller-retour indicative ; choisissez votre accès selon vos usages principaux
Nœud Zone desservie Aller-retour indicatif Usage recommandé
Singapour Asie du Sud-Est 20~50ms Développement interactif pour les équipes d’Asie du Sud-Est ; vérifiez aussi les chemins vers le dépôt et les sources de dépendances.
Japon (Tokyo) Asie de l’Est 30~60ms Utilisation de Xcode par les équipes d’Asie de l’Est ; rapprochez le runner et le stockage des artefacts si possible.
Corée du Sud (Séoul) Asie du Nord-Est 30~50ms Consultation des simulateurs, dépannage à distance et synchronisation des projets pour les équipes d’Asie du Nord-Est.
Hong Kong Sud de la Chine et Asie du Sud-Est 20~40ms Partage d’écran et tâches de build quotidiennes pour les équipes du sud de la Chine et d’Asie du Sud-Est.
États-Unis (côte Est) Est de l’Amérique du Nord et Europe de l’Ouest 25~35ms Collaboration pour les équipes de cette zone ; choisissez le nœud en fonction de l’emplacement du code et des artefacts.

Plages indicatives ; les résultats réels dépendent de votre réseau.

Depuis votre réseau de travail habituel, effectuez une opération sur le bureau, récupérez des dépendances et envoyez un artefact. Notez séparément la réactivité, la durée du transfert et celle du build : ne les réduisez pas à une seule mesure de la « vitesse de la machine ».

Réduisez la charge d’affichage avant de vérifier le réseau

Réservez la bande passante à la tâche en cours

Commencez par des réglages d’affichage suffisants. Plus l’image distante est grande et change souvent, plus l’encodage et le transfert sollicitent le réseau. Ajuster le bureau ne réduit pas le travail du compilateur, mais peut rendre les interactions plus réactives.

Adaptez la résolution à votre espace de travail

Commencez en 1440 × 900 ou 1600 × 900 pour lire confortablement l’éditeur et les logs. N’augmentez la résolution que si vous avez réellement besoin de plus de panneaux ; évitez de transmettre tout l’écran en haute résolution par défaut.

Modifiez un seul réglage à la fois et comparez la lisibilité du texte ainsi que la réactivité des fenêtres.

Ajustez la profondeur de couleur et la qualité au client

Si votre client propose des options de profondeur de couleur, de qualité ou de compression, réduisez d’abord la qualité d’image lorsque la bande passante est limitée. Gardez le code lisible et évitez la lecture vidéo ou l’actualisation continue de fenêtres inutiles.

Les options portent des noms différents selon les clients : utilisez les réglages réellement disponibles.

Fermez l’affichage quand vous n’interagissez pas

Pour transférer de gros fichiers ou travailler sur un réseau instable, consultez les logs texte en SSH et confiez le build à un runner configuré comme service. Ne comptez pas sur une fenêtre de terminal graphique pour maintenir une tâche longue ; vérifiez d’abord qu’elle continue de tourner sans session interactive.

Une fois vos vérifications terminées, déconnectez le bureau sans fermer la session système ni éteindre la machine.

Le développement Xcode à distance a ses limites

Le bureau sert à vérifier, le pipeline à reproduire

Transformez les vérifications manuelles en changements d’environnement traçables : notez la version de Xcode, le runtime du simulateur et les réglages de signature, puis vérifiez le tout en ligne de commande avec le même projet. Ne vous contentez pas d’une configuration « testée une fois depuis le bureau ».

Ordinateur et équipements de bureau dans un espace de développement à distance, illustrant l’accès à Xcode dans le cloud depuis un poste de travail local
Illustration d’un espace de développement à distance. Le partage d’écran transmet le bureau distant ; les périphériques locaux ne sont pas automatiquement connectés à la machine distante.

Ce que vous pouvez faire dans le cloud

La vérification des projets Xcode, la compilation et l’archivage, les tests sur simulateur et la configuration des certificats s’effectuent dans l’environnement macOS distant. SSH et VNC donnent accès aux mêmes fichiers : évitez de modifier manuellement un répertoire de travail utilisé par le runner.

Le débogage sur appareil réel nécessite une organisation distincte

Un iPhone connecté en local n’apparaît pas dans Xcode à distance lorsque vous ouvrez VNC. Les tests sur appareil réel nécessitent de prévoir séparément son accessibilité et le processus de test. Vous pouvez générer un build signé dans le cloud, puis le transmettre aux appareils de test selon le processus de distribution déjà utilisé par votre équipe.

Gérez séparément projet, cache et artefacts

Transférez les petits fichiers avec scp, synchronisez en incrémental

Le dépôt conserve l’historique des versions ; la synchronisation de fichiers gère les copies de travail et les artefacts. Ne transférez pas les certificats, clés privées et jetons avec les fichiers ordinaires du projet. Avant l’envoi, vérifiez les règles d’exclusion et le chemin de destination.

scp : transférer un artefact de build

Pratique pour récupérer une archive ou un paquet de ressources précis. La commande ci-dessous télécharge une archive déjà générée sur la machine distante ; remplacez le répertoire et le nom de fichier par les chemins réels.

scp -P "$SSH_PORT" \
  "$MAC_USER@$MAC_HOST:build/ios-build.zip" \
  ./ios-build.zip

Avec scp, l’option de port est un -P majuscule. Vérifiez la taille du fichier après le transfert ; pour contrôler l’intégrité du contenu, comparez les sommes de contrôle des deux côtés.

rsync : synchroniser une copie de travail

Idéal pour synchroniser plusieurs fois le même répertoire. Faites d’abord un essai à blanc et vérifiez le chemin de destination ainsi que les exclusions ; la barre oblique finale indique que le contenu du répertoire est synchronisé.

rsync -avn \
  -e "ssh -p $SSH_PORT" \
  --exclude '.git/' \
  --exclude 'DerivedData/' \
  ./project/ "$MAC_USER@$MAC_HOST:project/"

Après avoir vérifié le résultat de l’essai, remplacez -avn par -av pour lancer la synchronisation. Aucun paramètre de suppression n’est utilisé : les fichiers absents en local ne seront donc pas supprimés de la machine distante.

Choisissez un point d’accès, puis lancez votre première tâche

Choisissez le nœud le plus proche de vous

Pour le développement interactif, tenez compte du réseau de votre bureau ; pour les builds en continu, regardez où se trouvent le dépôt et les artefacts. Choisissez un nœud lors de la commande ; sa disponibilité réelle est celle indiquée en temps réel dans le portail.

Choisir un nœud et louer un Mac cloud Voir les repères des 5 nœuds