` |
| Shell | `bash` | `zsh` |
| Paketmanager | `apt-get` | `brew` (Homebrew unter `/opt/homebrew`) |
| Dateianhänge | `/home/ubuntu/.files/` | `/Users/devin/.files/` |
## Eine macOS-Sitzung starten
Sie können macOS pro Sitzung auswählen:
* **Blueprint**: Fügen Sie `runs-on: macos` hinzu, damit der Snapshot des Repos für macOS erstellt wird (siehe unten).
* **Slack**: Verwenden Sie den Bang-Befehl `!mac` ([Bang-Befehle](/de/integrations/slack)), um eine Sitzung auf einer macOS-VM zu starten.
* **API**: Setzen Sie beim Erstellen einer Sitzung, eines Zeitplans oder einer Automatisierung `platform: "macos"`. Siehe [API Reference](/de/api-reference/overview).
## macOS-Blueprints schreiben
### Blueprint für eine einzelne Plattform
Wenn dein Repository ausschließlich auf Apple-Plattformen abzielt, verwende `runs-on: macos` auf oberster Ebene:
```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
```
### Plattformübergreifender Blueprint
Um dasselbe Repository für mehrere Plattformen zu bauen, definieren Sie jede Plattform als eigenes YAML-Dokument, getrennt durch `---`. Jedes Dokument deklariert sein eigenes `runs-on`-Label. Hintergrundinformationen zu diesem Format finden Sie im Hinweis [Multi-document YAML](/de/onboard-devin/environment/blueprints#blueprint-sections) im Blueprint-Leitfaden.
```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
```
Jedes Dokument erzeugt einen separaten Snapshot-Build für seine Plattform. Sitzungen starten vom plattformspezifischen Snapshot.
Das YAML muss auf oberster Ebene ein Mapping sein, keine Sequenz. Wird das obige Beispiel als einzelne Liste geschrieben (`- runs-on: default` / `- runs-on: macos`), weist das Backend es zurück. Verwenden Sie den oben gezeigten Trenner `---`.
## Das Feld `runs-on`
Das Feld `runs-on` wird einer registrierten Maschinenkonfiguration in Ihrem Konto zugeordnet:
| Wert | Plattform |
| ---------------------- | ------------------------- |
| `default` oder `linux` | Linux (Standardplattform) |
| `macos` | macOS |
| `windows` | Windows |
Sie können `runs-on` als Zeichenkette oder als Liste angeben:
```yaml theme={null}
# Einzelne Plattform
runs-on: macos
# Mehrere Plattformen in einem Block (dieselben Befehle laufen auf jeder Plattform)
runs-on: [default, macos]
```
Die Listensyntax führt auf jeder Plattform in der Liste dieselben Befehle aus. Verwende sie nur, wenn die Befehle tatsächlich plattformübergreifend funktionieren (z. B. `npm install`). Für plattformspezifische Befehle (wie `apt-get` unter Linux oder `brew` unter macOS) verwende stattdessen das [Mehrdokumentformat](#multi-platform-blueprint).
## Nutzung und Kosten
macOS-Sitzungen verursachen dieselbe Nutzung wie vergleichbare Linux- oder Windows-Sitzungen. Ein Aufschlag für macOS fällt nicht an. Einzelheiten zur Erfassung der Nutzung finden Sie unter [Nutzung](/de/admin/billing/usage#macos-sessions).
## Was vorinstalliert ist
macOS-Sitzungs-Images werden mit bereits installierter Apple-Toolchain ausgeliefert, sodass Ihr Blueprint sie nicht erst herunterladen muss:
| Kategorie | Enthalten |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Xcode | Das neueste Xcode-26-Release als Standard unter `/Applications/Xcode.app`, dazu parallel die Xcode-27-Vorabversion (z. B. `/Applications/Xcode-27.0-RC.app`) |
| Simulatoren | Eine iOS-Simulator-Runtime pro installiertem Xcode (iOS 26 und iOS 27), jeweils mit einem vorkonfigurierten iPhone-Gerät |
| Apple-Tools | `xcodebuild`, `xcrun`, `simctl`, Swift und die Metal-Toolchain |
| Paketmanager | Homebrew unter `/opt/homebrew` |
| Sprachen | Node.js, Python, Java, Rust (plus `npm`, `yarn`, `pnpm`) |
| CLI-Tools | `git`, `git-lfs`, `gh`, `jq`, `ripgrep`, `ffmpeg`, `wget`, `direnv` |
| Browser | Google Chrome |
Die Versionen ändern sich, sobald Apple neue Releases veröffentlicht und das Image aktualisiert wird. Um genau zu sehen, was in einer Sitzung vorhanden ist, bitten Sie Devin, Folgendes auszuführen:
```bash theme={null}
sw_vers
xcodebuild -version
ls -d /Applications/Xcode*.app
xcrun simctl list runtimes
```
### Eine Xcode-Version auswählen
Standardmäßig wird das Xcode verwendet, auf das `xcode-select` verweist. Um für einen einzelnen Befehl eine andere installierte Version zu nutzen, setzen Sie `DEVELOPER_DIR`:
```bash theme={null}
DEVELOPER_DIR=/Applications/Xcode-27.0-RC.app/Contents/Developer /usr/bin/xcodebuild -version
```
Verwenden Sie `/usr/bin/xcodebuild` (den Shim, der `DEVELOPER_DIR` berücksichtigt) und nicht ein `xcodebuild`, das über `PATH` aus dem Verzeichnis `Contents/Developer/usr/bin` einer bestimmten Xcode-Version bezogen wird, denn dieses meldet unabhängig von `DEVELOPER_DIR` seine eigene Version.
Oder ändern Sie den Standard für die gesamte Sitzung:
```bash theme={null}
sudo xcode-select -s /Applications/Xcode-27.0-RC.app
```
Hinterlegen Sie die jeweils benötigte Version in Ihrem Blueprint, damit jede Sitzung mit der richtigen Toolchain startet.
## Sitzungsverhalten unter macOS
### Shell
macOS-Sitzungen verwenden **zsh** als Standard-Shell. Die meisten POSIX-Shell-Befehle funktionieren unverändert wie in Linux-Blueprints, beachten Sie jedoch das BSD-Userland: `sed -i` erfordert ein Argument (`sed -i ''`), und GNU-Tools wie `gsed`, `gdate` und `greadlink` stammen aus der Homebrew-Formula `coreutils`.
### Pfade
```yaml theme={null}
# Linux-Pfade
- run: cp config.json ~/.config/myapp/config.json
# macOS-Pfade
- run: cp config.json /Users/devin/.config/myapp/config.json
```
Repositorys werden nach `/Users/devin/repos/` geklont, und Dateien, die Sie in eine Sitzung hochladen, werden unter `/Users/devin/.files/` abgelegt.
### Secrets
[Secrets](/de/product-guides/secrets) stehen während Sitzungen als Umgebungsvariablen zur Verfügung (`$SECRET_NAME`), genau wie unter Linux. So hinterlegen Sie App Store Connect API keys, Signing-Credentials oder Tokens für private Registries:
```yaml theme={null}
maintenance:
- name: "Configure private Swift package registry"
run: |
git config --global url."https://$GIT_TOKEN@github.com/".insteadOf "https://github.com/"
```
### Schlafen und Aufwachen von Sitzungen
Beim Schlafen wird von Sitzungen ein Snapshot auf die Festplatte geschrieben. Alles, was auf der Festplatte liegt, übersteht das Aufwachen: installierte Tools, geklonte Repos, Build-Caches, abgeleitete Daten. Laufende Prozesse hingegen nicht: Dev-Server, Simulatoren und Watcher müssen nach dem Aufwachen der Sitzung neu gestartet werden.
### Computer Use
[Computer Use](/de/work-with-devin/computer-use) funktioniert in macOS-Sitzungen: Devin erhält einen vollständigen macOS-Desktop mit Chrome, Maus und Tastatur, kann sowohl macOS-native Apps als auch Web-Apps testen und [aufzeichnen](/de/work-with-devin/testing-and-recordings), was er dabei tut. Für macOS-Tastenkürzel verwendet Devin die Command-Taste (⌘C, ⌘V, ⌘Tab) statt Control.
### iOS-Simulator
Devin kann den iOS-Simulator direkt starten und bedienen:
```bash theme={null}
open -a Simulator # Standardgerät starten
xcrun simctl list devices # verfügbare Geräte anzeigen
xcrun simctl boot "iPhone 17" # ein bestimmtes Gerät starten
xcrun simctl install booted MyApp.app
xcrun simctl launch booted com.example.MyApp
```
Der Tab **iOS-Simulator** im Sitzungs-Workspace streamt den gestarteten Simulator, sodass Sie in Echtzeit verfolgen können, wie Devin sich durch Ihre App tippt. Er ist das Apple-Pendant zur [Unterstützung für Android-Emulatoren](/de/onboard-devin/environment/android-emulation).
## Tipps & Tricks
### Build-Caches vorwärmen
Ein kalter Xcode-Build führt zu längeren Build-Zeiten und damit zu einer schlechteren Entwicklererfahrung. Verwende das Feld `maintenance` in `environment.yml`, um den Cache vorzuwärmen.
```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
```
Bezogene Swift-Pakete, CocoaPods und DerivedData bleiben im Snapshot erhalten, sodass neue Sitzungen mit einem inkrementellen Build starten.
### Netzwerkzugriff
Builds, die Pakete von CocoaPods, dem Swift Package Manager, Firebase oder einer privaten Registry beziehen, benötigen Zugriff auf diese Hosts. Wenn Ihre Organisation mit einer eingeschränkten Netzwerkrichtlinie arbeitet, stellen Sie sicher, dass die macOS-Allowlist dieselben Registries abdeckt wie Ihre Linux-Builds. Beide werden getrennt konfiguriert, und ein fehlender Eintrag zeigt sich meist als Fehler bei der Abhängigkeitsauflösung oder als TLS-Fehler mitten im Build.
### Container ausführen
macOS-VMs bieten keine verschachtelte Hardware-Virtualisierung, weshalb eine Container-Runtime auf die Software-Emulation von QEMU (TCG) zurückgreifen muss. Colima erkennt dies und wechselt selbstständig zur Emulation:
```bash theme={null}
brew install colima docker qemu lima
colima start --vm-type qemu --arch aarch64 --cpu 4 --memory 8 --disk 30
```
Die VM benötigt zwei bis vier Minuten, bis sie nutzbar ist, und der erste Start kann beim Warten auf SSH in einen Timeout laufen, während der emulierte Gast das Netzwerk hochfährt – führen Sie `colima start` bei einem Fehlschlag daher einfach erneut aus. Container laufen anschließend auf der CPU etwa 15- bis 25-mal langsamer als nativ und brauchen jeweils einige Sekunden zum Starten; Pulls erfolgen mit der Netzwerkgeschwindigkeit des Hosts. Für einen Container zum Linting oder Packaging reicht das aus, zum Kompilieren ist es jedoch mühsam. Nutzen Sie für containerlastige Aufgaben besser eine Linux-Sitzung oder richten Sie die macOS-Sitzung auf einen entfernten Docker-Daemon aus.
### Installiere Xcode nur dann in einem Blueprint, wenn es sich nicht vermeiden lässt
Xcode ist ein mehrere Gigabyte großer Download, und Apple gibt ihn nur mit einer Apple-ID frei. Verwende bevorzugt die Versionen, die bereits im Image enthalten sind, und wähle sie über `DEVELOPER_DIR` oder `xcode-select` aus. Wenn du eine andere Version oder eine Beta benötigst, kannst du eine Apple-ID als [Secret](/de/product-guides/secrets) hinterlegen und den Blueprint diese Version herunterladen lassen – allerdings um den Preis eines deutlich langsameren Builds.
## Einschränkungen
| Einschränkung | Detail |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Docker und Container | Keine verschachtelte Hardware-Virtualisierung, daher laufen Container unter Software-Emulation. Siehe [Container ausführen](#running-containers). |
| Physische Geräte | Kein USB-Passthrough, daher laufen Builds und Tests auf Simulatoren und nicht auf physischen iPhones oder iPads. |
| Xcode-Downloads | Für eine weitere Xcode-Version oder Simulator-Runtime müssen Apple-ID-Credentials angegeben werden, und der Download dauert lange. |
| Performance-Messung | Zeitmessungen und Profiling mit Instruments innerhalb einer VM sind nicht repräsentativ für die Performance auf echten Geräten. |
## Troubleshooting
**Builds sind in der ersten Sitzung nach einem Snapshot-Rebuild deutlich langsamer.** DerivedData wurde komplett neu erzeugt. Fügen Sie in `maintenance` einen `build-for-testing`-Schritt hinzu, damit der Snapshot einen warmen Build enthält.
**`xcodebuild` verwendet die falsche Toolchain.** Prüfen Sie `xcode-select -p` und setzen Sie `DEVELOPER_DIR` im Blueprint-Schritt explizit.
**Eine Destination wird nicht gefunden.** Führen Sie `xcrun simctl list devices available` aus, um zu sehen, welche Geräte die installierten Runtimes tatsächlich bereitstellen, und passen Sie Namen und Betriebssystem in `-destination` entsprechend an.
**Die Auflösung der Abhängigkeiten hängt oder schlägt mit einem TLS-Fehler fehl.** Wahrscheinlich fehlt der Host in der Netzwerk-Allowlist Ihrer Organisation für macOS. Siehe [Netzwerkzugriff](#network-access).