Des ressources dédiées à votre équipe

Transférez vos pipelines
en attente sur un Mac dédié

Un Mac mini Apple Silicon M4 réservé à un seul client. Regroupez contrôles de PR, archives nocturnes et accès distant à Xcode sur une chaîne d’outils maîtrisée, sans partager les ressources CPU avec d’autres clients.

Louer un nœud macOS Voir les 3 étapes de migration

2 configurations M4 · dès 20 $/jour · Mac physique dédié, pas une VM

Votre environnement d’équipe

PRVérifications du commit
TestsCompilation et tests unitaires
ArchiveArchivage et distribution

La machine entière vous est réservée. La concurrence et les priorités des tâches de votre équipe dépendent de la configuration de vos runners.

Répartissez d’abord les tâches, puis les ressources

Organisez vos quatre types de tâches en files dédiées

Définissez d’abord le rôle principal de la machine, puis choisissez la mémoire et le stockage. Le développement interactif, les archives de publication et les expériences de modèles peuvent utiliser des nœuds similaires, mais ne devraient pas se disputer les ressources sans limites.

Cas 1 · Contrôles de PR

Compilez et lancez les tests unitaires à chaque commit

Idéal pour la CI d’un projet, les petites apps SwiftUI et les équipes qui veulent migrer leur machine de build du bureau. À chaque PR, récupérez le code, restaurez les dépendances, lancez les tests unitaires et renvoyez les résultats à votre plateforme CI habituelle.

Commencez avec le Merge M4 S : Apple Silicon M4, 16 Go de RAM et SSD de 256 Go. La machine est réservée à un seul client ; les builds ne partagent donc pas les cœurs avec d’autres clients. Limitez tout de même les tâches parallèles de votre équipe pour éviter que plusieurs builds ne saturent la mémoire.

Pour votre premier pipeline, limitez-vous à trois étapes

Figez le commit du dépôt, le fichier de verrouillage des dépendances et la version de Xcode.
Lancez d’abord la compilation et les tests unitaires d’un seul scheme.
Mesurez séparément l’attente, la compilation et les tests pour repérer les étapes les plus longues.

Quand envisager une autre configuration ? Si plusieurs targets ou des tests parallèles sur simulateur augmentent nettement la mémoire utilisée, évaluez les 24 Go. Ne déduisez pas le nombre de machines nécessaires du seul effectif de l’équipe.

Louer le Merge M4 S

Cas 2 · Publications quotidiennes

Réservez les archives nocturnes au nœud de publication

Idéal pour les équipes qui génèrent chaque jour des builds de test, planifient des archivages ou automatisent le packaging avec Fastlane. Réutilisez vos lanes existantes pour enchaîner archivage, export et envoi vers TestFlight dans un même pipeline de publication.

Nous recommandons le Merge M4 L : Apple Silicon M4, 24 Go de RAM et SSD de 512 Go. Par rapport à la configuration d’entrée de gamme, il offre plus de mémoire et de stockage local pour conserver les dépendances de plusieurs projets et les runtimes de simulateur nécessaires. Les gains réels dépendent du projet et de l’état du cache.

Réservez un créneau aux publications

Attribuez un tag à un runner dédié pour éviter que les PR ordinaires n’occupent le créneau d’archivage.
Injectez les certificats, profils de provisionnement et identifiants de distribution via les secrets CI.
Après chaque archivage réussi, conservez les journaux et les artefacts, puis nettoyez les fichiers locaux selon vos règles.

À noter : le nœud fonctionne toute l’année, 365 jours par an. Configurez des alertes d’échec et des tentatives de reprise dans votre plateforme CI pour les tâches planifiées et les envois.

Louer le Merge M4 L

Cas 3 · Développement à distance

Ouvrez Xcode, même sans Mac local

Utilisez le partage d’écran VNC pour accéder à l’interface macOS, consulter vos projets dans Xcode, diagnostiquer les erreurs de compilation et lancer des simulateurs. Avec SSH, exécutez des builds en ligne de commande, synchronisez vos fichiers et gérez vos runners.

Si vous devez utiliser Xcode, un simulateur et vos outils de dépendances en même temps, privilégiez le Merge M4 L. L’interface graphique et les tâches CI partagent les ressources de la même machine physique : planifiez les sessions de débogage et les archivages à des moments différents, ou répartissez-les sur plusieurs nœuds.

Testez la connexion avant de transférer tout le projet

Récupérez les informations de connexion dans la console, puis vérifiez l’accès SSH et VNC.
Réduisez la résolution de l’écran distant et vérifiez la réactivité des commandes et des fenêtres.
Testez Xcode et le simulateur avec un petit projet avant de synchroniser votre projet principal.

À savoir : le cloud convient à la compilation, à la signature et aux tests sur simulateur, mais ne donne pas directement accès à l’iPhone que vous avez en main. Conservez séparément les étapes qui nécessitent une connexion à un appareil physique local.

Voir les instructions de connexion SSH et VNC

Cas 4 · Expérimentation IA

Définissez un budget de ressources pour vos expériences MLX

Exécutez l’inférence locale MLX sur Apple Silicon pour tester des modèles quantifiés et des processus d’ajustement fin de petits modèles. Commencez par un modèle léger pour établir une base fonctionnelle, puis augmentez progressivement la longueur du contexte, la taille des lots et le volume des données d’entraînement.

Nous recommandons le Merge M4 L avec l’option de stockage supplémentaire de 2 To pour conserver les poids des modèles, les jeux de données et les points de contrôle. Les 24 Go de RAM servent à l’exécution ; le SSD supplémentaire augmente la capacité de stockage. L’un ne remplace pas l’autre.

