La documentation Apple distingue l’Archive, la distribution et le traitement du build dans App Store Connect ; cette séparation impose quatre contrôles distincts : dépendances, compilation, signature et envoi. Pour la compilation iOS React Native, gardez donc le JavaScript sur Windows ou Linux, mais déplacez le projet iOS sur un Mac distant réel dès qu’il faut utiliser Xcode, produire un Release, signer ou archiver.

Cette méthode évite d’emprunter une machine sans conserver l’environnement pour la version suivante. Elle vous donne aussi une procédure récupérable, adaptée aux développeurs indépendants et aux petites équipes.

Cette procédure vise les projets React Native CLI qui possèdent déjà un dossier ios et peuvent contenir des modules natifs. Elle ne décrit pas le flux principal d’un projet Expo utilisant une compilation hébergée.

01

Le calendrier de travail

Avant la première connexion

Votre ordinateur Windows ou Linux reste le poste de développement principal pour :

  • l’écriture JavaScript et TypeScript ;
  • la gestion des branches et des demandes de fusion ;
  • les tests de logique qui ne dépendent pas d’iOS ;
  • le développement Android ;
  • la préparation des ressources audio, vidéo et graphiques.

Le Mac distant prend en charge les opérations qui exigent macOS :

  • l’installation et l’exécution de Xcode ;
  • la compilation des modules natifs iOS ;
  • la résolution CocoaPods ;
  • la signature avec l’équipe Apple Developer ;
  • l’Archive Release ;
  • l’envoi vers App Store Connect et TestFlight.

Avant de transférer le projet, décidez où se trouve la référence. Utilisez un dépôt contrôlé, une branche explicitement nommée et un fichier de verrouillage conservé dans le dépôt. Ne copiez pas simplement un répertoire node_modules ou un dossier Pods préparé sur une autre machine.

Prévoyez également les responsabilités de test. Le simulateur iOS aide à vérifier l’interface, mais il ne remplace pas un appareil physique pour les notifications, la caméra, le Bluetooth, les achats intégrés ou les performances vidéo.

La première heure sur le Mac distant

Commencez par noter l’état de la machine avant toute modification :

  • version de macOS ;
  • version de Xcode ;
  • chemin de l’outil de développement sélectionné ;
  • version de Node ;
  • gestionnaire de paquets utilisé ;
  • version de CocoaPods si votre projet l’emploie ;
  • branche et identifiant du commit compilé.

La documentation officielle de configuration React Native doit servir de référence pour les prérequis de votre version du projet. Ne déduisez pas la compatibilité d’un tutoriel ancien. Les modèles React Native, les modules natifs et Xcode évoluent indépendamment.

Depuis SSH ou une session graphique, récupérez le dépôt dans un répertoire de travail séparé :

git clone <URL_DU_DEPOT> <DOSSIER_PROJET>
cd <DOSSIER_PROJET>
git checkout <BRANCHE_DE_PUBLICATION>

Remplacez chaque valeur entre chevrons par un élément non sensible. Ne publiez jamais dans un article, une capture ou un journal l’URL privée du dépôt, le nom d’utilisateur, l’adresse du Mac, le Bundle ID, le Team ID ou un jeton.

Fixez ensuite le chemin Node utilisé par les scripts React Native. Le fichier .xcode.env est utile pour éviter qu’Xcode appelle une version différente de Node lorsque l’environnement graphique ne charge pas le même profil shell que SSH. Vérifiez le contenu de ce fichier avant de lancer une compilation.

Attention. Ne commencez pas par supprimer les caches. Une suppression générale peut masquer la cause réelle et rendre la reproduction plus difficile. Conservez d’abord les versions, la commande exécutée et le premier message d’erreur.

La restauration des dépendances

Restaurez les dépendances JavaScript avec le gestionnaire prévu par le dépôt. Respectez le fichier de verrouillage : il constitue une partie de la définition de l’environnement, pas un simple fichier temporaire.

Puis installez les dépendances iOS depuis le répertoire approprié :

cd <DOSSIER_PROJET>
<COMMANDE_GESTIONNAIRE_PAQUETS> install
cd ios
pod install

