Pourquoi la WWDC 2026
a aggravé l'iOS CI ?

Le lundi matin 9 juin, les Slack des responsables iOS ont sonné en chœur : « l'Archive de main est passée de 11 à 34 minutes cette nuit », « macos-latest est en attente depuis 18 minutes sans démarrer », « après l'installation de la beta Xcode 26, DerivedData a disparu ». Ce n'est pas un workflow mal configuré dans un projet isolé. Chaque année, la saison WWDC provoque un séisme CI. L'édition 2026 cumule pénurie de mémoire, absence de nouveau Mac desktop et un SDK Apple Intelligence visiblement plus lourd, ce qui amplifie les secousses. Pour le contexte hardware, voir Pourquoi le M5 Mac mini était absent de la WWDC 26. Cet article répond à une seule question : pourquoi votre pipeline a soudainement ralenti, et quoi changer maintenant.

1) Les trois symptômes canoniques du ralentissement CI post-WWDC

Ouvrez vos logs Actions. Si vous cochez au moins deux des cas suivants, vous faites face à une onde de choc WWDC, non à une régression dans votre code :

• Phase bootstrap qui explose : pod install, résolution SPM et téléchargement du runtime iOS 27 Simulator consomment chacun plusieurs minutes — les runners hébergés démarrent de zéro à chaque job, c'est donc cette phase qui souffre le plus.
• Build qui repasse en compilation complète : après un saut de version majeure Xcode, le ModuleCache et le format DerivedData sont incompatibles avec l'ancienne version. La compilation incrémentale est neutralisée ; la durée xcodebuild s'approche d'un démarrage à froid.
• Files d'attente qui s'allongent : dans les 72 h suivant la WWDC, des équipes du monde entier modifient leurs workflows pour tester la beta, saturant le pool partagé de minutes macOS hébergées. Attendre en queue peut dépasser le build lui-même.

2) Xcode 26 beta : la saison forcée du vidage de cache

Apple a publié la beta Xcode 26 et le SDK iOS 27 le jour même de la WWDC. Pour un développeur local, la mise à jour signifie réindexation et quelques minutes d'attente ; pour votre infrastructure CI, cela signifie que l'intégralité de l'état disque est invalidée :

• Changement du chemin DerivedData et du format d'index — l'ancien cache n'est pas réutilisable ; la première Archive post-mise à jour est toujours une compilation complète.
• Changement de version du compilateur Swift — les binaires .swiftmodule sont incompatibles ; chaque cible recompile de zéro.
• Instabilité des lockfiles CocoaPods / SPM — certains pods ne supportent pas encore iOS 27, provoquant une résolution répétée ou un repo-update complet.
• Nouveau runtime Simulator — plusieurs gigaoctets par runtime ; les runners hébergés téléchargent à chaque job, ajoutant 5 à 15 minutes au bootstrap.

Le risque organisationnel plus profond est l'adoption de la beta sous pression : le lendemain du keynote, quelqu'un dans chaque entreprise demande « on supporte l'IA Siri ? » — et l'équipe pousse Xcode 26 sur main avant d'être prête. Un seul changement de workflow met toute la flotte CI en mode démarrage à froid. La bonne approche est la séparation des pipelines : garder la release de production fixée sur Xcode 16 stable ; n'ouvrir qu'une branche ios-27-beta ou un runner beta dédié pour le travail d'adaptation. Consultez la matrice de support Xcode.

3) Gonflement du SDK : la charge de compilation augmente, la puissance reste la même

La WWDC 26 a mis en avant Siri AI et l'extension d'Apple Intelligence (récap MacRumors WWDC 26). Pour les ingénieurs applicatifs, cela se traduit par des coûts de build concrets :

• Nouvelles dépendances de framework (App Intents, abstractions de pipeline vision/parole) — davantage de modules dans le graphe du linker.
• Vérification de concurrence Swift 6 plus stricte — le même code source demande plus de travail au compilateur.
• Asset Catalogs et ressources de localisation plus volumineux — la phase Copy Bundle Resources s'allonge visiblement.

Sur un MacBook M4 local avec un cache chaud, ces additions se ressentent comme « deux minutes de plus ». Sur un runner hébergé sans cache persistant, elles s'ajoutent à la pénalité de démarrage à froid et font basculer « lent » en « inacceptable ». Apple livre des fonctionnalités d'IA ; ce sont les développeurs dans la file d'attente CI qui en paient le coût.

4) Pas de nouveau Mac : la voie d'upgrade matériel est bloquée

Dans les cycles WWDC précédents, les équipes desktop pouvaient au moins se consoler avec « on achètera un Mac mini pour le CI après la conf ». En 2026, sans annonce matérielle, le M5 Mac mini est attendu à l'automne, et la pénurie mondiale de mémoire rend difficile l'approvisionnement en SKU 24 Go / 32 Go. Les conséquences pratiques :

