React Native 0.86 : build iOS dans le cloud en 2026

Un projet React Native 0.86 peut conserver son code JavaScript ou TypeScript sur Windows ou Linux, mais le build iOS natif doit passer par macOS et Xcode. La documentation React Native précise qu’un Mac est requis pour construire une application iOS avec du code natif. La meilleure organisation en 2026 est donc claire : développement local d’un côté, dépendances iOS, débogage natif, Archive, signature et envoi vers App Store Connect sur un Mac distant. (Documentation React Native sur l’exécution iOS)

Cet article s’adresse aux développeurs indépendants qui codent React Native sur Windows ou Linux, aux projets utilisant des modules natifs et aux petites équipes qui veulent transformer un build manuel en environnement iOS réutilisable.

Dernière mise à jour : 15 août 2026. Les informations de version ont été vérifiées dans la page officielle des versions React Native et la documentation Apple liée à Xcode et App Store Connect.

Développement local et build distant

Le premier choix consiste à ne pas déplacer tout le projet sur le Mac. L’éditeur, le serveur Git, les tests JavaScript et une grande partie du travail TypeScript peuvent rester sur le poste habituel. Le Mac distant intervient lorsque le projet touche à l’écosystème Apple.

Cela concerne notamment :

• Xcode et les fichiers .xcodeproj ou .xcworkspace ;
• CocoaPods et les bibliothèques iOS natives ;
• le simulateur iOS ;
• les profils de signature, certificats et entitlements ;
• la création d’un Archive Release ;
• la validation et le téléversement vers App Store Connect.

La séparation est encore plus importante lorsqu’une application utilise un module de caméra, d’audio, de vidéo, de Bluetooth, de paiement ou de partage de fichiers. Dans ces cas, le problème n’est pas seulement de produire un bundle JavaScript. Il faut vérifier le comportement d’un composant natif dans Xcode, ses permissions, ses ressources et parfois ses réglages de build.

Un projet utilisant un framework React Native peut masquer une partie de cette complexité. En revanche, dès qu’un dépôt contient un dossier ios, un Podfile, des modifications natives ou des scripts Xcode personnalisés, le contrôle complet de macOS devient préférable. Un environnement distant avec accès graphique et SSH permet alors de choisir le bon outil selon la tâche.

• VNC ou console graphique : réglages Xcode, simulateur, signature, inspection des targets et des phases de build.
• SSH : installation reproductible, commandes Git, bundle exec pod install, builds automatisés et conservation des journaux.
• Navigateur : accès rapide pour une vérification ponctuelle, mais moins adapté aux longues sessions Xcode ou au débogage de l’interface.

Avant de réserver une machine, le dépôt doit déjà préciser son gestionnaire de paquets, ses fichiers de verrouillage, son identifiant d’application, son équipe Apple et sa cible de distribution. Le compte Apple Developer et l’enregistrement de l’application dans App Store Connect doivent également être disponibles. Apple indique qu’un bundle ID doit correspondre à l’application enregistrée avant la distribution. (Préparation d’un projet pour la distribution)

Préparation du dépôt et de l’accès macOS

La première erreur fréquente consiste à synchroniser une machine de développement au lieu de synchroniser un projet. node_modules, Pods et DerivedData sont des résultats locaux. Ils peuvent contenir des chemins absolus, des binaires liés à une architecture précise ou des caches qui masquent une mauvaise configuration.

Le dépôt à envoyer doit plutôt contenir :

• le code JavaScript et TypeScript ;
• le dossier ios suivi par Git ;
• package.json et le lockfile utilisé ;
• Gemfile et Gemfile.lock s’ils sont présents ;
• Podfile et Podfile.lock ;
• les scripts de build et fichiers .xcode.env ;
• les ressources, configurations et fichiers nécessaires à l’application.

Le projet ne doit pas contenir de secret. Les certificats privés, clés API, mots de passe, profils sensibles et fichiers de configuration de production doivent être injectés séparément sur le Mac distant.

Commencez par contrôler l’état du dépôt :

git status --short
git ls-files | grep -E '(^|/)(node_modules|Pods|DerivedData)/'
git log -1 --oneline

Une sortie vide pour les répertoires générés est souhaitable. Si node_modules ou Pods apparaissent dans Git, corrigez d’abord le .gitignore. Sinon, le premier diagnostic sera brouillé par des fichiers provenant d’une autre machine.

