Suporte a macOS no Devin

O Devin agora tem acesso a máquinas virtuais macOS. Isso significa que ele já pode fazer build e testar aplicativos iOS e macOS, além de importar builds para o TestFlight.

Devin fazendo build de um jogo iOS em uma VM macOS

Para um passo a passo detalhado, veja Faça build de um app iOS com Devin.

Se você usa uma implantação Dedicated SaaS, entre em contato com seu account team para ativar as VMs macOS.

Como funciona

O suporte a macOS é construído sobre o mesmo sistema de configuração declarativa do Linux. O campo runs-on no seu blueprint indica ao Devin em qual plataforma fazer o build e a execução, e cada plataforma tem seu próprio snapshot. As principais diferenças em relação ao Linux são o shell, a organização do sistema de arquivos e o gerenciador de pacotes:

Aspecto	Linux (padrão)	macOS
Diretório home	`/home/ubuntu`	`/Users/devin`
Diretório do repositório	`~/repos/<repo-name>`	`/Users/devin/repos/<repo-name>`
Shell	`bash`	`zsh`
Gerenciador de pacotes	`apt-get`	`brew` (Homebrew em `/opt/homebrew`)
Anexos de arquivos	`/home/ubuntu/.files/`	`/Users/devin/.files/`

Iniciando uma sessão no macOS

Você pode escolher o macOS para cada sessão:

Blueprint: adicione runs-on: macos para que o snapshot do repositório seja criado para macOS (veja abaixo).
Slack: use o bang command !mac para iniciar uma sessão em uma VM macOS.
API: defina platform: "macos" ao criar uma sessão, um agendamento ou uma automação. Consulte a referência da API.
Padrão da organização: um administrador pode definir o macOS como padrão para novas sessões em Configurações → Devin → Default platform ou pela API Set Organization Default Platform. Para verificar o valor atual, use Get Organization Default Platform.

Escrevendo blueprints para macOS

Blueprint de plataforma única

Se o seu repositório tem como alvo apenas plataformas Apple, use runs-on: macos no nível superior:

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 multiplataforma

Para fazer o build do mesmo repositório para mais de uma plataforma, escreva cada plataforma como um documento YAML separado, delimitado por ---. Cada documento declara seu próprio rótulo runs-on. Consulte o aviso YAML multidocumento no guia de blueprints para mais informações sobre esse formato.

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

Cada documento gera um build do snapshot separado para sua plataforma. As sessões são inicializadas a partir do snapshot específico de cada plataforma.

O YAML de nível superior deve ser um mapping, não uma sequência. Escrever o exemplo acima como uma única lista (- runs-on: default / - runs-on: macos) é rejeitado pelo backend. Use o separador --- mostrado acima.

O campo `runs-on`

O campo runs-on é mapeado para uma configuração de máquina registrada na sua conta:

Valor	Plataforma
`default` ou `linux`	Linux (plataforma padrão)
`macos`	macOS
`windows`	Windows

Você pode especificar runs-on como uma string ou uma lista:

# Plataforma única
runs-on: macos

# Múltiplas plataformas em um único block (os mesmos comandos são executados em cada uma)
runs-on: [default, macos]

A sintaxe de lista executa comandos idênticos em todas as plataformas da lista. Use-a apenas quando os comandos forem de fato multiplataforma (por exemplo, npm install). Para comandos específicos de cada plataforma (como apt-get no Linux ou brew no macOS), use o formato de múltiplos documentos.

Uso e custo

Atualmente, sessões no macOS consomem o mesmo uso que sessões equivalentes no Linux, sem sobretaxa para macOS.

Este é um preço promocional de lançamento e está sujeito a alterações.

Para saber como o uso é medido, consulte Uso.

O que já vem instalado

As images de sessão do macOS já vêm com o toolchain da Apple instalado, então seu blueprint não precisa baixá-lo:

Categoria	Incluído
Xcode	A versão mais recente do Xcode 26 como padrão em `/Applications/Xcode.app`, além da prerelease do Xcode 27 instalada junto (ex.: `/Applications/Xcode-27.0-RC.app`)
Simuladores	Um runtime do iOS Simulator para cada Xcode instalado (iOS 26 e iOS 27), cada um com um dispositivo iPhone pré-configurado
Ferramentas da Apple	`xcodebuild`, `xcrun`, `simctl`, Swift e o toolchain do Metal
Gerenciador de pacotes	Homebrew em `/opt/homebrew`
Linguagens	Node.js, Python, Java, Rust (além de `npm`, `yarn`, `pnpm`)
Ferramentas de CLI	`git`, `git-lfs`, `gh`, `jq`, `ripgrep`, `ffmpeg`, `wget`, `direnv`
Browser	Google Chrome

