MacRunLouer un Mac
Guide

Pourquoi un agent de code iOS a besoin d’un vrai Mac

Un agent peut écrire du Swift n’importe où. Il ne peut compiler, lancer et voir une app iOS que sur un Mac. Cet écart est toute la raison pour laquelle le travail iOS a besoin d’un Mac dans la boucle. C’est aussi pourquoi un agent avec un Mac devient tellement meilleur. Il peut vérifier son propre travail. Cette page liste ce qui n’existe que sous macOS. Elle donne ensuite la boucle que nous configurons pour les agents sur nos machines.

Ce qui ne se fait que sous macOS

  • Compiler l’app. xcodebuild et Xcode n’existent que sous macOS. Une machine Linux peut compiler des paquets Swift et du Swift côté serveur. Elle ne peut pas produire une app iOS.
  • La lancer. Le simulateur iOS fait partie de Xcode. Sans simulateur, impossible de lancer l’app que l’agent vient de modifier.
  • La voir. Une capture d’écran de l’app en cours d’exécution permet à l’agent de découvrir que la mise en page est cassée. Il faut pour cela le simulateur.
  • Les tests d’interface. XCUITest pilote l’app sur un simulateur ou un appareil. Uniquement sous macOS.
  • Signer et envoyer. La signature de code, les profils de provisionnement et les envois vers App Store Connect passent tous par les outils d’Apple sous macOS.

Un agent sous Linux peut donc modifier vos fichiers Swift et deviner. Un agent sur un Mac peut modifier, compiler, lancer, regarder et corriger. C’est le second qui est utile.

La boucle, étape par étape

Configurez-la une fois. Mettez les commandes dans le fichier d’instructions de votre agent, pour qu’il les utilise sans qu’on le lui redise. D’abord, trouvez un simulateur et démarrez-le.

xcrun simctl list devices available
xcrun simctl boot "iPhone 16"

Compilez pour ce simulateur. Remplacez le scheme par le vôtre.

xcodebuild -scheme MyApp \
  -destination 'platform=iOS Simulator,name=iPhone 16' \
  -derivedDataPath build \
  build

Installez et lancez le build.

xcrun simctl install booted build/Build/Products/Debug-iphonesimulator/MyApp.app
xcrun simctl launch booted com.example.MyApp

Prenez une capture d’écran que l’agent peut lire.

xcrun simctl io booted screenshot /tmp/screen.png

Claude Code et Codex savent tous les deux ouvrir un fichier image. Demandez à l’agent de prendre une capture après chaque changement d’interface. Il doit décrire ce qu’il voit avant de décider qu’il a fini. Cette seule consigne attrape la plupart des erreurs de mise en page.

Lancez les tests de la même façon

xcodebuild -scheme MyApp \
  -destination 'platform=iOS Simulator,name=iPhone 16' \
  -derivedDataPath build \
  test

Le chemin des données dérivées compte. S’il reste dans le dossier du projet, le deuxième build est incrémental et prend des secondes au lieu de minutes. Un agent qui attend quatre minutes par build fait le quart du travail.

Mettez la boucle dans le fichier d’instructions

Les deux agents lisent un fichier à la racine du dépôt pour les instructions du projet. Claude Code lit CLAUDE.md et Codex lit AGENTS.md. Mettez-y la boucle, pour que chaque session commence avec.

## Building and checking this app
- Build: xcodebuild -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 16' -derivedDataPath build build
- Run: xcrun simctl install booted build/Build/Products/Debug-iphonesimulator/MyApp.app && xcrun simctl launch booted com.example.MyApp
- Look: xcrun simctl io booted screenshot /tmp/screen.png, then open the image
- After any UI change, build, run, and look before saying it is done.
- Tests: same xcodebuild command with test instead of build.

Ce qui fait trébucher les agents

  • Xcode non sélectionné. Après l’installation d’un nouveau Xcode, lancez xcode-select pour pointer dessus. Sinon xcodebuild utilise l’ancien.
  • Simulateur non démarré. La commande de lancement échoue avec une erreur vague. Démarrez-le d’abord et laissez-le tourner.
  • Runtime non installé. Un Xcode neuf n’a aucun runtime iOS tant que vous n’en téléchargez pas un. Ce téléchargement pèse plusieurs gigaoctets. Il doit se faire avant que l’agent démarre.
  • Pas de session ouverte. Le simulateur est une application graphique. Sur une machine headless où personne n’est connecté, il ne démarre pas. L’utilisateur de l’agent a besoin d’une session de bureau active. C’est pourquoi l’ouverture de session automatique compte sur un Mac sans surveillance.

Ce que nous configurons pour vous

Sur un Mac pour agents de chez nous, Xcode est installé avec un runtime iOS téléchargé. L’utilisateur de l’agent a une session de bureau toujours ouverte. Claude Code et Codex attendent votre connexion. Ajoutez la boucle ci-dessus à votre fichier d’instructions, et l’agent peut compiler et voir votre app dès la première tâche. Le guide des possibilités détaille ce qui fonctionne d’autre sur la machine, et ce qui ne fonctionne pas.

Questions fréquentes

Claude Code peut-il compiler une app iOS sous Linux ?

+

Non. Il peut modifier des fichiers Swift sous Linux, et compiler des paquets Swift qui ne dépendent pas des frameworks Apple. Compiler une app iOS demande Xcode, qui ne tourne que sous macOS.

L’agent a-t-il besoin d’un iPhone physique ?

+

Pas pour l’essentiel du travail. Le simulateur couvre la compilation, l’exécution, les captures d’écran et les tests d’interface. Un appareil est nécessaire pour la caméra, les notifications push, ou les performances sur du vrai matériel.

L’agent peut-il faire des captures d’écran du simulateur ?

+

Oui, avec la commande simctl screenshot. Il faut qu’un simulateur soit démarré et que l’utilisateur de l’agent ait une session de bureau. L’agent peut ensuite ouvrir l’image et la lire.

Quelle version de Xcode l’agent va-t-il utiliser ?

+

Celle vers laquelle pointe xcode-select. Fixez-la dans votre fichier d’instructions. Sur une machine avec plusieurs versions, demandez à l’agent de vérifier avant de compiler.

Guides associés