La commande exacte dépend de l’outil déclaré par votre projet et de la manière dont CocoaPods est intégré. N’introduisez pas une nouvelle version de gestionnaire au même moment que le premier transfert distant. Si une mise à jour est nécessaire, faites-la dans une branche séparée et notez la modification.

Contrôlez ensuite les différences entre votre poste local et le Mac :

  • modules natifs présents dans package.json ;
  • fichier Podfile réellement utilisé ;
  • workspace généré après l’installation ;
  • scripts de phase de build ;
  • chemins de ressources ;
  • fichiers de configuration par environnement.

Le premier objectif n’est pas encore l’Archive. Il consiste à prouver que le projet peut être reconstruit à partir du dépôt, sans dépendre d’un état caché sur votre ordinateur Windows ou Linux.

02

Le premier build iOS reproductible

Les trois vérifications de compilation

Lancez d’abord une compilation de développement contrôlée. Selon le projet, vous pouvez utiliser la commande React Native habituelle ou lancer le Scheme depuis Xcode. Le guide officiel consacré à l’exécution sur le simulateur iOS avec React Native rappelle le rôle de Xcode et du simulateur dans cette étape.

Séparez les résultats au lieu de conclure « le simulateur fonctionne » trop tôt.

Dépendances natives. Les Pods doivent être résolus et les modules doivent être compilés. Une erreur ici concerne souvent le Podfile, une version native, un script ou une configuration Xcode.

Bundle JavaScript. Le projet doit générer ou intégrer le bundle attendu par la configuration utilisée. Un lancement en développement peut fonctionner grâce au serveur Metro alors qu’un Release doit embarquer ses ressources autrement.

Lancement du simulateur. Il confirme que le binaire peut démarrer dans ce contexte de test. Il ne prouve ni la signature de distribution, ni la compatibilité d’un appareil physique, ni l’acceptation d’un upload.

Conservez le journal complet dans un répertoire d’artefacts associé au commit. Si le build échoue, classez l’erreur selon son premier point de rupture : dépendance, compilation native, bundle ou lancement. Évitez de modifier simultanément le Podfile, la version Node et les réglages de signature.

Le cas audio, vidéo et design

Les projets créatifs méritent une vérification supplémentaire. Une application de montage audio, de lecture vidéo ou de création graphique peut dépendre de codecs, de bibliothèques natives, de fichiers volumineux ou de permissions spécifiques.

Vérifiez notamment :

  • le chargement d’un fichier audio ou vidéo représentatif ;
  • l’orientation et la taille d’affichage sur l’appareil cible ;
  • la présence des ressources dans le bundle Release ;
  • les autorisations micro, caméra et bibliothèque multimédia ;
  • le comportement lorsque les ressources ne sont pas disponibles hors ligne.

Un simulateur distant peut valider un parcours visuel, mais il ne reproduit pas nécessairement le capteur, la latence audio, la caméra ou la mémoire d’un appareil réel. Notez ces limites dans votre procès-verbal de validation.

03

Le premier Archive signé

Les réglages à inspecter

Avant de lancer l’Archive, sélectionnez explicitement le Scheme et la configuration Release. Vérifiez ensuite :

  • le Bundle ID de l’application ;
  • l’équipe Apple Developer sélectionnée ;
  • les capacités activées ;
  • les entitlements ;
  • les extensions d’application ;
  • les identifiants associés à chaque Target ;
  • les réglages de version et de numéro de build.

La documentation Apple sur la préparation d’une application pour la distribution fournit la grille de contrôle à appliquer avant l’export. Dans un projet React Native, l’application principale n’est pas toujours la seule cible : une extension de partage, un widget ou une notification peut avoir sa propre signature.

La signature doit être traitée comme un actif sensible. Si vous importez un certificat ou une clé privée sur le Mac distant, limitez les droits d’accès, documentez l’emplacement et prévoyez la révocation ou le retrait. Apple explique les précautions relatives au partage sécurisé des identités de signature.

Les trois états à ne pas confondre

Build réussi. Le code a été compilé pour une configuration donnée.

Archive réussie. Xcode a produit une archive exploitable pour la distribution.

Export admissible. La signature, les entitlements et la destination permettent de créer un paquet destiné au canal choisi.

Ces états ne sont pas interchangeables. Lisez les journaux Xcode et conservez le chemin de l’Archive créée. La procédure Apple de distribution pour les versions bêta et les releases décrit le passage de l’Archive vers la distribution.