As versões mudam conforme a Apple lança novas versões e a image é atualizada. Para saber exatamente o que uma sessão tem, peça ao Devin para executar:

sw_vers
xcodebuild -version
ls -d /Applications/Xcode*.app
xcrun simctl list runtimes

Selecionando uma versão do Xcode

O Xcode padrão é aquele apontado pelo xcode-select. Para usar outra versão instalada em um único comando, defina DEVELOPER_DIR:

DEVELOPER_DIR=/Applications/Xcode-27.0-RC.app/Contents/Developer /usr/bin/xcodebuild -version

Use /usr/bin/xcodebuild (o shim que respeita DEVELOPER_DIR) em vez de um xcodebuild resolvido a partir do Contents/Developer/usr/bin de um Xcode específico no PATH, que reporta a própria versão independentemente de DEVELOPER_DIR. Ou altere o padrão para a sessão inteira:

sudo xcode-select -s /Applications/Xcode-27.0-RC.app

Inclua no seu blueprint a versão de que você precisa para que toda sessão comece com a toolchain correta.

Comportamento da sessão no macOS

Shell

As sessões no macOS usam o zsh como shell padrão. A maioria dos comandos de shell POSIX funciona sem alterações em relação aos blueprints Linux, mas atenção ao userland BSD: o sed -i exige um argumento (sed -i ''), e ferramentas GNU como gsed, gdate e greadlink vêm da fórmula coreutils do Homebrew.

Caminhos

# Caminhos no Linux
- run: cp config.json ~/.config/myapp/config.json

# Caminhos no macOS
- run: cp config.json /Users/devin/.config/myapp/config.json

Os repositórios são clonados em /Users/devin/repos/<repo-name>, e os arquivos que você importa para uma sessão são gravados em /Users/devin/.files/.

Segredos

Os segredos ficam disponíveis como variáveis de ambiente durante as sessões ($SECRET_NAME), assim como no Linux. É assim que você fornece chaves de API do App Store Connect, credenciais de assinatura ou tokens de registro privado:

maintenance:
  - name: "Configure private Swift package registry"
    run: |
      git config --global url."https://$GIT_TOKEN@github.com/".insteadOf "https://github.com/"

Para conhecer os segredos e a configuração do App Store Connect necessários para os envios ao TestFlight, veja Importar builds iOS para o TestFlight.

Sleep e wake da sessão

As sessões fazem um snapshot em disco ao entrar em sleep. Tudo o que está em disco sobrevive ao wake: ferramentas instaladas, repos clonados, caches de build, dados derivados. Processos em execução, não: servidores de desenvolvimento, simuladores e watchers precisam ser reiniciados depois que a sessão acorda.

Computer Use

O Computer Use funciona em sessões macOS: o Devin ganha um desktop macOS completo, com Chrome, mouse e teclado, podendo testar tanto apps nativos do macOS quanto web apps e gravar o que faz. O Devin usa a tecla Command para os atalhos do macOS (⌘C, ⌘V, ⌘Tab), e não a tecla Control.

iOS Simulator

O Devin pode iniciar e controlar o iOS Simulator diretamente:

open -a Simulator                  # inicia o dispositivo padrão
xcrun simctl list devices          # veja os dispositivos disponíveis
xcrun simctl boot "iPhone 17"      # inicia um dispositivo específico
xcrun simctl install booted MyApp.app
xcrun simctl launch booted com.example.MyApp

A aba iOS Simulator no workspace da sessão transmite o simulador em execução, permitindo que você acompanhe em tempo real o Devin tocando pelas telas do seu app. É o equivalente da Apple ao suporte a emulador Android.

Dicas e truques

Caches de build aquecidos

Um build frio do Xcode resulta em uma experiência de desenvolvimento abaixo do ideal, com tempos de build mais longos. Use o campo maintenance no environment.yml para preaquecer o cache.

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

Os Swift packages resolvidos, os CocoaPods e o DerivedData permanecem no snapshot, de modo que novas sessões começam a partir de um build incremental.

Acesso à rede

Builds que buscam dependências no CocoaPods, no Swift Package Manager, no Firebase ou em um registro privado precisam que esses hosts estejam acessíveis. Se a sua organização opera com uma política de rede restrita, verifique se a lista de permissões do macOS cobre os mesmos registros usados pelos seus builds no Linux. As duas são configuradas separadamente, e uma entrada ausente geralmente se manifesta como uma falha de resolução de dependências ou de TLS no meio de um build.

Executando contêineres

