Un projet iOS de Godot 4.7 doit être exporté depuis un ordinateur sous macOS avec Xcode installé, selon la documentation officielle de l’exportation iOS de Godot 4.7. La conclusion est donc opérationnelle : le développement des scènes, du code et des ressources peut rester sous Windows ou Linux, mais l’exportation iOS, la compilation finale, la signature et la publication doivent rejoindre un Mac.
Pour un besoin ponctuel ou irrégulier, la location d’un Mac distant est généralement le choix le plus réversible. Une équipe qui utilise ce nœud de manière intensive et dispose déjà d’une compétence d’exploitation peut envisager l’achat d’un Mac physique. Pour une chaîne de production mixte, le schéma le plus équilibré consiste à conserver les tâches générales sur les nœuds existants et à réserver un nœud Mac contrôlé à la publication Apple.
Dernière mise à jour : 16 septembre 2026. Les informations de version ont été vérifiées dans les archives officielles de Godot ; les exigences Xcode et de soumission ont été recoupées avec la documentation Apple.
[ SECTION_01 ] À qui s’adresse cette décision ?
Ce guide concerne les développeurs de jeux travaillant principalement sous Windows ou Linux qui doivent livrer un projet Godot 4.7 sur iOS sans déplacer tout leur poste de travail.
Il s’adresse également aux ingénieurs de build qui séparent les tâches générales des opérations Apple sensibles, ainsi qu’aux responsables techniques qui doivent arbitrer entre location, achat et CI hybride.
La question n’est pas simplement de savoir si Godot s’ouvre sur une machine donnée. Il faut déterminer où chaque artefact est produit, où les identifiants de signature sont conservés et quel nœud peut reproduire la version publiée.
[ SECTION_02 ] Le véritable périmètre Mac de Godot 4.7
Le projet Godot, les scènes, les scripts et la plupart des ressources restent indépendants du système d’exploitation. En revanche, plusieurs étapes souvent confondues relèvent de macOS et d’Xcode :
- édition du projet et préparation des ressources ;
- génération du projet Xcode par Godot ;
- compilation du projet Xcode ;
- signature de l’application et de ses extensions éventuelles ;
- création de l’archive ;
- distribution vers un appareil enregistré ou vers App Store Connect.
Générer un dossier Xcode n’est donc pas synonyme de livraison iOS. Le dossier est un intermédiaire. Il doit encore être ouvert ou traité par la chaîne Xcode, recevoir une configuration de signature cohérente, produire une archive exploitable et être vérifié selon le canal de distribution visé.
La documentation officielle de Godot 4.7 impose un ordinateur macOS équipé d’Xcode pour l’exportation iOS. La page d’archive officielle indique par ailleurs que Godot 4.7.2 est la version stable de maintenance 4.7 au 16 septembre 2026, tandis que les versions de développement ne doivent pas être assimilées à une base de production : archive officielle Godot 4.7.2.
Windows peut-il produire directement l’application iOS ?
Windows ou Linux peuvent conserver le dépôt Git, l’édition des scripts, la création des scènes, la préparation audio et vidéo, ainsi que les builds destinés à d’autres plateformes. Ils peuvent aussi déclencher un job distant.
Ils ne remplacent toutefois pas le nœud macOS nécessaire à l’exportation iOS complète. La bonne organisation consiste à transmettre au Mac un état reproductible du projet, plutôt qu’à essayer de transformer le poste principal en environnement Apple.
Cela est particulièrement utile pour les équipes créatives : les artistes peuvent continuer à préparer les textures, les bandes-son ou les séquences vidéo sur leur poste habituel, pendant que le Mac ne reçoit que le projet validé et les ressources nécessaires à la cible iOS.
L’installation complète d’Xcode est-elle nécessaire ?
Le seuil officiel n’est pas « un simple dossier Xcode généré ». Godot demande un Mac sous macOS avec Xcode installé. Les composants réellement nécessaires dépendent ensuite de la cible, du SDK utilisé, des simulateurs requis et des opérations de test.
La version de macOS doit être compatible avec la version d’Xcode retenue. Les exigences système d’Xcode doivent donc être consultées avant de réserver un nœud : configuration système requise par Xcode. Un nœud qui permet seulement d’ouvrir l’éditeur Godot, mais qui ne permet pas d’installer ou de sélectionner la version Xcode attendue, doit être écarté.
[ SECTION_03 ] Premier contrôle : la maîtrise de l’environnement
La différence entre un Mac utilisable et un Mac réellement exploitable en CI tient au contrôle accordé à l’équipe. Avant de déplacer un projet, il faut obtenir des réponses vérifiables sur les points suivants :
- La version de Godot 4.7 nécessaire peut-elle être installée sans remplacer une configuration partagée ?
- Le modèle d’exportation iOS correspondant est-il disponible et conservé avec le projet ?
- La version Xcode prévue peut-elle être installée et sélectionnée ?
- Les modules, extensions natives et outils du projet peuvent-ils être ajoutés avec les droits nécessaires ?
- Les variables sensibles peuvent-elles rester hors du dépôt ?
- Un nouvel espace de travail peut-il être initialisé sans intervention graphique obligatoire ?
- Le nœud conserve-t-il son état après une reconnexion SSH ou un redémarrage ?
La fixation des versions est plus importante que la simple présence de l’application. Le chemin actif d’Xcode doit être explicite avec xcode-select, les commandes doivent fonctionner sans dialogue bloquant et le projet doit pouvoir être reconstruit dans un espace propre.
La commande d’exportation de Godot peut être intégrée à une automatisation, mais elle ne supprime pas les étapes Xcode qui suivent. La documentation Godot sur l’exportation en ligne de commande sert de référence pour séparer le projet source, le préréglage d’exportation et le répertoire de sortie.
Particularité des projets C
Un projet GDScript et un projet C# ne doivent pas être évalués avec la même hypothèse. La documentation iOS de Godot 4.7 précise le périmètre de prise en charge et les éventuelles limites expérimentales. Cette indication doit primer sur les témoignages trouvés dans des forums.
Avant de choisir le nœud de publication, l’équipe doit donc vérifier la prise en charge exacte de la version Godot retenue, du langage C#, des extensions natives et des modules utilisés. Si un composant C# ou un plugin impose une étape non documentée, il faut le tester dans un projet représentatif avant de promettre une CI sans intervention.
Le résultat attendu n’est pas « le projet s’exporte sur le poste d’un développeur ». Il est plutôt : « le même dépôt, avec la même version de Godot, le même préréglage et les mêmes dépendances, produit un projet Xcode exploitable sur un nœud propre ».
[ SECTION_04 ] Deuxième contrôle : la signature et la publication
La chaîne Apple doit être découpée en objets distincts. Les valeurs réelles doivent rester dans le coffre ou dans les variables protégées ; les exemples de procédure doivent utiliser des espaces réservés tels que <BUNDLE_ID>, <TEAM_ID>, <CERTIFICAT> et <PROFIL>.
Le parcours logique est le suivant :
- le projet reçoit un identifiant de paquet tel que
<BUNDLE_ID>; - le compte Apple fournit l’équipe associée à
<TEAM_ID>; - le certificat et sa clé privée sont importés uniquement sur le nœud autorisé ;
- le profil de provisioning correspond à l’application et au canal choisi ;
- Xcode compile et signe l’application ;
- l’archive est contrôlée avant distribution ;
- l’envoi vers App Store Connect intervient depuis le nœud de publication autorisé.
L’automatisation de la signature réduit les actions manuelles, mais elle augmente l’importance de la gestion des permissions. La signature automatique peut simplifier la première configuration, tandis que la signature manuelle donne davantage de visibilité sur les profils et les certificats. Dans les deux cas, les cibles secondaires doivent être inspectées séparément : extension, module natif ou composant additionnel peuvent posséder leur propre état de signature.
La documentation Apple consacrée à la distribution vers des appareils enregistrés explique les exigences de cette étape : distribution Xcode vers des appareils enregistrés. La publication sur la plateforme de distribution doit ensuite être traitée comme une opération distincte : soumission dans App Store Connect.
La règle de sécurité est simple : les actifs de signature ne doivent pas être copiés sur tous les nœuds. Le traitement général des ressources, les builds non Apple et les contrôles de qualité peuvent rester sur les nœuds communs. Le certificat et la clé privée doivent rejoindre uniquement le nœud de publication contrôlé.
[ SECTION_05 ] Troisième contrôle : les preuves de test
Un export réussi ne prouve pas qu’un jeu est livrable. Le contrôle doit commencer par l’ouverture du projet Xcode généré, continuer avec une compilation réelle et se terminer par la production d’un artefact conforme au canal visé.
Trois niveaux de preuve doivent être distingués :
- Mac Apple Silicon : vérifie que le projet, les outils et les extensions natives s’exécutent sur le nœud de compilation ;
- simulateur iOS : vérifie certains comportements d’interface et d’exécution sans remplacer le matériel réel ;
- appareil iOS physique : vérifie les interactions matérielles, les permissions, certains comportements graphiques, les notifications et les services qui nécessitent un appareil.
Aucun de ces niveaux ne remplace intégralement les deux autres. Apple distingue elle-même l’exécution sur appareils simulés et physiques dans sa documentation de test Xcode.
Le niveau de validation doit suivre le risque du jeu. Un projet utilisant une entrée tactile simple n’a pas le même profil qu’un titre intégrant une extension native, un service de paiement, des contrôleurs, de l’audio temps réel ou un pipeline vidéo. Les plugins Godot, les shaders, les fonctions graphiques et les services de plateforme doivent être testés sur la cible qui peut réellement révéler leur défaut.
[ SECTION_06 ] Comparaison des architectures de build
Le tableau suivant évalue les options selon des critères d’exploitation, et non selon le seul fait qu’un Mac soit disponible.
| Option | Environnement Godot et Xcode | Signature et publication | Effort d’exploitation | Score de décision |
|---|---|---|---|---|
| Mac distant loué | Contrôle variable selon les droits ; validation indispensable avant engagement | Possible si les identifiants restent sur un nœud contrôlé | Faible à modéré ; remplacement plus simple | 4/5 pour un besoin court ou irrégulier |
| Mac physique acheté | Contrôle maximal de la version et des extensions | Adapté à une équipe qui gère elle-même les clés et les accès | Maintenance, sauvegardes et remplacement à la charge de l’équipe | 4/5 pour une utilisation fréquente et stable |
| Nœud commun plus Mac de publication | Tâches générales séparées des outils Apple | Surface sensible limitée au nœud Mac | Pipeline plus complexe, mais pannes mieux isolées | 5/5 pour une production structurée |
| Mac partagé non versionné | Reproductibilité faible | Risque élevé de profils, clés ou réglages résiduels | Débogage difficile | 1/5, à écarter |
La location ne devient intéressante que si le fournisseur permet de vérifier les versions, les extensions, les droits d’installation et la persistance de l’environnement. À l’inverse, l’achat ne résout pas automatiquement la signature : il transfère à l’équipe la responsabilité des certificats, des sauvegardes, des comptes et des mises à jour.
Pour une équipe qui doit comparer un achat de Mac mini à une solution distante, il est préférable d’examiner séparément le matériel, l’espace occupé, le remplacement en cas de panne et le temps d’administration. Une analyse d’achat de Mac mini peut servir de point de départ, mais elle ne remplace pas un test du projet Godot réel.
[ SECTION_07 ] Quatrième étape : construire une CI récupérable
Une CI iOS fiable ne se limite pas à lancer une commande sur une machine allumée. Elle doit conserver les journaux, archiver les artefacts, signaler l’échec et reprendre après une interruption.
Le flux recommandé sépare les responsabilités :
- Le nœud général récupère le commit et exécute les contrôles qui ne dépendent pas d’Apple.
- Le pipeline transmet au nœud Mac un état identifié du dépôt et le préréglage d’exportation.
- Godot génère l’artefact Xcode dans un répertoire de travail propre.
- Xcode compile, signe et crée l’archive avec les variables protégées.
- Le pipeline conserve l’archive, les journaux et les métadonnées utiles au diagnostic.
- Une étape distincte autorise la distribution vers App Store Connect.
Les préréglages d’exportation doivent être versionnés avec le projet, mais les certificats, clés privées, profils et jetons ne doivent pas l’être. Les variables sensibles doivent être injectées au dernier moment sur le nœud de publication.
Un auto-hébergeur peut être rattaché à une chaîne CI, à condition de contrôler son accès, ses étiquettes et son état de nettoyage. Les principes de placement et d’utilisation d’un runner auto-hébergé sont décrits dans la documentation GitHub Actions sur les runners auto-hébergés. Le nom du fournisseur de CI importe moins que la capacité à isoler les secrets et à empêcher une tâche non autorisée d’atteindre la clé de signature.
Les contrôles de reprise à effectuer
Avant la mise en production, l’équipe doit provoquer ou simuler plusieurs incidents :
- déconnexion SSH pendant la génération de l’artefact ;
- échec de compilation Xcode ;
- répertoire de travail laissé dans un état incomplet ;
- redémarrage du Mac avant la publication ;
- expiration ou remplacement d’un profil de provisioning ;
- absence d’un plugin ou d’un modèle d’exportation ;
- restauration sur un espace de travail propre.
Un Mac en ligne n’est pas nécessairement un Mac capable d’exécuter le job. La reprise doit être documentée : nettoyage, réinstallation des dépendances, resélection de la version Xcode, récupération des secrets et relance contrôlée.
Un accès distant via SSH convient aux commandes et aux journaux. Une interface graphique distante peut être nécessaire pour diagnostiquer un réglage Xcode ou un comportement visuel. Le choix entre SSH, VNC et console web doit suivre la tâche, et non une préférence générale.
[ SECTION_08 ] Cinquième étape : choisir selon la charge et la durée
Le modèle économique doit intégrer plus que le tarif d’accès. Les variables à inscrire dans le calcul sont :
- durée de location ou période d’amortissement de l’achat ;
- temps initial de préparation de Godot, des modèles et d’Xcode ;
- temps d’inactivité du nœud ;
- coût d’un remplacement ou d’une solution de secours ;
- gestion des certificats et des profils ;
- sauvegarde des archives ;
- temps d’administration ;
- coût d’une panne pendant une fenêtre de publication.
Aucun montant générique ne permet de trancher sans connaître la fréquence des versions, la taille de l’équipe et le niveau de contrôle requis. Une machine achetée peut être moins pertinente si elle reste inactive entre deux publications. Une location peut devenir moins avantageuse si le nœud est utilisé en permanence et si l’équipe sait déjà l’administrer.
| Profil de charge | Architecture conseillée | Pourquoi | Condition d’arrêt |
|---|---|---|---|
| Portage court ou publication occasionnelle | Mac distant loué | Évite un achat avant validation de la chaîne | Le fournisseur ne permet pas de fixer l’environnement |
| Itérations régulières mais variables | Mac distant réservé ou CI hybride | Adapte le coût à la charge et garde un nœud Apple disponible | Les files d’attente ou réinitialisations empêchent la reproductibilité |
| Utilisation élevée et continue | Mac physique acheté ou nœud dédié | Justifie le contrôle direct et la stabilité opérationnelle | L’équipe ne peut pas assurer mises à jour, sauvegardes et remplacement |
| Tâches générales nombreuses, publication Apple ponctuelle | Nœuds communs plus Mac de publication | Réduit la surface sensible et sépare les responsabilités | Le pipeline ne sait pas transférer proprement les artefacts |
Dans le premier cas, NOVAKVM peut servir à réaliser une première construction réversible : le projet réel est copié sur un Mac distant, le modèle d’exportation est installé, Xcode est configuré, puis le redémarrage et la signature sont vérifiés avant de choisir une durée plus longue. Les équipes qui souhaitent examiner les offres disponibles peuvent consulter la page française de NOVAKVM, sans confondre cette consultation avec la validation technique du projet.
[ SECTION_09 ] La décision finale pour une équipe Godot
Le choix peut être résumé par trois règles :
- Si le projet doit être porté rapidement, si la fréquence de publication reste incertaine ou si l’équipe ne possède pas encore de Mac, commencez par un Mac distant. Exigez un essai sur le dépôt réel, pas sur un projet vide.
- Si le projet produit continuellement des versions iOS, si les dépendances sont stables et si l’équipe peut gérer le système, l’achat d’un Mac physique devient défendable.
- Si les tests, l’analyse du code et les builds non Apple consomment déjà des nœuds généraux, placez uniquement l’exportation Xcode, la signature et la publication sur un Mac dédié. Cette CI hybride limite l’exposition des secrets et réduit le rayon d’impact d’une panne.
Le projet doit être déclaré livrable seulement lorsque l’exportation Godot, l’ouverture Xcode, la compilation, la signature, le test adapté et la récupération après redémarrage ont tous été vérifiés. La génération d’un dossier de sortie ne suffit pas.
Pour une équipe qui travaille encore sous Windows ou Linux, le Mac distant évite surtout un mauvais investissement initial : achat d’une machine peu utilisée, environnement installé une seule fois puis oublié, ou certificats dispersés sur plusieurs postes. Ses limites restent réelles : dépendance à la qualité de l’accès distant, nécessité de contrôler les droits et risque d’un environnement mal versionné. Dans ce contexte, louer un Mac auprès de NOVAKVM offre une étape de validation plus souple qu’un achat immédiat, à condition de conserver une procédure de reprise et de tester le projet Godot 4.7 avant de s’engager sur une durée longue.
La méthode la plus sûre consiste donc à exécuter un premier build réversible, à vérifier le modèle d’exportation, la version Xcode, la signature, l’artefact final et la reprise après redémarrage, puis à choisir entre location prolongée, achat physique ou architecture hybride en fonction de la charge réellement observée.