GitHub Actions macOS 26 Runner : arm64 ou Intel ? 2026

Le travail GitHub Actions échoue sur un outil ou une dépendance qui ne se comporte pas pareil selon l’architecture du Mac ?

Pour un nouveau projet et les compilations Apple Silicon courantes, essayez d’abord macos-26 ; retenez macos-26-intel si vous devez réellement construire, tester ou diagnostiquer un cas Intel.

Cet article s’adresse aux développeurs indépendants qui configurent leur intégration continue iOS ou macOS, aux équipes Apple qui doivent vérifier la prise en charge d’Intel, et aux responsables CI qui fixent les labels par défaut et les exceptions. Si vous devez décider quels travaux tester sur chaque architecture et comment le prouver avant publication, les critères ci-dessous sont conçus pour ce choix.

Mise à jour le 2 novembre 2026. Les disponibilités et correspondances de labels sont vérifiées à partir de la documentation GitHub sur le choix d’un runner, de l’annonce de disponibilité générale de macOS 26 et de l’annonce de l’image Xcode 27. Vérifiez de nouveau ces sources au moment de publier : les images, les labels disponibles et leur portée peuvent évoluer.

SECTION 01Développeurs indépendants : partir du livrable attendu

Si vous maintenez seul une application, choisissez le runner en fonction de ce que vous devez livrer et de ce que votre pipeline doit prouver, plutôt qu’en fonction d’une préférence générale pour une famille de processeurs. Pour une application iOS dont les outils et les dépendances tournent correctement sur Apple Silicon, macos-26 constitue un premier candidat à essayer. Cette recommandation ne signifie pas que tous les projets, scripts ou outils sont compatibles d’emblée.

Avant de modifier votre flux principal, reproduisez le travail avec le dépôt, les réglages de compilation et les étapes de test réellement utilisés. Une compilation isolée peut réussir alors que l’étape de signature, un outil de génération ou un test d’intégration échoue ensuite. Le label sélectionne un hôte d’exécution ; il ne résume pas à lui seul toutes les architectures produites ou couvertes par le projet.

Le tableau ci-dessous sépare les décisions que l’on confond souvent. GitHub documente la correspondance entre les labels et l’architecture des runners ; confirmez-la au moment de votre essai, car la disponibilité annoncée peut changer.

Une décision par conditions

• Si le livrable principal vise Apple Silicon, que les dépendances et les actions du flux fonctionnent sur arm64, et que votre engagement produit ne demande pas de validation Intel, choisissez macos-26 comme premier runner à tester.
• Si vous devez assurer un comportement Intel, reproduire un défaut Intel ou construire une version destinée à cette architecture, affectez ce travail à macos-26-intel et conservez une preuve spécifique à ce travail.
• Si vous prenez en charge les deux architectures, séparez compilation et tests dans une matrice plutôt que de supposer qu’un résultat obtenu sur une seule machine vaut pour l’autre.
• Si l’écart entre les runners vient d’une dépendance encore non vérifiée, bloquez le changement de label par défaut, isolez la dépendance et consignez les erreurs observées avant de décider.
• Si votre besoin porte surtout sur un environnement Mac durable et administrable, comparez un Mac distant après avoir validé les runners hébergés ; le seul choix entre deux labels ne justifie pas une migration.

SECTION 02Équipes Apple Silicon : vérifier la chaîne complète

Le label macos-26 désigne un runner arm64 selon les informations publiées par GitHub pour ses runners macOS hébergés. C’est une information sur la machine qui exécute le travail. Elle ne prouve pas, à elle seule, que votre application est exclusivement arm64, qu’elle produit toutes les variantes demandées ou que chacun de ses tests couvre la cible de livraison.

Pour éviter cette confusion, consignez séparément trois éléments dans votre procédure de validation :

• L’architecture de l’hôte : la machine qui exécute le travail CI, déterminée par le label sélectionné.
• Les architectures de compilation visées : les réglages, destinations et paramètres que vous donnez aux outils de construction.
• La preuve produite : l’artefact examiné, les tests exécutés et les plateformes dont le résultat est effectivement vérifié.