VMs macOS não têm virtualização de hardware aninhada, portanto o runtime de contêineres precisa recorrer à emulação por software do QEMU (TCG). O Colima detecta isso e alterna para a emulação automaticamente:

brew install colima docker qemu lima
colima start --vm-type qemu --arch aarch64 --cpu 4 --memory 8 --disk 30

A VM leva de dois a quatro minutos para ficar utilizável, e a primeira inicialização pode expirar esperando o SSH enquanto o guest emulado sobe a rede, então execute o colima start novamente se ele falhar. Depois disso, os contêineres rodam de 15 a 25x mais devagar na CPU do que nativamente, levando alguns segundos para iniciar cada um; os pulls acontecem na velocidade da rede do host. Isso é aceitável para um contêiner de linting ou empacotamento, mas sofrido para compilação. Para trabalhos que dependem muito de contêineres, use uma sessão Linux ou aponte a sessão macOS para um daemon Docker remoto.

Não instale o Xcode em um blueprint a menos que seja necessário

O Xcode é um download de vários gigabytes e a Apple exige um Apple ID para baixá-lo. Prefira as versões já disponíveis na image, selecionadas com DEVELOPER_DIR ou xcode-select. Se precisar de uma versão diferente ou de uma beta, você pode armazenar um Apple ID como segredo e fazer o blueprint baixar essa versão, ao custo de um build muito mais lento.

Limitações

Limitação	Detalhe
Docker e contêineres	Não há virtualização de hardware aninhada, portanto os contêineres rodam sob emulação por software. Veja Executando contêineres.
Dispositivos físicos	Não há passagem de USB (USB passthrough), então builds e testes rodam em simuladores, e não em iPhones ou iPads físicos.
Downloads do Xcode	Baixar outro Xcode ou runtime de simulador exige fornecer as credenciais do Apple ID e enfrentar um download demorado.
Medição de desempenho	Medições de tempo e profiling no estilo Instruments dentro de uma VM não refletem o desempenho real em dispositivos.

Solução de problemas

Os builds ficam muito mais lentos na primeira sessão após um rebuild do snapshot. O DerivedData foi reconstruído do zero. Adicione uma etapa build-for-testing ao maintenance para que o snapshot já inclua um build aquecido. O xcodebuild escolhe a toolchain errada. Verifique xcode-select -p e defina DEVELOPER_DIR explicitamente na etapa do blueprint. Um destino não é encontrado. Execute xcrun simctl list devices available para ver o que os runtimes instalados realmente oferecem e ajuste o nome e o SO em -destination de acordo. A resolução de dependências trava ou falha com um erro de TLS. Provavelmente o host não está na lista de permissões de rede da sua organização para macOS. Consulte Acesso à rede.

Introdução

Diretrizes fundamentais

Integração do Devin

Trabalhando com o Devin

Guias do produto

Integrações

Admin

Notas de versão

Suporte a macOS no Devin

Como funciona

Iniciando uma sessão no macOS

Escrevendo blueprints para macOS

Blueprint de plataforma única

Blueprint multiplataforma

O campo `runs-on`

Uso e custo

O que já vem instalado

Selecionando uma versão do Xcode

Comportamento da sessão no macOS

Shell

Caminhos

Segredos

Sleep e wake da sessão

Computer Use

iOS Simulator

Dicas e truques

Caches de build aquecidos

Acesso à rede

Executando contêineres

Não instale o Xcode em um blueprint a menos que seja necessário

Limitações

Solução de problemas

​Como funciona

​Iniciando uma sessão no macOS

​Escrevendo blueprints para macOS

​Blueprint de plataforma única

​Blueprint multiplataforma

​O campo runs-on

​Uso e custo

​O que já vem instalado

​Selecionando uma versão do Xcode

​Comportamento da sessão no macOS

​Shell

​Caminhos

​Segredos

​Sleep e wake da sessão

​Computer Use

​iOS Simulator

​Dicas e truques

​Caches de build aquecidos

​Acesso à rede

​Executando contêineres

​Não instale o Xcode em um blueprint a menos que seja necessário

​Limitações

​Solução de problemas

Como funciona

Iniciando uma sessão no macOS

Escrevendo blueprints para macOS

Blueprint de plataforma única

Blueprint multiplataforma

O campo `runs-on`

Uso e custo

O que já vem instalado

Selecionando uma versão do Xcode

Comportamento da sessão no macOS

Shell

Caminhos

Segredos

Sleep e wake da sessão

Computer Use

iOS Simulator

Dicas e truques

Caches de build aquecidos

Acesso à rede

Executando contêineres

Não instale o Xcode em um blueprint a menos que seja necessário

Limitações

Solução de problemas