Devin macOS-Unterstützung

Devin hat jetzt Zugriff auf virtuelle macOS-Maschinen. Damit kann Devin nun iOS- und macOS-Anwendungen erstellen und testen.

Wenn Sie ein Dedicated-SaaS-Deployment nutzen, wenden Sie sich bitte an Ihr Account-Team, um macOS-VMs zu aktivieren.

Funktionsweise

Die macOS-Unterstützung basiert auf demselben System zur deklarativen Konfiguration wie Linux. Das Feld runs-on in Ihrem Blueprint legt fest, auf welcher Plattform Devin baut und ausführt, und jede Plattform erhält ihren eigenen Snapshot. Die wesentlichen Unterschiede zu Linux betreffen die Shell, den Aufbau des Dateisystems und den Paketmanager:

Aspekt	Linux (Standard)	macOS
Home-Verzeichnis	`/home/ubuntu`	`/Users/devin`
Repo-Verzeichnis	`~/repos/<repo-name>`	`/Users/devin/repos/<repo-name>`
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), 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.

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:

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 im Blueprint-Leitfaden.

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:

# 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.

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.

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:

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:

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:

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

# 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/<repo-name> geklont, und Dateien, die Sie in eine Sitzung hochladen, werden unter /Users/devin/.files/ abgelegt.

Secrets

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:

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 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, 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:

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.

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.

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:

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 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.
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.

Loslegen

Grundlegende Richtlinien

Einführung in Devin

Arbeiten mit Devin

Produktleitfäden

Integrationen

Admin

Versionshinweise

Devin macOS-Unterstützung

Funktionsweise

Eine macOS-Sitzung starten

macOS-Blueprints schreiben

Blueprint für eine einzelne Plattform

Plattformübergreifender Blueprint

Das Feld `runs-on`

Nutzung und Kosten

Was vorinstalliert ist

Eine Xcode-Version auswählen

Sitzungsverhalten unter macOS

Shell

Pfade

Secrets

Schlafen und Aufwachen von Sitzungen

Computer Use

iOS-Simulator

Tipps & Tricks

Build-Caches vorwärmen

Netzwerkzugriff

Container ausführen

Installiere Xcode nur dann in einem Blueprint, wenn es sich nicht vermeiden lässt

Einschränkungen

Troubleshooting

​Funktionsweise

​Eine macOS-Sitzung starten

​macOS-Blueprints schreiben

​Blueprint für eine einzelne Plattform

​Plattformübergreifender Blueprint

​Das Feld runs-on

​Nutzung und Kosten

​Was vorinstalliert ist

​Eine Xcode-Version auswählen

​Sitzungsverhalten unter macOS

​Shell

​Pfade

​Secrets

​Schlafen und Aufwachen von Sitzungen

​Computer Use

​iOS-Simulator

​Tipps & Tricks

​Build-Caches vorwärmen

​Netzwerkzugriff

​Container ausführen

​Installiere Xcode nur dann in einem Blueprint, wenn es sich nicht vermeiden lässt

​Einschränkungen

​Troubleshooting

Funktionsweise

Eine macOS-Sitzung starten

macOS-Blueprints schreiben

Blueprint für eine einzelne Plattform

Plattformübergreifender Blueprint

Das Feld `runs-on`

Nutzung und Kosten

Was vorinstalliert ist

Eine Xcode-Version auswählen

Sitzungsverhalten unter macOS

Shell

Pfade

Secrets

Schlafen und Aufwachen von Sitzungen

Computer Use

iOS-Simulator

Tipps & Tricks

Build-Caches vorwärmen

Netzwerkzugriff

Container ausführen

Installiere Xcode nur dann in einem Blueprint, wenn es sich nicht vermeiden lässt

Einschränkungen

Troubleshooting