Prise en charge de macOS par Devin

Devin a désormais accès à des machines virtuelles macOS. Il peut donc maintenant builder et tester des applications iOS et macOS, et téléverser des builds vers TestFlight.

Devin buildant un jeu iOS sur une VM macOS

Pour un guide pas à pas, consultez Builder une application iOS avec Devin.

Si vous utilisez un déploiement Dedicated SaaS, contactez votre account team pour activer les VM macOS.

Fonctionnement

La prise en charge de macOS repose sur le même système de configuration déclarative que Linux. Le champ runs-on de votre blueprint indique à Devin sur quelle plateforme effectuer le build et l’exécution, et chaque plateforme dispose de son propre snapshot. Les principales différences par rapport à Linux concernent le shell, l’organisation du système de fichiers et le package manager :

Aspect	Linux (par défaut)	macOS
Répertoire personnel	`/home/ubuntu`	`/Users/devin`
Répertoire du repo	`~/repos/<repo-name>`	`/Users/devin/repos/<repo-name>`
Shell	`bash`	`zsh`
Package manager	`apt-get`	`brew` (Homebrew dans `/opt/homebrew`)
Fichiers joints	`/home/ubuntu/.files/`	`/Users/devin/.files/`

Démarrer une session macOS

Vous pouvez choisir macOS pour chaque session :

Blueprint : ajoutez runs-on: macos afin que le snapshot du repo soit construit pour macOS (voir ci-dessous).
Slack : utilisez la bang command !mac pour démarrer une session sur une VM macOS.
API : définissez platform: "macos" lors de la création d’une session, d’une planification ou d’une automation. Consultez l’API reference.
Valeur par défaut de l’organisation : un admin peut définir macOS comme plateforme par défaut des nouvelles sessions dans Settings → Devin → Default platform, ou via l’API Set Organization Default Platform. Pour connaître la valeur actuelle, utilisez Get Organization Default Platform.

Rédiger des blueprints macOS

Blueprint monoplateforme

Si votre repository cible uniquement les plateformes Apple, utilisez runs-on: macos au niveau supérieur :

runs-on: macos

initialize:
  - name: "Install build tooling"
    run: |
      brew install xcodegen swiftlint xcbeautify

maintenance: |
  xcodebuild -resolvePackageDependencies -project MyApp.xcodeproj -scheme MyApp

knowledge:
  - name: build
    contents: xcodebuild -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 17' build
  - name: test
    contents: xcodebuild -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 17' test
  - name: lint
    contents: swiftlint

Blueprint multiplateforme

Pour builder le même repository sur plusieurs plateformes, écrivez chaque plateforme dans un document YAML distinct, séparé par ---. Chaque document déclare son propre libellé runs-on. Consultez l’encadré Multi-document YAML du guide des blueprints pour plus de contexte sur ce format.

runs-on: default
initialize: |
  apt-get update && apt-get install -y build-essential

maintenance: |
  npm install

knowledge:
  - name: test
    contents: npm test

---
runs-on: macos
initialize: |
  brew install cocoapods

maintenance: |
  npm install
  (cd ios && pod install)

knowledge:
  - name: test
    contents: npm test

Chaque document produit un build du snapshot distinct pour sa plateforme. Les sessions démarrent à partir du snapshot spécifique à la plateforme.

Le YAML de premier niveau doit être un mapping, et non une séquence. Si vous écrivez l’exemple ci-dessus sous la forme d’une seule liste (- runs-on: default / - runs-on: macos), le backend la rejettera. Utilisez le séparateur --- présenté ci-dessus.

Le champ `runs-on`

Le champ runs-on correspond à une configuration de machine enregistrée sur votre compte :

Valeur	Plateforme
`default` ou `linux`	Linux (plateforme par défaut)
`macos`	macOS
`windows`	Windows

Vous pouvez spécifier runs-on sous forme de chaîne ou de liste :

# Plateforme unique
runs-on: macos

# Plusieurs plateformes dans un même block (les mêmes commandes s'exécutent sur chacune)
runs-on: [default, macos]