Si l’Archive échoue, ne modifiez pas immédiatement tous les profils. Commencez par identifier la Target qui échoue, le certificat sélectionné et la capacité concernée. Une extension oubliée peut bloquer l’ensemble alors que l’application principale compile correctement.

04

Le premier envoi vers TestFlight

La préparation App Store Connect

Avant l’upload, vérifiez que l’enregistrement de l’application existe dans le bon compte et correspond au Bundle ID. La page Apple consacrée à la création d’un enregistrement d’application explique cette association.

Depuis l’Archive validée, lancez la distribution selon le flux choisi par votre équipe. L’aide Apple dédiée à l’envoi des builds sert de référence pour l’upload et les contrôles associés.

Après l’envoi, suivez séparément ces états :

  • transfert terminé depuis Xcode ou l’outil d’envoi ;
  • build reçu par App Store Connect ;
  • traitement serveur terminé ;
  • build associé à la bonne version ;
  • build ajouté à un groupe de test ;
  • installation sur un appareil réel ;
  • éventuelle soumission à la revue.

Un build visible n’est pas nécessairement prêt pour vos testeurs. Utilisez l’interface App Store Connect pour confirmer le statut réel, les avertissements et les informations manquantes.

La validation finale

Installez le build TestFlight sur au moins un appareil représentatif de votre public. Testez les fonctions qui ne peuvent pas être simulées correctement :

  • connexion et reprise de session ;
  • achats intégrés ;
  • notifications ;
  • appareil photo et microphone ;
  • lecture ou export vidéo ;
  • synchronisation en arrière-plan ;
  • liens universels ;
  • accès aux fichiers et aux photos.

Associez le numéro de build au commit exact. Sans cette correspondance, une correction testée sur l’appareil peut ne pas être celle qui a été archivée.

05

La première semaine d’exploitation

La transformation en procédure réutilisable

Après un premier envoi réussi, découpez le processus en tâches indépendantes :

  1. récupérer le commit de publication ;
  2. restaurer les dépendances JavaScript ;
  3. installer ou vérifier les Pods ;
  4. lancer le build Release ;
  5. produire l’Archive ;
  6. conserver les journaux et les artefacts ;
  7. envoyer le build ;
  8. vérifier son traitement dans App Store Connect.

Chaque tâche doit avoir une condition d’arrêt. Par exemple, arrêtez le processus si le commit attendu n’est pas disponible, si le Bundle ID ne correspond pas ou si la signature sélectionnée n’est pas celle de l’équipe. Une procédure qui continue après une anomalie produit souvent une Archive difficile à diagnostiquer.

Testez ensuite la récupération : déconnexion SSH, reconnexion, redémarrage de la session graphique et redémarrage du Mac. Le but est de vérifier que le projet ne dépend pas d’une fenêtre Xcode laissée ouverte ou d’un serveur Metro oublié.

Isolez enfin les accès :

  • dépôt source ;
  • clé privée de signature ;
  • profils de provisionnement ;
  • identifiants App Store Connect ;
  • journaux de build.

Ne placez pas ces éléments dans le même dossier partagé sans contrôle. Si vous utilisez une automatisation ultérieure, créez un compte technique et des droits limités plutôt que de réutiliser une session personnelle.

L’outil de décision pour votre environnement

Utilisez cette liste de conditions avant de choisir une location courte, un Mac distant conservé dans le temps ou un poste local :

  • Si vous devez publier une seule fois, que le projet est stable et qu’aucun module natif ne doit être modifié, choisissez un Mac distant pour une durée courte. Conservez toutefois la branche, l’Archive, les journaux et la procédure de reprise.
  • Si vous devez corriger régulièrement des modules natifs, des extensions ou des capacités iOS, choisissez un environnement Mac distant réutilisable. Vous éviterez de réinstaller CocoaPods, les certificats et les réglages Xcode à chaque version.
  • Si vous publiez à intervalles réguliers, gardez une machine prête à compiler et documentez le chemin de récupération après une déconnexion SSH ou un redémarrage.
  • Si plusieurs personnes doivent produire des builds, choisissez un environnement dont les accès sont séparés. Formalisez les versions, les droits, les artefacts et les responsables avant d’ajouter une automatisation.
  • Si votre application utilise une caméra, un périphérique audio, le Bluetooth ou des fonctions très dépendantes du matériel, choisissez un Mac distant pour la compilation, mais prévoyez une validation complémentaire sur un appareil physique.
  • Si vous ne possédez pas encore de Mac et que votre fréquence de publication est incertaine, commencez par une période courte. Prolongez-la uniquement lorsque le nombre de builds et la maintenance justifient un environnement conservé.
  • Si vous avez besoin d’un poste local disponible hors connexion ou d’un accès direct à des périphériques, le Mac local peut être préférable malgré son coût matériel et sa maintenance.

