` |
| Shell | `bash` | `zsh` |
| Gestore di pacchetti | `apt-get` | `brew` (Homebrew in `/opt/homebrew`) |
| File allegati | `/home/ubuntu/.files/` | `/Users/devin/.files/` |
## 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](/it/integrations/slack) `!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](/it/api-reference/overview).
## 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:
```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
```
### 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](/it/onboard-devin/environment/blueprints#blueprint-sections) nella guida ai blueprint.
```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
```
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:
| Valore | Piattaforma |
| ------------------- | ------------------------------ |
| `default` o `linux` | Linux (piattaforma di default) |
| `macos` | macOS |
| `windows` | Windows |
Puoi specificare `runs-on` come stringa o come elenco:
```yaml theme={null}
# Piattaforma singola
runs-on: macos
# Più piattaforme in un unico block (su ognuna vengono eseguiti gli stessi comandi)
runs-on: [default, macos]
```
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](#multi-platform-blueprint).
## 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](/it/admin/billing/usage#macos-sessions).
## Cosa è preinstallato
Le immagini delle sessioni macOS includono già la toolchain Apple, così il tuo blueprint non deve scaricarla:
| Categoria | Incluso |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Xcode | L'ultima release di Xcode 26 come default in `/Applications/Xcode.app`, più la prerelease di Xcode 27 affiancata (ad es. `/Applications/Xcode-27.0-RC.app`) |
| Simulatori | Un runtime di iOS Simulator per ogni Xcode installato (iOS 26 e iOS 27), ciascuno con un dispositivo iPhone preconfigurato |
| Strumenti Apple | `xcodebuild`, `xcrun`, `simctl`, Swift e la toolchain Metal |
| Gestore di pacchetti | Homebrew in `/opt/homebrew` |
| Linguaggi | Node.js, Python, Java, Rust (oltre a `npm`, `yarn`, `pnpm`) |
| Strumenti CLI | `git`, `git-lfs`, `gh`, `jq`, `ripgrep`, `ffmpeg`, `wget`, `direnv` |
| Browser | Google Chrome |
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:
```bash theme={null}
sw_vers
xcodebuild -version
ls -d /Applications/Xcode*.app
xcrun simctl list runtimes
```
### 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`:
```bash theme={null}
DEVELOPER_DIR=/Applications/Xcode-27.0-RC.app/Contents/Developer /usr/bin/xcodebuild -version
```
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:
```bash theme={null}
sudo xcode-select -s /Applications/Xcode-27.0-RC.app
```
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
```yaml theme={null}
# Percorsi Linux
- run: cp config.json ~/.config/myapp/config.json
# Percorsi macOS
- run: cp config.json /Users/devin/.config/myapp/config.json
```
Le repo vengono clonate in `/Users/devin/repos/`, mentre i file che carichi in una sessione vengono scritti in `/Users/devin/.files/`.
### Secrets
I [secrets](/it/product-guides/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:
```yaml theme={null}
maintenance:
- name: "Configure private Swift package registry"
run: |
git config --global url."https://$GIT_TOKEN@github.com/".insteadOf "https://github.com/"
```
### 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](/it/work-with-devin/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](/it/work-with-devin/testing-and-recordings) 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:
```bash theme={null}
open -a Simulator # avvia il dispositivo predefinito
xcrun simctl list devices # visualizza i dispositivi disponibili
xcrun simctl boot "iPhone 17" # avvia un dispositivo specifico
xcrun simctl install booted MyApp.app
xcrun simctl launch booted com.example.MyApp
```
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](/it/onboard-devin/environment/android-emulation).
## 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.
```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
```
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:
```bash theme={null}
brew install colima docker qemu lima
colima start --vm-type qemu --arch aarch64 --cpu 4 --memory 8 --disk 30
```
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](/it/product-guides/secrets) e fare in modo che il blueprint scarichi quella versione, al costo di un build molto più lento.
## Limitazioni
| Limitazione | Dettaglio |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Docker e container | Nessuna virtualizzazione hardware annidata, quindi i container vengono eseguiti tramite emulazione software. Vedi [Esecuzione dei container](#running-containers). |
| Dispositivi fisici | Nessun passthrough USB, quindi build e test vengono eseguiti su simulatori e non su iPhone o iPad fisici. |
| Download di Xcode | Per scaricare un'altra versione di Xcode o un altro runtime del simulatore occorre fornire le credenziali dell'Apple ID e attendere un download lungo. |
| Misurazione delle prestazioni | Le misurazioni dei tempi e il profiling in stile Instruments all'interno di una VM non sono rappresentativi delle prestazioni reali su dispositivo. |
## 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](#network-access).