• Les équipes qui espéraient « acheter pour sortir des builds lents » — décision d'achat gelée 3 à 4 mois.
• Les équipes avec des runners M2/M3 16 Go — après la mise à jour SDK, la mémoire est plus contrainte ; quand swift-frontend et le Simulator tournent en parallèle, le swap s'enclenche et les temps de build dégradent de façon non linéaire.
• Les équipes qui voulaient ajouter un deuxième runner pour plus de parallélisme — les délais de livraison hardware ne peuvent pas battre la deadline d'adaptation beta.

Ce n'est pas dire que le M4 est insuffisant — pour la grande majorité des CI iOS, M4 16 Go est largement suffisant. La clé est que la cause principale du ralentissement post-WWDC n'est pas la puissance du chip, mais le modèle d'exécution (ephemeral vs. disque persistant). Attendre le M5, c'est substituer un récit hardware à un vrai correctif d'ingénierie.

5) La « bousculade WWDC » sur les runners hébergés

Chaque juin, le pool macOS hébergé de GitHub connaît un pic de demande. La particularité de 2026 : le récit IA a attiré des équipes non iOS vers les jobs macOS — exécution de conversions Core ML, test de projets d'exemple Apple Intelligence — en compétition avec les vrais pipelines de release.

Trois faiblesses structurelles des runners hébergés sont amplifiées en saison WWDC :

Changer de label vers macos-15 ou macos-latest ne résout rien — le label change l'image OS, pas « votre DerivedData reste demain ». Dans notre analyse de vitesse GitHub Actions iOS CI, un projet Swift de complexité moyenne atteint ~28 min P50 sur runners hébergés, dont queue + bootstrap représentent souvent plus de la moitié ; une inflation de +40 % du seul bootstrap post-WWDC n'est pas rare dans nos données.

6) Avant / après WWDC : évolutions typiques de durée sur le même dépôt (échantillon)

Observations P50 de clients Nuvcloud qui n'ont pas changé leur modèle de runner, ayant uniquement migré vers Xcode 26 beta sur main — projet Swift/UIKit avec CocoaPods, scheme unique. Ce ne sont pas des SLA ; validez avec votre propre dépôt :

Sur un Mac mini M4 self-hosted, avec les jobs de production fixés sur Xcode 16 et seul le runner beta mis à jour en Xcode 26, le P50 de la ligne de production reste au niveau pré-WWDC. La ligne beta prend certes 20+ minutes en compilation complète la première semaine, mais elle ne touche pas à main. C'est là toute la valeur de la séparation des runners.

7) Quoi faire maintenant : corriger le modèle d'exécution, ne pas attendre le M5

Dans les 48 heures suivant la WWDC, priorisez ces actions :

1. Figer la version Xcode sur la release de production — coder en dur xcode-select ou DEVELOPER_DIR dans le workflow ; empêcher main de suivre automatiquement toute beta.
2. Acheminer le travail beta vers une branche + un label de runner dédiés — ex. runs-on: [self-hosted, macos, xcode26-beta], isolé du label de production ios-ci.
3. Utiliser un runner self-hosted avec disque persistant — DerivedData, Pods et caches SPM survivent d'un job à l'autre ; le deuxième build beta revient à une durée incrémentale. Voir la documentation self-hosted runners GitHub.
4. Pré-installer les runtimes Simulator une seule fois — intégrer le runtime iOS 27 dans l'image du runner ; ne plus lancer xcodebuild -downloadPlatform dans les étapes de workflow.
5. Valider avec une location journalière de 48 h — avant de s'engager sur un plan mensuel, utilisez un Mac mini cloud deux jours pour benchmarker votre build réel. Voir la comparaison TCO runner six régions pour le choix de région.

8) Questions fréquentes

Faut-il migrer vers Xcode 26 immédiatement après la WWDC ? Non. La soumission App Store requiert toujours une version stable de Xcode ; réservez la beta à l'adoption anticipée des APIs iOS 27, isolée sur un pipeline dédié.

Le M5 Mac mini à l'automne va tout résoudre ? Pas structurellement. Un nouveau chip peut raccourcir une compilation complète de 10 à 15 %, mais ne corrige pas le surcoût de démarrage à froid à chaque job. Avec la pénurie mémoire, les SKU 24 Go / 32 Go du M5 risquent d'être chers — calculez le TCO avant de vous laisser emporter par le battage du lancement.

actions/cache sur DerivedData n'est pas suffisant ? Rarement en saison WWDC. Les clés de cache sont invalidées après un saut majeur de Xcode ; et le temps réseau pour uploader/télécharger des gigaoctets de DerivedData coûte souvent plus que le bénéfice, comparé à un disque local persistant.

Que faire si la beta est instable et que tout le CI passe au rouge ? C'est attendu. Les runners beta ne doivent jamais bloquer les merges sur main — marquez le pipeline beta comme optional status check, ou schedulez-le en nightly seulement.

Qu'est-ce qui distingue la WWDC 2026 des précédentes ? Trois facteurs simultanés : gonflement SDK piloté par l'IA, absence de nouveau Mac desktop, pression sur la chaîne d'approvisionnement mémoire. Chaque facteur seul est gérable ; combinés, ils font diagnostiquer « la machine est trop lente » à tort, entraînant de mauvais achats matériels ou un gaspillage de minutes hébergées.