Skip to main content
Dans ce tutoriel, Devin crée un petit suivi d’habitudes en SwiftUI à partir d’un repository vide. Devin écrit le code, le compile avec Xcode, l’exécute dans l’iOS Simulator et ouvre une pull request. Vous le regardez travailler, vous examinez le résultat, puis vous demandez à Devin de téléverser un build bêta vers TestFlight.
Devin créant un jeu iOS sur une VM macOS

​
Avant de commencer

  • VM macOS : les sessions de Devin doivent s’exécuter sur macOS. Si vous utilisez un déploiement Dedicated SaaS, demandez à votre account team d’activer les VM macOS. Voir Prise en charge de macOS.
  • Un repository : créez un repository vide (par exemple, habit-tracker) et donnez-y accès à Devin via votre Git integration.
  • Mode bureau : activez Enable desktop mode dans Settings > Customization afin que Devin puisse interagir avec le Simulator et enregistrer ses tests. Voir Computer Use.
Les sessions macOS consomment autant que les sessions Linux. Aucun surcoût n’est appliqué pour macOS.

​
Étape 1 : demandez à Devin de développer l’application

Démarrez une nouvelle session sur le repository de votre choix et choisissez macOS dans le menu des plateformes, sous la zone de prompt. Xcode, l’iOS Simulator et Homebrew sont préinstallés : vous n’avez donc rien à configurer au préalable.
Dans Slack, ajoutez la bang command !mac à votre message. Via l’API, définissez platform: "macos" lors de la création d’une session.
Donnez à Devin un prompt spécifique couvrant les fonctionnalités de l’application, l’outillage et la manière de démontrer que tout fonctionne. Voici un exemple :
Un bon prompt iOS :
  • Précise la version de la plateforme et les frameworks, pour que Devin n’ait pas à deviner la cible de déploiement ni l’architecture.
  • Précise l’appareil du Simulator, pour que les commandes de build utilisent une destination qui existe réellement sur la VM.
  • Décrit un flux de vérification concret, pour que Devin teste le comportement qui vous intéresse au lieu de se contenter de vérifier que le code compile.

​
Étape 2 : observer Devin compiler et tester

Devin traite la tâche comme le ferait un développeur iOS :
  1. Il met en place la structure du projet : il écrit project.yml, les vues SwiftUI, le modèle d’habitude et la cible de test, puis exécute xcodegen generate.
  2. Il compile et corrige les erreurs : il lance xcodebuild depuis son shell, lit la sortie du compilateur et corrige les erreurs jusqu’à ce que le build et les tests passent.
  3. Il exécute l’application dans le Simulator : il démarre l’appareil, puis installe et lance le build :
  4. Il teste le flux que vous avez décrit : il parcourt l’application avec Computer Use, vérifie le résultat à l’écran et enregistre l’exécution.
  5. Il ouvre une pull request avec le résumé et la capture d’écran.
Ouvrez l’onglet iOS Simulator dans l’espace de travail de la session pour suivre en direct le simulateur démarré pendant que Devin parcourt l’application.
Si le build ne trouve pas de destination, demandez à Devin d’exécuter xcrun simctl list devices available et d’utiliser un appareil et un OS réellement disponibles sur la VM.

​
Étape 3 : relire et itérer

Relisez la pull request comme vous le feriez pour n’importe quelle autre. Vérifiez que la capture d’écran et l’enregistrement correspondent bien à votre demande. Poursuivez ensuite le développement dans la même session à l’aide de prompts de suivi :
Vous pouvez également laisser des commentaires de revue sur la pull request : Devin y répond tant que la session est active. Consultez l’intégration GitHub et Devin Review.

​
Step 4 : publier une bêta sur TestFlight

Une fois que l’application fonctionne dans le Simulator, Devin peut l’archiver, la signer et téléverser le build sur TestFlight afin que les testeurs puissent l’installer sur de vrais appareils. Cela nécessite une configuration ponctuelle que vous devez réaliser vous-même. Téléverser des builds iOS vers TestFlight détaille chaque étape :
  1. Configurer App Store Connect : accepter les contrats, enregistrer le bundle ID, créer la fiche de l’application, créer un groupe bêta et répondre au questionnaire de conformité à l’exportation.
  2. Créer une API key App Store Connect et télécharger son fichier .p8.
  3. Ajouter les secrets Devin : ASC_KEY_ID, ASC_ISSUER_ID, ASC_PRIVATE_KEY et APPLE_TEAM_ID.
  4. Autoriser l’accès réseau aux serveurs d’Apple si votre organisation applique une politique réseau restrictive.
Utilisez le même bundle ID dans project.yml et dans App Store Connect. Si Devin a choisi un bundle ID générique à l’étape 1, demandez-lui d’abord de mettre à jour le projet.
Démarrez ensuite une nouvelle session pour que les secrets soient disponibles, puis donnez ce prompt à Devin :
Devin écrit l’API key sur le disque, archive l’application avec xcodebuild archive, puis la téléverse avec xcodebuild -exportArchive. Il ajoute ensuite le build traité au groupe bêta. Pour réutiliser ces étapes sans les répéter dans chaque prompt, ajoutez une entrée testflight à la section knowledge du blueprint. Voir Enregistrer les étapes dans votre blueprint.

​
Conseils

  • Épingler la chaîne d’outils : les images macOS incluent plusieurs versions de Xcode. Utilisez DEVELOPER_DIR ou xcode-select dans le blueprint pour en choisir une. Voir Sélectionner une version de Xcode.
  • Stocker les credentials sous forme de secrets : les API keys App Store Connect, les certificats de signature et les tokens de registres de packages privés doivent être placés dans Secrets. Devin les lit comme des variables d’environnement.
  • Autoriser les registres de packages : si votre organisation applique une politique réseau restrictive, assurez-vous que la liste d’autorisation macOS inclut Swift Package Manager, CocoaPods ainsi que tout registre privé utilisé par votre application. Voir Accès réseau.
  • Redémarrer le Simulator après une sortie de veille : lorsqu’une session se met en veille puis en sort, les fichiers sont conservés, mais pas les processus en cours d’exécution. Demandez à Devin de relancer le Simulator avant les tests.
  • Demander des preuves : demandez des captures d’écran ou un enregistrement d’écrans spécifiques afin de vérifier l’UI sans avoir à exécuter l’application vous-même.

​
Limites

  • Devin exécute les applications sur des simulateurs, et non sur des iPhone ou iPad physiques. Pour tester sur un appareil, installez un build TestFlight.
  • Les mesures de chronométrage et de profilage réalisées dans une VM ne reflètent pas les performances réelles d’un appareil.
  • Les containers s’exécutent en émulation logicielle sur les VM macOS : les tâches qui en font un usage intensif sont donc lentes.
Consultez les limites de la prise en charge de macOS pour plus de détails.

​
Étapes suivantes

Téléversements TestFlight

Configuration d’App Store Connect, API keys et secrets pour le téléversement des builds

Prise en charge de macOS

Options de blueprint, outils préinstallés et dépannage pour les sessions macOS

Tests et enregistrements

Comment Devin teste votre application et en enregistre les résultats