Choisissez selon votre workflow, pas les specs

Un Mac cloud, quatre usages

Ajoutez un nœud Apple Silicon dédié à votre workflow de développement. Pas de machine virtuelle : SSH et interface graphique macOS disponibles, du build ponctuel au pipeline permanent en passant par l’inférence sur mémoire unifiée.

Louer un Mac cloud

Trois configurations, cinq sites. Shell M4 à la journée à partir de $21.8 pour tester votre propre projet.

01 / BUILD

Gardez votre poste principal,
déplacez Xcode dans le cloud

Vous développez sous Windows ou Linux ? Synchronisez votre dépôt avec le Mac cloud au moment de publier, puis lancez le build via SSH. Pour vérifier les réglages du projet, le simulateur ou la signature, passez à l’interface graphique macOS sans déplacer tout votre environnement de développement.

Shell M4 convient pour valider le build et l’archivage d’un projet. Les 16 Go de mémoire unifiée suffisent ou non selon la taille du projet, le nombre de simulateurs et les outils utilisés simultanément. Relevez d’abord le pic mémoire et la durée d’un build propre avant de choisir une autre configuration.

  • Vérifiez les versions de Xcode et des dépendances fixées par le projet pour éviter les écarts entre builds locaux et distants.
  • Commencez par un build sans signature, puis configurez les certificats et profils de provisionnement que vous êtes autorisé à utiliser.
  • Un archivage réussi ne signifie pas que l’app est prête à être publiée : vérifiez séparément les droits de signature et de distribution ainsi que les artefacts.
02 / AUTOMATE

Pour vos builds macOS,
un runner toujours prêt

Enregistrez le nœud dédié comme runner self-hosted GitLab ou GitHub pour réunir commits, tests, archivage et transfert des artefacts dans un même pipeline. Le nœud fonctionne 365 jours par an ; l’ordonnancement des tâches, la supervision des processus et le nettoyage des builds sont à configurer par l’équipe selon le projet.

Avec 24 Go de mémoire unifiée et un SSD de 512 Go, Shell M4 Plus offre de la marge pour la résolution des dépendances, la compilation et les tests, tout en conservant dépôts, caches et artefacts. Commencez avec une seule tâche simultanée, puis ajustez après avoir observé l’utilisation du CPU, la pression mémoire et la croissance du stockage. Le parallélisme logique ne garantit pas un débit équivalent.

  • Utilisez un compte macOS dédié à la CI pour éviter de partager le répertoire de travail avec les sessions interactives.
  • Indiquez macOS, l’architecture de la puce et la version de Xcode dans les tags du runner pour éviter les mauvaises affectations.
  • Pour les tâches nécessitant une session graphique ou un trousseau de signature, vérifiez d’abord les autorisations dans la session du compte concerné.
  • N’autorisez que les dépôts de confiance à utiliser un runner doté d’identifiants de publication et isolez les contributions externes.
03 / VERIFY

Retrouvez facilement les résultats des tests nocturnes

Organisez les tâches avec fastlane, exécutez les tests d’interface avec XCUITest et conservez les détails des échecs dans les rapports. Stabilisez d’abord l’environnement de test avant d’élargir la couverture des appareils.

Commencez par les tests de régression sur simulateur

Installez les runtimes de simulateur nécessaires au projet et fixez l’appareil cible ainsi que la version du système. Commencez par exécuter xcrun simctl list devices available pour afficher les appareils disponibles, puis renseignez l’identifiant exact dans la configuration des tests.

Les tâches nocturnes enregistrent .xcresultainsi que captures d’écran et journaux. En cas d’échec, distinguez un défaut du produit, un script de test instable et un problème d’environnement au lieu de masquer la cause par des tentatives infinies.

Idéal pour les vérifications de commit et les régressions nocturnes

Vérifiez séparément l’accès aux appareils iOS réels

Louer un Mac physique ne signifie pas louer un iPhone ou un iPad. L’offre ne comprend pas d’appareil iOS et ne garantit pas par défaut la connexion à un appareil. Avant de commander, précisez à qui appartient l’appareil, comment il sera connecté et quels outils de test seront utilisés.

Un appareil USB branché à votre ordinateur n’apparaît pas sur la machine distante après une connexion SSH. Votre solution de test doit prévoir un appareil accessible, l’appairage et l’approbation de confiance, ainsi que les autorisations de signature requises. Vérifiez la faisabilité par e-mail au préalable.

Vérifier par e-mail les conditions de test sur appareil réel

Conservez un rapport pour chaque exécution

À exécuter une fois le lane de test fastlane configuré dans le projet. Classez les résultats par identifiant de tâche et transférez-les à la fin des tests, sans les laisser s’accumuler sur le nœud.

bundle exec fastlane scan \
  --scheme App \
  --result_bundle true \
  --output_directory build/test-results
04 / EXPERIMENT

Exploitez la mémoire unifiée pour
valider vos hypothèses d’inférence

Shell M4 Pro associe une puce M4 Pro, 64 Go de mémoire unifiée et un SSD de 2 To. Cette configuration convient pour tester le chargement de modèles, les versions quantifiées, la longueur du contexte et l’inférence Metal avec MLX ou llama.cpp. CPU et GPU partagent la mémoire unifiée, mais celle-ci n’est pas entièrement disponible pour les poids du modèle.

