Skip to main content
En este tutorial, Devin crea una pequeña app de seguimiento de hábitos con SwiftUI a partir de un repositorio vacío. Devin escribe el código, lo compila con Xcode, lo ejecuta en el simulador de iOS y abre un pull request. Tú lo ves trabajar, revisas el resultado y luego le pides que publique una compilación beta en TestFlight.
Devin creando un juego de iOS en una VM de macOS

​
Antes de empezar

  • VMs de macOS: las sesiones de Devin deben ejecutarse en macOS. Si tienes un despliegue Dedicated SaaS, pide a tu account team que habilite las VMs de macOS. Consulta Compatibilidad con macOS.
  • Un repositorio: crea un repositorio vacío (por ejemplo, habit-tracker) y dale acceso a Devin mediante tu integración con Git.
  • Desktop mode: activa Enable desktop mode en Settings > Customization para que Devin pueda interactuar con el simulador y grabar sus pruebas. Consulta Computer Use.
Las sesiones de macOS consumen el mismo uso que las sesiones de Linux. No hay recargo por macOS.

​
Paso 1: Pide a Devin que compile la app

Inicia una nueva sesión en el repositorio que elijas y elige macOS en el menú de plataformas que aparece debajo del cuadro de prompt. Xcode, el iOS Simulator y Homebrew vienen preinstalados, así que no hay nada que configurar de antemano.
En Slack, agrega el bang command !mac a tu mensaje. A través de la API, define platform: "macos" al crear una sesión.
Dale a Devin un prompt específico que cubra las funcionalidades de la app, las herramientas y cómo demostrar que funciona. Aquí tienes un ejemplo:
Un buen prompt para iOS:
  • Indica la versión de la plataforma y los frameworks, para que Devin no tenga que adivinar el destino de despliegue ni la arquitectura.
  • Indica el dispositivo del simulador, para que los comandos de compilación usen un destino que exista en la VM.
  • Describe un flujo de verificación concreto, para que Devin pruebe el comportamiento que te interesa y no se limite a comprobar que compila.

​
Paso 2: Observa a Devin compilar y probar

Devin aborda la tarea de forma muy similar a como lo haría un desarrollador de iOS:
  1. Genera la estructura del proyecto: escribe project.yml, las vistas de SwiftUI, el modelo de hábitos y el target de pruebas, y luego ejecuta xcodegen generate.
  2. Compila y corrige errores: ejecuta xcodebuild desde su shell, lee la salida del compilador y corrige los errores hasta que la compilación y las pruebas pasen.
  3. Ejecuta la app en el Simulator: arranca el dispositivo e instala y lanza la compilación:
  4. Prueba el flujo que describiste: navega por la app con Computer Use, comprueba el resultado en pantalla y graba la ejecución.
  5. Abre un pull request con el resumen y la captura de pantalla.
Abre la pestaña iOS Simulator en el workspace de la sesión para ver en directo el simulador arrancado mientras Devin navega por la app.
Si la compilación no encuentra un destino, pídele a Devin que ejecute xcrun simctl list devices available y use un dispositivo y un sistema operativo que la VM realmente tenga.

​
Paso 3: Revisar e iterar

Revisa el pull request como lo harías con cualquier otro. Verifica que la captura de pantalla y la grabación coincidan con lo que pediste. Luego continúa desarrollando en la misma sesión con prompts de seguimiento:
También puedes dejar comentarios de revisión en el pull request, y Devin responde a ellos mientras la sesión está activa. Consulta integración con GitHub y Devin Review.

​
Paso 4: Publicar una beta en TestFlight

Una vez que la app funcione en el Simulador, Devin puede archivarla, firmarla y subir la compilación a TestFlight para que los testers puedan instalarla en dispositivos reales. Esto requiere una configuración inicial única que debes hacer tú mismo. Subir compilaciones de iOS a TestFlight explica cada paso:
  1. Configura App Store Connect: acepta los acuerdos, registra el bundle ID, crea el registro de la app, crea un grupo beta y responde el cuestionario de cumplimiento de exportación.
  2. Crea una clave de API de App Store Connect y descarga su archivo .p8.
  3. Agrega los secretos de Devin: ASC_KEY_ID, ASC_ISSUER_ID, ASC_PRIVATE_KEY y APPLE_TEAM_ID.
  4. Permite el acceso de red a los servidores de Apple si tu organización usa una política de red restringida.
Usa el mismo bundle ID en project.yml y en App Store Connect. Si Devin eligió un bundle ID provisional en el Paso 1, pídele que actualice el proyecto primero.
Después, inicia una nueva sesión para que los secretos estén disponibles e indícale a Devin:
Devin escribe la clave de API en disco, archiva la app con xcodebuild archive y la sube con xcodebuild -exportArchive. Luego agrega la compilación procesada al grupo beta. Para reutilizar estos pasos sin repetirlos en cada prompt, agrega una entrada testflight a la sección knowledge del blueprint. Consulta Guardar los pasos en tu blueprint.

​
Consejos

  • Fija la cadena de herramientas: las imágenes de macOS incluyen más de una versión de Xcode. Usa DEVELOPER_DIR o xcode-select en el blueprint para elegir una. Consulta Selección de una versión de Xcode.
  • Guarda las credenciales como secretos: las claves de API de App Store Connect, los certificados de firma y los tokens de registros de paquetes privados deben ir en Secretos. Devin los lee como variables de entorno.
  • Permite los registros de paquetes: si tu organización usa una política de red restringida, asegúrate de que la lista de permitidos de macOS incluya Swift Package Manager, CocoaPods o cualquier registro privado que use tu app. Consulta Acceso a la red.
  • Reinicia el Simulador tras despertar la sesión: cuando una sesión duerme y despierta, los archivos se conservan, pero los procesos en ejecución no. Pídele a Devin que vuelva a arrancar el Simulador antes de hacer pruebas.
  • Pide evidencia: solicita capturas de pantalla o una grabación de pantallas concretas para revisar la UI sin tener que ejecutar la app tú mismo.

​
Limitaciones

  • Devin ejecuta apps en simuladores, no en iPhones o iPads físicos. Para probar en un dispositivo, instala una compilación de TestFlight.
  • Los resultados de tiempos y de profiling dentro de una VM no reflejan el rendimiento real de un dispositivo.
  • Los contenedores se ejecutan mediante emulación por software en las VM de macOS, por lo que el trabajo intensivo en contenedores es lento.
Consulta las limitaciones de la compatibilidad con macOS para más detalles.

​
Próximos pasos

Subidas a TestFlight

Configuración de App Store Connect, claves de API y secretos para subir compilaciones

Compatibilidad con macOS

Opciones de blueprint, herramientas preinstaladas y resolución de problemas en sesiones de macOS

Pruebas y grabaciones

Cómo Devin prueba tu app y registra los resultados