Vérifiez ensuite les références locales :

grep -R "/Users/" ios package.json scripts .xcode.env 2>/dev/null
grep -R "NODE_BINARY\|BUNDLE_IDENTIFIER\|TEAM_ID" ios scripts .env* 2>/dev/null

Le résultat attendu n’est pas nécessairement vide, car certains chemins peuvent être légitimes. En revanche, un chemin vers le dossier personnel d’un ancien développeur, un script qui appelle un binaire absent ou une variable non définie doit être corrigé avant le premier build.

Première heure : outil par outil

React Native 0.86 est une version stable publiée en juin 2026 et indiquée comme active dans la page officielle des versions. La page de versions mentionne également une version 0.87 prévue pour le cycle suivant ; elle ne doit donc pas être utilisée comme base implicite pour un projet qui cible 0.86. (Versions et statut de support React Native)

Le contrôle doit commencer par le dépôt, et non par une liste générique trouvée en ligne. Les versions de Xcode, Node, Ruby et CocoaPods doivent être compatibles avec le projet et avec les bibliothèques natives qu’il utilise. La documentation React Native actuelle recommande Node 22.11.0 ou une version plus récente pour son environnement courant, mais cette indication ne remplace pas les contraintes du lockfile ou de la chaîne de CI du projet. (Configuration de l’environnement React Native)

Sur le Mac distant, créez un dossier de travail stable, puis vérifiez les outils :

mkdir -p "$HOME/Builds/<PROJECT_NAME>"
cd "$HOME/Builds/<PROJECT_NAME>"

xcodebuild -version
xcode-select -p
node --version
npm --version
ruby --version
bundle --version
pod --version

Si plusieurs installations de Xcode existent, sélectionnez explicitement celle prévue pour le projet :

sudo xcode-select --switch "/Applications/<XCODE_VERSION>.app/Contents/Developer"
xcodebuild -runFirstLaunch

Le nom de l’application Xcode et le chemin doivent rester des variables à remplacer. Il ne faut pas copier une commande contenant un chemin présenté comme universel.

Les résultats doivent être enregistrés dans un fichier de diagnostic :

{
  date
  xcodebuild -version
  xcode-select -p
  node --version
  npm --version
  ruby --version
  bundle --version
  pod --version
} | tee toolchain-report.txt

Cette trace répond à une question essentielle lorsqu’un build échoue après quelques jours : l’environnement a-t-il changé, ou le code a-t-il changé ? Sans ce relevé, les deux causes sont souvent mélangées.

Le fichier .xcode.env mérite une attention particulière. React Native l’utilise pour indiquer à Xcode le chemin du binaire Node. Un terminal interactif peut trouver Node grâce à son profil shell alors qu’une phase de build non interactive ne le trouve pas. Vérifiez donc la variable avec le même utilisateur qui exécutera le build :

cat .xcode.env
command -v node

Dépendances verrouillées et CocoaPods

Une fois le dépôt récupéré, installez uniquement les dépendances définies par le projet. Pour npm :

npm ci

Pour Yarn, utilisez la commande correspondant au fichier de verrouillage présent dans le dépôt. Ne mélangez pas plusieurs gestionnaires pendant le premier diagnostic. Une modification accidentelle du lockfile peut transformer une erreur de compilation en résolution différente de paquets.

Pour la partie iOS, privilégiez le Gemfile du projet :

cd ios
bundle install
bundle exec pod install

La documentation officielle d’intégration React Native 0.86 montre l’usage de bundle install puis bundle exec pod install. Elle signale aussi que certains projets générés avec Xcode 16 peuvent exiger des versions précises de CocoaPods et de xcodeproj. Ces versions doivent être lues dans le Gemfile du projet, pas copiées aveuglément d’un autre dépôt. (Guide d’intégration React Native 0.86)

Après l’installation, vérifiez que le workspace attendu existe :

test -f "<PROJECT_NAME>.xcworkspace" && echo "workspace présent"
git diff -- ios/Podfile.lock

Un changement du Podfile.lock n’est pas automatiquement une erreur. Il indique cependant que l’environnement distant n’a pas reproduit exactement l’état du dépôt. Pour un premier build de référence, il est préférable de comprendre chaque différence avant de la valider.

