Skip to main content
In diesem Tutorial entwickelt Devin einen kleinen SwiftUI-Habit-Tracker aus einem leeren Repository. Devin schreibt den Code, baut ihn mit Xcode, führt ihn im iOS-Simulator aus und öffnet einen Pull Request. Du siehst Devin bei der Arbeit zu, prüfst das Ergebnis und lässt Devin anschließend einen Beta-Build zu TestFlight ausliefern.
Devin entwickelt ein iOS-Spiel auf einer macOS-VM

​
Bevor Sie beginnen

  • macOS-VMs: Devins Sitzungen müssen unter macOS laufen. Wenn Sie ein Dedicated-SaaS-Deployment nutzen, bitten Sie Ihr Account-Team, macOS-VMs zu aktivieren. Siehe macOS-Unterstützung.
  • Ein Repository: Erstellen Sie ein leeres Repository (zum Beispiel habit-tracker) und geben Sie Devin über Ihre Git-Integration Zugriff darauf.
  • Desktop-Modus: Aktivieren Sie Enable desktop mode unter Settings > Customization, damit Devin mit dem Simulator interagieren und seine Tests aufzeichnen kann. Siehe Computer Use.
macOS-Sitzungen verbrauchen genauso viel wie Linux-Sitzungen. Ein macOS-Aufschlag fällt nicht an.

​
Schritt 1: Devin auffordern, die App zu bauen

Starten Sie eine neue Sitzung im Repository Ihrer Wahl und wählen Sie im Plattform-Menü unterhalb des Prompt-Felds macOS aus. Xcode, der iOS-Simulator und Homebrew sind vorinstalliert – Sie müssen also vorab nichts konfigurieren.
Fügen Sie in Slack den Bang-Befehl !mac zu Ihrer Nachricht hinzu. Über die API setzen Sie beim Erstellen einer Sitzung platform: "macos".
Geben Sie Devin einen konkreten Prompt, der die Funktionen der App, die Tools und den Nachweis der Funktionsfähigkeit abdeckt. Hier ein Beispiel:
Ein guter iOS-Prompt:
  • Nennt die Plattformversion und die Frameworks, damit Devin das Deployment-Target oder die Architektur nicht erraten muss.
  • Nennt das Simulator-Gerät, damit Build-Befehle ein Ziel verwenden, das auf der VM tatsächlich vorhanden ist.
  • Beschreibt einen konkreten Verifizierungsablauf, damit Devin das Verhalten testet, auf das es dir ankommt, statt nur zu prüfen, ob der Code kompiliert.

​
Schritt 2: Devin beim Bauen und Testen zusehen

Devin geht die Aufgabe ganz ähnlich an wie ein iOS-Entwickler:
  1. Projektgerüst erstellen: schreibt project.yml, die SwiftUI-Views, das Habit-Modell und das Test-Target und führt anschließend xcodegen generate aus.
  2. Bauen und Fehler beheben: führt xcodebuild in der Shell aus, liest die Compiler-Ausgabe und behebt Fehler, bis Build und Tests erfolgreich durchlaufen.
  3. App im Simulator ausführen: bootet das Gerät, installiert den Build und startet ihn:
  4. Den beschriebenen Ablauf testen: tippt sich mit Computer Use durch die App, prüft das Ergebnis auf dem Bildschirm und zeichnet den Durchlauf auf.
  5. Einen Pull Request öffnen – mit Zusammenfassung und Screenshot.
Öffne im Sitzungs-Workspace den Tab iOS-Simulator, um den gebooteten Simulator live zu verfolgen, während Devin sich durch die App tippt.
Wenn der Build kein Ziel findet, bitte Devin, xcrun simctl list devices available auszuführen und ein Gerät samt Betriebssystem zu verwenden, das die VM tatsächlich bereitstellt.

​
Schritt 3: Review und Iteration

Reviewen Sie den Pull Request wie jeden anderen auch. Prüfen Sie, ob Screenshot und Aufzeichnung dem entsprechen, was Sie angefordert haben. Entwickeln Sie anschließend in derselben Sitzung mit Folge-Prompts weiter:
Sie können auch Review-Kommentare im Pull Request hinterlassen, auf die Devin reagiert, solange die Sitzung aktiv ist. Siehe GitHub-Integration und Devin Review.