Pour choisir un modèle, estimez d’abord la mémoire nécessaire aux poids, puis gardez une marge pour l’exécution. À titre indicatif, avec des poids en 4 bits, un modèle de 8B paramètres nécessite environ 4 Go et un modèle de 32B environ 16 Go. Cette estimation correspond au nombre de paramètres multiplié par 0,5 octet ; elle n’inclut ni les métadonnées de quantification, ni le cache KV, ni le runtime et le système. Elle ne garantit pas qu’un modèle donné pourra être chargé.

  • Commencez avec un contexte court et une seule requête. Mesurez la latence du premier token et la vitesse de génération stable avant d’augmenter le contexte ou le parallélisme.
  • Notez la version du modèle, le format de quantification, la version des outils et les paramètres d’échantillonnage pour ne pas comparer des résultats obtenus avec des configurations différentes.
  • Pour les tâches nécessitant l’écosystème CUDA ou un entraînement multi-GPU, ce Mac ne constitue pas un remplacement équivalent.
Du local au cloud

Migrez en trois étapes, chacune vérifiable séparément

Ne copiez pas tout votre dossier utilisateur. Migrez d’abord le projet, restaurez ensuite les outils, puis basculez les tâches. Les durées indiquées sont des estimations de planification pour les opérations manuelles, pas des délais de mise à disposition ; les téléchargements, transferts et builds sont à prévoir en plus.

01

Données : préparez un dépôt reconstructible

Temps prévu : 10 à 30 min, hors transfert

Pour la première migration, clonez de préférence le dépôt ; synchronisez séparément les ressources non validées. Exécutez les commandes ci-dessous en local,cloud-mac est l’alias SSH que vous avez déjà configuré, et l’adresse du dépôt provient d’une variable d’environnement propre au projet.

ssh cloud-mac 'mkdir -p ~/work'
rsync -av --exclude '.git' \
  ./App/ cloud-mac:~/work/App/
ssh cloud-mac
git clone "$REPOSITORY_URL" ~/work/repo

Vérification : le commit correspond et toutes les ressources nécessaires sont présentes. Inutile de migrer les caches et les répertoires de build reconstructibles.

02

Outils : verrouillez les versions et les autorisations

Temps prévu : 20 à 60 min, hors téléchargement

Sur la machine distante, vérifiez le chemin de Xcode et les SDK. Si le projet contient un Brewfile, restaurez les outils avec Homebrew. Transférez certificats et profils de provisionnement par un canal sécurisé approuvé par l’équipe ; ne les ajoutez ni au dépôt ni aux journaux de tâches.

xcode-select -p
xcodebuild -version
xcodebuild -showsdks
brew bundle --file Brewfile
security list-keychains -d user

Vérification : les versions des dépendances correspondent et le SDK cible est disponible. Effectuez un archivage signé avec le compte qui exécutera réellement les tâches.

03

CI : faites un essai avant de changer les tags

Temps prévu : 15 à 45 min, hors build

Enregistrez le runner avec les informations fournies par votre organisation. Les commandes ci-dessous concernent GitLab ; pour GitHub Runner, utilisez le script de configuration fourni par l’organisation et vérifiez l’état du service sur le nœud. Saisissez le jeton uniquement dans une session de confiance.

gitlab-runner register
gitlab-runner install
gitlab-runner start
gitlab-runner verify

Vérification : une branche de test utilise le nouveau tag et ses artefacts sont téléchargeables. Après validation, basculez le pipeline de production et gardez l’ancien runner pour pouvoir revenir en arrière.

Une migration réussie ne se résume pas à une connexion SSH : un même commit doit pouvoir installer les dépendances, compiler, tester et transférer les artefacts. En cas d’échec, conservez d’abord les journaux avant de passer à l’étape suivante.

Relais entre fuseaux horaires

Partagez un planning, pas des mots de passe

L’équipe peut utiliser le même nœud à tour de rôle, mais le CPU, le GPU, la mémoire et le stockage restent des ressources partagées. Plusieurs comptes système ne constituent pas une isolation équivalente à des machines virtuelles ; les identifiants de publication et les projets sensibles exigent une gestion des accès plus stricte.

  1. 01

    Un compte par personne

    Chaque membre utilise son propre compte macOS et sa clé publique SSH : ne partagez pas de clé privée. La CI utilise un compte dédié. Lorsqu’une personne quitte l’équipe, supprimez sa clé et vérifiez les jetons associés.

  2. 02

    Transmettez les tâches clairement

    Planifiez en utilisant un fuseau horaire commun. Dans le compte rendu, indiquez le commit, le répertoire de travail, les processus en cours et la prochaine tâche. Confiez les tâches longues au runner ou à une session gérée plutôt que de laisser une connexion de bureau ouverte.

  3. 03

    Gérez la signature séparément

    Vérifiez les autorisations du trousseau pour le compte qui exécute les tâches et ne mettez pas son mot de passe de déverrouillage dans l’historique du shell. Avant le relais, vérifiez qu’aucune demande de signature interactive ne reste en attente et ne fermez pas la session d’un autre utilisateur au milieu d’une publication.

  4. 04

    Gardez une seconde copie des données

    Poussez le code vers le dépôt, transférez les artefacts vers le stockage de l’équipe et conservez les identifiants dans un emplacement sécurisé séparé. Effectuez une sauvegarde avant l’échéance : le nœud ne doit pas être votre unique archive. Consultez le panneau de contrôle pour les informations de renouvellement et d’expiration.

NEXT / RUN YOUR PROJECT

Choisissez votre tâche,
puis lancez votre premier nœud

Pour compiler un projet, commencez avec Shell M4 ; pour un pipeline d’équipe, choisissez Shell M4 Plus ; pour des expériences d’inférence gourmandes en mémoire, optez pour Shell M4 Pro. Sur la page de commande, vérifiez la durée, le site et les options.

Paiement uniquement par USDT-TRC20 ou Visa / Mastercard / Amex (via Stripe), en dollars américains. Les moyens de paiement effectivement disponibles sont ceux indiqués par l’interface de paiement.

Développement indépendant · Shell M4 CI d’équipe · Shell M4 Plus Expériences IA · Shell M4 Pro