Ce que c'est et pourquoi ça compte
Quand Claude modifie un écran de votre app iOS, il vous dit en général « c'est fait ». Ensuite, c'est à vous : compiler, ouvrir le simulateur, aller jusqu'à cet écran et regarder. Et si ça ne va pas, vous le lui réexpliquez avec des mots.
Dans l'app de bureau de Claude pour Mac, il y a le panneau iOS Simulator : un iPhone simulé à côté du chat. Claude compile l'app, l'installe, l'ouvre, touche les boutons et lit l'écran pour vérifier sa propre modification. Vous regardez en direct, et vous pouvez toucher aussi.
La seconde moitié du guide, c'est l'astuce qu'on utilise chez STRIKT pour les posts et pour l'App Store : des écrans de démo qui s'ouvrent déjà remplis grâce à un paramètre de lancement, pour que chaque capture soit vraie et vienne du dernier commit. Le panneau est en bêta publique, uniquement dans l'app de bureau pour macOS, sur les forfaits Pro, Max, Team et Enterprise (sauf les organisations Enterprise avec la configuration HIPAA).
1. Ce qu'il vous faut
- Un Mac : le simulateur d'Apple ne tourne que sur macOS.
- Xcode avec la plateforme iOS, qui apporte les simulateurs. S'ils manquent, téléchargez-les depuis les réglages de Xcode ou avec xcodebuild -downloadPlatform iOS.
- La dernière version de l'app de bureau de Claude : Claude > Check for Updates…
- Une session locale : dans les sessions cloud ou SSH, Claude tourne sur une machine qui ne voit pas les simulateurs de votre Mac.
- Un projet qui se compile pour le simulateur iOS. N'importe quel projet qui le fait convient.
2. Lancez-le et faites-lui vérifier son propre travail
- Dans l'app de bureau, ouvrez l'onglet Code et lancez une session dans le dossier du projet.
- Demandez-lui de lancer ou de tester l'app. Le panneau s'ouvre tout seul dès que l'app démarre ; vous pouvez aussi l'ouvrir vous-même avec le bouton iOS Simulator de la barre de titre, puis Attach simulator.
- La première fois, l'app vous demande si Claude peut utiliser ce simulateur. L'accord vaut pour le piloter et en faire des captures, une fois par appareil. Compiler l'app et ouvrir un lien sur l'appareil suivent en revanche le mode d'autorisation de la session, parce que la compilation exécute les scripts du projet sur votre Mac.
L'enjeu n'est pas de voir l'app : c'est que Claude vérifie sa modification au lieu de vous dire « c'est fait » sur parole. Mettez-le dans la demande :
Déplace le bouton « Enregistrer » en bas de l'écran du profil. Ensuite, compile, lance l'app dans le simulateur, ouvre le profil, change le nom et touche « Enregistrer ». Ferme et rouvre l'app et vérifie que le nom est toujours là. Envoie-moi la capture avant et après, et dis-moi si quelque chose cloche.
Vous voulez un appareil précis ? Écrivez-le : « lance-la sur le simulateur de l'iPhone SE ». Ça sert à voir si un texte passe mal à la ligne sur un petit écran.
3. Touchez en même temps que lui
- Vous touchez et faites défiler en cliquant et en faisant glisser sur l'écran du panneau.
- Cmd+Maj+H pour l'écran d'accueil, Cmd+L pour verrouiller, Cmd+Flèche droite pour faire pivoter.
- Cmd+S enregistre une capture et Cmd+R un enregistrement de l'écran, sur le Bureau.
- Quand la mention Claude is using this device s'affiche au-dessus de l'écran, ne touchez à rien : c'est le même appareil, et vos gestes changent ce qu'il voit.
Chaque session a ses propres simulateurs, jusqu'à 4. Ceux que Claude démarre s'éteignent tout seuls quand vous quittez l'app, quand vous archivez la session ou 10 minutes après les avoir détachés du panneau.
4. L'astuce : des écrans de démo déjà remplis
Pour un post ou pour l'App Store, il faut l'écran à son meilleur moment : le classement rempli, la journée terminée. Y arriver à la main, c'est des comptes de test, du réseau, parfois la caméra, et beaucoup de gestes. Du coup, on finit avec des captures anciennes ou redessinées, qui ne sont plus la vraie app.
Voilà comment on fait : l'app contient des vues de démo qui s'ouvrent avec un argument de lancement, c'est-à-dire un mot que vous passez à l'app au démarrage, ou avec une variable d'environnement. Elles démarrent déjà remplies de données réalistes écrites dans le code, sans compte, réseau ni caméra. Ce sont les vrais écrans, avec les mêmes composants : seules les données changent.
- Une vue de démo pour chaque écran dont vous avez besoin, avec un nom clair.
- Des données fictives mais crédibles : des chiffres que l'app pourrait vraiment afficher, aucune donnée de vraies personnes. Quand on voit les noms et les chiffres de la démo dans un post, on écrit que c'est un exemple.
- Tout le code de démo dans #if DEBUG, pour qu'il ne se retrouve pas dans l'app que vous publiez.
- La langue se choisit au lancement avec -AppleLanguages "(it)" -AppleLocale it_IT : les mêmes écrans, dans chaque langue.
Les vues de démo, vous n'avez pas à les écrire vous-même. Demandez-les à Claude :
Ajoute à mon app des vues de démo pour les captures. Si l'app démarre avec l'argument -DemoScreen suivi d'un nom (par exemple today, stats, profile), elle saute la connexion et l'onboarding et ouvre directement cet écran, déjà rempli de données réalistes écrites dans le code : pas de réseau, de compte, de caméra ni de demandes d'autorisation. Utilise les mêmes composants que les vrais écrans, seules les données changent. Mets tout dans #if DEBUG. À la fin, écris dans le README la liste des vues et la commande pour les ouvrir dans le simulateur.
5. Les captures du dernier commit
Avec les vues de démo, une capture devient une commande. Claude utilise xcrun simctl, l'outil de Xcode qui pilote les simulateurs depuis le terminal :
- Mettez à jour et compilez la dernière version pour le simulateur, et notez le commit avec git log -1 --oneline : vous saurez d'où vient chaque image.
- Utilisez un simulateur réservé aux captures, pas un simulateur démarré par une autre session : xcrun simctl create avec un nom et le modèle d'iPhone, puis xcrun simctl boot.
- Une barre d'état propre : xcrun simctl status_bar <appareil> override --time 9:41 --batteryState charged --batteryLevel 100 --cellularBars 4 --wifiBars 3.
- Installez : xcrun simctl install <appareil> <chemin du fichier .app>.
- Ouvrez la vue : xcrun simctl launch --terminate-running-process <appareil> <bundle id> -DemoScreen today. Les variables d'environnement arrivent à l'app si vous les placez devant la commande avec le préfixe SIMCTL_CHILD_.
- Capturez : xcrun simctl io <appareil> screenshot today.png. Puis regardez l'image : elle doit montrer exactement ce que dit le texte du post.
Fais-moi les 6 captures pour l'App Store à partir du dernier commit. Mets à jour le dépôt, note le commit, compile pour le simulateur et crée un nouveau simulateur juste pour ça, d'un modèle dont App Store Connect accepte les dimensions. Barre d'état à 9:41 avec batterie et réseau pleins. Ensuite, ouvre une par une les vues de démo today, stats, workout, friends, profile et settings avec -DemoScreen et enregistre un PNG pour chacune dans screenshots/, avec le commit dans le nom. Vérifie que les PNG n'ont pas de transparence, regarde chaque image et dis-moi si quelque chose est vide, coupé ou dans la mauvaise langue.
Pour l'App Store, vous pouvez envoyer jusqu'à 10 captures par taille d'écran, en PNG ou JPEG, sans transparence. Les dimensions en pixels changent selon le type d'iPhone : vérifiez-les sur la page Screenshot specifications d'App Store Connect avant de choisir le simulateur. Pour les réseaux, on place la capture dans un iPhone entier aux vraies proportions ; quand le code change, il suffit de relancer la même demande.
Les erreurs les plus courantes
- Demander « corrige l'écran » sans demander de vérification dans le simulateur. Demandez toujours : relance, va jusque-là, envoie-moi la capture.
- Se connecter avec de vrais comptes dans le simulateur. Les captures que Claude fait de l'appareil sont envoyées à Anthropic et conservées avec la conversation : utilisez uniquement des données fictives.
- Laisser le code de démo hors de #if DEBUG : il se retrouve dans l'app publiée.
- Faire les captures sur un simulateur déjà utilisé par une autre session : l'état de l'app n'est pas celui que vous croyez.
- S'attendre à ce que Claude utilise votre vrai iPhone : il ne pilote que des appareils simulés. Pour le vrai téléphone, vous lancez l'app depuis Xcode et vous lui envoyez une capture.
Check-list
- Xcode avec la plateforme iOS et au moins un simulateur
- App de bureau de Claude à jour, session locale dans l'onglet Code
- Vues de démo dans #if DEBUG, une par écran
- Barre d'état à 9:41 avant les captures
- Commit noté à côté des images
- Chaque capture regardée avant de l'utiliser
Questions fréquentes
Est-ce que ça marche aussi depuis le terminal, sans l'app de bureau ?
Le panneau, non : il appartient à l'app de bureau. Depuis la ligne de commande, Claude atteint le simulateur avec computer use, c'est-à-dire en pilotant l'écran comme vous le feriez avec la souris. Les commandes xcrun simctl de la section 5, elles, marchent partout où Xcode est installé.
Est-ce que ça marche aussi avec l'iPad ?
Oui. Le panneau affiche des iPhone et des iPad simulés, les mêmes que ceux que vous gérez dans Xcode. Demandez à Claude de lancer l'app sur le simulateur dont vous avez besoin, ou choisissez-le dans le menu des appareils du panneau.
Les écrans de démo, ce n'est pas tricher ?
Non : c'est la vraie app, avec le code d'aujourd'hui. Seuls les noms et les chiffres sont inventés, c'est pour ça qu'on les veut crédibles. Tricher, c'est un écran dessiné à la main de quelque chose que l'app ne fait pas.