Cette séparation importe si vous distribuez un binaire universel pour macOS. Apple explique dans son guide de construction d’un binaire macOS universel comment réunir les architectures prises en charge dans un même binaire. Ne déduisez donc pas la composition de l’artefact à partir du seul processeur de l’hôte : contrôlez le résultat construit et, si nécessaire, son contenu avec les outils adaptés à votre pipeline.

Pour une équipe qui travaille sur iOS, la cible de livraison et les environnements de test doivent aussi être vérifiés indépendamment du label. Une compilation réussie démontre que les étapes exécutées ont abouti dans ces conditions ; elle ne démontre pas que vous avez testé chaque architecture, chaque appareil ou chaque configuration pertinente. Le bon choix peut être un runner arm64 par défaut et un travail Intel ciblé, mais ce partage doit correspondre à une exigence réelle de prise en charge.

SECTION 03Équipes avec dépendances anciennes : rendre les incompatibilités visibles

Un projet peut dépendre de bibliothèques binaires, d’outils de génération, de scripts de compilation ou d’actions tierces qui ont leurs propres contraintes. Si l’un de ces composants n’existe que pour Intel, ou si son comportement sur arm64 n’est pas vérifié, le passage direct à un runner arm64 risque de transformer un choix d’architecture en incident difficile à diagnostiquer.

Inventoriez les dépendances à partir du flux réel, pas uniquement du fichier manifeste principal. Incluez les outils appelés indirectement par les scripts, les binaires récupérés pendant le travail, les étapes de signature et les actions réutilisées. Pour chacune, notez l’origine du composant, la version utilisée dans votre configuration, l’architecture disponible et l’étape où son fonctionnement est vérifié. Si vous ne pouvez pas établir sa prise en charge sur arm64, traitez-la comme une hypothèse à tester plutôt que comme une incompatibilité déjà prouvée.

En cas d’échec, consignez le message exact, l’étape fautive et l’architecture du runner. Un binaire introuvable, un processus qui refuse de démarrer et un test qui échoue après compilation n’indiquent pas nécessairement le même problème. La documentation Apple sur la résolution des erreurs de compilation pour Apple Silicon peut aider à distinguer les erreurs de construction liées à l’architecture des autres causes.

Un échec sur arm64 ne suffit pas à conclure qu’un projet doit rester sur Intel. Reproduisez-le sur l’autre runner, identifiez la dépendance ou l’étape fautive, puis limitez l’exception au travail qui en a besoin.

Si un composant ne fonctionne aujourd’hui que sur Intel, conservez un travail Intel clairement nommé et documentez son propriétaire, son motif et les conditions qui permettraient de le retirer. Évitez de faire tourner tout le pipeline sur Intel simplement parce qu’une seule étape ancienne le requiert : vous rendriez moins visible la compatibilité arm64 du reste du produit et compliqueriez la réévaluation de la dépendance.

SECTION 04Équipes qui doivent conserver Intel : distinguer compilation et validation

La présence de clients Intel dans votre base installée ne signifie pas automatiquement que chaque travail CI doit s’exécuter sur un runner Intel. Vous devez d’abord traduire la promesse produit en contrôles : faut-il construire un artefact Intel, lancer des tests sur cette architecture, ou reproduire un problème signalé par un utilisateur ? Ces objectifs sont différents et peuvent conduire à des travaux distincts.

Si votre produit distribue un binaire universel, vérifiez l’artefact lui-même et associez une preuve à chaque architecture prise en charge. Si vous ne produisez qu’une cible particulière, assurez-vous que ce choix correspond bien à votre politique de livraison. Dans les deux cas, une compilation sur arm64 ne permet pas d’affirmer qu’un chemin d’exécution Intel a été testé. Inversement, un runner Intel ne prouve pas que l’artefact livré contient les variantes attendues.

Réservez macos-26-intel aux contrôles dont le résultat répond à une exigence explicite : compatibilité revendiquée, test significatif ou reproduction de défaut. Dans le nom du travail et dans ses résultats, indiquez ce qu’il vérifie réellement. Une tâche appelée « compatibilité Intel » qui se contente de compiler une cible différente, sans tester le comportement visé, peut donner une fausse assurance aux équipes de publication.

