2026 · Mac distants en six régions : builds Apple Silicon natifs vs x86_64 (Rosetta)—ARCHS, binaires universels & matrice CI

Lecture ~17 min · MACCOME

Les équipes qui louent des Mac distants dédiés (M4 / M4 Pro) à Singapour, Tokyo, Séoul, Hong Kong, US Est et US Ouest héritent encore de bibliothèques statiques x86_64 uniquement, de binaires CLT anciens ou d’artefacts universels. Ce guide formalise les irritants, une matrice, un runbook en six étapes, des KPI et le FinOps de bail, avec des liens vers Flutter/React Native sur un même hôte, l’hygiène DerivedData et miroirs CocoaPods/SPM & disque.

Six raisons concrètes d’échec du « tout arm64 » sur Apple Silicon neuf

  1. SDK fournisseur x86_64 seulement—il faut xcframework ou rebuild.
  2. Vieux pods binaires CocoaPods réintroduisent x86 par transitivité.
  3. macOS universel + iOS arm64 gonflent les intermédiaires.
  4. YAML fige des simulateurs x86_64—passer à arm64 ou fermes d’appareils.
  5. Artefacts internes amd64-darwin sans slice arm64.
  6. Caches laptops Intel masquent la dérive jusqu’au premier resolve cloud.

Sans drapeau REQUIRES_ROSETTA, même un M4 brûle des minutes en mauvaises relances de link et cleans agressifs. Traitez ARCHS comme la concurrence des runners (self-hosted).

Rosetta n’est pas gratuit : mémoire unifiée et SSD en subissent le pic, surtout combiné au double stack mobile.

Les régions corrigent latence et mix de bail ; si les miroirs sont alignés mais les builds restent rouges, revenez à ARCHS avant le guide multi-région.

Axe arm64 natif Mix / Rosetta Ligne rouge
Graphe de lien lipo arm64 partout Inventaire x86 + date de fin Archives statiques mixtes sans xcframework
Horloge Faible variance Variance suivie à part >35% sans incident réseau
Mémoire Monter la concurrence prudemment Concurrence −1, pas de lourd Simulator mixte Swap croissant
SSD Croissance prévisible Binaires universels = hygiene plus fréquente <12 Go libres
Bail Jour/semaine suffisent souvent Petit bail « burn-in » compat Bail principal sans ligne budgétaire Rosetta
info

Principe : Rosetta 2 traduit dynamiquement ; ce n’est pas du CPU « gratuit »—cela change la forme des pics et la reproductibilité.

Runbook en six étapes

  1. Journaliser uname -m et lipo -info en tête de job.
  2. Geler Xcode/CLT et les ensembles ARCHS autorisés.
  3. Métadonnées de sunset pour le x86 legacy.
  4. Séparer PR arm64 et pipelines universels ; aligner DerivedData.
  5. Tableau Git/miroirs/région.
  6. Ordre de nettoyage figé.
bash
set -euo pipefail
echo "machine: $(uname -m)"
find "$WORKSPACE/Pods" -name "*.a" -maxdepth 6 2>/dev/null | head -n 40 | while read -r f; do
  echo "---- $f"
  lipo -info "$f" || file "$f"
done
xcodebuild -scheme "$SCHEME" -configuration Debug ONLY_ACTIVE_ARCH=YES ARCHS=arm64

Trois KPI

  • Part CPU Rosetta >18% une semaine → revue dépendances.
  • Croissance DerivedData >40% sans nouvelles cibles → orage universal.
  • Part d’échecs « arch mismatch » >12% → gel fonctionnel une semaine.

Limites des laptops Intel ou Rosetta permanent en CI

Pas de politique d’architecture auditable.

MACCOME propose des Mac mini M4 / M4 Pro bare-metal avec baux flexibles sur six régions clés lorsqu’il faut aligner politique ARCHS, concurrence et scripts de nettoyage avec les chemins chauds Git/artefacts.

Pièces jointes de gate ARCHS_POLICY.md + BINARY_INVENTORY.csv

Coordonner avec FinOps monorepo pour éviter les budgets contradictoires.

Quand sauter cet article

Tout est xcframework, CI iOS arm64 uniquement, pas d’universel macOS → articles Runner/Simulator.

FAQ

EXCLUDED_ARCHS=arm64 pour ne sortir que x86_64 ?

Legacy documenté seulement. Voir tarifs.

Les binaires universels saturent-ils les SSD courts ?

Oui—fenêtres de nettoyage + 1TB/2TB. Commander / pages d’aide.