Qu'est-ce qu'un Mac Cloud Server ? La réponse qu'on voit en salle

Le mois dernier, un client m'a demandé : « Pourquoi louer un Mac mini est plus simple qu'en acheter un ? »

Personne dans l'équipe n'utilise un Mac au quotidien, mais l'App Store veut une release chaque semaine. Un Mac mini a été acheté pour une app iOS — chez nous, le taux d'utilisation : environ neuf dixièmes du temps à l'arrêt, sauf deux jours de release où quelqu'un se connecte.

Après avoir basculé la CI sur un Mac cloud dédié, la machine de bureau n'a plus été touchée. Le ticket disait simplement : « Il ne nous manque pas un Mac, mais une machine qui compile iOS 7×24. »

C'est souvent la vraie motivation derrière Mac Cloud Server (aussi Cloud Mac, serveur Mac cloud) — pas une définition de manuel, mais du matériel acheté qui dort.

Ci-dessous, ce que nous écrivons côté salle Vuncloud : ce qu'est un Mac Cloud Server, qui l'utilise, pourquoi, et ce qui change ensuite. Définition courte seulement ? Allez à ici ; pour juger si la location vaut le coup, continuez.

Trois raisons (pas « apprendre macOS »)

Des années à vendre du Mac Cloud Server — les demandes semblent dispersées, elles tombent en trois paniers :

Premier : pas de Mac en entreprise, mais iOS obligatoire. Postes Windows ou Linux, le PM veut TestFlight ce soir. On loue un Mac distant qui exécute xcodebuild, pas un « bureau cloud » — SSH pour le pipeline, VNC de temps en temps pour le simulateur.

Deuxième : Mac mini acheté, utilisation honteuse. L'exemple du début. CapEx dépensé, la compta demande pourquoi encore Apple. En cloud, builds sur M4 en salle, versions et certificats plus propres.

Troisième : CI sur GitHub macos-latest qui épuise. File d'attente, cache vidé à chaque job, pod install aléatoire. Le Mac Cloud Server recherché est un self-hosted runner à chemins fixes, numéro de machine dans le workflow.

Techniquement : qu'est-ce qu'un Mac Cloud Server ? (court)

Comme nous le livrons : un Mac mini dédié en salle, accessible par le réseau. macOS complet, Xcode, simulateur, p12, archive TestFlight. Votre portable fait SSH ou bureau à distance ; la compilation tourne ailleurs.

Ce n'est pas du macOS virtualisé sur Linux, ni du Hackintosh. Apple attache la toolchain au vrai Mac — le Mac Cloud Server met ce Mac en salle, location jour/semaine/mois.

Cloud Mac, remote Mac, Mac build server : même famille ; « Mac Cloud Server » insiste sur l'usage serveur (build, runner).

Cas : ~14 → ~6 min — le plus gros gain n'était pas le CPU

Une équipe d'apps utilitaires, 300–500 builds iOS/jour (PR + nuit). Tout sur macos-latest :

• file l'après-midi avant release ;
• DerivedData et CocoaPods pas conservés selon leur règle ;
• pod install seul souvent plusieurs minutes.

Sur un Mac mini M4 dédié (16 Go, 1 To SSD) en self-hosted : même workflow, PR de ~14 à ~6 minutes (bande Slack de l'équipe).

Logs ensemble : pas de magie M4, mais —

1. ~/Library/Developer/Xcode/DerivedData et cache Pods survivent aux jobs ;
2. runner, remote Git et artefacts dans la même région.

Le CTO : « On pensait acheter un chip plus rapide — on achetait un SSD qu'on ne vide plus. » Architecture : CI/CD iOS sur Mac mini M4.

Cas : Flutter 100 % Windows — on loue « celle qui sort l'ipa »

Classique : postes Windows, CI Android mature, flutter build ipa bloque. Collègue compile sur MacBook chez lui — « ça passe seulement sur la machine de Léa ».

Un Cloud Mac APAC pour : git pull → pod install → flutter build ipa. Code côté Windows en Remote-SSH, pas de VNC toute la journée — conseil répété : la GUI mange le réseau, pas la compile.

Deux semaines après : pas « tout le monde sait Swift », mais une machine de signature fixe. Détails : carnet Flutter iOS cloud.

Mac VPS : le mot a été galvaudé

En « neutre », j'écrirais Mac VPS pour scripts légers. D'après nos tickets, je serre le ton :

Beaucoup de pages « Mac » livrent :

• vieux Intel, simulateurs récents pénibles ;
• CPU/disque partagés — job voisin, vous swappez ;
• macOS sous hyperviseur, Metal/simulateur bizarres.

Objectif Xcode 26, simulateur iOS ou agent IA longue durée sur macOS : en 2026 notre défaut, c'est Mac physique Apple Silicon exclusif (Mac mini M4), pas l'offre Mac VPS la moins chère.

Demandez : exclusif ? puce M ? disque pour DerivedData ? Comparaison : Mac VPS vs Cloud Mac.

Achat, EC2 Mac, macos-latest (vue ingénieur)

• Mac mini acheté : utilisation stable haute (>4 h build/jour) → acheter. Release compliance seule → louer — modèle Windows + iOS · achat vs location.
• AWS EC2 Mac : déjà dans AWS, facturation à l'heure OK. Cache/Xcode/APAC fixes → nous, souvent.
• macOS hébergé GitHub : peu de builds, file acceptable ; centaines de PR/jour → Mac Cloud Server.

Souvent hybride : Mac bureau pour PM/simulateur, M4 salle pour CI ; semaine release, deuxième nœud puis résiliation.

Comment nous branchons les équipes

  Votre portable (Win / Mac / Linux)
           │  quotidien : SSH + git / xcodebuild / fastlane
           │  parfois : VNC (Storyboard, GUI simulateur)
           ▼
  Salle : Mac mini M4 dédié
       · DerivedData / Pods persistants
       · trousseau uniquement sur cette machine
           ▼
  TestFlight / App Store Connect

Région : équipe en EU, code sur miroir GitHub EU → nœud adapté ; sandbox TestFlight US → US Ouest à part — une machine pour tous les fuseaux, rare. FAQ : régions & disque.

Vocabulaire (docs en anglais)

FAQ (vraiment posées)

Cloud PC ? Non — souvent Windows. Nous : macOS sur vrai Apple.

Débit ? Build SSH : quelques Mbps ; VNC : 10 Mbps+ montant stable, filaire > Wi‑Fi.

Plusieurs devs ? Possible — nous conseillons un rôle par machine de build, pas d'Apple ID partagé.

Publication App Store incluse ? Environnement oui ; compte dev, signature, review : vous.

Vous vendez des VM ? Non — Mac mini M4 entier en SSH, APAC / US Ouest, jour/semaine/mois. SSH/VNC : pratique Mac distant.

À lire aussi

• Windows + iOS : louer ou acheter un Mac ? Modèle de décision
• Xcode depuis Windows via Cloud Mac
• TestFlight & nœuds régionaux