Skip to main content
Devin ora ha accesso a macchine virtuali macOS. Questo significa che può creare e testare applicazioni iOS e macOS.
Se utilizzi una distribuzione Dedicated SaaS, contatta il tuo account team per abilitare le VM macOS.

​
Come funziona

Il supporto per macOS si basa sullo stesso sistema di configurazione dichiarativa di Linux. Il campo runs-on nel blueprint indica a Devin su quale piattaforma eseguire build e run, e ogni piattaforma ha il proprio snapshot. Le principali differenze rispetto a Linux riguardano la shell, la struttura del file system e il gestore di pacchetti:

​
Avviare una sessione macOS

Puoi scegliere macOS per singola sessione:
  • Blueprint: aggiungi runs-on: macos in modo che lo snapshot del repo venga creato per macOS (vedi sotto).
  • Slack: usa il bang command !mac per avviare una sessione su una VM macOS.
  • API: imposta platform: "macos" quando crei una sessione, una pianificazione o un’automazione. Consulta l’API reference.

​
Scrivere blueprint per macOS

​
Blueprint per singola piattaforma

Se il tuo repository ha come target solo le piattaforme Apple, usa runs-on: macos al livello principale:

​
Blueprint multipiattaforma

Per compilare lo stesso repository su più piattaforme, scrivi ogni piattaforma come documento YAML separato, delimitato da ---. Ogni documento dichiara la propria label runs-on. Per approfondire questo formato, consulta il riquadro Multi-document YAML nella guida ai blueprint.
Ogni documento produce uno snapshot build separato per la propria piattaforma. Le sessioni si avviano dallo snapshot specifico della piattaforma.
Lo YAML di primo livello deve essere una mappatura, non una sequenza. Scrivere l’esempio precedente come un unico elenco (- runs-on: default / - runs-on: macos) viene rifiutato dal backend. Usa il separatore --- mostrato sopra.

​
Il campo runs-on

Il campo runs-on corrisponde a una configurazione di macchina registrata nel tuo account: Puoi specificare runs-on come stringa o come elenco:
La sintassi con elenco esegue comandi identici su ogni piattaforma dell’elenco. Usala solo quando i comandi sono davvero multipiattaforma (ad es. npm install). Per i comandi specifici di una piattaforma (come apt-get su Linux o brew su macOS), usa invece il formato multi-documento.

​
Utilizzo e costo

Le sessioni macOS comportano lo stesso utilizzo delle sessioni Linux o Windows equivalenti. Non è previsto alcun sovrapprezzo per macOS. Per i dettagli su come viene misurato l’utilizzo, consulta Utilizzo.

​
Cosa è preinstallato

Le immagini delle sessioni macOS includono già la toolchain Apple, così il tuo blueprint non deve scaricarla: Le versioni cambiano man mano che Apple pubblica nuove release e l’immagine viene aggiornata. Per sapere esattamente cosa contiene una sessione, chiedi a Devin di eseguire:

​
Selezionare una versione di Xcode

La versione di Xcode predefinita è quella a cui punta xcode-select. Per usare un’altra versione installata per un singolo comando, imposta DEVELOPER_DIR:
Usa /usr/bin/xcodebuild (lo shim che rispetta DEVELOPER_DIR) anziché un xcodebuild risolto dalla directory Contents/Developer/usr/bin di una specifica versione di Xcode presente nel PATH, che riporta la propria versione indipendentemente da DEVELOPER_DIR. Oppure cambia l’impostazione predefinita per l’intera sessione:
Inserisci nel blueprint la versione che ti serve, così ogni sessione parte con la toolchain corretta.

​
Comportamento delle sessioni su macOS

​
Shell

Le sessioni macOS utilizzano zsh come shell predefinita. La maggior parte dei comandi shell POSIX funziona senza modifiche rispetto ai blueprint Linux, ma occorre tenere presente lo userland BSD: sed -i richiede un argomento (sed -i '') e strumenti GNU come gsed, gdate e greadlink provengono dalla formula Homebrew coreutils.

​
Percorsi

Le repo vengono clonate in /Users/devin/repos/<repo-name>, mentre i file che carichi in una sessione vengono scritti in /Users/devin/.files/.

​
Secrets

