Le workflow iOS avec Claude Code : de l'idée à TestFlight

Structurer son workflow autour de l'IA

Développer des applications iOS procure une satisfaction particulière. Le rendu natif, les frameworks Apple, le moment où une fonctionnalité arrive sur l'App Store... rien ne remplace ça.

Mais en intégrant l'IA dans mon processus de travail, un constat s'est rapidement imposé : disposer d'un LLM capable de générer du code, c'est une chose. Avoir un workflow structuré autour de cet outil, c'en est une autre.

Pendant des semaines, j'ai cherché le bon équilibre. Comment maintenir un code propre tout en accélérant ? Comment garder le contrôle sur l'architecture ? Comment éviter que l'IA fasse n'importe quoi dans un codebase en production ?

Voici le système que j'ai bâti. Ce n'est pas un tutoriel théorique : c'est ce que je fais quotidiennement sur Keepio, mon application iOS de productivité avec de vrais utilisateurs.

Isoler chaque tâche avec les worktrees

Chaque fonctionnalité, correction ou refactoring commence de la même façon : un git worktree.

git worktree add ../keepio-ma-feature feature/ma-feature

Un worktree crée une copie de travail séparée du dépôt, sur sa propre branche. Pendant que je travaille sur une fonctionnalité, la branche main reste intacte. Si l'expérimentation tourne mal, il suffit de supprimer le worktree comme si rien ne s'était passé.

Mon principe : une branche, une responsabilité. Feature, fix, refactoring : chaque branche a un seul objectif. C'est propre, isolé, et cela simplifie considérablement les revues de code.

Quand j'ouvre Claude Code dans ce worktree, il se retrouve automatiquement dans le bon contexte et ne voit que les fichiers de cette branche.

Réfléchir avant d'écrire du code

Avant la moindre ligne de code, je discute avec Claude. Comme je le ferais avec un collègue.

Je lui expose ce que je veux accomplir, le contexte fonctionnel, les contraintes. Il passe en plan mode : il explore le code existant, analyse l'architecture, et propose une approche.

Ce n'est pas lui qui décide. Il propose, je valide. Parfois je suis d'accord, parfois je le réoriente. L'essentiel est d'être aligné avant de toucher au code.

Ce qui rend cela possible, c'est le fichier CLAUDE.md à la racine du projet. C'est le document d'onboarding de Claude : toute l'architecture, les patterns, les conventions de nommage, les règles du projet. Sans ce fichier, il code "à l'aveugle". Avec, il respecte mes conventions.

Mon CLAUDE.md contient :

• Les commandes build/test/lint
• L'architecture du projet (namespaces, patterns ViewModel, flux de données)
• Les modèles de données SwiftData
• Le template strict pour chaque fichier View
• Les règles de navigation et de premium gating

C'est l'investissement le plus rentable que j'aie fait. Une heure d'écriture qui fait économiser des jours de corrections.

Le pair programming en pratique

C'est là que ça devient intéressant. Claude écrit le code, et je lis tout en temps réel.

Ce n'est pas du "génère-moi tout et je copie-colle". C'est du pair programming. Je suis présente, j'observe, j'interviens quand nécessaire. Quand il propose quelque chose qui ne colle pas avec l'architecture de Keepio, je le corrige sur-le-champ. Il comprend et s'adapte pour la suite.

L'expertise métier, c'est moi qui la détiens. Claude apporte la vitesse d'exécution. Cette combinaison est ce qui fait fonctionner le workflow.

J'ai également développé des plugins iOS spécialisés pour Claude Code : analyse d'architecture, sécurité, performance. Ils permettent de valider l'approche avant même de commencer à coder.

Tester rigoureusement

Le code est là. Avant tout commit, on teste.

D'abord, je demande à Claude de générer une checklist de tests manuels : tout ce qui doit être vérifié dans le simulateur. Pourquoi manuels ? Parce que Claude ne peut pas lancer le simulateur. Tout ce qui relève du visuel, des interactions et des cas limites UX, c'est moi qui vérifie.

Puis on itère jusqu'à obtenir la fonctionnalité telle qu'elle avait été imaginée.

Commit, SwiftLint et Push

Le moment favori : le commit.

git commit -m "feat: ma nouvelle feature"

Le pre-commit hook se déclenche alors. C'est un script qui lance SwiftLint automatiquement sur tous les fichiers stagés. Si SwiftLint détecte des violations, le commit est refusé. Point final.

Même Claude se fait recaler par le pipeline. Aucun passe-droit.

Le script est simple mais efficace : il récupère les fichiers .swift stagés (en excluant les fichiers supprimés) et lance swiftlint lint --strict sur chacun. Une seule violation et exit 1 : le commit ne passe pas.

Ensuite, git push et la fonctionnalité est sur GitHub, prête pour la revue.

Vue d'ensemble du workflow

Worktree isolé -> Réflexion avec Claude -> Pair programming -> Tests -> SwiftLint -> Push

Même sans CI complète à ce stade, le workflow est déjà robuste. Le worktree isole la fonctionnalité. Le plan mode structure la réflexion. Le code est revu en temps réel. Les tests sont là. Et le pré-commit hook interdit de livrer du code non conforme.