La syntaxe de liste exécute les mêmes commandes sur toutes les plateformes de la liste. Ne l’utilisez que lorsque les commandes sont réellement multiplateformes (par exemple npm install). Pour les commandes propres à une plateforme (comme apt-get sous Linux ou brew sous macOS), utilisez plutôt le format multi-document.

Utilisation et coût

Les sessions macOS génèrent actuellement la même utilisation que les sessions Linux équivalentes, sans supplément pour macOS.

Il s’agit d’une tarification promotionnelle de lancement, susceptible d’être modifiée.

Pour savoir comment l’utilisation est mesurée, consultez Utilisation.

Ce qui est préinstallé

Les images de session macOS sont livrées avec la chaîne d’outils Apple déjà installée, afin que votre blueprint n’ait pas à la télécharger :

Catégorie	Inclus
Xcode	La dernière release Xcode 26 par défaut dans `/Applications/Xcode.app`, ainsi que la préversion Xcode 27 installée en parallèle (par ex. `/Applications/Xcode-27.0-RC.app`)
Simulateurs	Un environnement d’exécution iOS Simulator par Xcode installé (iOS 26 et iOS 27), chacun avec un iPhone préconfiguré
Outillage Apple	`xcodebuild`, `xcrun`, `simctl`, Swift et la chaîne d’outils Metal
Package manager	Homebrew dans `/opt/homebrew`
Langages	Node.js, Python, Java, Rust (ainsi que `npm`, `yarn`, `pnpm`)
Outils CLI	`git`, `git-lfs`, `gh`, `jq`, `ripgrep`, `ffmpeg`, `wget`, `direnv`
Browser	Google Chrome

Les versions évoluent au fil des nouvelles releases d’Apple et des mises à jour de l’image. Pour savoir exactement ce dont dispose une session, demandez à Devin d’exécuter :

sw_vers
xcodebuild -version
ls -d /Applications/Xcode*.app
xcrun simctl list runtimes

Sélectionner une version de Xcode

La version de Xcode par défaut est celle vers laquelle pointe xcode-select. Pour utiliser une autre version installée le temps d’une seule commande, définissez DEVELOPER_DIR :

DEVELOPER_DIR=/Applications/Xcode-27.0-RC.app/Contents/Developer /usr/bin/xcodebuild -version

Utilisez /usr/bin/xcodebuild (le shim qui respecte DEVELOPER_DIR) plutôt qu’un xcodebuild résolu depuis le dossier Contents/Developer/usr/bin d’un Xcode spécifique présent dans le PATH : ce dernier renvoie sa propre version sans tenir compte de DEVELOPER_DIR. Vous pouvez aussi changer la valeur par défaut pour toute la session :

sudo xcode-select -s /Applications/Xcode-27.0-RC.app

Indiquez celle dont vous avez besoin dans votre blueprint afin que chaque session démarre avec la bonne chaîne d’outils.

Comportement des sessions macOS

Shell

Les sessions macOS utilisent zsh comme shell par défaut. La plupart des commandes shell POSIX fonctionnent sans modification par rapport aux blueprints Linux, mais attention à l’espace utilisateur BSD : sed -i exige un argument (sed -i ''), et les outils GNU comme gsed, gdate et greadlink proviennent de la formule Homebrew coreutils.

Chemins

# Chemins Linux
- run: cp config.json ~/.config/myapp/config.json

# Chemins macOS
- run: cp config.json /Users/devin/.config/myapp/config.json

Les repositories sont clonés dans /Users/devin/repos/<repo-name>, et les fichiers que vous uploadez dans une session sont écrits dans /Users/devin/.files/.

Secrets

Les secrets sont exposés sous forme de variables d’environnement pendant les sessions ($SECRET_NAME), comme sous Linux. C’est ainsi que vous fournissez les API keys App Store Connect, les credentials de signature ou les tokens de registre privé :

maintenance:
  - name: "Configure private Swift package registry"
    run: |
      git config --global url."https://$GIT_TOKEN@github.com/".insteadOf "https://github.com/"