I secrets sono disponibili come variabili d’ambiente durante le sessioni ($SECRET_NAME), esattamente come su Linux. È così che si forniscono le API key di App Store Connect, le credenziali di firma o i token per registry privati:

​
Sleep e risveglio della sessione

Quando vanno in sleep, le sessioni creano uno snapshot su disco. Tutto ciò che si trova su disco sopravvive al risveglio: strumenti installati, repo clonati, cache di build, dati derivati. I processi in esecuzione, invece, no: server di sviluppo, simulatori e watcher vanno riavviati dopo il risveglio della sessione.

​
Computer Use

Computer Use funziona nelle sessioni macOS: Devin dispone di un desktop macOS completo con Chrome, mouse e tastiera, può testare sia app native per macOS sia web app e registrare ciò che fa. Devin usa il tasto Command per le scorciatoie di macOS (⌘C, ⌘V, ⌘Tab) anziché Control.

​
iOS Simulator

Devin può avviare e controllare direttamente l’iOS Simulator:
Il tab iOS Simulator nel workspace della sessione trasmette in streaming il simulatore avviato, così puoi vedere Devin che interagisce con la tua app in tempo reale. È l’equivalente Apple del supporto all’emulatore Android.

​
Consigli e trucchi

​
Cache di build precaricate

Una build Xcode a freddo offre un’esperienza di sviluppo non ottimale, con tempi di build più lunghi. Usa il campo maintenance in environment.yml per precaricare la cache.
I package Swift risolti, i CocoaPods e la DerivedData vengono mantenuti nello snapshot, così le nuove sessioni partono da una build incrementale.

​
Accesso alla rete

Le build che scaricano da CocoaPods, Swift Package Manager, Firebase o da un registry privato richiedono che tali host siano raggiungibili. Se la tua organizzazione applica una network policy restrittiva, assicurati che l’allowlist di macOS copra gli stessi registry usati dalle build su Linux. Le due configurazioni sono separate e una voce mancante si manifesta di solito come un errore di risoluzione delle dipendenze o di TLS nel bel mezzo di una build.

​
Esecuzione dei container

Le VM macOS non supportano la virtualizzazione hardware annidata, quindi un runtime per container deve ripiegare sull’emulazione software di QEMU (TCG). Colima lo rileva e passa automaticamente all’emulazione:
La VM richiede dai due ai quattro minuti per diventare utilizzabile e il primo avvio può andare in timeout in attesa di SSH mentre il guest emulato configura la rete: se fallisce, riprova con colima start. I container vengono poi eseguiti su CPU circa 15-25 volte più lentamente rispetto al nativo, con qualche secondo di avvio ciascuno; i pull avvengono alla velocità di rete dell’host. Accettabile per un container di linting o di packaging, molto penalizzante per la compilazione. Per attività che fanno un uso intensivo di container, usa una sessione Linux oppure punta la sessione macOS a un daemon Docker remoto.

​
Non installare Xcode in un blueprint se non è strettamente necessario

Xcode è un download di diversi gigabyte e Apple ne richiede l’accesso tramite Apple ID. Meglio usare le versioni già presenti nell’image, selezionandole con DEVELOPER_DIR o xcode-select. Se ti serve una release diversa o una beta, puoi memorizzare un Apple ID come secret e fare in modo che il blueprint scarichi quella versione, al costo di un build molto più lento.

​
Limitazioni

​
Troubleshooting

Le build sono molto più lente nella prima sessione dopo la ricostruzione di uno snapshot. DerivedData è stata ricostruita da zero. Aggiungi un passaggio build-for-testing a maintenance, così lo snapshot includerà una build già “calda”. xcodebuild seleziona la toolchain sbagliata. Verifica xcode-select -p e imposta esplicitamente DEVELOPER_DIR nel passaggio del blueprint. Una destinazione non viene trovata. Esegui xcrun simctl list devices available per vedere cosa offrono effettivamente i runtime installati e fai corrispondere di conseguenza il nome e il sistema operativo indicati in -destination. La risoluzione delle dipendenze si blocca o fallisce con un errore TLS. Probabilmente l’host non è presente nella network allowlist della tua organizzazione per macOS. Consulta Accesso di rete.