Skip to main content
In questo tutorial, Devin crea un piccolo habit tracker in SwiftUI partendo da un repository vuoto. Devin scrive il codice, lo compila con Xcode, lo esegue nell’iOS Simulator e apre una pull request. Tu segui il suo lavoro, esamini il risultato e poi fai pubblicare a Devin una build beta su TestFlight.
Devin crea un gioco iOS su una VM macOS

​
Prima di iniziare

  • VM macOS: le sessioni di Devin devono essere eseguite su macOS. Se utilizzi una distribuzione Dedicated SaaS, chiedi al tuo account team di abilitare le VM macOS. Consulta Supporto macOS.
  • Un repository: crea un repository vuoto (ad esempio, habit-tracker) e concedi a Devin l’accesso tramite la tua integrazione Git.
  • Desktop mode: attiva Enable desktop mode in Settings > Customization così che Devin possa interagire con il Simulator e registrare il testing. Consulta Computer Use.
Le sessioni macOS consumano lo stesso utilizzo delle sessioni Linux. Non è previsto alcun sovrapprezzo per macOS.

​
Passaggio 1: chiedi a Devin di creare l’app

Avvia una nuova sessione sul repository che hai scelto e scegli macOS dal menu delle piattaforme sotto la casella del prompt. Xcode, l’iOS Simulator e Homebrew sono preinstallati, quindi non serve configurare nulla in anticipo.
In Slack, aggiungi il bang command !mac al tuo messaggio. Tramite l’API, imposta platform: "macos" quando crei una sessione.
Fornisci a Devin un prompt specifico che descriva le funzionalità dell’app, gli strumenti da usare e come dimostrare che tutto funziona. Ecco un esempio:
Un buon prompt per iOS:
  • Indica la versione della piattaforma e i framework, così Devin non deve indovinare il target di distribuzione o l’architettura.
  • Indica il dispositivo del simulatore, così i comandi di build usano una destinazione che esiste sulla VM.
  • Descrive un flusso di verifica concreto, così Devin testa il comportamento che ti interessa invece di limitarsi a verificare che il codice compili.

​
Passaggio 2: osserva Devin mentre compila e testa

Devin affronta l’attività proprio come farebbe uno sviluppatore iOS:
  1. Imposta la struttura del progetto: scrive project.yml, le view SwiftUI, il modello delle abitudini e il target di test, quindi esegue xcodegen generate.
  2. Compila e corregge gli errori: esegue xcodebuild dalla sua shell, legge l’output del compilatore e corregge gli errori finché la build e i test non vanno a buon fine.
  3. Esegue l’app nel Simulator: avvia il dispositivo, installa e lancia la build:
  4. Testa il flusso che hai descritto: naviga nell’app con Computer Use, verifica il risultato a schermo e registra il run.
  5. Apre una pull request con il riepilogo e lo screenshot.
Apri la tab iOS Simulator nel workspace della sessione per seguire in diretta il simulatore avviato mentre Devin naviga nell’app.
Se la build non riesce a trovare una destinazione, chiedi a Devin di eseguire xcrun simctl list devices available e di usare un dispositivo e un sistema operativo effettivamente disponibili sulla VM.

​
Passaggio 3: rivedi e itera

Rivedi la pull request come faresti con qualsiasi altra. Verifica che lo screenshot e la registrazione corrispondano a quanto hai richiesto. Poi continua a sviluppare nella stessa sessione con prompt di follow-up:
Puoi anche lasciare commenti della review sulla pull request: Devin risponde finché la sessione è attiva. Consulta integrazione GitHub e Devin Review.

​
Passaggio 4: Distribuire una beta su TestFlight

Una volta che l’app funziona nel Simulator, Devin può archiviarla, firmarla e caricare la build su TestFlight, così i tester possono installarla su dispositivi reali. Serve una configurazione una tantum da eseguire personalmente. Caricare build iOS su TestFlight illustra ogni passaggio:
  1. Configura App Store Connect: accetta i contratti, registra il bundle ID, crea il record dell’app, crea un gruppo beta e rispondi alle domande sulla conformità all’esportazione.
  2. Crea una API key di App Store Connect e scarica il relativo file .p8.
  3. Aggiungi i secret di Devin: ASC_KEY_ID, ASC_ISSUER_ID, ASC_PRIVATE_KEY e APPLE_TEAM_ID.
  4. Consenti l’accesso alla rete ai server Apple se la tua organizzazione utilizza una network policy restrittiva.
Usa lo stesso bundle ID in project.yml e in App Store Connect. Se nel Passaggio 1 Devin ha scelto un bundle ID segnaposto, chiedigli prima di aggiornare il progetto.
Avvia quindi una nuova sessione, in modo che i secret siano disponibili, e invia questo prompt a Devin:
Devin scrive l’API key su disco, archivia l’app con xcodebuild archive e la carica con xcodebuild -exportArchive. Poi aggiunge la build elaborata al gruppo beta. Per riutilizzare questi passaggi senza doverli ripetere in ogni prompt, aggiungi una entry testflight alla sezione knowledge del blueprint. Consulta Salvare i passaggi nel blueprint.

​
Suggerimenti

  • Blocca la toolchain: le immagini macOS includono più di una versione di Xcode. Usa DEVELOPER_DIR o xcode-select nel blueprint per sceglierne una. Vedi Selezionare una versione di Xcode.
  • Archivia le credenziali come secret: le API key di App Store Connect, i certificati di firma e i token dei registry di pacchetti privati vanno inseriti in Secrets. Devin li legge come variabili d’ambiente.
  • Consenti i registry di pacchetti: se la tua organizzazione usa una network policy restrittiva, assicurati che l’allowlist di macOS includa Swift Package Manager, CocoaPods o qualsiasi registry privato utilizzato dalla tua app. Vedi Accesso alla rete.
  • Riavvia il Simulator dopo un risveglio: quando una sessione va in sleep e poi si risveglia, i file rimangono ma i processi in esecuzione no. Chiedi a Devin di avviare di nuovo il Simulator prima del testing.
  • Chiedi evidenze: richiedi schermate o una recording di schermate specifiche, così puoi verificare la UI senza dover eseguire tu stesso l’app.

​
Limitazioni

  • Devin esegue le app su simulatori, non su iPhone o iPad fisici. Per testare su un dispositivo reale, installa una build TestFlight.
  • I risultati di timing e profiling all’interno di una VM non riflettono le prestazioni reali di un dispositivo.
  • I container vengono eseguiti tramite emulazione software sulle VM macOS, quindi le attività che ne fanno ampio uso risultano lente.
Per i dettagli, consulta le limitazioni del supporto macOS.

​
Passaggi successivi

Caricamenti su TestFlight

Configurazione di App Store Connect, API key e secret per caricare le build

Supporto macOS

Opzioni dei blueprint, strumenti preinstallati e risoluzione dei problemi per le sessioni macOS

Testing e registrazioni

Come Devin testa la tua app e registra i risultati