` |
| Shell | `bash` | `zsh` |
| Gestor de paquetes | `apt-get` | `brew` (Homebrew en `/opt/homebrew`) |
| Archivos adjuntos | `/home/ubuntu/.files/` | `/Users/devin/.files/` |
## Iniciar una sesión de macOS
Puedes elegir macOS en cada sesión:
* **Blueprint**: agrega `runs-on: macos` para que la instantánea del repo se compile para macOS (consulta más abajo).
* **Slack**: usa el [bang command](/es/integrations/slack) `!mac` para iniciar una sesión en una VM de macOS.
* **API**: establece `platform: "macos"` al crear una sesión, una programación o una automatización. Consulta la [referencia de la API](/es/api-reference/overview).
## Escribir blueprints de macOS
### Blueprint de una sola plataforma
Si tu repositorio solo está dirigido a plataformas de Apple, usa `runs-on: macos` en el nivel 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 compilar el mismo repositorio en más de una plataforma, escribe cada plataforma como un documento YAML independiente separado por `---`. Cada documento declara su propia etiqueta `runs-on`. Consulta el aviso [YAML multidocumento](/es/onboard-devin/environment/blueprints#blueprint-sections) en la guía de blueprints para obtener más contexto sobre este 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 genera una compilación de instantánea independiente para su plataforma. Las sesiones arrancan desde la instantánea correspondiente a cada plataforma.
El YAML de nivel superior debe ser un mapping, no una secuencia. Si escribes el ejemplo anterior como una única lista (`- runs-on: default` / `- runs-on: macos`), el backend lo rechazará. Usa el separador `---` que se muestra arriba.
## El campo `runs-on`
El campo `runs-on` se asigna a una configuración de máquina registrada en tu cuenta:
| Valor | Plataforma |
| ------------------- | --------------------------------- |
| `default` o `linux` | Linux (plataforma predeterminada) |
| `macos` | macOS |
| `windows` | Windows |
Puedes especificar `runs-on` como una cadena o como una lista:
```yaml theme={null}
# Una sola plataforma
runs-on: macos
# Múltiples plataformas en un mismo block (los mismos comandos se ejecutan en cada una)
runs-on: [default, macos]
```
La sintaxis de lista ejecuta los mismos comandos en todas las plataformas de la lista. Úsala solo cuando los comandos sean realmente multiplataforma (por ejemplo, `npm install`). Para comandos específicos de una plataforma (como `apt-get` en Linux o `brew` en macOS), usa mejor el [formato de múltiples documentos](#multi-platform-blueprint).
## Consumo y costo
Las sesiones de macOS consumen lo mismo que las sesiones equivalentes de Linux o Windows. No hay recargo por macOS. Para conocer los detalles sobre cómo se mide el consumo, consulta [Consumo](/es/admin/billing/usage#macos-sessions).
## Qué viene preinstalado
Las imágenes de sesión de macOS incluyen la cadena de herramientas de Apple ya instalada, así que tu blueprint no necesita descargarla:
| Categoría | Incluido |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Xcode | La última versión de Xcode 26 como predeterminada en `/Applications/Xcode.app`, además de la versión preliminar de Xcode 27 junto a ella (p. ej. `/Applications/Xcode-27.0-RC.app`) |
| Simuladores | Un runtime de iOS Simulator por cada Xcode instalado (iOS 26 e iOS 27), cada uno con un dispositivo iPhone preconfigurado |
| Herramientas de Apple | `xcodebuild`, `xcrun`, `simctl`, Swift y la cadena de herramientas de Metal |
| Gestor de paquetes | Homebrew en `/opt/homebrew` |
| Lenguajes | Node.js, Python, Java, Rust (además de `npm`, `yarn`, `pnpm`) |
| Herramientas de CLI | `git`, `git-lfs`, `gh`, `jq`, `ripgrep`, `ffmpeg`, `wget`, `direnv` |
| Navegador | Google Chrome |
Las versiones cambian a medida que Apple publica nuevas versiones y se actualiza la imagen. Para ver exactamente qué incluye una sesión, pídele a Devin que ejecute:
```bash theme={null}
sw_vers
xcodebuild -version
ls -d /Applications/Xcode*.app
xcrun simctl list runtimes
```
### Selección de una versión de Xcode
El Xcode predeterminado es aquel al que apunta `xcode-select`. Para usar otra versión instalada en un solo comando, define `DEVELOPER_DIR`:
```bash theme={null}
DEVELOPER_DIR=/Applications/Xcode-27.0-RC.app/Contents/Developer /usr/bin/xcodebuild -version
```
Usa `/usr/bin/xcodebuild` (el shim que respeta `DEVELOPER_DIR`) en lugar de un `xcodebuild` resuelto desde el directorio `Contents/Developer/usr/bin` de un Xcode específico presente en el `PATH`, ya que este informa su propia versión sin tener en cuenta `DEVELOPER_DIR`.
O cambia el valor predeterminado para toda la sesión:
```bash theme={null}
sudo xcode-select -s /Applications/Xcode-27.0-RC.app
```
Incluye en tu blueprint la que necesites para que cada sesión arranque con la cadena de herramientas correcta.
## Comportamiento de las sesiones en macOS
### Shell
Las sesiones de macOS usan **zsh** como shell predeterminado. La mayoría de los comandos de shell POSIX funcionan sin cambios respecto a los blueprints de Linux, pero ten en cuenta el userland de BSD: `sed -i` requiere un argumento (`sed -i ''`), y las herramientas GNU como `gsed`, `gdate` y `greadlink` provienen de la fórmula `coreutils` de Homebrew.
### Rutas
```yaml theme={null}
# Rutas en Linux
- run: cp config.json ~/.config/myapp/config.json
# Rutas en macOS
- run: cp config.json /Users/devin/.config/myapp/config.json
```
Los repositorios se clonan en `/Users/devin/repos/`, y los archivos que subes a una sesión se guardan en `/Users/devin/.files/`.
### Secretos
Los [secretos](/es/product-guides/secrets) están disponibles como variables de entorno durante las sesiones (`$SECRET_NAME`), igual que en Linux. Así es como se proporcionan las claves de API de App Store Connect, las credenciales de firma o los tokens de registries privados:
```yaml theme={null}
maintenance:
- name: "Configure private Swift package registry"
run: |
git config --global url."https://$GIT_TOKEN@github.com/".insteadOf "https://github.com/"
```
### Suspensión y reactivación de la sesión
Las sesiones crean una instantánea en disco cuando duermen. Todo lo que está en disco sobrevive a la reactivación: herramientas instaladas, repos clonados, cachés de compilación y datos derivados. Los procesos en ejecución no: los servidores de desarrollo, los simuladores y los watchers deben reiniciarse cuando la sesión se reactiva.
### Computer Use
[Computer Use](/es/work-with-devin/computer-use) funciona en sesiones de macOS: Devin dispone de un escritorio completo de macOS con Chrome, ratón y teclado, puede probar tanto aplicaciones nativas de macOS como aplicaciones web y [grabar](/es/work-with-devin/testing-and-recordings) lo que hace. Devin usa la tecla Command para los atajos de macOS (⌘C, ⌘V, ⌘Tab) en lugar de Control.
### iOS Simulator
Devin puede iniciar y controlar directamente el iOS Simulator:
```bash theme={null}
open -a Simulator # arranca el dispositivo predeterminado
xcrun simctl list devices # ver los dispositivos disponibles
xcrun simctl boot "iPhone 17" # arranca un dispositivo específico
xcrun simctl install booted MyApp.app
xcrun simctl launch booted com.example.MyApp
```
La pestaña **iOS Simulator** del workspace de la sesión transmite el simulador en ejecución, para que puedas ver a Devin interactuar con tu app en tiempo real. Es el equivalente de Apple a la [compatibilidad con el emulador de Android](/es/onboard-devin/environment/android-emulation).
## Consejos y trucos
### Cachés de compilación precalentadas
Una compilación en frío de Xcode ofrece una experiencia de desarrollo poco óptima, con tiempos de compilación más largos. Usa el campo `maintenance` de `environment.yml` para precalentar la caché.
```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
```
Los Swift packages resueltos, los CocoaPods y DerivedData se conservan en la instantánea, de modo que las nuevas sesiones parten de una compilación incremental.
### Acceso a la red
Las compilaciones que descargan desde CocoaPods, Swift Package Manager, Firebase o un registry privado necesitan que esos hosts sean accesibles. Si tu organización opera con una política de red restringida, asegúrate de que la allowlist de macOS incluya los mismos registries que usan tus compilaciones de Linux. Ambas se configuran por separado, y la falta de una entry suele manifestarse como un fallo de resolución de dependencias o de TLS a mitad de una compilación.
### Ejecución de contenedores
Las VM de macOS no cuentan con virtualización de hardware anidada, por lo que un runtime de contenedores tiene que recurrir a la emulación por software de QEMU (TCG). Colima detecta esto y cambia a emulación automáticamente:
```bash theme={null}
brew install colima docker qemu lima
colima start --vm-type qemu --arch aarch64 --cpu 4 --memory 8 --disk 30
```
La máquina virtual tarda entre dos y cuatro minutos en estar operativa, y el primer arranque puede agotar el tiempo de espera de SSH mientras el sistema invitado emulado levanta la red, así que vuelve a ejecutar `colima start` si falla. Después, los contenedores se ejecutan en CPU entre 15 y 25 veces más lento que de forma nativa, con unos segundos de arranque cada uno; las descargas van a la velocidad de la red del host. Es aceptable para un contenedor de linting o de empaquetado, pero desesperante para compilar. Para trabajos con mucha carga de contenedores, usa una sesión de Linux o apunta la sesión de macOS a un demonio de Docker remoto.
### No instales Xcode en un blueprint a menos que sea imprescindible
Xcode es una descarga de varios gigabytes y Apple exige un Apple ID para obtenerlo. Es preferible usar las versiones ya incluidas en la imagen, seleccionadas con `DEVELOPER_DIR` o `xcode-select`. Si necesitas una versión distinta o una beta, puedes almacenar un Apple ID como [secreto](/es/product-guides/secrets) y hacer que el blueprint descargue esa versión, a costa de una compilación mucho más lenta.
## Limitaciones
| Limitación | Detalle |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Docker y contenedores | No hay virtualización de hardware anidada, por lo que los contenedores se ejecutan mediante emulación por software. Consulta [Ejecutar contenedores](#running-containers). |
| Dispositivos físicos | No hay passthrough de USB, por lo que las compilaciones y las pruebas se ejecutan en simuladores, no en iPhones o iPads físicos. |
| Descargas de Xcode | Obtener otro Xcode u otro runtime de simulador exige proporcionar las credenciales del Apple ID y una descarga prolongada. |
| Medición del rendimiento | La medición de tiempos y el perfilado al estilo de Instruments dentro de una VM no reflejan el rendimiento real de un dispositivo. |
## Solución de problemas
**Las compilaciones son mucho más lentas en la primera sesión tras reconstruir una instantánea.** DerivedData se reconstruyó desde cero. Agrega un paso `build-for-testing` a `maintenance` para que la instantánea conserve una compilación ya calentada.
**`xcodebuild` elige la cadena de herramientas incorrecta.** Revisa `xcode-select -p` y define `DEVELOPER_DIR` de forma explícita en el paso del blueprint.
**No se encuentra un destino.** Ejecuta `xcrun simctl list devices available` para ver qué ofrecen realmente los runtimes instalados y haz coincidir con ello el nombre y el sistema operativo de `-destination`.
**La resolución de dependencias se queda bloqueada o falla con un error de TLS.** Lo más probable es que el host no esté en la lista de permitidos de red de tu organización para macOS. Consulta [Acceso a la red](#network-access).