Le diagnostic doit rester séparé en quatre niveaux :

1. résolution JavaScript et exécution de Metro ;
2. installation et intégration CocoaPods ;
3. compilation et édition de liens Xcode ;
4. lancement sur simulateur ou appareil.

Si pod install réussit mais que l’Archive échoue, le problème se situe probablement après la résolution des pods. Cherchez alors un symbole manquant, une configuration Release différente, un script qui ne trouve pas Node, une ressource absente ou un réglage de signature incorrect. Effacer tous les caches ne constitue pas une méthode de diagnostic.

Comparaison des tâches et des accès

Ce tableau ne signifie pas que le poste local est secondaire. Il reste le meilleur endroit pour modifier le code, examiner les pull requests et exécuter les tests indépendants de la plateforme. Le Mac distant devient le poste spécialisé qui reproduit les étapes impossibles ou peu fiables sur Windows et Linux.

Premier build Debug

Le premier objectif n’est pas l’App Store. Il faut d’abord prouver que le projet peut démarrer sur le simulateur avec la configuration Debug.

Depuis la racine du dépôt, lancez Metro dans une session SSH séparée :

npx react-native start --reset-cache

Dans une autre session, utilisez la commande adaptée aux scripts du projet :

npx react-native run-ios --simulator="<SIMULATOR_NAME>"

Si le projet utilise des scripts personnalisés, lisez package.json avant de remplacer la commande. La commande générique ne doit pas écraser un réglage nécessaire aux modules natifs.

Le simulateur distant sert à confirmer :

• le chargement du bundle JavaScript ;
• la génération éventuelle de code ;
• l’intégration des modules natifs ;
• la présence des images, polices et fichiers de configuration ;
• l’ouverture correcte de l’application dans la cible iOS choisie.

Pour une interface audio, vidéo ou design, l’accès graphique est particulièrement utile. Le développeur peut vérifier une permission, une surface vidéo, une animation ou un comportement d’orientation que les seuls journaux SSH ne montrent pas. En revanche, les commandes répétables doivent rester dans SSH afin de pouvoir être rejouées après une reconnexion.

Conservez les journaux sans y laisser de secret :

npx react-native run-ios --simulator="<SIMULATOR_NAME>" \
  2>&1 | tee logs/debug-$(date +%Y%m%d-%H%M).log

Si l’échec survient, notez la première erreur pertinente et sa phase. Un message de compilation, un symbole introuvable et une application qui se ferme après lancement ne demandent pas la même correction.

Archive, signature et App Store Connect

Après le Debug, passez à la configuration Release. Le chemin de distribution Apple distingue plusieurs états : Archive créée, Archive validée, export réussi, téléversement terminé, traitement par App Store Connect achevé et soumission à l’examen. Aucun de ces états ne doit être présenté comme une publication effective.

Dans Xcode, vérifiez d’abord :

• le scheme utilisé ;
• la configuration Release ;
• le bundle ID ;
• l’équipe Apple sélectionnée ;
• les entitlements ;
• les capacités activées ;
• la version et le numéro de build ;
• le certificat ou la signature automatique retenue.

Apple précise qu’il faut d’abord créer une Archive avant de choisir une méthode de distribution. Xcode permet ensuite de valider l’Archive avant le téléversement. (Distribution avec Xcode)

Depuis la ligne de commande, le projet peut utiliser une commande de build avec des variables de remplacement :

xcodebuild \
  -workspace "<PROJECT_NAME>.xcworkspace" \
  -scheme "<SCHEME_NAME>" \
  -configuration Release \
  -sdk iphoneos \
  -archivePath "$PWD/build/<PROJECT_NAME>.xcarchive" \
  archive

Cette commande ne doit être exécutée qu’après vérification du workspace et du scheme. Elle ne configure pas automatiquement un bundle ID correct, une équipe Apple ou une autorisation de signature.

Pour l’envoi, Xcode ou les outils Apple peuvent être utilisés. App Store Connect associe notamment le bundle ID, le numéro de version et le numéro de build au bon enregistrement. Le build doit ensuite être traité par les systèmes Apple avant d’apparaître comme disponible. (Téléversement des builds dans App Store Connect)

Le compte utilisé doit disposer du rôle nécessaire. Apple documente les rôles autorisés pour le téléversement, notamment Account Holder, Admin, App Manager ou Developer. Il est préférable de donner le niveau minimal compatible avec la tâche. (Rôles requis pour téléverser un build)

