` |
| 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](/fr/integrations/slack) `!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](/fr/api-reference/overview).
## Rédiger des blueprints macOS
### Blueprint monoplateforme
Si votre repository cible uniquement les plateformes Apple, utilisez `runs-on: macos` au niveau supérieur :
```yaml theme={null}
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](/fr/onboard-devin/environment/blueprints#blueprint-sections) du guide des blueprints pour plus de contexte sur ce format.
```yaml theme={null}
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 :
```yaml theme={null}
# 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](#multi-platform-blueprint).
## Utilisation et coût
Les sessions macOS génèrent la même utilisation que les sessions Linux ou Windows équivalentes. Aucun supplément n'est appliqué pour macOS. Pour savoir comment l'utilisation est mesurée, consultez [Utilisation](/fr/admin/billing/usage#macos-sessions).
## 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 :
```bash theme={null}
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` :
```bash theme={null}
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 :
```bash theme={null}
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
```yaml theme={null}
# 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/`, et les fichiers que vous uploadez dans une session sont écrits dans `/Users/devin/.files/`.
### Secrets
Les [secrets](/fr/product-guides/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é :
```yaml theme={null}
maintenance:
- name: "Configure private Swift package registry"
run: |
git config --global url."https://$GIT_TOKEN@github.com/".insteadOf "https://github.com/"
```
### 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](/fr/work-with-devin/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](/fr/work-with-devin/testing-and-recordings) 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 :
```bash theme={null}
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](/fr/onboard-devin/environment/android-emulation).
## 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.
```yaml theme={null}
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 :
```bash theme={null}
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](/fr/product-guides/secrets) 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](#running-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](#network-access).