SECTION 05Équipes Xcode et publication : séparer image, signature et architecture

GitHub a annoncé la disponibilité générale de son image contenant Xcode 27 le 15 octobre 2026 dans son avis sur l’image du runner. Apple publie les changements et détails de cette version dans les notes de version de Xcode 27. Ces références établissent l’existence de l’image et des informations de version ; elles ne remplacent pas l’essai de votre propre projet sur le label choisi.

Pour votre flux de publication, vérifiez distinctement la sélection de l’image Xcode, les réglages de compilation, le processus de signature et les tests. Les exigences d’installation et de compatibilité de l’outil doivent être contrôlées dans les prérequis système publiés par Apple pour Xcode. Ne concluez pas qu’une contrainte de signature ou d’enregistrement d’un appareil s’applique à tous les runners uniquement parce qu’elle est apparue dans un flux particulier : établissez le lien avec l’étape concernée et le type de travail.

Enfin, examinez le type de runner utilisé et ses limites propres. GitHub documente les capacités et restrictions des runners de plus grande taille. Consultez cette page si votre choix porte aussi sur les ressources, l’accès ou le mode de fonctionnement. Ne supposez pas qu’une différence de label d’architecture entraîne automatiquement une différence de capacité ou de comportement de signature.

Validation reproductible avant le changement

Pour tester macos-26, macos-26-intel ou une image Xcode 27, appliquez une procédure qui préserve un retour arrière :

• Figer le point de départ. Notez le commit, le workflow, le label actuellement utilisé, l’image Xcode sélectionnée et les dépendances résolues. Sans ce relevé, une différence de résultat peut provenir d’un changement de code plutôt que de l’architecture.
• Créer un travail d’essai isolé. Ajoutez un travail qui utilise le label candidat sans remplacer immédiatement le travail de publication. Gardez les étapes pertinentes identiques afin que la comparaison porte sur le runner, et non sur deux procédures différentes.
• Exécuter le chemin réel. Lancez les commandes de construction, les tests, les scripts de génération et les étapes de signature nécessaires à votre projet. Un exemple minimal confirme une partie de la chaîne, pas le pipeline complet.
• Examiner l’artefact et les journaux. Vérifiez les architectures attendues dans le produit livré, puis conservez les journaux qui identifient le runner et les versions d’outils. Séparez les échecs de compilation des erreurs de test, de signature ou d’accès.
• Comparer le travail d’architecture opposée lorsque c’est requis. Si votre engagement couvre Intel et arm64, ajoutez le second travail et comparez les preuves pour chaque cible ; ne remplacez pas cette validation par une simple compilation sur l’architecture par défaut.
• Décider et assigner la revue. Documentez le label par défaut, les exceptions, la raison de chacune et la personne chargée de réexaminer les dépendances ou les exigences produit. Recommencez cette vérification lorsque GitHub modifie les images disponibles ou lorsque votre chaîne d’outils évolue.

Cette méthode transforme le choix d’un label en décision auditable. Elle évite aussi de confondre un succès ponctuel avec une garantie de compatibilité, particulièrement lorsqu’une équipe prend en charge plusieurs types de livrables ou conserve des outils historiques.

SECTION 06Responsables CI : organiser les travaux et les exceptions

Pour un responsable de plateforme, le choix n’est pas seulement « arm64 ou Intel ». Il faut définir un comportement par défaut compréhensible, isoler les exceptions, rendre les résultats comparables et maintenir les workflows lorsque les images évoluent. Une matrice est appropriée quand les deux architectures font partie des critères d’acceptation ; elle est inutile si elle duplique des travaux sans vérifier une exigence distincte.

Définissez la responsabilité de chaque tâche : qui confirme les architectures livrées, qui maintient les dépendances et qui valide les changements de label. Pour les exceptions Intel, exigez un motif mesurable au niveau du travail — par exemple un test dédié ou une reproduction documentée — et une revue lors de la suppression ou du remplacement de la dépendance. Cette règle empêche qu’un choix temporaire devienne la configuration permanente par oubli.

