Checklist pour compiler votre app

Une fois le code terminé,
que faire sur un Mac ?

Continuez à développer en local sous Windows ou Linux, puis migrez votre projet vers un Mac cloud le jour de l’archivage. Vérifiez d’abord la connexion et l’environnement, restaurez les dépendances, importez vos éléments de signature, puis générez le build iOS avec votre framework.

Nous vous aidons pour la connexion, le bureau à distance dans le navigateur, l’initialisation de l’environnement et la facturation. Nous n’écrivons pas votre code métier, ne gérons pas votre compte développeur Apple et ne prenons pas en charge votre éligibilité à la distribution ni vos autorisations de signature.

Louer un Mac à la journée Ouvrir un ticket

Vous avez déjà loué une machine ? Commencez par la checklist de migration ci-dessous. Consultez les identifiants de connexion et l’état de l’instance dans l’espace client après connexion.

Projet local → Mac cloud → build

Clarifiez ces quatre points avant de commencer

Cette checklist aide à préparer la migration ; elle ne signifie pas que les opérations ci-dessous ont déjà été effectuées sur votre instance.

01
Version du projet
Notez la branche, le commit et les fichiers de verrouillage des dépendances pour utiliser le même code des deux côtés.
02
Versions des outils
Vérifiez les versions de Xcode, du SDK et du framework : un écart d’environnement n’est pas forcément une panne de la machine.
03
Éléments de signature
Préparez les certificats, clés privées et profils de provisioning correspondants. Importez-les et conservez-les vous-même.
04
Fichiers à récupérer
Avant la fin de la location, exportez l’archive, le package d’installation, les logs de build et les configurations nécessaires.

Vérifiez la durée de location restante avant de lancer un téléchargement ou un archivage de longue durée.

Migrez chaque élément séparément

Projet, outils et CI : suivez le bon parcours pour chacun.

Un projet sur Mac local comme sur Windows peut être restauré depuis le dépôt de code. Commencez par migrer les configurations reproductibles, puis les éléments sensibles. Évitez de copier en bloc le cache de l’ancienne machine.

Transfert du projet

Récupérer le projet et les éléments de signature

Clonez le projet depuis un dépôt Git auquel vous avez accès. Fournissez l’URL du dépôt via une variable d’environnement ; ne placez pas le jeton d’accès dans l’historique des commandes ni dans une capture d’écran.

Synchronisez les branches et sous-modules, et conservez les fichiers de verrouillage du framework et du gestionnaire de paquets.
Pour signer l’app, transférez le certificat et le profil de provisioning par un canal sécurisé ; n’importez que les éléments nécessaires à cette tâche.
Pour les fichiers volumineux, privilégiez le transfert SSH s’il est activé et accessible. La possibilité d’envoyer des fichiers depuis le bureau dans le navigateur dépend de l’interface de connexion utilisée.

git clone "$PROJECT_REPOSITORY" project
cd project
git submodule update --init --recursive
git rev-parse HEAD
git status --short

Vérification : le commit doit être identique sur les deux machines. L’accès aux dépendances privées, aux ressources supplémentaires et aux fichiers de signature n’est pas restauré automatiquement avec le code.

Configuration de l’environnement

Vérifiez les versions avant d’installer les dépendances

Commencez par vérifier les outils réellement disponibles sur l’instance. Ne supposez pas que toutes les machines ont les mêmes versions préinstallées. Si Xcode ne correspond pas aux exigences du projet, réglez d’abord la compatibilité avant de compiler.

Vérifiez le répertoire de développement Xcode, sa version et les SDK disponibles, puis confirmez que la ligne de commande utilise la chaîne d’outils souhaitée.
Restaurez les outils requis par le projet avec Homebrew et Brewfile, puis vérifiez CocoaPods, Flutter SDK et Node.
Pour un projet Unity, utilisez la version de l’éditeur correspondante et vérifiez dans Unity Hub que iOS Build Support est installé.

xcode-select -p
xcodebuild -version
xcodebuild -showsdks
brew --version
brew bundle check
pod --version
flutter --version
node --version