Pour les secrets App Store Connect et la configuration requis par les téléversements vers TestFlight, consultez Téléverser des builds iOS vers TestFlight.

Mise en veille et sortie de veille des sessions

Lors de leur mise en veille, les sessions sont enregistrées sur le disque sous forme de snapshot. Tout ce qui se trouve sur le disque est conservé après une sortie de veille : outils installés, repos clonés, caches de build, données dérivées. Ce n’est pas le cas des processus en cours d’exécution : les serveurs de développement, les simulateurs et les watchers doivent être redémarrés une fois la session sortie de veille.

Computer Use

Computer Use fonctionne sur les sessions macOS : Devin dispose d’un bureau macOS complet avec Chrome, souris et clavier, peut tester aussi bien les applications natives macOS que les applications web, et enregistrer ses actions. Devin utilise la touche Command pour les raccourcis macOS (⌘C, ⌘V, ⌘Tab) plutôt que Control.

Simulateur iOS

Devin peut lancer et piloter directement le simulateur iOS :

open -a Simulator                  # démarrer l'appareil par défaut
xcrun simctl list devices          # afficher les appareils disponibles
xcrun simctl boot "iPhone 17"      # démarrer un appareil spécifique
xcrun simctl install booted MyApp.app
xcrun simctl launch booted com.example.MyApp

L’onglet iOS Simulator du workspace de session diffuse le simulateur démarré, ce qui vous permet de voir Devin parcourir votre application en temps réel. C’est l’équivalent Apple de la prise en charge de l’émulateur Android.

Conseils et astuces

Préchauffer les caches de build

Un build Xcode à froid dégrade l’expérience développeur, avec des temps de build plus longs. Utilisez le champ maintenance dans environment.yml pour préchauffer le cache.

runs-on: macos

initialize:
  - name: "Install tooling"
    run: brew install cocoapods xcodegen swiftlint

maintenance:
  - name: "Resolve dependencies and warm the build"
    run: |
      xcodebuild -resolvePackageDependencies -project MyApp.xcodeproj -scheme MyApp
      xcodebuild -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 17' build-for-testing
  - name: "Pre-boot the simulator"
    run: xcrun simctl boot "iPhone 17" || true

Les packages Swift résolus, les CocoaPods et le dossier DerivedData sont conservés dans le snapshot : les nouvelles sessions démarrent donc à partir d’un build incrémental.

Accès réseau

Les builds qui récupèrent des dépendances depuis CocoaPods, Swift Package Manager, Firebase ou un registre privé nécessitent que ces hôtes soient joignables. Si votre organisation applique une politique réseau restrictive, vérifiez que la liste d’autorisation macOS couvre les mêmes registres que vos builds Linux. Les deux se configurent séparément, et une entrée manquante se traduit généralement par un échec de résolution de dépendances ou une erreur TLS en plein milieu d’un build.

Exécuter des containers

Les VM macOS ne disposent pas de virtualisation matérielle imbriquée : un environnement d’exécution de containers doit donc se replier sur l’émulation logicielle de QEMU (TCG). Colima le détecte et bascule automatiquement en mode émulation :

brew install colima docker qemu lima
colima start --vm-type qemu --arch aarch64 --cpu 4 --memory 8 --disk 30

La VM met deux à quatre minutes à devenir utilisable, et le premier démarrage peut expirer en attente de SSH pendant que l’invité émulé initialise le réseau : relancez donc colima start en cas d’échec. Les containers s’exécutent ensuite environ 15 à 25 fois plus lentement sur CPU qu’en natif, avec quelques secondes de démarrage chacun ; les pulls, eux, se font à la vitesse du réseau de l’hôte. C’est acceptable pour un container de linting ou d’empaquetage, mais pénible pour de la compilation. Pour les travaux reposant fortement sur les containers, utilisez une session Linux ou faites pointer la session macOS vers un démon Docker distant.

N’installez Xcode dans un blueprint qu’en cas de nécessité

