Compatibilité Rosetta 2 sur Mac mini Cloud

Il est deux heures du matin, et le plus vieux projet iOS de l'équipe vient d'être migré d'un Mac Intel local vers un Mac mini M4 cloud tout juste provisionné. pod install se termine sans problème, mais dès que xcodebuild démarre, la console crache une série d'erreurs rouges du type have architecture 'x86_64', need 'arm64'. Ce n'est ni un souci réseau, ni une erreur de configuration : c'est que la machine a changé de puce. Apple Silicon et Intel reposent sur deux jeux d'instructions totalement différents, et un vieux projet accumule au fil des années des bibliothèques tierces, des scripts et des outils en ligne de commande — dont beaucoup sont restés figés à l'ère x86_64. Migrer ne se résume pas à un simple copier-coller : il faut d'abord franchir cet obstacle architectural.

Scène : le premier build échoue sur une machine dédiée

La puce M4 du Mac mini cloud fait tourner un système arm64 natif, alors que le projet peut cacher plusieurs types de « squatteurs » : un binaire précompilé d'un outil de signature, une source privée CocoaPods jamais mise à jour, voire un vieil outil en ligne de commande appelé directement dans un script CI. Ces éléments n'ont jamais posé problème sur le Mac Intel local — c'est seulement en arrivant sur une machine Apple Silicon qu'ils révèlent enfin leur vraie nature.

Note système : cette machine est un serveur physique dédié. Le changement d'architecture, l'installation de Rosetta et toute modification des réglages système n'affectent que votre propre instance, sans impact sur l'environnement d'un quelconque « voisin » — c'est d'ailleurs une des raisons de choisir une machine physique dédiée plutôt qu'une VM partagée.

Qu'est-ce que Rosetta 2, et quand en a-t-on vraiment besoin

Rosetta 2 est la couche de traduction dynamique fournie par Apple, qui permet d'exécuter des binaires compilés en x86_64 sur une puce arm64 — au prix d'une perte de performance. Elle convient bien à une phase transitoire « faire fonctionner avant d'optimiser », mais ne doit pas devenir une dépendance durable : toute dépendance disponible en version arm64 native doit être remplacée dès que possible.

Vérifier si une dépendance en a besoin

Avant d'installer quoi que ce soit, deux commandes suffisent pour repérer les « corps étrangers » :

file /usr/local/bin/some-tool
lipo -info /usr/local/lib/libSomeSDK.a

file indique directement s'il s'agit d'un Mach-O 64-bit x86_64 executable ou d'un binaire arm64 ; lipo -info est plus précis pour les bibliothèques statiques, car il révèle si elles sont universal (contenant à la fois x86_64 et arm64). Si la sortie ne mentionne que x86_64, cet élément devra soit passer par Rosetta, soit être remplacé par une version arm64 fournie par l'éditeur.

Trois étapes pour combler la couche de compatibilité

Étape 1 : installer Rosetta

À exécuter une seule fois sur le Mac mini cloud, l'effet est global au système :

softwareupdate --install-rosetta --agree-to-license

Étape 2 : repérer toutes les dépendances problématiques

Une petite boucle permet de scanner en masse les bibliothèques statiques et binaires de dépendances dans Pods/, pour lister celles qui ne sont pas arm64 et les archiver — cette liste servira de checklist lors des futures mises à jour :

find Pods -name "*.a" -exec sh -c 'lipo -info "$1" | grep -q arm64 || echo "$1"' _ {} \;

Étape 3 : forcer l'architecture d'exécution si nécessaire

Pour un outil en ligne de commande dont aucune version arm64 n'est disponible pour l'instant, utilisez arch pour spécifier explicitement l'architecture et le faire passer par Rosetta — plutôt que de laisser le système deviner et échouer :

arch -x86_64 /usr/local/bin/legacy-signing-tool --version

Diagnostiquer les conflits d'architecture entre CocoaPods et Homebrew

Si le build du simulateur affiche une erreur du type « aucune slice correspondant à cette architecture », c'est très probablement que le Podfile n'exclut pas l'architecture arm64 du simulateur — ou, à l'inverse, qu'il exclut par erreur l'architecture arm64 des appareils physiques. Ajoutez en fin de Podfile une règle d'exclusion spécifique au simulateur, et vérifiez également que le champ Excluded Architectures dans les réglages de build Xcode n'a pas été inversé.

Côté Homebrew, le piège classique est le mélange de deux préfixes : le Homebrew arm64 natif s'installe dans /opt/homebrew, tandis que le Homebrew x86_64 exécuté sous Rosetta va dans /usr/local. Utiliser les deux brew en parallèle provoque fréquemment des conflits de versions entre dépendances — il est recommandé de n'en garder qu'un seul et de spécifier explicitement la priorité du PATH dans votre .zshrc.

Checklist et tableau des erreurs courantes

Mot-clé de l'erreur	Cause courante	Solution
`have architecture 'x86_64', need 'arm64'`	La bibliothèque statique ne fournit pas de slice arm64	Vérifier avec `lipo -info` puis passer à une version universal
`Bad CPU type in executable`	L'outil en ligne de commande est un binaire x86_64 pur	Forcer l'exécution avec le préfixe `arch -x86_64`
Slice manquante pour le simulateur CocoaPods	Le Podfile n'exclut pas l'architecture arm64 du simulateur	Ajouter une règle `EXCLUDED_ARCHS`
Commande `brew` ne trouve pas le paquet	Mélange de deux préfixes Homebrew	Conserver un seul préfixe et nettoyer le `PATH`

Validation post-migration : natif ou couche de compatibilité ?

Un build qui réussit ne signifie pas que la migration est terminée : il faut encore vérifier que les chemins critiques tournent réellement en mode arm64 natif, et non entièrement soutenus par Rosetta. Vous pouvez ajouter une ligne d'auto-diagnostic dans le script de build pour afficher l'architecture du processus en cours ; si le flux de build principal (et non un outil marginal) dépend durablement de Rosetta, cela indique une marge de remplacement à prévoir dans le prochain cycle de mise à jour des dépendances.

Questions fréquentes

Faut-il recompiler immédiatement chaque dépendance x86_64 ?

Pas forcément. Testez d'abord sous Rosetta 2 pour vérifier que tout fonctionne, puis remplacez progressivement chaque dépendance par sa version arm64 plutôt que de bloquer toute l'équipe pour une réécriture complète.

L'installation de Rosetta 2 sur mon Mac mini cloud affecte-t-elle d'autres utilisateurs ?

Non. Chaque nœud est une machine physique dédiée : les réglages d'architecture ne s'appliquent qu'à votre propre instance, sans effet de voisinage comme sur une VM partagée.

CocoaPods ne trouve pas d'architecture simulateur, que faire ?

En général, le Podfile n'exclut pas l'architecture arm64 du simulateur, ou EXCLUDED_ARCHS est réglé à l'envers. Vérifiez le champ Excluded Architectures dans les réglages de build Xcode comme décrit dans l'article.