Vérification : lancez le contrôle dans le répertoire du Brewfile, s’il existe. Si une commande est introuvable, installez d’abord l’outil correspondant. À vous de vérifier les droits d’utilisation de Unity.

Automatisation

Passez à la CI après un build réussi sur le bureau

Effectuez d’abord un build dans une session interactive et vérifiez que les dépendances et la signature fonctionnent. Enregistrez ensuite un runner self-hosted temporaire pour éviter de confondre les problèmes d’environnement avec ceux du pipeline.

Téléchargez depuis votre plateforme CI le package runner compatible avec macOS et l’architecture de la machine, ainsi qu’un jeton d’enregistrement à durée limitée.
Dans le répertoire décompressé, procédez à l’enregistrement selon les instructions de la plateforme, puis vérifiez les labels de tâche, le répertoire de travail et l’utilisateur d’exécution.
Si le projet contient déjà une configuration fastlane, affichez d’abord la liste des lanes, puis lancez le processus de build prévu par votre équipe.

./config.sh --url "$CI_REPOSITORY_URL" --token "$RUNNER_TOKEN"
./run.sh

bundle check
bundle exec fastlane lanes

Vérification : les commandes du runner varient selon la plateforme CI ; ce n’est pas un installateur universel. La procédure d’enregistrement ci-dessus ne s’applique qu’aux plateformes fournissant les scripts correspondants. Désenregistrez le runner et révoquez le jeton avant son expiration.

Pouvoir ouvrir un bureau à distance ne signifie pas qu’on peut y glisser-déposer des fichiers.Les types de contenu du presse-papiers, leur taille et les options de transfert de fichiers dépendent de l’implémentation de la connexion. Si vous avez besoin d’un client SSH ou VNC, vérifiez dans l’espace client les modes d’accès, les identifiants et l’adresse de connexion ; ne supposez pas qu’un port est ouvert. Ne placez pas de données sensibles sur un site de téléchargement public et ne les joignez pas à un ticket.

Choisissez votre parcours de build

Trois façons de compiler ; le résultat ne se résume pas à un simple « build réussi ».

Restaurez l’environnement avec les versions définies par le projet, puis gérez les dépendances de la plateforme et la signature. Exécutez les commandes ci-dessous dans le répertoire du projet concerné. La distribution du build dépend aussi de la configuration de signature, des droits de distribution et des exigences de la plateforme cible.

Flutter : générer une archive et un IPA à partir du projet

Prérequis : La version de Flutter SDK doit correspondre aux exigences du projet. Le projet iOS, les dépendances des plugins et la chaîne d’outils Xcode doivent être disponibles ; les éléments de signature doivent correspondre à l’identifiant de l’app.

flutter doctor -v
flutter pub get
flutter build ipa

Commencez par corriger les problèmes de la chaîne d’outils iOS signalés par flutter doctor -v . Si la restauration des dépendances échoue, vérifiez séparément le réseau, les contraintes de version et les droits d’accès aux paquets privés. Ne relancez pas les commandes d’archivage pour masquer une erreur préalable.

Résultat attendu : Après la réussite du build, vérifiez l’archive dans build/ios/archive ainsi que les fichiers exportés dans build/ios/ipa . Les répertoires et le comportement d’export dépendent de la version de Flutter utilisée et de la sortie du build.

Si vous avez une archive mais pas d’IPA, vérifiez les erreurs d’export et de signature. La fin du build ne soumet pas automatiquement le package à TestFlight.

React Native : archiver avec le bon workspace

Prérequis : Node, le gestionnaire de paquets et le fichier de verrouillage doivent correspondre au projet. Si le projet utilise CocoaPods, les dépendances iOS doivent être installées et le bon scheme sélectionné.

node --version
bundle check
cd ios
bundle exec pod install
open .

Si le projet contient un Gemfile, utilisez l’environnement Bundler prévu par le projet. Sinon, installez les dépendances selon le processus de l’équipe. Dans Xcode, ouvrez le .xcworkspace généré, et non le fichier de projet qui ne contient pas les dépendances Pods.