​
Schritt 4: Eine Beta über TestFlight ausliefern

Sobald die App im Simulator läuft, kann Devin sie archivieren, signieren und den Build zu TestFlight hochladen, damit Tester sie auf echten Geräten installieren können. Dafür ist ein einmaliges Setup nötig, das du selbst durchführst. iOS-Builds zu TestFlight hochladen beschreibt jeden Schritt:
  1. App Store Connect einrichten: Vereinbarungen akzeptieren, die Bundle-ID registrieren, den App-Eintrag anlegen, eine Beta-Gruppe erstellen und die Angaben zur Exportkonformität machen.
  2. Einen App Store Connect API key erstellen und die zugehörige .p8-Datei herunterladen.
  3. Devin-Secrets hinzufügen: ASC_KEY_ID, ASC_ISSUER_ID, ASC_PRIVATE_KEY und APPLE_TEAM_ID.
  4. Netzwerkzugriff auf Apples Server erlauben, falls deine Organisation eine eingeschränkte Netzwerkrichtlinie verwendet.
Verwende in project.yml und in App Store Connect dieselbe Bundle-ID. Falls Devin in Schritt 1 eine Platzhalter-Bundle-ID gewählt hat, weise Devin an, das Projekt zuerst zu aktualisieren.
Starte anschließend eine neue Sitzung, damit die Secrets verfügbar sind, und gib Devin folgenden Prompt:
Devin schreibt den API key auf die Festplatte, archiviert die App mit xcodebuild archive und lädt sie mit xcodebuild -exportArchive hoch. Anschließend fügt Devin den verarbeiteten Build der Beta-Gruppe hinzu. Um diese Schritte wiederzuverwenden, ohne sie in jedem Prompt zu wiederholen, füge einen testflight-Eintrag zum Abschnitt knowledge des Blueprints hinzu. Siehe Die Schritte im Blueprint speichern.

​
Tipps

  • Toolchain anpinnen: macOS-Images enthalten mehr als eine Xcode-Version. Verwende DEVELOPER_DIR oder xcode-select im Blueprint, um eine auszuwählen. Siehe Eine Xcode-Version auswählen.
  • Anmeldedaten als Secrets speichern: App Store Connect API keys, Signaturzertifikate und Tokens für private Package-Registries gehören in Secrets. Devin liest sie als Umgebungsvariablen aus.
  • Package-Registries freigeben: Wenn deine Organisation eine eingeschränkte Netzwerkrichtlinie verwendet, stelle sicher, dass die macOS-Allowlist Swift Package Manager, CocoaPods sowie alle privaten Registries enthält, die deine App nutzt. Siehe Netzwerkzugriff.
  • Simulator nach dem Aufwachen neu starten: Wenn eine Sitzung schläft und wieder aufwacht, bleiben Dateien erhalten, laufende Prozesse jedoch nicht. Bitte Devin, den Simulator vor dem Testen erneut zu starten.
  • Nachweise anfordern: Fordere Screenshots oder eine Aufzeichnung bestimmter Screens an, damit du die UI prüfen kannst, ohne die App selbst auszuführen.

​
Einschränkungen

  • Devin führt Apps auf Simulatoren aus, nicht auf physischen iPhones oder iPads. Um auf einem Gerät zu testen, installieren Sie einen TestFlight-Build.
  • Timing- und Profiling-Ergebnisse innerhalb einer VM geben die tatsächliche Leistung auf einem Gerät nicht wieder.
  • Container laufen auf macOS-VMs unter Software-Emulation, daher sind containerlastige Aufgaben langsam.
Weitere Informationen finden Sie unter Einschränkungen der macOS-Unterstützung.

​
Nächste Schritte

TestFlight-Uploads

App-Store-Connect-Setup, API keys und Secrets zum Hochladen von Builds

macOS-Unterstützung

Blueprint-Optionen, vorinstallierte Tools und Troubleshooting für macOS-Sitzungen

Tests und Aufzeichnungen

Wie Devin deine App testet und die Ergebnisse aufzeichnet