L'outil manquant à mon workflow iOS x Claude Code

Le chaînon manquant

Mon pipeline de développement iOS fonctionnait bien jusqu'à un certain point. Je codais avec Claude Code, testais, SwiftLint validait en pré-commit, et je poussais sur GitHub. Jusque-là, tout était fluide. Mais ensuite ? C'est moi qui lançais manuellement le build dans Xcode, archivais le projet, uploadais sur App Store Connect, puis attendais le processing pour TestFlight. Chaque fois, à la main.

Dans un précédent article, j'avais reconnu que mon pipeline s'arrêtait au git push. Aujourd'hui, je complète le tableau. Voici comment j'ai mis en place Xcode Cloud sur Keepio pour automatiser toute la suite.

Tout ce qu'on fait manuellement après un push

Quand on pousse du code sur GitHub, il ne se passe... rien. C'est au développeur de :

1. Ouvrir Xcode
2. Lancer un build pour vérifier la compilation
3. Archiver le projet
4. Uploader vers App Store Connect
5. Attendre le processing
6. Vérifier la disponibilité sur TestFlight

C'est répétitif, sujet aux erreurs, et c'est du temps gaspillé, surtout quand on est développeur solo. La solution : tout automatiser. On pousse, le reste se fait tout seul. Si quelque chose casse, on reçoit une alerte.

Créer le workflow Xcode Cloud

La configuration se fait directement dans Xcode via Integrate > Xcode Cloud > Create Workflow. L'IDE détecte automatiquement le projet et le dépôt GitHub. L'assistant guide à travers :

1. Sélection du produit : l'application cible (Keepio ici), plateforme iOS
2. Connexion du dépôt : Xcode Cloud demande l'accès GitHub, on autorise et c'est lié
3. Connexion App Store Connect : nécessaire pour le déploiement TestFlight

Point important : Xcode Cloud utilise la version de Xcode sélectionnée dans le workflow. Avec plusieurs versions installées (par exemple 26.2 et 26.3), il faut s'assurer d'ouvrir la bonne. Le menu "Manage Workflows" n'apparaît que dans la version liée au workflow, un piège qui m'a coûté du temps.

Configurer le déclencheur

Le déclencheur définit le "quand". Pour Keepio, j'ai choisi un build à chaque changement sur la branche main. Dès qu'une PR est mergée ou qu'un push arrive sur main, Xcode Cloud se lance automatiquement.

D'autres options sont disponibles : build sur Pull Request (pour valider avant le merge), sur tag (pour les releases), programmé, ou manuel.

Définir les actions

Les actions définissent le "quoi". La configuration initiale comprend :

• Build : vérifier que le projet compile
• Archive : préparer le binaire pour distribution
• Notify : recevoir un email en cas de succès ou d'échec

Les Post Actions sont particulièrement puissantes : on peut envoyer automatiquement le build sur TestFlight Internal ou External Testing après un build réussi. Les testeurs reçoivent la nouvelle version sans intervention manuelle.

Les scripts CI personnalisés

Xcode Cloud permet d'exécuter des scripts custom à des moments précis du build. Il suffit de créer un dossier ci_scripts/ à la racine du projet. Xcode Cloud le détecte automatiquement, et les noms des scripts déterminent quand ils s'exécutent.

L'avantage majeur : ces scripts sont versionnés dans le dépôt. Pas de configuration cachée sur un serveur. Toute l'équipe (ou soi-même dans six mois) peut comprendre exactement ce que fait la CI.

Branch protection sur GitHub

Dernière pièce du puzzle : empêcher tout merge de code qui casse le build. Sur GitHub, dans Settings > Branches > Add rule sur la branche main, l'option clé est Require status checks to pass before merging, en sélectionnant le check Xcode Cloud.

Concrètement, si le build est rouge, le merge est bloqué. Le pré-commit hook local empêche de commiter du code non conforme, la branch protection empêche de merger du code qui ne compile pas. Double sécurité.

Retours d'expérience

Quelques problèmes rencontrés en pratique :

• Ouvrir le bon Xcode : avec plusieurs versions, le menu "Manage Workflows" n'apparaît que dans la version liée au workflow
• Commits terminal vs Xcode : les commits faits depuis le terminal ne déclenchent pas toujours Xcode Cloud immédiatement, contrairement à ceux faits depuis Xcode
• Premiers builds en échec : c'est normal. SwiftLint en mode strict sur l'ensemble du projet va probablement trouver des choses. C'est le système qui fonctionne comme prévu.

Le pipeline complet

Worktree isolé
  → Plan mode (réflexion)
    → Pair programming (code)
      → Tests (manuels + auto)
        → Pré-commit SwiftLint (local)
          → Push sur GitHub
            → Xcode Cloud (build + SwiftLint CI)
              → TestFlight (automatique)

De l'idée au déploiement, chaque étape est automatisée. Chaque maillon possède son filet de sécurité. Et si quelque chose casse, c'est détecté avant d'atteindre les utilisateurs.