Devin ya tiene acceso a máquinas virtuales de macOS, lo que significa que puede compilar y probar aplicaciones de iOS y macOS.
Si tienes un despliegue de SaaS Dedicado, comunícate con tu account team para habilitar las VMs de macOS.
runs-on de tu blueprint le indica a Devin en qué plataforma compilar y ejecutar, y cada plataforma tiene su propia instantánea.
Las principales diferencias respecto a Linux son el shell, la estructura del sistema de archivos y el gestor de paquetes:
Iniciar una sesión de macOS
- 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
!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.
Escribir blueprints de macOS
runs-on: macos en el nivel superior:
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 en la guía de blueprints para obtener más contexto sobre este formato.
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.
runs-on se asigna a una configuración de máquina registrada en tu cuenta:
Puedes especificar runs-on como una cadena o como una lista:
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. Selección de una versión de Xcode
xcode-select. Para usar otra versión instalada en un solo comando, define DEVELOPER_DIR:
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:
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
sed -i requiere un argumento (sed -i ''), y las herramientas GNU como gsed, gdate y greadlink provienen de la fórmula coreutils de Homebrew.
Los repositorios se clonan en /Users/devin/repos/<repo-name>, y los archivos que subes a una sesión se guardan en /Users/devin/.files/.
Los secretos 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:
Suspensión y reactivación de la sesión
Cachés de compilación precalentadas
maintenance de environment.yml para precalentar la caché.
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.
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
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
DEVELOPER_DIR o xcode-select. Si necesitas una versión distinta o una beta, puedes almacenar un Apple ID como secreto y hacer que el blueprint descargue esa versión, a costa de una compilación mucho más lenta.
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. 
