Répartissez vos builds iOS entre plusieurs Mac physiques dédiés. Affectez chaque scheme à un runner macOS pour archiver, signer et envoyer les builds sur TestFlight, au lieu de tout faire attendre sur un seul poste de travail.
ArmRDP fournit un Mac mini complet, pas une machine virtuelle. Trois configurations et 5 sites, à partir de $21.1/jour. Migrez d’abord un pipeline, puis augmentez la capacité selon la file d’attente réelle.
Pour livrer un build pendant la nuit, configurez au préalable le runner, la signature et l’envoi. Le délai dépend du projet, de ses dépendances et de la file des tâches.
Isolez les tâches par scheme et rassemblez les artefacts par nœud.
Enregistrez le Mac cloud comme runner macOS auto-hébergé dans GitLab ou GitHub Actions. Continuez à gérer le dépôt comme à votre habitude et dirigez uniquement les jobs qui nécessitent macOS vers ce nœud physique.
Consignez la version complète de Xcode, le SDK, le chemin des outils en ligne de commande et les fichiers de verrouillage des dépendances. Gérez plusieurs versions de Xcode avec xcodes et définissez DEVELOPER_DIR pour chaque job afin d’éviter que les projets ne partagent le même choix global.
Les labels du runner doivent indiquer au minimum le système, la chaîne d’outils et l’usage, par exemple macos, xcode-pinned et ios-release. Réservez les tâches de publication aux runners de confiance. N’exécutez pas de branches non vérifiées dans un environnement qui contient des éléments de signature.
Pour commencer, limitez chaque machine à une tâche de build lourde. Observez les builds à froid, l’efficacité du cache, la pression mémoire et l’espace disque utilisé avant d’augmenter la concurrence ou d’ajouter des nœuds. Le nombre de machines n’est pas le seul facteur : le cache et le découpage des tâches influent aussi sur la file d’attente.
xcodebuild -version
xcode-select -p
xcrun --sdk iphoneos --show-sdk-version
xcodebuild \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
-archivePath artifacts/App.xcarchive \
archiveRemplacez le workspace et le scheme App par les noms utilisés dans votre projet. Conservez séparément les archives, journaux de build et résultats des tests pour chaque job ; évitez que deux tâches écrivent dans le même dossier de sortie.
Préparez la publication sur l’App Store en reliant chaque artefact de build au commit, à la chaîne d’outils et à la configuration de signature correspondants. Le Mac cloud fournit l’environnement d’exécution ; votre équipe garde la maîtrise des autorisations de publication et des éléments de revue.
Conservez le fichier .xcarchive, la configuration d’export et les dSYM. Vérifiez d’abord la configuration Release, le numéro de version et le numéro de build, puis lancez l’export. Ne gardez pas uniquement le fichier .ipa final au risque de perdre les symboles nécessaires à l’analyse des plantages.
Critère de validation : chaque artefact doit correspondre à un commit et à un numéro de build uniques.
Importez les certificats de distribution et profils de provisionnement de manière contrôlée, et utilisez un trousseau dédié pour les tâches de build. Si vous utilisez fastlane match, limitez l’accès au dépôt et stockez les éléments de déchiffrement dans le gestionnaire de secrets de la CI, pas dans un script.
Critère de validation : une tâche non interactive peut exécuter codesign.
Envoyez les artefacts avec les identifiants autorisés par votre équipe. Vérifiez les captures du simulateur dans l’interface graphique et préparez les éléments de revue en contrôlant les appareils cibles, les langues et les versions. L’envoi et l’approbation sont deux étapes distinctes.
Critère de validation : archivez ensemble le résultat de l’envoi, les éléments de revue et les journaux.
Limitez les jobs de publication aux branches et aux opérateurs autorisés. Un certificat expiré, un profil de provisionnement incompatible ou des droits d’envoi insuffisants doivent être traités séparément à partir des journaux : ajouter des ressources ne résoudra pas ces problèmes.
macOS s’exécute nativement sur un nœud physique dédié ; Metal et les simulateurs conviennent aux tâches de développement compatibles. Utilisez SSH pour les scripts et les journaux, et le partage d’écran VNC pour Xcode, les simulateurs et les vérifications visuelles. Chaque mode d’accès a son rôle.
La compilation avec une version fixe, les tests automatisés, les captures du simulateur et l’installation des dépendances peuvent être exécutés sans mobiliser votre poste local. Pour diagnostiquer un problème interactif, reproduisez-le d’abord dans l’interface graphique, puis automatisez les étapes reproductibles.
Vérifiez d’abord la compatibilité entre le système cible, le runtime du simulateur et la version de Xcode.
La réactivité de l’affichage à distance dépend du réseau, de la résolution et de l’encodage ; elle ne sera pas identique à celle d’un écran local. Pour les tâches qui nécessitent un appareil externe, un périphérique spécifique ou des interactions fréquentes, testez-les réellement à la journée avant de décider de migrer.
ArmRDP M4 Pro embarque une puce M4 Pro, 64 Go de mémoire unifiée et un SSD de 2 To. Testez en environnement dédié le chargement de modèles locaux, comparez leurs versions quantifiées et validez les interfaces d’inférence avant de décider d’investir davantage.
La taille des fichiers du modèle ne correspond pas à la mémoire nécessaire à son exécution. En plus des poids, prévoyez la KV cache, la longueur du contexte, le framework d’exécution et les autres processus. Commencez avec le modèle cible et un contexte court, mesurez le pic mémoire et la pression mémoire, puis augmentez progressivement le volume de requêtes.
Utilisez un framework d’inférence compatible avec Apple Silicon et vérifiez la compatibilité des opérateurs utilisés et du format du modèle. La mémoire unifiée ne garantit pas que tous les modèles fonctionneront et ne permet pas, à elle seule, de prévoir la vitesse de génération. Validez les résultats avec vos propres prompts, contextes et longueurs de sortie.
Dans la mesure du possible, planifiez les expériences d’inférence séparément des builds de publication afin d’éviter que la concurrence mémoire ne fausse les résultats. Protégez les interfaces à distance par une authentification et un accès restreint ; n’exposez pas directement les ports d’écoute.
Ne migrez pas tout votre système de publication dès le départ. Choisissez un scheme aux dépendances bien définies qui produit déjà des builds fiables en local, gardez le résultat local comme référence et validez successivement les trois étapes ci-dessous.
Clonez le dépôt avec des identifiants en lecture seule ou à privilèges minimaux, puis vérifiez les sous-modules, dépendances privées et fichiers volumineux. Gérez séparément les certificats, profils de provisionnement et clés de déchiffrement ; ne placez pas de fichiers sensibles dans le dépôt.
Validation : toutes les données et dépendances du même commit sont disponibles.
Installez et verrouillez la version de Xcode requise par le projet avec xcodes. Conservez la liste des dépendances Homebrew et les fichiers de verrouillage des gestionnaires de paquets, installez le runtime du simulateur cible et consignez les variables d’environnement et chemins d’exécution.
Validation : l’exécution manuelle produit les artefacts attendus.
Enregistrez le runner, configurez ses labels et les autorisations du dépôt, puis dirigez le premier pipeline vers le Mac cloud. Une fois le flux validé, ajoutez la signature et l’envoi, puis étendez-le à d’autres schemes et à des nœuds indépendants.
Validation : les tâches sans intervention humaine s’exécutent de façon reproductible.
Pendant la migration, conservez le runner existant jusqu’à validation des builds à froid, de la signature, de l’envoi et des nouvelles tentatives après échec. Avant la fin de la location, exportez les données à conserver ; ne faites pas du disque du nœud votre unique emplacement d’archivage.
Les recommandations ci-dessous servent de point de départ selon le volume quotidien de tâches. Elles ne constituent ni un test de débit ni une garantie de livraison. Une compilation complète de grande ampleur peut être plus exigeante que plusieurs builds incrémentiels. Mesurez aussi le temps d’exécution, l’efficacité du cache et le pic mémoire avant de choisir une machine plus puissante ou d’ajouter des nœuds.
| Volume quotidien indicatif | Configuration de départ | Points à vérifier en priorité | Location à la journée |
|---|---|---|---|
| 1–5 builds Tests ponctuels, démarrage avec un seul projet |
ArmRDP M4 Base M4 / 16 Go / 256 Go |
Vérifiez le cycle complet d’archivage et de signature ; surveillez l’espace disque utilisé par les dépendances, DerivedData et les artefacts. | $21.1/jourLouer un M4 Base |
| 6–20 builds Intégration continue, itérations fréquentes |
ArmRDP M4 Plus M4 / 24 Go / 512 Go |
Vérifiez la pression mémoire lorsque compilation et tests s’exécutent ensemble. Optimisez d’abord le cache, puis évaluez le besoin de plusieurs runners. | $41.4/jourLouer un M4 Plus |
| 21 builds ou plus Évaluation des tâches lourdes et multi-cibles |
ArmRDP M4 Pro M4 Pro / 64 Go / 2 To |
Évaluez les ressources nécessaires aux grands projets ou aux expériences sur modèles. Si le goulot d’étranglement vient de la file d’attente, répartissez les tâches indépendantes entre plusieurs nœuds. | $59.5/jourLouer un M4 Pro |
Les 5 sites sont Singapour, le Japon (Tokyo), la Corée du Sud (Séoul), Hong Kong et l’ouest des États-Unis ; les trois configurations sont disponibles sur chacun. Pour une utilisation graphique interactive, comparez la qualité de connexion entre votre équipe et les nœuds. Pour les builds sans intervention, vérifiez aussi les chemins d’accès au dépôt, de téléchargement des dépendances et d’envoi des artefacts. La disponibilité réelle est indiquée dans la console.
Commencez à la journée pendant la phase de validation ; comparez ensuite les tarifs à la semaine, au mois ou au trimestre si votre rythme de publication est régulier. Paiement accepté : USDT-TRC20 et Visa / Mastercard / Amex (via Stripe), avec facturation en dollars US. Les moyens de paiement disponibles sont confirmés par le système.
Préparez un scheme, une configuration de signature et des critères de validation clairs. Une fois l’archivage, la signature et la livraison validés, ajoutez des nœuds pour les autres tâches.