Surveillez le pic de mémoire, pas seulement la taille du modèle

Mesurez le pic de mémoire pendant le chargement du modèle, l’inférence et l’ajustement fin.
Prévoyez de l’espace disque pour les téléchargements, la décompression et les points de contrôle.
Mettez en pause les tâches CI parallèles sur la machine pour éviter que la concurrence ne fausse les résultats de vos expériences.

À savoir : la possibilité de charger un modèle en mémoire dépend aussi de la quantification, du contexte et du mode d’exécution. L’option SSD de 2 To n’augmente pas la mémoire et ne garantit pas l’exécution de n’importe quel modèle.

Configurer le Merge M4 L avec du stockage supplémentaire

Une machine dédiée ne permet pas un nombre illimité de tâches parallèles.Limitez d’abord le nombre de tâches simultanées sur la machine, puis surveillez les pics de mémoire, l’espace disque disponible et les files d’attente. Si les publications nécessitent des créneaux fiables, répartissez les rôles des runners au lieu d’entasser toutes les tâches dans la même file.

Migrez en suivant l’ordre des dépendances

Reproduisez l’environnement avant de basculer vos pipelines

Ne mettez pas tout de suite votre ancienne machine de build hors service. Procédez dans l’ordre — données, chaîne d’outils, intégration CI — et lancez le même commit dans les deux environnements. Vérifiez les artefacts et les journaux avant de basculer les tâches de production.

01 · Données

Transférez séparément le projet, les éléments de signature et le cache

Récupérez le projet et ses sous-modules depuis le dépôt en conservant les fichiers de verrouillage des dépendances. Évitez de copier tout votre répertoire de travail local et de le considérer comme un environnement reproductible.
- Transférez les certificats et profils de provisionnement par un canal sécurisé ; stockez les mots de passe dans les secrets CI.
- Distinguez les caches à l’aide de clés basées sur la version de Xcode, le fichier de verrouillage des dépendances et l’architecture.
- Ne migrez que les caches dont la réutilisation est confirmée ; les anciens dossiers DerivedData ne doivent pas être indispensables.
Critère de validation :Le commit spécifié peut être récupéré, les fichiers de signature sont localisables et aucun élément sensible n’a été ajouté au dépôt.
02 · Chaîne d’outils

Consignez les versions, ne comptez pas sur votre mémoire

Alignez Xcode, Homebrew, Ruby et CocoaPods. Commencez par vérifier les fichiers de version déjà présents dans le projet et évitez de mettre les dépendances à niveau pendant la migration afin de ne pas mélanger les causes d’éventuels problèmes.
```
xcodebuild -version
xcode-select -p
uname -m
ruby --version
bundle exec pod --version
```
Critère de validation :Vérifiez l’environnement arm64, le chemin Xcode sélectionné et les versions des dépendances, puis effectuez un build local en ligne de commande avec un seul scheme.
03 · Intégration CI

Connectez d’abord les tests, puis les publications

Enregistrez un runner self-hosted ou un agent sur votre plateforme habituelle et attribuez des tags explicites au nœud. GitHub Actions peut utiliser les tags ci-dessous ; pour les autres plateformes, utilisez leur configuration de planification propre.
```
runs-on:
  - self-hosted
  - macOS
  - ARM64
  - macos-m4
```
Critère de validation :Vérifiez que les mêmes tags sont enregistrés, que la branche de test est prise en charge par le nouveau nœud et que les journaux et artefacts sont récupérables. Conservez la configuration de retour à l’ancien runner avant le basculement définitif.

Ne mettez pas les jetons d’enregistrement ni les éléments de signature dans des commandes d’exemple ou des journaux publics. Après toute modification du nœud, vérifiez son état en ligne, ses tags et ses conditions de déclenchement sur la plateforme CI. N’ouvrez l’accès à l’équipe que lorsque les trois sont corrects.

Voir le guide d’intégration et de dépannage des runners

Validez les résultats de la migration

Comparez le même commit lors de votre point d’équipe

Comparez les temps de build uniquement avec des entrées identiques. Séparez les résultats avec cache et sans cache pour ne pas confondre différence matérielle, téléchargement, nouvel essai ou changement du périmètre des tests.

Scène de développement sur ordinateur portable, avec comparaison des journaux de build et du suivi de migration lors d’un point d’équipe — Illustration d’une collaboration entre développeurs. Pour comparer les builds, référez-vous aux journaux CI de votre équipe ; cette illustration ne constitue ni un témoignage client ni une preuve de performance.

Stabilisez les entrées

Consignez le hash du commit, la version de Xcode, le scheme, les appareils de test et le fichier de verrouillage des dépendances. Avant de comparer, vérifiez que le périmètre des tests est identique.

Détaillez les durées

Mesurez séparément l’attente, le téléchargement des dépendances, la compilation, les tests, l’archivage et le transfert des artefacts. Une machine dédiée élimine la concurrence avec d’autres clients, pas les délais de transfert réseau.

Gardez une solution de repli

Conservez les tags de l’ancien runner et la configuration du pipeline. Arrêtez les tâches de production sur l’ancien nœud uniquement après avoir confirmé que le nouvel environnement fonctionne de manière reproductible.

Choisissez votre configuration selon vos besoins

Commencez avec 16 Go pour les contrôles de PR ; envisagez 24 Go pour plusieurs targets, les simulateurs et les archives de publication. Consultez la page des offres pour comparer les configurations, les quatre périodes de facturation et les options de stockage, puis créez votre environnement d’équipe.

Voir le tableau des configurations Louer un Mac cloud

Transférez vos pipelinesen attente sur un Mac dédié