Résultat attendu : Sélectionnez le scheme cible et la destination d’archivage adaptée à l’appareil, puis choisissez Product → Archive pour créer un .xcarchive ; dans Organizer, exportez ou téléversez l’archive selon le mode de distribution.

Un lancement réussi dans le simulateur ne garantit pas que l’archive pour appareil fonctionnera. En cas d’erreur dans un module natif, conservez la première erreur de compilation et les versions des dépendances concernées, pas seulement le résumé de l’échec final.

Unity : l’export ne suffit pas, il faut poursuivre dans Xcode

Prérequis : La version de l’éditeur Unity doit correspondre au projet, le module iOS doit être disponible, les plugins natifs tiers et les ressources doivent être complets, et vous devez disposer des droits d’utilisation de l’éditeur nécessaires.

xcodebuild -version
xcodebuild -list -project "$EXPORTED_XCODE_PROJECT"

Dans Unity, sélectionnez iOS comme plateforme de build et exportez le projet Xcode. Avec IL2CPP, le code généré doit être compilé en natif. L’export seul ne produit pas encore un package installable prêt à distribuer.

Résultat attendu : Dans Xcode, configurez la signature, les dépendances et la cible, puis lancez Archive. Vous obtiendrez une archive que vous pourrez exporter en IPA ou téléverser selon le processus de distribution. Si un plugin a généré un workspace, ouvrez-le pour continuer.

Pour les projets volumineux, prévoyez suffisamment de mémoire et d’espace pour les fichiers intermédiaires. Apple Silicon M4 Pro / 64GB RAM / 2TB SSD est une configuration proposée pour les grands projets, sans garantie de durée de compilation fixe.

Après le premier build réussi, emportez aussi de quoi le reproduire.

Notez le commit, les versions de Xcode et du framework, les fichiers de verrouillage des dépendances, le scheme utilisé, la commande de build et le chemin des artefacts. Versionnez les configurations qui peuvent être partagées ; conservez à part les clés privées de signature et les jetons d’accès. Lors de votre prochaine location de Mac à la journée, restaurez ces informations au lieu de reconstituer l’environnement à l’aveugle.

Distinguez un bureau lent d’un build lent

Si l’affichage saccade, vérifiez la connexion ; si l’archive bloque, consultez les logs.

Un curseur qui répond en retard ou un affichage qui se rafraîchit lentement indique généralement un problème de réseau ou de réglages d’affichage. Si le curseur répond normalement mais que la compilation dure, examinez les logs de build et l’utilisation des ressources. Changer de mode de connexion à distance ne corrigera pas une erreur du projet.

01
Vérifiez le nœud et le réseau

Vérifiez d’abord si le nœud de la commande est proche de votre zone de connexion. Comparez ensuite une connexion filaire à un Wi-Fi stable et mettez en pause les synchronisations qui saturent le débit montant. Si vous envisagez un autre nœud, consultez la section suivante : ne partez pas du principe que votre commande actuelle peut être transférée immédiatement et sans perte.
À garder en tête : la proximité géographique n’est qu’un premier critère. Le routage de l’opérateur, les liaisons interrégionales et la congestion locale influent aussi sur la latence réelle.
02
Réduisez la charge d’affichage

Dans les options proposées par votre connexion à distance, réduisez la qualité d’image, la résolution ou la fréquence d’images et désactivez les animations inutiles. Ne modifiez qu’un paramètre à la fois et notez le résultat avant et après.
À garder en tête : cela peut réduire la charge d’encodage et de transmission de l’image, mais pas le temps de latence physique du réseau ni la durée d’une compilation CPU.
03
Comparez avec un client VNC

Si l’espace client fournit les informations de connexion correspondantes, utilisez un client VNC pour comparer l’expérience sur la même instance. L’accès par navigateur permet d’ouvrir rapidement le bureau ; un client peut servir à vérifier les différences liées à l’implémentation de la connexion.
À garder en tête : un client peut proposer d’autres options d’affichage ou de presse-papiers, mais ne change pas l’emplacement du nœud. Le transfert de fichiers dépend toujours de l’implémentation des deux côtés et n’est pas garanti de façon uniforme.
04
Conservez les éléments utiles au diagnostic

