Ce guide s’adresse aux développeurs qui souhaitent utiliser un Mac dédié pour Xcode ou une CI macOS. Choisissez votre configuration et votre région, récupérez vos informations de connexion, vérifiez les outils, puis lancez un build reproductible.
Les commandes et résultats affichés sont des exemples et ne signifient pas que votre projet est déjà configuré. Les paramètres de connexion, l’état de la machine et l’avancement de la livraison sont ceux indiqués dans la console.
Vérifiez ces quatre points avant de confier le projet à un nœud distant.
Checklist indicative · La commande et la console font foi
Les cinq étapes suivent l’ordre des opérations. Si vous avez déjà une commande, passez directement à la connexion ou au dépannage.
Vérifiez le modèle, la région, la durée de location et le statut de la commande pour savoir où récupérer vos informations de connexion.
Voir les étapes de commande → 02Vérifiez les paramètres SSH et distinguez les tâches en ligne de commande de celles qui nécessitent un bureau graphique.
Voir un exemple de connexion → 03Récupérez le projet, vérifiez Xcode et ses dépendances, puis confirmez l’emplacement des artefacts.
Voir les étapes de build → 04Vérifiez l’identité du Runner, les tags de job et les droits de signature avant de lancer les builds automatisés.
Voir les vérifications CI → 05Vérifiez la durée de location et les options. Consultez les détails des commandes et créez des tickets depuis la console.
Voir les démarches de gestion →Le temps indiqué sert uniquement à illustrer la durée d’une démonstration, et non un délai de livraison. Consultez le statut de la commande et de la machine dans la console pour connaître l’avancement réel et vérifier si les informations de connexion sont disponibles.
Environ 4 minutesDurée totale des opérations présentées, hors attente de livraison
Choisissez une configuration disponible selon les besoins en mémoire et en stockage du projet, puis une région adaptée à l’emplacement de l’équipe et à ses fuseaux horaires. Vérifiez la couverture avant de commander.
Vérifiez la durée de location et les options, puis validez la commande. La disponibilité et les moyens de paiement proposés sont ceux affichés en temps réel dans la console.
Attendez que la machine soit indiquée comme prête. Dans la console, récupérez l’adresse, le compte et les instructions de connexion associés à cette instance. Ne réutilisez pas les identifiants des exemples publics.
Connectez-vous et vérifiez le compte utilisé, l’espace disque et la version de la chaîne d’outils Xcode. En cas d’écart, arrêtez les tâches automatisées et consignez les résultats.
SSH convient pour récupérer le code, lancer un build et consulter les journaux. Pour utiliser l’interface graphique de Xcode, suivez les instructions de connexion au bureau à distance fournies pour votre instance.
$ ssh developer@192.0.2.10
Last login: example session
$ xcodebuild -version
Xcode
Build version: example
$ xcodebuild -workspace App.xcworkspace \
-scheme App -configuration Release \
-destination 'generic/platform=iOS' build
** BUILD SUCCEEDED **
$ fastlane build
[example] Build completed
[example] Artifact: ./build/App.ipaMac local → Mac cloud : assurez-vous d’abord que le code source et les dépendances sont accessibles, vérifiez la chaîne d’outils, puis dirigez les tâches CI vers le nouveau nœud d’exécution.
Privilégiez la récupération du code depuis le dépôt et identifiez les fichiers de configuration et ressources de build non suivis. Faites l’inventaire des éléments sensibles avant le transfert afin de ne pas inclure d’identifiants dans le dépôt ou les journaux.
Vérification : Les fichiers du projet attendus sont présents dans le répertoire cloud et les droits d’accès aux fichiers sensibles ont été vérifiés.
Notez les versions de Xcode, des outils en ligne de commande et des dépendances gérées par un gestionnaire de paquets en local. Résolvez à nouveau les dépendances dans le cloud et vérifiez les exigences minimales du projet en matière de système et d’architecture.
Vérification : Le même Scheme lance un build en ligne de commande et les différences de version sont consignées.
Attribuez au nouveau nœud une identité Runner et des tags de job dédiés. Lancez d’abord une tâche de validation ne nécessitant aucun identifiant de publication, puis vérifiez les autorisations requises pour le packaging.
Vérification : Les tâches de test s’exécutent sur le nœud prévu et leurs journaux comme leurs artefacts sont traçables.
Commencez par effectuer un build complet manuellement et conservez les versions, la commande et les messages d’erreur. Décidez ensuite si vous souhaitez automatiser la tâche. Les besoins en signature et en dépendances varient selon les projets.
Récupérez le dépôt par la méthode approuvée par votre équipe et vérifiez le commit cible, les sous-modules et les fichiers de verrouillage. Exécutez d’abord git status pour éviter d’évaluer le build à partir de modifications non identifiées.
Définissez qui gère les certificats, les profils de provisionnement et les clés nécessaires, et qui peut y accéder. Ne placez pas de clé privée dans un dépôt public et ne copiez pas d’identifiants complets dans un ticket de dépannage.
Vérifiez d’abord xcodebuild -version ainsi que le Scheme du projet, puis lancez la commande de build réellement utilisée par le projet. Notez le code de sortie et la première erreur pertinente au lieu de ne conserver que la fin des journaux.
Vérifiez les fichiers générés, leur taille et leur chemin, puis archivez-les ou transférez-les selon le processus de l’équipe. Un message de réussite ne remplace pas la vérification des fichiers et de leur signature.
Pour configurer un runner macOS GitLab CI, installez-le et enregistrez-le sur le nœud, associez-le à un projet autorisé et utilisez des tags de job pour contrôler où les tâches s’exécutent. La méthode d’enregistrement, le périmètre d’accès et les paramètres de concurrence doivent respecter les règles CI de votre équipe.
Le premier job de validation peut simplement afficher les versions du système et de Xcode. Cela confirme que la tâche a atteint le nœud Apple Silicon prévu, mais ne garantit pas que la signature, le téléchargement des dépendances ou la publication fonctionnent.
fastlane peut s’intégrer au processus de packaging existant, mais ne remplace pas les vérifications propres au projet sur les accès, la signature et les versions.
Avant de commander, choisissez le modèle, la région et la durée de location (jour, semaine, mois ou trimestre), puis déterminez si vous avez besoin d’une extension SSD ou de la mise en parallèle Thunderbolt 5. Chaque option est facturée séparément ; la commande confirmée fait foi pour le choix final et le montant.
Paiement uniquement par USDT-TRC20 ou Visa / Mastercard / Amex (via Stripe), en dollars américains (USD). Les moyens disponibles dépendent de ceux indiqués par la console.
Dans la console, vérifiez la référence de commande, la durée de location, la région, les options et le statut de la machine. Pour toute question de facturation concernant une commande existante, connectez-vous et ouvrez un ticket en indiquant sa référence et les points à vérifier. N’envoyez pas d’informations de paiement dans un message public.
Ouvrir la consoleAvant de contacter l’équipe, notez l’heure de l’incident, la référence de commande associée à l’instance, l’opération effectuée et le message d’erreur anonymisé. N’envoyez ni mot de passe, ni clé privée, ni certificat de signature, ni document de projet non expurgé.
Vérifiez d’abord dans la console le statut de la machine, son adresse et le compte utilisé, puis contrôlez votre réseau local et le mode de connexion. Notez la commande, le type d’erreur et l’heure de l’incident ; masquez les identifiants.
Notez la version du commit, celle de Xcode, le Scheme, la commande complète et la première erreur pertinente. Identifiez s’il s’agit de la récupération des dépendances, de la compilation, de la signature ou de l’exportation. Ne fournissez pas uniquement la dernière ligne indiquant l’échec du build.
Vérifiez l’espace occupé par le projet, le cache de build et les artefacts. Déterminez d’abord avec l’équipe quels fichiers peuvent être supprimés en toute sécurité. Joignez un relevé anonymisé de l’espace utilisé et le chemin en erreur, sans supprimer par mégarde des artefacts à archiver.
Vérifiez le compte d’exécution, la propriété des fichiers et les droits d’accès au dépôt ou aux éléments de signature. Notez le chemin concerné et le message d’erreur ; n’élargissez pas les droits sur tous les fichiers pour contourner le problème.
Comparez les trois configurations et les durées de location, puis vérifiez les disponibilités en temps réel dans la console. Après connexion, commencez par un build de validation reproductible.