Xcode pèse plusieurs gigaoctets au téléchargement, et Apple en conditionne l’accès à un Apple ID. Privilégiez les versions déjà présentes dans l’image, sélectionnées avec DEVELOPER_DIR ou xcode-select. Si vous avez besoin d’une autre version ou d’une bêta, vous pouvez stocker un Apple ID sous forme de secret et laisser le blueprint télécharger cette version, au prix d’un build bien plus lent.

Limitations

Limitation	Détail
Docker et containers	Pas de virtualisation matérielle imbriquée : les containers s’exécutent donc en émulation logicielle. Voir Exécuter des containers.
Appareils physiques	Pas de passthrough USB : les builds et les tests s’exécutent sur des simulateurs, et non sur de véritables iPhone ou iPad.
Téléchargements Xcode	Récupérer une autre version de Xcode ou un autre environnement d’exécution de simulateur nécessite de fournir les credentials d’un Apple ID et implique un téléchargement long.
Mesure des performances	Le chronométrage et le profilage de type Instruments au sein d’une VM ne reflètent pas les performances réelles d’un appareil.

Résolution des problèmes

Les builds sont beaucoup plus lents lors de la première session suivant une reconstruction de snapshot. DerivedData a été reconstruit de zéro. Ajoutez une étape build-for-testing à maintenance pour que le snapshot embarque un build déjà à chaud. xcodebuild sélectionne la mauvaise chaîne d’outils. Vérifiez xcode-select -p et définissez explicitement DEVELOPER_DIR dans l’étape du blueprint. Une destination est introuvable. Exécutez xcrun simctl list devices available pour voir ce que les environnements d’exécution installés fournissent réellement, puis alignez le nom et l’OS de -destination en conséquence. La résolution des dépendances se bloque ou échoue avec une erreur TLS. L’hôte est probablement absent de la liste d’autorisation réseau de votre organisation pour macOS. Consultez Accès réseau.

Prise en main

Concepts essentiels

Mise en place de Devin

Travailler avec Devin

Guides produit

Intégrations

Administration

Notes de version

Prise en charge de macOS par Devin

Fonctionnement

Démarrer une session macOS

Rédiger des blueprints macOS

Blueprint monoplateforme

Blueprint multiplateforme

Le champ `runs-on`

Utilisation et coût

Ce qui est préinstallé

Sélectionner une version de Xcode

Comportement des sessions macOS

Shell

Chemins

Secrets

Mise en veille et sortie de veille des sessions

Computer Use

Simulateur iOS

Conseils et astuces

Préchauffer les caches de build

Accès réseau

Exécuter des containers

N’installez Xcode dans un blueprint qu’en cas de nécessité

Limitations

Résolution des problèmes

​Fonctionnement

​Démarrer une session macOS

​Rédiger des blueprints macOS

​Blueprint monoplateforme

​Blueprint multiplateforme

​Le champ runs-on

​Utilisation et coût

​Ce qui est préinstallé

​Sélectionner une version de Xcode

​Comportement des sessions macOS

​Shell

​Chemins

​Secrets

​Mise en veille et sortie de veille des sessions

​Computer Use

​Simulateur iOS

​Conseils et astuces

​Préchauffer les caches de build

​Accès réseau

​Exécuter des containers

​N’installez Xcode dans un blueprint qu’en cas de nécessité

​Limitations

​Résolution des problèmes

Fonctionnement

Démarrer une session macOS

Rédiger des blueprints macOS

Blueprint monoplateforme

Blueprint multiplateforme

Le champ `runs-on`

Utilisation et coût

Ce qui est préinstallé

Sélectionner une version de Xcode

Comportement des sessions macOS

Shell

Chemins

Secrets

Mise en veille et sortie de veille des sessions

Computer Use

Simulateur iOS

Conseils et astuces

Préchauffer les caches de build

Accès réseau

Exécuter des containers

N’installez Xcode dans un blueprint qu’en cas de nécessité

Limitations

Résolution des problèmes