En cas d’échec de connexion, notez le message affiché, l’heure et le fuseau horaire. En cas d’échec du build, conservez la première erreur pertinente, la commande exécutée et les informations de version. Avant toute capture d’écran, masquez les mots de passe, jetons, détails des certificats et contenus de projets privés.
À garder en tête : une capture peut aider au diagnostic, mais ne remplace pas le texte de l’erreur, qu’il est possible de copier. Ne signalez pas seulement « c’est lent » ou « le build échoue » sans étapes pour reproduire le problème.

Les nœuds indiquent des pistes de choix, pas des mesures de votre propre connexion.

Les cinq nœuds sont indiqués ci-dessous. Les plages correspondent aux zones desservies annoncées et ne garantissent pas la latence depuis une ville donnée.

Nœud → zone desservie → latence aller-retour indicative
Nœud	Zone desservie	Latence aller-retour indicative
Singapour	Asie du Sud-Est	20~50ms
Tokyo	Asie de l’Est	30~60ms
Séoul	Asie du Nord-Est	30~50ms
Hong Kong	Sud de la Chine et Asie du Sud-Est	20~40ms
Est des États-Unis	Est de l’Amérique du Nord et Europe de l’Ouest	25~35ms

Ces plages sont indicatives ; la latence réelle dépend de votre réseau. Pour utiliser le bureau en temps réel, privilégiez un nœud proche de vous. Pour exécuter un build et récupérer ses artefacts, tenez aussi compte du téléchargement des dépendances et des conditions de transfert des fichiers.

Vérifiez votre commande avant toute migration

Avant de changer de nœud, distinguez le projet de la location.

Le nœud fait partie de la configuration de la commande. Cette page ne considère pas le changement de nœud d’une même commande comme une fonctionnalité disponible par défaut et ne garantit pas le transfert automatique du disque, de l’adresse de connexion ou de la durée restante. Pour savoir si un changement est possible et comment seront traités les frais et les données, faites vérifier votre commande précise via un ticket dans l’espace client.

Posez la question avant d’agir sur l’instance actuelle

Indiquez le numéro de commande, le nœud actuel, le nœud souhaité et la raison de votre demande. Précisez si un build est en cours. Attendez la confirmation des modalités de changement, des éventuels frais et des étapes à suivre. Ne supprimez pas l’environnement et ne supposez pas que le nouvel nœud reprendra l’état de l’ancienne instance avant d’avoir obtenu une confirmation.

Si vous devez louer une autre machine, vérifiez d’abord la configuration, la durée et la disponibilité en temps réel de la nouvelle commande. La clôture ou le renouvellement de l’ancienne dépend de la commande concernée et des conditions du service.

Considérez la nouvelle instance comme un nouveau Mac

Poussez d’abord le code non validé et exportez les artefacts de build. Sauvegardez séparément les configurations nécessaires, les certificats et les profils de provisioning. Sur la nouvelle instance, revérifiez les versions des outils, les droits d’accès et la signature ; ne partez pas du principe que le contenu de l’ancien disque a été transféré.

Une fois le changement effectué, mettez à jour la configuration de connexion de la CI, désenregistrez l’ancien runner et révoquez les jetons inutilisés. Le traitement des données à l’échéance dépend des conditions du service et des indications de l’espace client ; ne comptez pas sur une récupération après expiration comme solution de sauvegarde.

Demander un changement de nœud Vérifier les règles de renouvellement et d’expiration

Rendez votre premier ticket facile à traiter

Indiquez clairement quelle machine est concernée et à quelle étape le problème survient.

Connectez-vous à l’espace client, ouvrez un nouveau ticket depuis la rubrique Assistance et associez-y la commande à vérifier. Les tickets dans l’espace client permettent de traiter les problèmes d’instance, de connexion, d’initialisation et de facturation. Si vous ne pouvez pas vous connecter, contactez-nous à l’adresse support@testmini.com .

Rassemblez ces informations avant d’envoyer votre demande

