Premier build iOS sur Mac cloud : une vraie app qui tourne

Mon poste quotidien, c'est un portable Windows ; le backend et les scripts tournent sur des VPS Linux — seul le chemin iOS impose Xcode et du matériel Apple. Acheter un Mac mini reste possible, mais tant que je ne sais pas si l'app ira au bout, j'ai préféré valider toute la chaîne au moindre coût : connexion, compilation, simulateur, signature, Archive. J'ai donc loué un Mac cloud, passé un week-end à faire tourner une app SwiftUI dans le simulateur iPhone, et dimanche soir j'ai produit mon premier Archive Release. Ce n'est pas un tutoriel « Hello World en trois lignes », mais un journal de dev à la première personne sur Xcode à distance — avec les pièges que j'ai rencontrés et les étapes plus rapides que prévu.

Mac mini cloud pour toute la chaîne

~6h

De la connexion au simulateur OK

1er

Archive réussi du premier coup

Pourquoi louer un Mac cloud sans Mac sur le bureau

La première réaction en iOS, c'est souvent « xcode windows » — la mienne aussi. Conclusion rapide : impossible de builder pour l'App Store nativement sous Windows. Simulateur, codesign, Archive, envoi TestFlight : chaque étape est liée à macOS. Hackintosh et VM douteuses, j'ai écarté : pour jouer peut-être, mais pour signer proprement et auditer plus tard, il faut du vrai matériel Apple.

Acheter un Mac, ce n'est pas que l'argent : c'est « est-ce que ça vaut le coup maintenant ? » Si dans deux semaines je n'ai plus besoin d'iOS, un Mac mini inutilisé coûte plus cher qu'un nœud cloud mensuel. À l'inverse, louer un Mac cloud dédié à la semaine ou au mois, c'est répondre à trois questions par la pratique : est-ce que le Xcode distant me convient ? La compile est-elle assez rapide ? Signature et Archive bloquent-ils quelque part ? Si oui partout, on achète ou on monte la CI ensuite. Pour une équipe Windows qui compare les options, voir le guide Xcode sous Windows et Mac virtuel en ligne.

Jour 0 : connexion, bureau et le « c'est vraiment un Mac »

Avec l'accès au Mac cloud, j'ai mis en place deux voies : SSH pour le shell et VS Code Remote, Microsoft Remote Desktop quand il faut cliquer dans le simulateur et l'interface Xcode. La région compte — ma première erreur : un nœud européen depuis loin ; git clone et la latence RDP étaient pénibles. Après changement vers une zone proche, l'interaction redevient « acceptable comme du local ».

macOS était préinstallé, Xcode à installer. Mac App Store avec mon Apple ID, version stable actuelle, puis xcodebuild -version et xcode-select -p pour valider la CLI. sudo xcodebuild -license accept et premier lancement Xcode avec composants additionnels — voir la barre de progression en bureau distant rassure plus qu'en SSH aveugle. Avantage Mac cloud : pas de galère Hackintosh, du vrai Apple Silicon au boot. Homebrew, Git, clés SSH comme sur mes serveurs Linux — courbe d'apprentissage plus douce que je ne pensais.

Checklist jour 0

SSH et RDP stables ; Xcode et Command Line Tools alignés ; git clone sans erreur ; keychain login créable et déverrouillable. Tant qu'un point échoue, ne pas créer le projet — la signature vous fera tout refaire.

Du nouveau projet au « on peut vraiment taper dans le simulateur »

Dans Xcode : modèle App, SwiftUI + Swift, Bundle ID enregistré avant sur le compte développeur. Au premier Cmd+R sur le simulateur, l'Apple Silicon du Mac cloud se voyait : compile à froid trois à quatre minutes, builds incrémentaux souvent sous vingt secondes — bien plus concret que mes anciennes tentatives en conteneurs Linux.

Ce qui m'a enthousiasmé, ce n'était pas la ligne verte du build, mais l'icône dans la fenêtre simulateur qu'on peut ouvrir et utiliser — là seulement ça ressemblait à une app, pas à des fichiers Swift dans le dépôt. Astuce remote : RDP en plein écran, résolution simulateur = appareil cible ; SSH seul pour le code et xcodebuild test, premier réglage UI via le bureau. Sous Windows, VS Code Remote SSH pour la logique, RDP pour la mise en page — les deux en parallèle battent un seul canal.

La ligne de commande confirme aussi que « ça tourne »

Après le succès GUI, j'ai refait un passage CLI pour préparer l'Archive :

Shell · build Debug simulateur

cd ~/Projects/MyFirstApp
                xcodebuild build \
                  -scheme MyFirstApp \
                  -destination 'platform=iOS Simulator,name=iPhone 16' \
                  -configuration Debug

Quand cette commande passe en vert en SSH, la config du projet ne dépend pas d'un état implicite de l'interface — la CI nocturne ne repartira pas de zéro.

Le mur de la signature : même un dev solo bloque une fois

