Le projet Unreal Engine se construit sous Windows, mais le paquet iOS échoue au moment de la signature ou de l’appel à Xcode.
La solution la plus rapide consiste à configurer un Mac principal accessible en SSH pour la compilation iOS distante d’Unreal Engine 5.8. Une seule machine suffit généralement au départ ; ajoutez un Secondary Remote Mac seulement si la préparation du débogage doit être accélérée. Pour un projet C++, une publication signée ou un débogage Xcode, un Mac réel reste indispensable.
[ SECTION_01 ] Périmètre de cette configuration
Ce guide s’adresse à trois profils :
- les développeurs indépendants qui éditent leur projet Unreal Engine sous Windows et doivent produire une application iOS ;
- les ingénieurs de construction et les équipes DevOps qui veulent intégrer ce processus à un nœud partagé ou à une chaîne CI ;
- les responsables d’équipes mobiles qui hésitent entre l’achat d’un appareil Apple et l’utilisation périodique d’un Mac distant.
Le principe est de conserver sous Windows les tâches qui n’exigent pas l’environnement Apple : édition du code et des Blueprints, création des niveaux, préparation des ressources, itérations de gameplay et une partie du processus Cook. Le Mac prend ensuite le relais pour les éléments propres à iOS : compilation Apple, interaction avec Xcode, certificats, profils de provisioning, signature et validation du paquet.
Il faut également distinguer quatre fonctions souvent confondues :
| Élément | Responsabilités principales | Preuve attendue |
|---|---|---|
| Poste Windows | Édition Unreal Engine, ressources, déclenchement du build | Projet propre et commande distante lancée |
| Primary Mac | Outils Apple, compilation de référence, signature et archivage | Paquet signé et journal de compilation |
| Secondary Remote Mac | Préparation d’un environnement secondaire et certains tests | Données synchronisées et projet ouvrable |
| iPhone de test | Installation, exécution et observation du comportement réel | Application installée sur un appareil enregistré |
La documentation officielle d’Epic Games sur les compilations distantes de projets Unreal Engine pour iOS confirme la séparation entre le poste Windows et les Mac utilisés pour le processus Remote Mac Builds. Un bureau distant n’est pas, à lui seul, une compilation distante : il fournit une interface graphique, tandis que le système Unreal Engine doit encore transférer, construire et récupérer les artefacts.
[ SECTION_02 ] Scénarios de projet et limites techniques
Projet Blueprint-only
Un projet composé uniquement de Blueprints peut conserver un cycle d’itération largement centré sur Windows. Le besoin Mac apparaît lorsque le projet doit produire une application iOS, utiliser les outils Apple ou passer par une distribution destinée à des appareils enregistrés.
Cette configuration convient à un prototype qui alterne entre création de contenu et builds occasionnels. Elle ne dispense toutefois pas de vérifier la version d’Unreal Engine, la version de Xcode, le SDK cible et les appareils pris en charge dans la documentation applicable au moment du déploiement. La documentation iOS, iPadOS et tvOS d’Unreal Engine constitue le point de départ pour cette matrice.
Projet C++
Dès qu’un module C++ entre dans le projet, le Mac devient un nœud de compilation et non plus un simple poste de distribution. Les outils Apple, les en-têtes du SDK, Xcode et les bibliothèques nécessaires doivent fonctionner ensemble sur cette machine.
Le transfert du code depuis Windows ne transfère pas automatiquement les certificats, les clés privées ou les profils de provisioning. Ces éléments doivent former une chaîne cohérente dans le trousseau du compte de construction. Une connexion SSH réussie ne prouve donc pas que le projet sera compilable.
Test interne et publication
Un paquet de développement, un paquet destiné à des testeurs et une archive de publication ne répondent pas aux mêmes exigences. Le premier sert à valider le fonctionnement sur des appareils autorisés. Le second doit respecter la méthode de distribution retenue. Le dernier doit satisfaire les contrôles de signature et de soumission Apple.
La page Apple consacrée à la distribution d’une application vers des appareils enregistrés décrit le cadre des tests sur appareils autorisés. Pour la publication, il faut aussi surveiller les exigences d’App Store Connect : Apple indique notamment qu’une exigence de SDK s’applique à partir du 28 avril 2026 dans sa page officielle sur les prochaines exigences de publication. Cette date doit être vérifiée avant toute livraison planifiée.
[ SECTION_03 ] Matrice de versions et préparation du Primary Mac
La première erreur consiste à installer Xcode, Unreal Engine et les profils de signature séparément, puis à espérer que Windows corrigera les incompatibilités. La méthode fiable est inverse : partir du projet réel, relever la version d’Unreal Engine 5.8, déterminer la version de Xcode 26 et le SDK requis, puis contrôler la compatibilité dans les documents Epic et Apple publiés le jour de la configuration.
| Contrôle | Côté Windows | Côté Mac |
|---|---|---|
| Version du moteur | Projet Unreal Engine 5.8 identique au projet source | Version installée et chemin validé |
| Outils Apple | Aucun remplacement local complet | Xcode 26 et composants requis selon la matrice officielle |
| Code natif | Compilation déclenchée à distance | Compilation C++ exécutée localement au nœud |
| Signature | Identifiants transmis sans secret en clair | Certificat, clé privée et profil disponibles pour le compte |
| Appareil | Définition de la cible iOS | Enregistrement et validation lorsque le test le permet |
Les notes de version officielles d’Unreal Engine 5.8 doivent être relues pour les changements propres à cette version. Il ne faut pas remplacer une mention officielle par une recommandation de forum ou une correction non fusionnée. Les problèmes signalés par la communauté peuvent orienter le diagnostic, mais restent des informations non confirmées tant qu’ils ne figurent pas dans la documentation ou les notes de version.
Préparation du compte de construction
Sur le Mac principal, créez un compte dédié, par exemple <BUILD_USER>. Utilisez un chemin de projet neutre tel que <PROJECT_PATH> et un nom d’hôte tel que <PRIMARY_MAC_HOST>. Le compte doit accéder au répertoire de travail et aux outils requis, mais il ne doit pas être confondu avec le compte personnel d’administration.
Activez SSH sur le Mac, puis préparez une clé dédiée depuis Windows. La clé privée reste dans le coffre de l’environnement Windows ou de la CI ; seule la clé publique est déposée dans le fichier d’autorisation du compte <BUILD_USER>. Aucun identifiant Apple, mot de passe, certificat ou secret ne doit être écrit dans un script partagé.
La séquence de validation comporte plusieurs étapes concrètes :
- relever les versions installées sur le Mac et les comparer aux pages Epic et Apple ;
- ouvrir ou générer le projet depuis le Mac afin de vérifier que les outils Apple fonctionnent localement ;
- créer le compte
<BUILD_USER>et son répertoire de travail ; - générer la clé SSH sur Windows et installer sa partie publique ;
- tester une connexion non interactive vers
<PRIMARY_MAC_HOST>; - déclencher une opération Unreal Engine depuis Windows ;
- conserver le journal, le résultat de compilation et le chemin de l’artefact.
L’objectif n’est pas seulement d’obtenir une invite SSH. La première preuve utile est l’exécution d’une tâche distante avec retour d’un résultat exploitable. Si la connexion fonctionne mais que le transfert du projet échoue, l’arrêt doit intervenir avant la configuration de la CI.
Attention : une clé SSH valide ne donne ni accès à la clé privée de signature ni autorisation de publier. Ces trois sujets — transport, compilation et distribution — doivent être testés séparément.
[ SECTION_04 ] Signature, artefacts et débogage sur appareil
La signature doit rester une chaîne vérifiable sur le Mac. Le certificat de développement, la clé privée correspondante, le profil de provisioning et l’identifiant de paquet <BUNDLE_ID> doivent désigner le même projet et le même type de distribution.
Pour un test de développement, l’équipe peut utiliser un profil prévu pour les appareils enregistrés. Pour une archive de distribution, elle doit appliquer la méthode autorisée par Apple et vérifier l’archive produite. Les profils et certificats ne doivent pas être copiés en clair dans le dépôt Unreal Engine. Un trousseau séparé, un compte de construction isolé et des permissions limitées réduisent le risque de mélange entre projet de test et projet de publication.
La vérification doit produire des éléments observables :
- résultat de compilation C++ sur le Mac ;
- identité de signature correspondant à
<BUNDLE_ID>; - paquet ou archive généré dans
<ARTIFACT_PATH>; - contrôle de l’installation sur un appareil autorisé lorsque ce scénario est prévu ;
- validation Apple adaptée au type de distribution.
La documentation Epic sur la création de jeux mobiles rappelle que la cible mobile doit être testée au-delà de la seule génération du paquet. Une application qui se signe correctement peut encore rencontrer un problème de permissions, de ressources, de rendu ou de comportement sur appareil.
Secondary Remote Mac
Le Secondary Remote Mac répond à un besoin précis : préparer plus rapidement un environnement secondaire lorsque le Primary Mac a déjà généré les données nécessaires. Il ne doit pas être installé comme une solution de secours abstraite avant que le nœud principal ne soit fiable.
Le flux peut être organisé ainsi :
- le Primary Mac génère et valide les données de construction ;
- les caches et fichiers nécessaires sont synchronisés vers
<SECONDARY_MAC_HOST>; - le projet Xcode est généré selon la configuration validée ;
- l’appareil de test est connecté à un environnement qui peut réellement le voir ;
- l’équipe utilise « Run Without Building » lorsque les conditions de synchronisation sont remplies.
Cette dernière étape ne signifie pas que le Secondary Mac peut compiler n’importe quel état du projet. Si le code, les ressources, les profils ou les paramètres ont changé, l’artefact doit être régénéré et revalidé.
Un Mac hébergé dans un centre de données ne peut généralement pas accéder directement à l’iPhone posé près du développeur. Trois options restent réalistes : utiliser un Mac local auxiliaire pour l’installation et le débogage, déployer un accès matériel contrôlé, ou limiter le Mac distant à la compilation et à la signature. Cette limite doit être inscrite dans le cahier d’acceptation, au même titre que le résultat du build.
[ SECTION_05 ] Automatisation et nœud partagé
Une fois le build manuel validé, l’équipe peut déplacer l’exécution vers un nœud partagé ou un agent CI. Le script doit réutiliser un projet, un outil Apple et une configuration de signature déjà éprouvés. La première installation ne doit jamais être découverte dans une tâche sans surveillance.
| Risque | Contrôle demandé | Condition d’arrêt |
|---|---|---|
| Comptes mélangés | Un compte de construction par usage ou projet | Accès impossible à attribuer |
| Répertoire pollué | Workspace isolé avec nettoyage contrôlé | Artefacts d’un ancien build réutilisés |
| Certificat inaccessible | Trousseau et permissions testés par le compte CI | Signature impossible sans session interactive |
| Concurrence | Verrouillage ou files d’attente par workspace | Deux builds modifient les mêmes fichiers |
| Diagnostic incomplet | Journaux et artefacts conservés | Échec sans commande ni étape identifiable |
Le premier passage doit utiliser un workspace neuf. Le second doit reproduire le même projet dans un workspace contrôlé afin de détecter une dépendance cachée au cache. Le troisième doit vérifier la récupération après redémarrage du Mac ou de l’agent. Ces essais ne constituent pas une mesure de durée : aucun temps de compilation ne doit être généralisé sans mesure publiée par NOVAKVM sur une configuration précisément identifiée.
Le guide de référence des builds installés d’Unreal Engine est utile lorsque l’équipe veut standardiser un environnement de construction plutôt que dépendre d’une installation Unreal Engine propre à un poste de développeur.
[ SECTION_06 ] Choix d’architecture selon le projet
Le choix ne dépend pas uniquement de la puissance supposée de la machine. Il dépend surtout de la fréquence des builds, de la sensibilité des certificats, du besoin d’accès à un appareil et du nombre de personnes qui partagent le nœud.
| Architecture | Adaptée si | Limite principale |
|---|---|---|
| Un Primary Mac | Projet indépendant, builds planifiés, signature centralisée | Préparation du débogage moins parallèle |
| Primary Mac + Secondary Remote Mac | Plusieurs environnements doivent être préparés ou les équipes partagent les tâches | Synchronisation des données et des profils |
| Nœud Mac dédié à la CI | Builds récurrents, journalisation et accès contrôlé | Mise en place plus stricte des secrets et de la reprise |
| Poste Windows seul | Édition, Blueprints, ressources et itérations non liées à Apple | Impossible de remplacer la chaîne Mac pour le paquet iOS signé |
La décision peut être prise avec les conditions suivantes :
- Si le projet est Blueprint-only et produit rarement un paquet iOS, choisissez d’abord un Primary Mac utilisé à la demande ; ajoutez le débogage local séparément.
- Si le projet contient du C++ ou doit produire un paquet signé, choisissez un Primary Mac réel et validez localement la chaîne Apple avant toute automatisation.
- Si plusieurs builds doivent être isolés, passez à un nœud CI dédié ou à une séparation stricte des comptes et workspaces ; ne partagez pas un trousseau personnel.
- Si l’iPhone reste physiquement auprès des développeurs, conservez un Mac local auxiliaire ou un dispositif d’accès contrôlé ; un Secondary Remote Mac distant ne résout pas, à lui seul, l’accès matériel.
- Si les builds sont fréquents et concurrents, ajoutez une capacité secondaire seulement après avoir prouvé la synchronisation et la reprise du Primary Mac.
Cette méthode évite de confondre une capacité de compilation avec une capacité de débogage. Le Mac principal est le point de vérité. Le secondaire accélère certains usages, mais ne doit pas masquer une chaîne de signature mal définie.
[ SECTION_07 ] Dossier d’acceptation de livraison
Une chaîne de compilation iOS distante est acceptée lorsque le projet réel parcourt tout le cycle : déclenchement depuis Windows, transfert, compilation sur le Mac, signature, retour du paquet, puis installation ou archivage vérifiable. Une simple connexion SSH ou un journal sans erreur ne suffit pas.
Le dossier doit conserver :
- la matrice des versions Unreal Engine, macOS, Xcode et SDK, avec les liens Epic et Apple consultés ;
- le nom logique du nœud, le compte de construction et le chemin de workspace sous forme d’identifiants non sensibles ;
- le journal complet de compilation et la commande de déclenchement ;
- l’état de signature associé à
<BUNDLE_ID>; - le hash ou le contrôle d’intégrité de l’artefact ;
- la preuve d’installation sur appareil ou la preuve d’archivage ;
- la procédure de reprise après redémarrage ;
- la liste des éléments qui ne sont volontairement pas pris en charge, notamment l’accès direct à un iPhone distant.
Dernière mise à jour : 31 août 2026. Les informations de version, de Remote Mac Builds, de séparation Primary/Secondary et de publication ont été recoupées avec les documents officiels d’Epic Games et d’Apple Developer. Toute révision d’Unreal Engine 5.8, de Xcode 26 ou des exigences App Store Connect doit déclencher une nouvelle vérification.
[ SECTION_08 ] Questions fréquentes
Windows peut-il remplacer complètement le Mac pour un projet Unreal Engine iOS ?
Non. Windows reste parfaitement adapté à l’édition Unreal Engine, aux Blueprints, aux ressources et à une partie du processus Cook. En revanche, la compilation liée aux outils Apple, la signature avec clé privée, l’archivage et certaines opérations de validation doivent être exécutés dans l’environnement Mac requis. Le poste Windows déclenche donc le processus, mais ne remplace pas le nœud Apple.
Quelle est la bonne méthode pour tester une clé SSH Unreal Engine ?
La clé doit être dédiée au compte <BUILD_USER> et testée sans interaction, avec <PRIMARY_MAC_HOST> et <PROJECT_PATH> comme valeurs contrôlées. Il faut ensuite déclencher une véritable tâche Unreal Engine depuis Windows. Une session SSH ouverte manuellement ne vérifie ni le transfert du projet, ni les permissions du workspace, ni l’accès aux outils de signature.
Le Secondary Remote Mac peut-il devenir le seul Mac de l’équipe ?
Il ne devrait pas être considéré comme le seul nœud avant validation du flux principal. Sa fonction dépend de données générées par le Primary Mac et de leur synchronisation. Il peut convenir à la préparation d’un projet Xcode ou à certains tests, mais il ne remplace pas automatiquement le Mac de référence pour la compilation, la signature et la publication.
Pourquoi le paquet signé ne permet-il pas toujours de déboguer sur l’iPhone ?
Le paquet peut être correctement généré alors que l’iPhone reste inaccessible au Mac distant. Un hébergement en centre de données ne fournit généralement pas de liaison physique avec l’appareil du développeur. Il faut donc prévoir un Mac local auxiliaire, un accès matériel contrôlé ou un processus d’installation distinct. La preuve de signature ne constitue pas une preuve de débogage réel.
[ SECTION_09 ] Décision de déploiement et prochaine étape
Le poste Windows seul présente trois défauts concrets : il ne fournit pas la chaîne Xcode requise, il ne garde pas les clés Apple dans un environnement de construction adapté et il ne permet pas de valider seul le parcours d’installation sur iPhone. La location ou l’achat d’un Mac physique ajoute, de son côté, une immobilisation matérielle, une maintenance locale et une disponibilité moins souple pour un projet ponctuel.
Après vérification des versions et de la signature, une approche raisonnable consiste à utiliser NOVAKVM par période pour établir une chaîne de test Unreal Engine 5.8 avec un vrai projet, puis à conserver les preuves de compilation, de reprise et de retour des artefacts. Les équipes qui veulent comparer cette approche avec un appareil dédié peuvent consulter la page Mac mini pour une équipe de développement. Pour un besoin temporaire de build, de validation Xcode ou de préparation d’un futur nœud CI, la solution Mac distant de NOVAKVM permet ensuite de décider, sur des résultats observés, s’il faut rester sur un Primary Mac ou ajouter un nœud secondaire.