Commande et nœud : numéro de commande, modèle, nœud actuel et instance concernée.
Date et environnement : date et heure du problème, fuseau horaire, système d’exploitation local et version du navigateur ou du client VNC.
Étapes et résultat : page ou commande de départ, résultat attendu et résultat observé.
Erreur et éléments utiles : texte de l’erreur, capture d’écran expurgée, extraits de logs pertinents et possibilité de reproduire le problème.
Vérifications déjà effectuées : changement de réseau, réglage de la qualité d’image, nouvelle connexion, etc., et résultats obtenus.

Pour une question de paiement, indiquez le numéro de commande, le mode de paiement et le statut affiché dans l’espace client. Pour USDT-TRC20, vous pouvez fournir le hash de transaction. Pour un problème de carte bancaire, n’envoyez jamais le numéro complet, le cryptogramme ni le code de vérification.

Structurez le corps du ticket ainsi

Remplissez les champs ci-dessous dans un ticket de l’espace client ; inutile de téléverser tout le projet.

Éléments concernés: Numéro de commande, nœud, modèle
Date et heure: Heure précise et fuseau horaire
Étapes pour reproduire le problème: Ordre des actions, commandes, texte de l’erreur
Environnement: Navigateur, Xcode, version du framework
Résultats des vérifications: Solutions déjà essayées et changements observés

Ne joignez pas de mot de passe, de clé privée, de certificat de signature original ni de jeton d’enregistrement CI. Si notre équipe a besoin d’éléments supplémentaires pour diagnostiquer le problème, elle vous demandera le minimum nécessaire dans le ticket.

Suivez l’avancement dans le ticket : envoyer une demande ne signifie pas qu’elle a déjà été traitée.

L’assistance est principalement disponible pendant les heures de travail en Asie-Pacifique. Nous ne garantissons pas de délai fixe en minutes ou en heures ; les réponses et la suite du traitement figurent dans l’espace client. Pour ajouter des informations, répondez dans le même ticket et conservez un environnement permettant de reproduire le problème. Si la location approche de son terme, exportez d’abord vos fichiers essentiels, puis vérifiez les modalités de renouvellement.

Les paiements acceptés pour les règlements en dollars sont USDT-TRC20 et les cartes Visa / Mastercard / Amex via Stripe. Les moyens disponibles dépendent de la passerelle renvoyée par le système. La confirmation peut dépendre des validations sur la blockchain ou du traitement par l’émetteur de la carte ; une capture d’écran ne prouve pas à elle seule que le paiement est confirmé.

Se connecter et ouvrir un ticket Contacter l’assistance par e-mail

Vérifiez également les règles du service

Au-delà des étapes techniques, vérifiez la durée de location et le nœud.

La connexion, le build et la commande sont des sujets distincts. Consultez la documentation correspondante pour vérifier les prérequis, puis choisissez entre poursuivre le diagnostic, ouvrir un ticket ou louer une autre machine.

Résoudre un problème

Vérifiez la location à la journée, les différences entre le navigateur et VNC, la facturation des options, les éléments de signature et le traitement des données à la fin de la location.

Consulter la FAQ

Choisir un nœud

Comparez les cinq nœuds en fonction de votre région et de votre façon de travailler. Les latences indicatives vous aident à choisir une direction ; votre expérience réelle dépend aussi de votre réseau.

Comparer les nœuds

Lire les conditions du service

Avant une longue compilation, vérifiez la période de facturation, le renouvellement, le traitement à l’échéance et les limites d’utilisation. Exportez à l’avance les fichiers irremplaçables.

Consulter les conditions du service

Vérifiez l’environnement avant le build ; en cas de blocage, fournissez les informations utiles.

Si vous avez déjà une commande, poursuivez dans l’espace client. Si vous n’avez pas encore loué de machine, choisissez d’abord une configuration et un nœud adaptés à votre projet. Sauvegardez vous-même le projet et les artefacts ; les tickets permettent de vérifier les problèmes liés à la machine et à la commande.

Louer un Mac cloud Accéder à l’espace client

Une fois le code terminé, que faire sur un Mac ?