Le Debug simulateur n'exige pas de certificat Distribution, mais l'Archive rencontre toujours la signature. Deux blocages chez moi : App ID côté Apple Developer différent du Bundle ID ; première fenêtre keychain sur le Mac distant pendant une coupure RDP, personne pour cliquer « toujours autoriser », xcodebuild archive échoue en silence.

Compte personnel : Automatic Signing pour démarrer ; si vous visez le Store, documentez tôt une clé selon App Store Connect API Key, sans tout miser sur des clics GUI. Ma méthode : Signing & Capabilities en gestion auto, bonne équipe ; puis un Archive GUI en présence pour toutes les autorisations keychain. Ensuite le CLI sans surveillance réussit bien mieux.

Signature à distance : l'angle mort

Après reboot Mac cloud ou session expirée, le keychain login peut se reverrouiller. Avant release : security unlock-keychain -p '…' ~/Library/Keychains/login.keychain-db (mot de passe dans un coffre, pas dans le repo) et vérifier le certificat Distribution dans « Mes certificats ». Sinon Xcode GUI archive, la CLI échoue la nuit.

Premier Archive : du « ça tourne » au « livrable »

Archive et build Debug sont deux chemins. Dans Xcode : Any iOS Device (arm64), Product → Archive — quand la première entrée est apparue dans l'Organizer, c'était plus rassurant que le tap dans le simulateur, car config Release, niveau d'optimisation et chaîne de signature étaient validés. Équivalent CLI :

Shell · Archive Release (signature valide requise)

xcodebuild archive \
                  -scheme MyFirstApp \
                  -configuration Release \
                  -archivePath build/MyFirstApp.xcarchive \
                  -destination 'generic/platform=iOS' \
                  CODE_SIGN_STYLE=Automatic \
                  DEVELOPMENT_TEAM=XXXXXXXXXX

Export IPA via Organizer « Distribute App » ou xcodebuild -exportArchive. J'ai stoppé à Archive + vérification locale de la structure IPA, sans TestFlight — pour un premier iOS, un Archive réussi est déjà une étape majeure. Pour automatiser ensuite, le plan de capacité CI iOS sur Mac cloud explique pourquoi isoler l'Archive des PR ; pas besoin de trois machines au premier passage, mais connaître la règle évite des détours.

Xcode à distance en vrai : acceptable si on répartit les rôles

Honnêtement, ce n'est pas la fluidité d'un MacBook local, mais avec une latence acceptable, un premier iOS est faisable. Mon ressenti :

Écrire du code : Windows + VS Code Remote SSH pour le Swift, proche du local.
UI / simulateur : RDP ou partage d'écran obligatoire, latence selon région et bande passante.
Compile & Archive : sur le Mac cloud, pas de cross-compile iOS sous Windows.
Assets & dépôt : Git uniquement, pas de clé USB entre machines — DerivedData sur le Mac distant est recréable, l'historique Git non.

Un gain discret : environnement propre — utilisateur et keychain dédiés iOS, sans conflit avec la toolchain chaotique du portable perso. Pour un dev backend qui fait iOS par intermittence, cette isolation est souvent plus pragmatique qu'un Mac qui prend la poussière.

Ma chronologie (pour comparer)

Phase	Durée (env.)	Résultat
Connexion, Xcode, clone dépôt	1–2 h	Shell distant + bureau OK
Nouveau projet, Debug simulateur	2–3 h	App utilisable dans le simulateur
Signature & keychain	1–2 h	Automatic Signing stable
Premier Archive Release	30–60 min	.xcarchive / IPA exportable

Sur un second projet similaire, l'Archive tombe souvent sous une demi-heure — le goulot devient « cache et signature toujours chauds », plus « est-ce que je sais faire ». D'où l'abonnement plutôt que la location à la journée pour beaucoup : DerivedData et état du keychain méritent de rester sur la même machine.

Checklist premier iOS : de zéro à Archive

Si vous validez iOS sans Mac local, cochez dans l'ordre :

Louer un Mac cloud conforme (Apple Silicon, RAM ≥16 Go conseillé).
SSH + RDP prêts ; région proche de vous.
Installer Xcode, accepter la licence, composants additionnels.
Bundle ID sur Apple Developer, Signing sans rouge dans Xcode.
Debug simulateur et xcodebuild build au vert.
Un Archive GUI en présence, puis essai CLI.
(Optionnel) exporter l'IPA, métadonnées selon App Store Connect.

À l'étape six, vous êtes plus loin que ceux qui restent sur « xcode windows » — vous avez un archivage livrable, pas seulement une démo simulateur.

Et ensuite ?

App perso : abonnement Mac cloud + Archive manuel suffit. Releases hebdomadaires : même machine en runner self-hosted, tests sur PR, Archive sur main. Ne pas sur-architecturer la CI avant le premier vert — mais le jour de l'Archive, passer la « machine de build » du « bureau temporaire » au « nœud de release nommé ».