Après l’envoi, distinguez les états :

• Processing : Apple traite encore le fichier ;
• Failed : le traitement a rencontré une erreur ;
• Complete : le build est prêt pour les étapes de test prévues.

Apple indique qu’un traitement restant en cours au-delà de 24 heures peut signaler un problème. (États de traitement des uploads)

Pour les identifiants, les exemples doivent rester abstraits :

export ASC_KEY_ID="<KEY_ID>"
export ASC_ISSUER_ID="<ISSUER_ID>"
export ASC_KEY_PATH="$HOME/.secrets/<PRIVATE_KEY_FILE>"

Le fichier privé ne doit pas se trouver dans le dépôt. Les variables ne doivent pas apparaître dans les journaux. Une fois le téléversement terminé, déconnectez la session graphique, vérifiez le trousseau et supprimez les fichiers temporaires non nécessaires.

Conditions de choix de l’environnement

Le choix entre une session temporaire et un Mac distant conservé plus longtemps peut être pris avec les règles suivantes :

• Si le projet est publié seulement à chaque version majeure, choisissez une session temporaire, mais sauvegardez le relevé d’outils et la procédure de reconstruction.
• Si l’Archive doit être produite plusieurs fois par semaine, choisissez un environnement persistant afin d’éviter de réinstaller Xcode, les simulateurs et les dépendances.
• Si le projet contient des modules audio, vidéo ou graphiques, choisissez un accès combinant interface graphique et SSH, car la validation visuelle ne peut pas être remplacée par un simple journal.
• Si plusieurs développeurs doivent publier, utilisez des comptes séparés, des droits Apple limités et un registre de versions de l’environnement.
• Si le dépôt dépend de chemins locaux ou de scripts non documentés, ne lancez pas encore la publication : stabilisez d’abord le build Debug et le lockfile.
• Si l’équipe exige un périphérique iPhone physique connecté en permanence, vérifiez la possibilité technique de cette configuration avant de choisir une machine distante ; un simulateur ne remplace pas tous les tests matériels.

La validation finale doit couvrir un démarrage à froid, un build incrémental, une reconnexion SSH, une nouvelle session graphique et une nouvelle opération de signature. Le résultat attendu n’est pas seulement « le build fonctionne une fois ». Il faut pouvoir expliquer comment reconstruire l’environnement après une déconnexion ou un remplacement de machine.

Pour compléter cette organisation, les équipes peuvent consulter le guide SFTPMAC consacré aux solutions de développement iOS sans Mac local, puis comparer les formules de location de Mac mini. Lorsqu’une équipe veut distinguer accès graphique et exécution distante, la présentation du Mac mini avec accès distant fournit un point de comparaison utile.

Pourquoi le Mac distant devient le choix opérationnel

Un poste Windows ou Linux reste excellent pour écrire React Native, gérer Git et tester la logique applicative. Il devient moins adapté dès qu’il faut installer Xcode, reproduire CocoaPods, inspecter un workspace, manipuler le simulateur, signer une Archive et envoyer le résultat à App Store Connect. Les contournements ajoutent souvent une deuxième chaîne de dépendances, des limites d’accès graphique et une procédure difficile à reprendre par un autre membre de l’équipe.

Pour un usage ponctuel, acheter un Mac uniquement pour quelques publications annuelles peut immobiliser un budget et laisser une machine sous-utilisée. Pour un usage continu, une solution distante apporte surtout un environnement macOS dédié, accessible par VNC et SSH, avec des droits suffisants pour installer les outils et conserver le projet. Le choix doit toutefois rester rationnel : un Mac local sera préférable si le travail exige des périphériques physiques, une latence minimale ou une charge lourde permanente.

Après le premier Archive validé, la décision devient plus simple. Si le besoin se limite à quelques livraisons, privilégiez la rapidité de remise en service. Si le projet doit être testé et publié régulièrement, privilégiez la persistance, l’accès root, la combinaison VNC-SSH et une procédure de restauration documentée. Dans ce second cas, les offres de Mac distant de SFTPMAC peuvent servir de base pour mettre en place un environnement React Native iOS réutilisable, sans déplacer toute la programmation hors de Windows ou Linux.