2026 — React Native / Expo : équipes Windows et Linux, Mac distant US Est / Asie-Pacifique pour builds iOS — trois paliers M4, caches CocoaPods / SwiftPM, extension 1 To / 2 To face à EAS et M4 Pro, runners GitHub Actions auto-hébergés (check-lists SSH / VNC + FAQ)

En 2026, la majorité des équipes React Native et Expo codent sur Windows ou Linux, mais la livraison iOS exige toujours xcodebuild, CocoaPods ou SwiftPM, et souvent une session graphique pour le simulateur ou la signature. Plutôt qu'acheter un parc de Mac locaux, beaucoup louent un Mac mini M4 distant proche de leurs fuseaux US Est ou Asie-Pacifique, y installent un runner GitHub Actions auto-hébergé, et réservent EAS Build aux pics ou aux profils cloud managés. Ce guide aligne région, stockage, caches et bail avec cette réalité hybride. Pour le démarrage à froid Git et les files CocoaPods/SwiftPM, voir aussi la FAQ CI : gros dépôts, Git blobless/shallow et caches CocoaPods.

1. Windows / Linux en local, Mac distant pour la couche iOS

Le poste développeur reste sur Node, Metro et Android ; le Mac distant absorbe pod install, eas build --local (si vous l'autorisez), archives IPA et uploads TestFlight via Fastlane. Choisissez la région selon qui déclenche la CI : Singapour ou Tokyo pour l'Asie, US West pour les équipes américaines — mesurez le RTT depuis vos runners, pas depuis le siège marketing. Un tunnel SSH stable vaut mieux qu'un VPN générique qui casse les gros artefacts binaires.

2. Trois paliers M4 : entrée, équilibré, M4 Pro

Entrée (M4) : un pipeline Expo sérialisé, prebuild occasionnel, peu de simulateurs lourds. Équilibré : plusieurs jobs expo export + native iOS en parallèle modéré, caches Pods/SwiftPM chauds. M4 Pro : monorepos lourds, Hermes + plusieurs schémas, VNC QA sur le même hôte. Si df -h sature avant le CPU, montez le SSD avant le SoC.

3. Caches CocoaPods et SwiftPM sur disque NVMe dédié

Expo prebuild régénère souvent le dossier ios/ ; sans politique, ~/Library/Caches/CocoaPods et les checkouts SwiftPM explosent. Montez des volumes APFS séparés pour Pods, DerivedData et .swiftpm, avec mutex par job sur le runner. Épinglez le CDN CocoaPods ou un miroir interne ; évitez deux pipelines qui écrivent dans le même cache mutable. Pour checkout Git et worktrees multi-dépôts, croisez avec la FAQ pool CI : git worktree, clone par job et caches NVMe.

4. Extension 1 To / 2 To « en parallèle » versus monter au M4 Pro

Les builds Expo accumulent pods binaires, archives et journaux EAS locaux. +1 To prolonge la marge pour une équipe qui purge chaque semaine ; +2 To si vous conservez plusieurs branches LTS et symboles pour le support. Le M4 Pro se justifie quand plusieurs xcodebuild concurrents saturent CPU et GPU, pas quand seul le disque crie famine.

5. Matrice EAS (minutes) versus Mac M4 Pro loué

Les quotas EAS Build facturent des minutes cloud managées : excellent pour pics, releases ponctuelles ou équipes sans ops macOS. Un Mac distant M4 avec runner auto-hébergé amortit les PR quotidiennes si vous tenez les caches chauds. Comparez le coût horaire amorti d'un bail mensuel + extension disque au panier EAS sur la même fenêtre, en incluant le temps ingénieur de maintenance.

6. GitHub Actions : runner auto-hébergé sur Mac distant

Installez le runner en service launchd sous un utilisateur dédié, labels macos + expo-ios, secrets App Store Connect et certificats dans un coffre (pas dans le dépôt). Limitez la concurrence : un job lourd Expo + Xcode à la fois sur M4 entrée. Déclenchez depuis Windows/Linux via les mêmes workflows ; seule l'étape runs-on: [self-hosted, macos] cible le Mac. Purgez ios/build et les artefacts entre jobs pour éviter les fuites de profils.

7. Check-lists SSH et VNC (acceptation)

SSH — avant mise en production

• Connexion par clé uniquement ; mot de passe désactivé ; clés rotatives dans le coffre CI.
• xcode-select -p pointe vers la version attendue ; xcodebuild -version OK.
• node -v, npm -v ou pnpm alignés avec le dépôt ; eas-cli si utilisé.
• pod --version et accès CDN Specs ou miroir interne validé.
• Runner GitHub en ligne, label visible, job test vert sur branche factice.

VNC — acceptation GUI

• Session VNC fermée pendant les builds parallèles (pas de capture UI concurrente).
• Simulateur iOS démarre ; résolution adaptée à la bande passante montante.
• Keychain déverrouillé pour la signature uniquement pendant la fenêtre release, puis reverrouillé.
• Horloge NTP synchronisée (uploads App Store sensibles au décalage).

8. FAQ courte

• « Expo Go suffit-il pour iOS en prod ? » Non pour les binaires store : il faut prebuild + archive sur macOS ou EAS cloud.
• « EAS ou Mac loué ? » EAS pour pics et simplicité ; Mac distant si les minutes EAS dépassent un bail M4 avec caches chauds.
• « 1 To ou 2 To ? » 1 To avec purge hebdo ; 2 To si plusieurs SDK Expo/Xcode coexistent.
• « VNC obligatoire ? » Non pour la CI pure SSH ; oui pour débogage simulateur ou correctifs Xcode ponctuels.
• « Windows peut signer iOS ? » Non nativement : déléguez signature et notarytool au Mac distant.

Pourquoi le Mac mini M4 reste le socle idéal pour Expo + iOS distant

Sur macOS, xcodebuild, CocoaPods, SwiftPM et le simulateur partagent le même environnement que vos releases — sans VM macOS fragile depuis Windows. Le Mac mini M4 combine Apple Silicon, faible conso au repos (~4 W), Gatekeeper, SIP et FileVault pour des runners longue durée, et un format silencieux adapté aux nœuds CI 24/7.

Industrialisez React Native en choisissant d'abord la région qui minimise vos uploads iOS, puis le stockage avant les cœurs — consultez la page d'accueil Macstripe pour comparer modèles et emplacements. Si votre pipeline Expo approche d'une release, un Mac mini M4 loué est le point d'entrée le plus rentable pour brancher SSH, runner et caches sans friction.