> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Créer une application iOS avec Devin
> Créer une application iOS avec Devin sur une VM macOS : compilation, tests et TestFlight
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.
## 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](/fr/onboard-devin/environment/macos-support).
* **Un repository** : créez un repository vide (par exemple, `habit-tracker`) et donnez-y accès à Devin via votre [Git integration](/fr/onboard-devin/environment#before-you-start).
* **Mode bureau** : activez **Enable desktop mode** dans [Settings > Customization](https://app.devin.ai/customization) afin que Devin puisse interagir avec le Simulator et enregistrer ses tests. Voir [Computer Use](/fr/work-with-devin/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](/fr/integrations/slack) `!mac` à votre message. Via l'[API](/fr/api-reference/overview), 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 :
```text theme={null}
Développe une application iOS SwiftUI nommée HabitTracker dans ce repo.
Exigences :
- Cibler iOS 17+. Utiliser SwiftUI et le framework Observation.
- Écran principal : une liste d'habitudes, chacune avec un nom, une icône
SF Symbol et un bouton de validation qui marque l'habitude comme faite pour aujourd'hui.
- Afficher la série en cours (jours consécutifs validés) à côté de chaque habitude.
- Un bouton « + » dans la barre d'outils ouvre une feuille pour ajouter une habitude. Balayer pour supprimer.
- Conserver les habitudes en mémoire pour l'instant. Pas de persistance pour le moment.
Configuration du projet :
- Installer xcodegen, swiftlint et xcbeautify avec Homebrew.
- Définir le projet dans project.yml avec XcodeGen. Commiter project.yml
et ajouter le .xcodeproj généré au .gitignore.
- Ajouter une cible de tests unitaires avec des tests XCTest pour le calcul de la série.
- Vérifier que swiftlint passe sans erreur.
Vérification :
- Compiler et exécuter les tests sur le Simulator iPhone 17.
- Installer et lancer l'application dans le Simulator. Ajouter deux habitudes, en marquer
une comme faite et en supprimer une. Enregistre l'opération et envoie-moi une capture
de l'écran principal.
- Ouvrir une PR avec un court résumé et la capture d'écran.
```
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 :
```bash theme={null}
xcrun simctl boot "iPhone 17"
xcrun simctl install booted
xcrun simctl launch booted
```
4. **Il teste le flux que vous avez décrit** : il parcourt l'application avec [Computer Use](/fr/work-with-devin/computer-use), vérifie le résultat à l'écran et [enregistre](/fr/work-with-devin/testing-and-recordings) 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 :
```text theme={null}
Rends les habitudes et l'historique de complétion persistants avec SwiftData
afin qu'ils survivent aux redémarrages de l'application. Ajoute un test qui insère
une habitude dans un container de modèle en mémoire et vérifie la série. Relance
l'application dans le Simulator pour confirmer que les habitudes persistent, puis
pousse sur la même PR.
```
```text theme={null}
Ajoute une cible de tests UI avec un XCUITest qui ajoute une habitude, la
marque comme terminée et vérifie que la série affiche 1. Exécute-le sur le
simulateur iPhone 17.
```
```text theme={null}
Prends en charge le mode sombre et Dynamic Type. Analyse l'écran principal
dans le Simulator en apparence sombre et à la plus grande taille de texte
d'accessibilité, puis envoie une capture d'écran de chacun des deux cas.
```
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](/fr/integrations/gh) et [Devin Review](/fr/work-with-devin/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](/fr/onboard-devin/environment/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 :
```text theme={null}
Archive le schéma HabitTracker et téléverse-le sur TestFlight. Utilise un numéro
de build supérieur à celui du dernier build dans App Store Connect, ajoute le build
au groupe bêta « QA », puis envoie-moi le numéro de build une fois terminé.
```
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](/fr/onboard-devin/environment/testflight#save-the-steps-in-your-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](/fr/onboard-devin/environment/macos-support#selecting-an-xcode-version).
* **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](/fr/product-guides/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](/fr/onboard-devin/environment/macos-support#network-access).
* **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](#step-4-ship-a-beta-to-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](/fr/onboard-devin/environment/macos-support#limitations) pour plus de détails.
## Étapes suivantes
Configuration d'App Store Connect, API keys et secrets pour le téléversement des builds
Options de blueprint, outils préinstallés et dépannage pour les sessions macOS
Comment Devin teste votre application et en enregistre les résultats