Ça vous parle ?
- Pourquoi le CI iOS ralentit sans cesse ?
- Les runners macOS GitHub Actions encore en file d'attente ?
xcodebuildqui bloque, timeoute ou plante sans raison évidente ?- Pas de Mac sur le bureau — comment livrer un build iOS ?
- Un Cloud Mac peut-il vraiment faire tourner Xcode correctement ?
- Claude Code / Ollama 24h/24, mais le portable s'éteint quand on ferme le capot ?
Ce sont les questions qu'on entend le plus en ce moment. Mon habitude : la conclusion d'abord, ensuite pourquoi ça coince, puis comment choisir — sans détours.
En bref
Cloud Mac, c'est en gros un Mac Mini dédié que vous louez à la journée — quand les builds macOS attendent des heures, Actions vous laisse en plan, ou qu'il vous faut Xcode sans Mac sous la main.
Trois lignes qui résument pour moi :
- Votre Mac à vous — pas de file CI partagée avec tout le monde
- Build et release sur une machine distante — pas d'achat MacBook juste pour la semaine de release
- Louer les jours nécessaires — le pic de charge bat le hardware qui dort
Cloud Mac, concrètement ?
Quelques faits simples : SSH ou VNC sur un vrai Mac Mini (classe M4), la machine entière est à vous, paiement journalier ou mensuel, en ligne en cinq minutes environ.
- Pas un Mac VM tassé sur un hôte partagé
- Pas une API Claude / GPT — signature et notarisation exigent toujours macOS
- C'est un Mac en datacenter pensé pour la compile ou l'inférence
Même idée de base qu'AWS EC2 Mac : du vrai matériel. La différence, c'est souvent la location à la journée, la proximité du nœud avec votre bureau, et la vitesse de déploiement. Pour du xcodebuild ou Ollama stable, je prendrais un Mac physique dédié plutôt qu'une VM bruyante multi-tenant.
Quand envisager Cloud Mac ?
Les équipes bloquent souvent sur l'un de ces cas. Si ça vous parle, louer un Cloud Mac bat généralement l'achat d'un autre MacBook ou regarder la file Actions :
- Runner macOS GitHub Actions en file 10+ minutes
xcodebuilden CI instable — timeouts et rouges aléatoires- Chaque build re-télécharge Pods / SPM — cold starts sans fin
- Quotidien sur Windows / Linux, pas de Xcode local, mais TestFlight doit partir
- Agents ou Ollama doivent rester allumés — le sleep du portable tue le job
- Semaine de release : builders en plus — pas de mini inactif toute l'année
Pour « poste principal pas Mac, builds à distance » : Windows/Linux principal + îlot Mac build distant.
Pourquoi le CI iOS ralentit ?
On pense toujours d'abord « le repo a grossi » — mais souvent c'est comment le CI tourne :
- Les runners macOS GitHub Actions sont partagés — en semaine de release, l'attente dépasse souvent le build
- Les builds Xcode sont gourmands en disque — perdez
DerivedDataet vous reconstruisez tout - CocoaPods / SPM redémarrent à froid — on détruit le runner, tout se re-télécharge
- La toolchain Apple ne se containerise pas comme le CI Linux — signature, trousseau, TCC veulent une machine fixe
- Les logs ressemblent à : 8 minutes de build, 40 minutes d'attente
En clair : ce n'est peut-être pas votre code — ce sont les runners partagés et des caches qui ne tiennent pas. Un Mac dédié plus runner self-hosted cible exactement ça.
Calcul acheter vs louer : runners Mac self-hosted, cache et disque persistant.
Acheter, louer ou utiliser une API ?
| Où ça coince | Ce que je pencherais |
|---|---|
| File CI iOS, rush de release | Cloud Mac — machines à la journée, runner self-hosted |
| Pas de Mac, Archive / TestFlight requis | Cloud Mac — builds SSH, VNC une fois pour les certs |
| Tester Agent, OpenClaw, Ollama | Cloud Mac — on rend si ça ne colle pas |
| Codage quotidien, même machine des années | Acheter un Mac mini |
| Chat rapide, proto jetable | API cloud suffit |
| Code sensible, inférence toujours allumée | Cloud Mac ou mini possédé — selon l'utilisation |
Trois voies côte à côte
| Cloud Mac | Mac mini possédé | API cloud | |
|---|---|---|---|
| Mise en route | ~5 minutes | Livraison + setup | Inscription et go |
| Xcode / notarisation | ✔ | ✔ | ❌ |
| Élasticité CI | Rendre quand c'est fini | Actif fixe | — |
| Inférence privée | Ollama/MLX, dédié | Dédié | Les données sortent de votre périmètre |
Une nuance : Cloud Mac ne remplace pas votre MacBook du quotidien — c'est le Mac dans la baie qui fait le build ; le portable reste là où vous tapez.
Combien coûte la location ?
Si le CI ne picke qu'aux releases, quelques jours de location battent souvent l'achat d'un mini. Si ça tourne 24h/24 toute l'année, la propriété peut amortir moins cher — l'utilisation décide.
| Option | Ordre de grandeur | Charge |
|---|---|---|
| Cloud Mac M4 16GB | environ 20,6 $/jour ou 102,9 $/mois | Sprint release 3–5 jours, runner dédié |
| Cloud Mac M4 Pro 24GB | environ 39,8 $/jour ou 202,9 $/mois | 14B Ollama + agents d'équipe |
| Mac mini M4 16GB possédé | environ 599 $+ ; ~0,55 $/jour sur 3 ans + ops | CI / home lab 24h/24 fixe |
Calcul rapide : trois jours de release en 16GB ≈ 62 $ — sous le prix d'achat d'un mini. Deux machines cinq jours chacune en ship week ≈ 206 $ — parfois moins cher que l'équipe qui regarde Actions tourner. Tarifs actuels : tarifs Macstripe.
Dimensionnement
| Scénario | Choix |
|---|---|
| CI iOS dédié / repo modeste | 16GB ; gros repo ajouter disque 1TB pour DerivedData |
Équipe ollama serve + 14B | 24GB (notes terrain 7B vs 14B) |
| Latence | Bureaux APAC : Singapour / Tokyo / Hong Kong ; RTT SSH souvent 30–80ms |
Ce que ça gère vraiment
1. Dompter la file CI
Runner self-hosted sur Cloud Mac, garder DerivedData et le cache Pods. Allumer pour la ship week, rendre quand c'est calme — l'attente passe de dizaines de minutes à quasi zéro.
2. Parcours release Xcode à distance
Windows / Linux au quotidien ; la pipeline déclenche Archive, signature, notarisation, TestFlight sur le Mac distant. Certs et TCC via VNC une fois, puis SSH headless.
3. Des agents qui restent allumés
ollama serve dans la baie, Claude Code sur la machine dev pointe là-dessus. Fermer le portable ne tue pas le run. Câblage : workflow Claude Code + Ollama.
4. Inférence Ollama privée
Code et docs internes restent chez vous ; 24GB avec 14B bat le swap du portable. Framework : Ollama vs MLX ; scale-out : cluster IA privé.
5. Automatisation navigateur
Vrais profils navigateur, CDP, TCC macOS — les setups type OpenClaw tournent souvent mieux sur un Mac distant. Voir OpenClaw sur Mac distant.
FAQ
Pourquoi le CI iOS est-il si lent ?
Souvent file de runners partagés, caches non persistants, et une toolchain qui ne se containerise pas proprement — le temps d'attente dépasse souvent le vrai build, pas seulement « projet plus gros ».
Runner macOS GitHub Actions toujours en file — que faire ?
Louer un Mac dédié pour la ship week, attacher un runner self-hosted, garder les caches chauds, rendre la machine après. Mieux que de regarder le pool partagé.
Puis-je faire du iOS sans Mac ?
Vous codez partout ; Archive, signature, notarisation et TestFlight exigent macOS. SSH / VNC vers un Cloud Mac pour le parcours release.
Cloud Mac peut-il faire tourner Xcode ?
Oui — vrai Mac Mini, Xcode complet, xcodebuild, certs et trousseau. Une box de build distante, rien d'exotique.
Cloud Mac vs acheter un Mac mini — qui gagne ?
Les pics de release et « essayer avant d'acheter » favorisent la location. Une charge 24h/24 toute l'année favorise souvent la propriété. Regardez l'utilisation.
xcodebuild qui échoue ou timeoute en CI ?
Vérifier le temps de file, le disque pour DerivedData, la dérive de l'env de signature. Un Mac dédié réduit les combats IO et les resets d'environnement.
Un Cloud Mac peut-il sérieusement faire tourner Xcode ?
Oui. Installer Xcode, SSH pour les builds quotidiens, VNC la première fois pour certs et TCC.
En quoi c'est différent des runners hébergés GitHub ?
Hébergé = pool partagé, file et cold start hors de votre contrôle. Cloud Mac = machine entière, caches et env de signature peuvent rester en place.
C'est quoi Cloud Mac ?
Mac Mini dédié loué à la journée ou au mois, via SSH / VNC. Pas une tranche VM, pas une API.
Combien coûte la location ?
Référence : M4 16GB environ 20,6 $/jour, 102,9 $/mois ; 24GB environ 39,8 $/jour, 202,9 $/mois. Voir tarifs.