Vous pouvez consulter les tarifs de location de Mac mini pour comparer une utilisation ponctuelle et un environnement conservé. Pour une équipe qui veut surtout un poste distant administrable, la page de commande d’un Mac mini permet également d’examiner les modalités disponibles, sans modifier votre dépôt ni vos réglages de signature.

Expérience de maintenance. Une compilation reproductible ne signifie pas « aucune intervention ». Vous devrez toujours revoir les certificats, les profils, les dépendances natives et les exigences App Store Connect lorsque le projet évolue. La valeur de l’environnement distant est de rendre cette intervention identifiable et récupérable.

Les contrôles après redémarrage

Une fois la procédure documentée, exécutez-la après une reconnexion SSH, puis après un redémarrage du Mac distant. Vérifiez que le dépôt peut être récupéré sans fichiers laissés par une session précédente, que le chemin Node est toujours correct et que le workspace CocoaPods est régénéré de façon cohérente.

Lancez ensuite un build Release sans modifier le code. Si le résultat change, cherchez d’abord une différence d’environnement : outil de développement sélectionné, trousseau, profil de signature, variable d’environnement ou dépendance téléchargée. Cette discipline est plus fiable qu’un nettoyage systématique.

06

Questions fréquentes

Windows ou Linux comme poste principal

Oui, votre poste Windows ou Linux peut conserver le développement JavaScript, la gestion du dépôt et Android. Pour la partie iOS, le projet doit toutefois atteindre un environnement Xcode. La méthode fiable consiste à synchroniser la branche vers un Mac distant, puis à y exécuter CocoaPods, le build Release, l’Archive et la distribution.

La dépendance à un Mac

Vous n’avez pas nécessairement besoin d’acheter un Mac local. En revanche, vous avez besoin d’un accès à un Mac réel dès que votre projet React Native CLI compile des modules iOS, utilise Xcode, doit être signé ou doit produire une Archive. Cette distinction évite de confondre « développer en JavaScript » et « livrer une application iOS ».

CocoaPods et Archive sur une machine distante

Installez les dépendances depuis le dépôt, utilisez le fichier de verrouillage, lancez pod install dans le bon répertoire, puis ouvrez le workspace généré. Vérifiez le Scheme Release, les Targets et la signature avant l’Archive. Sauvegardez le journal et le chemin de sortie avant de nettoyer quoi que ce soit.

Envoi vers TestFlight

L’upload n’est que le début du contrôle App Store Connect. Confirmez la réception, le traitement serveur, l’association à la version, l’ajout au groupe de test et l’installation sur un appareil. Pour une application audio, vidéo ou graphique, ajoutez une régression réelle sur appareil : le simulateur ne couvre pas tous les comportements matériels.

07

Le choix après votre première publication

Un poste Windows ou Linux reste pertinent pour coder, mais il devient limité dès que vous devez maintenir les modules natifs, signer une nouvelle version ou produire régulièrement une Archive. Emprunter une machine crée des dépendances de calendrier et laisse souvent un environnement non documenté. Acheter un Mac dédié immobilise du matériel pour une charge parfois irrégulière et vous laisse gérer les mises à jour, l’accès distant et la disponibilité.

Après votre première Archive, la décision est plus simple : une publication unique peut justifier une location courte, tandis qu’un rythme régulier demande un environnement Mac réutilisable. VpsMesh peut servir de solution intermédiaire lorsque vous avez besoin d’un Mac distant pour construire, signer et envoyer sans acheter immédiatement une machine dédiée. Consultez les conditions de location avant de choisir la durée, puis conservez votre procédure de build avec le dépôt et les artefacts associés.