> ## Documentation Index > Fetch the complete documentation index at: https://docs.devin.ai/llms.txt > Use this file to discover all available pages before exploring further. # Suporte a macOS no Devin > Execute o Devin em VMs macOS com Xcode e o iOS Simulator para compilar, executar e testar apps das plataformas Apple. O Devin agora tem acesso a máquinas virtuais macOS. Isso significa que ele já pode compilar e testar aplicativos iOS e macOS. 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](/pt-BR/onboard-devin/environment/blueprints) 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/` | `/Users/devin/repos/` | | 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](/pt-BR/integrations/slack) `!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](/pt-BR/api-reference/overview).
## 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: ```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 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](/pt-BR/onboard-devin/environment/blueprints#blueprint-sections) no guia de blueprints para mais informações sobre esse formato. ```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 ``` 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: ```yaml theme={null} # 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](#multi-platform-blueprint).
## Uso e custo
Sessões no macOS consomem o mesmo uso que sessões equivalentes no Linux ou no Windows. Não há sobretaxa para macOS. Para saber como o uso é medido, consulte [Uso](/pt-BR/admin/billing/usage#macos-sessions).
## 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: ```bash theme={null} 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`: ```bash theme={null} 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: ```bash theme={null} 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
```yaml theme={null} # 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/`, e os arquivos que você importa para uma sessão são gravados em `/Users/devin/.files/`.
### Segredos
Os [segredos](/pt-BR/product-guides/secrets) 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: ```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 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](/pt-BR/work-with-devin/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](/pt-BR/work-with-devin/testing-and-recordings) 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: ```bash theme={null} 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](/pt-BR/onboard-devin/environment/android-emulation).
## 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. ```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 ``` 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: ```bash theme={null} 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](/pt-BR/product-guides/secrets) 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](#running-containers). | | 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](#network-access).