L’absence d’UDID fixe sur un Runner arm64 ne bloque pas, à elle seule, les compilations iOS, les tests sur simulateur ni la publication sur la boutique. Avant de changer de nœud, déterminez si votre workflow a besoin de l’identifiant du Mac hôte ou de l’UDID d’un iPhone enregistré.
Ce guide s’adresse aux responsables IT et plateforme qui choisissent des Runner GitHub Actions pour la CI macOS et iOS. Il vous aide à isoler le point de blocage, à vérifier la signature et à décider si un nœud Mac dédié est justifié.
Dernière vérification : 4 octobre 2026, d’après la documentation GitHub sur les Runner de grande taille et les documents Apple Developer sur l’enregistrement des appareils et les profils de provisionnement. Vérifiez de nouveau ces pages avant toute modification de production : les offres, libellés de Runner et règles de plateforme peuvent évoluer.
01 Commencez par identifier l’étape réellement bloquée
Un UDID fixe manquant est un problème précis, pas un diagnostic général de panne de CI. La documentation GitHub indique que les Runner macOS arm64 n’ont pas d’UUID ou d’UDID statique. Elle décrit également une option de Runner macOS Intel avec UDID fixe, sous les conditions d’offre précisées dans cette documentation. Cela ne signifie pas que tous les projets iOS doivent quitter arm64 : vous devez d’abord relier l’erreur à une étape et à une exigence Apple. Consultez les conditions et la disponibilité documentées par GitHub avant de modifier vos étiquettes de Runner ou vos workflows.
| Tâche exécutée par le workflow | L’absence d’UDID fixe du Mac est-elle automatiquement bloquante ? | Preuve à rechercher |
|---|---|---|
| Compilation iOS et génération d’une archive | Non. Vérifiez le résultat de compilation et le processus de signature employé. | Archive produite, journaux de compilation et signature vérifiée. |
| Tests sur simulateur iOS | Non. Un simulateur n’est pas un iPhone physique enregistré. | Simulateur démarré, tests exécutés et résultats conservés. |
| Signature de développement avec installation sur appareils enregistrés | À vérifier. Le profil et les appareils concernés comptent ; ne confondez pas l’UDID de l’hôte avec celui d’un appareil. | Profil utilisé, liste d’appareils et installation sur un appareil autorisé. |
| Test sur iPhone physique | Il faut un appareil réellement accessible au dispositif d’exécution, en plus des conditions d’enregistrement et de signature applicables. | Appareil connecté et reconnu, application installée, test exécuté sur celui-ci. |
| Publication d’une version destinée à la boutique | L’absence d’UDID fixe du Mac ne suffit pas à conclure à un blocage. Vérifiez le processus de signature et de téléversement retenu. | Archive signée, validation du téléversement et traitement du build dans l’espace de distribution. |
Le tableau sert à trier les incidents, pas à remplacer la configuration effective de votre pipeline. Un message d’erreur qui mentionne un profil, un certificat ou un appareil doit être lu avec les journaux de la tâche concernée. Si la compilation échoue avant la signature, changer de Runner pour obtenir un UDID stable risque de laisser intacte la cause réelle.
02 L’UDID du Mac et celui de l’iPhone désignent deux objets différents
Le Runner arm64 est un Mac qui exécute les commandes de votre workflow. Son UDID ou UUID concerne cet hôte. Un iPhone de test est un autre appareil, avec son propre identifiant. Apple décrit l’enregistrement d’un appareil dans le compte de développement et l’utilisation des appareils enregistrés dans certains chemins de développement et de distribution Ad Hoc. Cela concerne l’appareil qui exécutera l’application, pas l’identité matérielle du Mac de compilation. La procédure Apple d’enregistrement d’un appareil précise l’objet à enregistrer.
Cette distinction évite une erreur de configuration fréquente : tenter d’ajouter l’UDID du Runner Mac à une liste d’appareils iOS en croyant autoriser un iPhone. Ce ne sont pas des identifiants interchangeables. Si un profil doit autoriser l’installation sur des appareils enregistrés, vérifiez que le profil correspond bien aux appareils iOS destinataires. La documentation Apple sur les profils de développement décrit la création de ce type de profil ; la documentation sur les profils Ad Hoc porte sur un autre chemin de distribution.
Pour éviter de tirer une conclusion sur le seul nom du profil, relevez les éléments utilisés lors d’une exécution réelle : type de certificat, type de profil, identifiant d’application, destination prévue et appareil de test attendu. Ensuite, comparez ces éléments au profil téléchargé et à sa liste d’appareils. Apple documente aussi la modification, le téléchargement et la suppression des profils ; utilisez ces informations pour confirmer quel profil a effectivement été choisi par le pipeline, plutôt que de vous fier à un fichier conservé dans un ancien espace de travail. Voir la gestion des profils Apple.
03 La compilation, le simulateur et la publication ont des exigences distinctes
Une archive compilée n’est pas la preuve qu’une application a été installée sur un iPhone. Réciproquement, l’absence d’accès à un iPhone physique ne rend pas impossible une compilation ou un test sur simulateur. Votre pipeline doit exposer des résultats séparés afin que l’équipe ne transforme pas un échec de test matériel en prétendu blocage général de CI.
Pour les tests sur simulateur, consignez le simulateur choisi, l’installation de l’application et les résultats produits. Pour un test physique, exigez une preuve que l’appareil était connecté et reconnu par l’environnement, puis conservez les résultats du test correspondant. Un Runner hébergé ne doit pas être réputé capable de se connecter à un appareil simplement parce qu’il fournit macOS : confirmez la topologie et l’accès réel. Si votre test dépend d’un appareil branché à un Mac précis, il s’agit d’une exigence matérielle à valider avec le fournisseur ou sur un nœud contrôlé.
La publication sur la boutique est une autre étape. L’envoi d’un build à App Store Connect ne signifie pas qu’un appareil de test a été enregistré pour l’installation. Apple décrit la procédure de téléversement d’un build séparément des règles de profil associées au développement et à la distribution Ad Hoc. Vérifiez le flux de téléversement Apple et contrôlez le résultat de traitement du build. Ne déduisez pas d’une exigence propre à l’installation sur appareils enregistrés une interdiction générale de publier.
04 Questions à résoudre avant de modifier le Runner
L’absence d’UDID fixe bloque-t-elle la signature iOS ?
Pas par principe. Examinez la signature réellement appliquée et le profil sélectionné. Une archive destinée à une publication sur la boutique et une application destinée à être installée sur des appareils précis ne répondent pas nécessairement aux mêmes conditions. Si l’étape fautive exige explicitement un UDID stable de l’hôte, consignez ce message et vérifiez les options Runner documentées. N’attribuez pas à l’architecture arm64 un problème de certificat ou de profil sans preuve.
Quelle différence entre l’UDID du Runner Mac et celui d’un iPhone de test ?
L’identifiant du Runner concerne le Mac qui exécute le travail. Celui de l’iPhone concerne l’appareil enregistré pour recevoir ou tester l’application. Le premier ne remplace pas le second. Comparez l’identifiant de l’appareil iOS attendu avec la liste associée au profil concerné, et non avec l’identité du Runner. Cette vérification permet d’éviter de changer de nœud alors que le profil de test ne contient pas l’appareil visé.
Un Runner macOS hébergé peut-il se connecter directement à un iPhone ?
Ne le supposez pas sans preuve. Un Runner macOS hébergé peut compiler sans pour autant disposer d’un appareil physique connecté, détectable et utilisable par les tests. Exigez une trace de connexion et de reconnaissance de l’iPhone, puis une preuve d’installation et de test. Si vous ne pouvez pas obtenir ces éléments, séparez les validations sur simulateur des tests physiques et affectez ces derniers à un environnement dont l’accès matériel a été vérifié.
Quels workflows ont besoin d’un UDID Mac fixe ?
Seulement ceux dont une opération dépend explicitement d’un identifiant stable de l’hôte Mac, selon les capacités et conditions du Runner documentées par GitHub. Faites reproduire l’erreur sur le travail concerné avant de classer tout le projet comme incompatible avec arm64. Les tests sur simulateur, la compilation et la publication doivent être évalués selon leurs propres résultats, pas regroupés avec les tests nécessitant un appareil physique ou un profil lié à des appareils enregistrés.
05 Une migration de nœud exige des preuves, pas une hypothèse
Lorsque l’étape exige vraiment un UDID fixe du Mac, comparez les options de Runner documentées et leur disponibilité actuelle. GitHub décrit des conditions pour l’option Intel à UDID fixe ; lisez-les avant de compter sur elle, car une capacité documentée n’est ni une garantie de disponibilité pour votre organisation ni une solution universelle à la signature iOS. Si l’obstacle est la connexion d’un iPhone, un UDID fixe de Mac ne crée pas à lui seul cette connexion.
Un Runner auto-hébergé peut donner davantage de contrôle sur l’hôte, mais ce contrôle transfère aussi à votre équipe la gestion de la machine, des mises à jour, des secrets et de l’isolation des tâches. GitHub décrit les responsabilités associées aux Runner auto-hébergés. Pour les workflows provenant de contributions non fiables, évaluez également les risques liés aux permissions et à l’exécution de code ; la documentation de sécurité GitHub sur pull_request_target souligne les précautions nécessaires. L’accès à un Mac ne constitue pas, à lui seul, une validation de sécurité de l’environnement de production.
| Option d’exécution | À privilégier lorsque… | Point à valider avant décision |
|---|---|---|
| Runner GitHub Actions hébergé arm64 | Les tâches sont la compilation, les validations sur simulateur ou des étapes qui ne requièrent pas l’identité fixe de l’hôte. | Reproduire la tâche et conserver ses preuves de compilation, de signature et de test. |
| Runner GitHub Actions Intel documenté avec UDID fixe | Une étape exige réellement un UDID Mac stable et les conditions de l’option conviennent à votre organisation. | Vérifier l’offre, les étiquettes disponibles et les limites dans la documentation GitHub à la date de décision. |
| Mac auto-hébergé ou dédié | La tâche dépend d’un hôte contrôlé, d’un accès matériel vérifié ou d’un environnement de signature isolé. | Définir la maintenance, les permissions, l’effacement des espaces de travail et la séparation des secrets. |
| Mac distant loué | Vous avez besoin d’un environnement Mac réel sans acheter immédiatement un poste supplémentaire, et les conditions d’accès conviennent au workflow. | Confirmer l’accès requis, la politique de données et la connexion matérielle éventuelle avant d’y déplacer les tests. |
Un Mac distant peut être une option à évaluer pour une tâche qui exige un hôte contrôlé ; il ne faut toutefois pas lui attribuer une capacité de connexion à un iPhone ou une configuration de signature qui n’a pas été vérifiée. Avec CALMVPS, vous pouvez étudier la location d’un Mac distant via les offres de location et la page des tarifs, puis confirmer que le mode d’accès et le dispositif de test répondent à vos critères avant toute migration.
06 Liste de validation avant le changement de capacité
Effectuez ces contrôles sur une exécution représentative. Ne faites pas migrer tous les workflows parce qu’un seul job a mentionné un UDID.
- [ ] Identifiez le job, la commande et l’étape exacte à l’origine de l’échec.
- [ ] Classez le travail : compilation, test simulateur, signature de développement, test physique ou téléversement d’un build.
- [ ] Vérifiez si l’identifiant attendu appartient au Runner Mac ou à un iPhone de test.
- [ ] Pour une installation sur appareil, contrôlez l’enregistrement de l’appareil et le profil réellement utilisé.
- [ ] Pour un test physique, produisez une preuve de connexion, de détection, d’installation et d’exécution sur l’appareil.
- [ ] Pour une publication, vérifiez la signature de l’archive et le résultat du traitement du build, sans déduire une exigence de test physique.
- [ ] Si le job exige un UDID Mac fixe, confrontez cette exigence aux conditions actuelles des Runner GitHub documentées.
- [ ] Avant d’adopter un Mac auto-hébergé ou distant, définissez qui gère les secrets, les accès, les espaces de travail et la reprise après incident.
- [ ] Lancez un pilote sur le seul type de tâche concerné, puis consignez les preuves avant d’étendre la capacité.
Votre décision de capacité doit s’appuyer sur les journaux, le profil choisi, l’appareil réellement visé et la preuve de test ou de publication. Si le seul besoin est la compilation et la validation sur simulateur, ne migrez pas par réflexe vers un autre Mac à cause du terme « UDID ». Si un travail exige un hôte stable, un iPhone connecté ou un environnement de signature isolé, un Mac dédié ou distant peut être plus pertinent qu’un Runner partagé, à condition que les critères d’accès et de sécurité soient vérifiés.
Les Runner hébergés réduisent la gestion directe des machines, mais ne garantissent ni un identifiant Mac fixe ni un accès à votre appareil physique. Un Mac auto-hébergé donne davantage de contrôle, au prix de la maintenance, de l’isolation et de la responsabilité opérationnelle. Si vous avez une tâche ponctuelle à reproduire ou un environnement Mac à valider avant d’engager un achat, la location d’un Mac distant chez CALMVPS peut servir de voie d’essai ; pour une charge soutenue avec exigences matérielles permanentes, comparez aussi cette option à un Mac détenu et administré par votre équipe.