Les runners hébergés sont adaptés lorsque les tâches correspondent à leur mode d’exécution et que leur environnement répond aux besoins du flux. Un Mac distant peut être pertinent si votre travail nécessite un environnement Mac maintenu dans la durée, un contrôle direct de l’hôte ou une organisation opérationnelle différente. Il ne remplace pas automatiquement les runners GitHub : vous devez aussi prévoir l’accès, la maintenance, la disponibilité et la gestion des secrets. Pour cadrer ce choix, consultez la présentation des environnements Mac proposés par MACNOX et examinez les options de location MACNOX uniquement si ces conditions correspondent à votre exploitation.

Pour une tâche CI éphémère, sans besoin de persistance ni de contrôle particulier de l’hôte, ajouter un Mac dédié peut créer de la maintenance sans résoudre de problème d’architecture. À l’inverse, si un environnement doit rester accessible pour des tâches récurrentes ou des essais manuels, le cycle de vie d’un runner hébergé peut ne pas correspondre à vos exigences. Évaluez le mode d’exploitation à partir des besoins constatés, pas du seul fait que macos-26 et macos-26-intel ne ciblent pas la même architecture.

SECTION 07FAQ sur le choix des runners macOS 26

Quelle différence pratique existe entre les runners arm64 et Intel ?

Le label choisi détermine l’architecture du runner, pas nécessairement celle de l’application construite. macos-26 correspond au runner arm64 et macos-26-intel au runner Intel selon la documentation GitHub sur les labels. Vérifiez aussi les architectures de compilation, le contenu de l’artefact et les tests : ce sont ces éléments qui prouvent la couverture de votre produit.

Quel label employer pour une intégration continue iOS ?

Essayez macos-26 si vos outils, vos dépendances et les tests requis fonctionnent sur arm64 et si votre politique ne demande pas de validation Intel. Employez macos-26-intel pour un contrôle qui doit réellement s’exécuter sur Intel. Si votre application doit prendre en charge les deux architectures, rendez cette couverture explicite dans des travaux distincts et examinez les résultats de chacun.

Dans quels cas garder un travail macOS 26 Intel ?

Gardez-le pour valider un livrable Intel, exécuter un test qui dépend de cette architecture ou reproduire un défaut qui n’apparaît que sur Intel. Un composant ancien peut aussi justifier temporairement une tâche dédiée si son incompatibilité avec arm64 est confirmée. Documentez le motif et évitez d’imposer le runner Intel aux tâches qui n’en dépendent pas.

Quel runner associer à Xcode 27 ?

Choisissez selon l’architecture que vous devez tester et les composants de votre projet, puis vérifiez que l’image Xcode souhaitée est disponible pour le label retenu. L’annonce de GitHub sur l’image Xcode 27 et les notes de version d’Apple ne démontrent pas la compatibilité de votre dépôt : exécutez les étapes réelles de compilation, de test et de publication avant de changer le flux stable.

SECTION 08Décision de mise en production

Pour la plupart des nouveaux flux destinés à Apple Silicon, démarrez l’évaluation sur macos-26, puis ajoutez un travail macos-26-intel uniquement lorsqu’une exigence de produit, une dépendance vérifiée ou un test le justifie. Les runners hébergés conviennent moins bien si vous avez besoin d’un hôte durable et contrôlé, d’un environnement conservé entre les travaux ou d’une exploitation spécifique ; mais un Mac dédié apporte aussi des tâches de maintenance et n’est pas la réponse automatique à un problème de label.

Exécutez d’abord votre vrai projet sur les runners concernés et gardez les preuves par architecture. Si vos tâches exigent ensuite un environnement Mac persistant, avec un mode d’accès et d’exploitation distinct des travaux hébergés, comparez cette option à vos contraintes actuelles avant de migrer. Vous pouvez alors examiner une solution de location de Mac avec MACNOX comme environnement dédié, sans substituer cette décision à la validation de votre matrice CI.

SECTION 09FAQ