Compilation iOS Unity 6.3 LTS : comment compiler sous Windows en 2026 ?

Le numéro de version 6000.3.0f1 correspond à la publication de Unity 6.3 LTS dans les notes officielles de Unity (notes de version Unity 6000.3.0f1). Cela ne signifie toutefois pas qu’un PC Windows peut produire seul une application iOS téléversable : Windows peut préparer le projet Unity et générer le projet Xcode, tandis que macOS reste nécessaire pour compiler avec Xcode, créer l’archive, signer l’application et l’envoyer vers App Store Connect. Pour une publication occasionnelle, transférez le projet Xcode vers un Mac distant ; pour des livraisons fréquentes, synchronisez les sources sur un Mac distant permanent et automatisez l’export Unity puis la compilation Xcode.

Cette méthode répond à trois cas précis :

• vous développez principalement sous Windows et préparez votre première version iOS ;
• votre petite équipe doit produire régulièrement des versions TestFlight sans acheter ni administrer un Mac physique ;
• vous transformez une suite d’actions manuelles en tâche de construction distante, rejouable après une modification du code, d’un module natif ou des identifiants de signature.

Dernière mise à jour : 29 août 2026. Les points relatifs à Unity 6.3, au processus iOS, à Xcode et à l’envoi des builds doivent être revérifiés dans la documentation officielle du processus de compilation iOS de Unity et dans les pages Apple liées à la distribution avant chaque mise en production.

Le premier risque vient d’une confusion de vocabulaire. « Construire pour iOS » recouvre en réalité plusieurs opérations distinctes :

1. Unity prépare les scènes, les scripts, les ressources et les bibliothèques nécessaires ;
2. Unity génère un projet Xcode ;
3. Xcode compile ce projet avec les outils Apple ;
4. la chaîne Apple applique la signature et les entitlements ;
5. une archive distribuable est validée puis envoyée à App Store Connect ;
6. App Store Connect traite le fichier avant de l’afficher pour TestFlight.

La description Unity des deux étapes de construction iOS confirme cette séparation entre la génération du projet Xcode et la construction finale de l’application. Un export réussi sur Windows ne prouve donc ni que le code natif compile, ni que le certificat est exploitable, ni que le build sera accepté par App Store Connect.

Windows peut-il produire directement un fichier IPA ?

Non, pas dans le sens d’un flux complet et autonome. Windows peut servir à développer le jeu, gérer les fichiers du projet et, si les modules requis sont installés, produire les fichiers d’un projet Xcode. La compilation finale dépend ensuite de macOS et de Xcode.

La conséquence pratique est simple : ne cherchez pas à résoudre une erreur de signature comme s’il s’agissait d’un problème Unity. Il faut d’abord déterminer si l’échec se produit pendant l’export Unity, pendant la compilation Xcode, pendant la signature, pendant l’envoi ou durant le traitement côté App Store Connect.

Pour un projet audio, vidéo ou très riche en ressources, cette distinction évite également de transférer inutilement tout l’environnement de développement. Le PC Windows peut rester le poste de création, tandis que le Mac distant ne reçoit que ce qui est nécessaire à la production iOS — ou récupère les sources lorsqu’une reconstruction complète est préférable.

Avant d’importer le projet de production, créez un petit projet de validation. L’objectif n’est pas de tester le gameplay, mais de prouver que la chaîne minimale fonctionne sur les deux systèmes.

Liste de contrôle de la première heure

• [ ] relever précisément l’éditeur Unity utilisé, notamment la branche Unity 6.3 LTS ;
• [ ] vérifier que iOS Build Support est installé dans l’environnement Windows ;
• [ ] contrôler l’architecture du Mac distant et la version de macOS disponible ;
• [ ] choisir une version de Xcode compatible avec la cible iOS et les exigences actuelles de distribution ;
• [ ] enregistrer le chemin de Xcode sélectionné sur le Mac ;
• [ ] figer le fichier de verrouillage des paquets Unity ;
• [ ] confirmer la version du projet dans le système de contrôle de version ;
• [ ] tester un projet vide avant d’importer les plugins natifs ;
• [ ] conserver un journal de l’export, de la compilation et des options choisies.

Les exigences générales de Unity 6 doivent être contrôlées dans la page officielle des prérequis système. Elles ne remplacent pas la vérification de la compatibilité entre une version donnée de Unity, le SDK iOS fourni par Xcode et les plugins utilisés par votre application. Les contraintes de distribution peuvent évoluer lorsque Apple modifie les versions de Xcode acceptées ; une configuration valable pour un ancien cycle de publication ne doit donc pas être traitée comme une règle permanente.

Attention : n’enregistrez pas seulement « Unity 6.3 » dans votre documentation interne. Notez le numéro complet de l’éditeur, l’état des paquets, le chemin Xcode et les scripts de post-traitement. Une mise à jour silencieuse d’un paquet peut modifier le projet Xcode sans modifier vos scènes.

Le projet vide doit aller jusqu’à la compilation en ligne de commande sur le Mac. Vous pouvez par exemple utiliser des variables explicites plutôt que des valeurs ambiguës :

export PROJET_NOM="<NOM_PROJET>"
export CHEMIN_PROJET="<CHEMIN_PROJET_XCODE>"
export SCHEME_NOM="<NOM_SCHEME>"
export CONFIGURATION_NOM="<Debug_ou_Release>"

xcodebuild \
  -project "$CHEMIN_PROJET/<NOM_PROJET>.xcodeproj" \
  -scheme "$SCHEME_NOM" \
  -configuration "$CONFIGURATION_NOM" \
  -destination "generic/platform=iOS" \
  build

Ce test ne constitue pas encore une publication. Il vérifie uniquement que le projet généré peut être compris par Xcode. Les noms de projet, chemins, identifiants, certificats et secrets doivent rester des variables ou des références sécurisées, jamais des valeurs copiées dans un script partagé.

Deux méthodes sont valables, mais elles ne répondent pas au même rythme de publication.

Option A — transférer le projet Xcode déjà généré

Cette méthode convient à une sortie ponctuelle ou à un prototype proche de sa version finale :

1. ouvrir le projet Unity sous Windows ;
2. sélectionner la plateforme iOS et vérifier les paramètres de build ;
3. générer un nouveau projet Xcode dans un répertoire de sortie dédié ;
4. attendre la fin complète de l’export ;
5. compresser ou synchroniser l’intégralité du répertoire généré ;
6. transférer ce répertoire vers le Mac distant ;
7. vérifier les bibliothèques, les frameworks, les ressources et les scripts de post-traitement ;
8. ouvrir le projet dans Xcode, puis compiler avant de configurer la distribution.

Ne transférez pas uniquement le fichier .xcodeproj. Selon les plugins, le projet peut dépendre de dossiers, de bibliothèques natives, de fichiers de configuration ou d’un espace de travail généré. Les liens symboliques, les scripts exécutables et les résultats d’un post-traitement doivent également être contrôlés après le transfert.

Cette solution limite le travail demandé au Mac distant, mais elle rend la reproduction plus fragile : si le projet Xcode a été modifié manuellement, il devient difficile de savoir quelle modification sera écrasée lors du prochain export Unity.

Option B — synchroniser les sources et réexporter sur le Mac

Pour une publication régulière, cette méthode est généralement plus propre. Le Mac distant récupère le projet Unity, installe ou sélectionne la version attendue de l’éditeur, restaure les paquets, exécute l’export iOS, puis transmet le résultat à Xcode.

Un flux contrôlé peut ressembler à ceci :

export UNITY_EXECUTABLE="<CHEMIN_EDITEUR_UNITY>"
export PROJET_UNITY="<CHEMIN_PROJET_UNITY>"
export SORTIE_XCODE="<CHEMIN_SORTIE_XCODE>"
export SCRIPT_EXPORT="<NOM_SCRIPT_EXPORT>"

"$UNITY_EXECUTABLE" \
  -batchmode \
  -quit \
  -projectPath "$PROJET_UNITY" \
  -executeMethod "<NAMESPACE>.<CLASSE>.<METHODE>" \
  -buildTarget iOS \
  -buildPath "$SORTIE_XCODE" \
  -logFile "<CHEMIN_LOG_UNITY>"

La classe appelée doit être fournie par votre projet et non supposée par le script. Elle doit fixer les scènes, les options de build, l’identifiant d’application et les réglages spécifiques à votre pipeline.

Le tableau suivant aide à décider sans mélanger les deux modèles :

Le Mac distant doit-il avoir l’éditeur Unity complet ?

Cela dépend du chemin retenu. Si Windows génère le projet Xcode et que le Mac ne fait que compiler, signer et archiver, l’éditeur Unity complet n’est pas nécessaire pour cette étape. En revanche, une construction continue depuis les sources exige sur le Mac les composants Unity appropriés, notamment l’éditeur utilisé par le projet et le support iOS.

Cette différence est importante pour le budget et pour la maintenance. Installer seulement Xcode convient à un relais de compilation ; installer Unity et les paquets nécessaires convient à un véritable serveur de construction. Dans les deux cas, les plugins natifs doivent être compatibles avec le mode d’exécution retenu.

Ne générez jamais simultanément la même sortie Xcode depuis Windows et depuis le Mac. Choisissez un propriétaire de la sortie, supprimez ou archivez l’ancien répertoire avant un nouvel export, et ne corrigez pas manuellement sur le Mac un fichier que l’export Unity recréera ensuite.

Une fois le projet Xcode disponible, commencez par une compilation simple. Cette étape doit précéder la configuration complète de la distribution, car elle permet de distinguer une erreur de code natif d’un problème de certificat.

Vérifiez ensuite les éléments suivants :

• l’équipe Apple sélectionnée dans les réglages de signature ;
• le Bundle ID exact, identique à celui déclaré dans l’espace développeur ;
• les entitlements réellement utilisés par le jeu ou l’application ;
• le certificat de distribution et sa clé privée ;
• le profil de provisioning approprié ;
• les capacités activées pour les notifications, achats, accès réseau ou services associés ;
• les bibliothèques et frameworks ajoutés par les plugins Unity ;
• les scripts PostProcessBuild et leurs chemins ;
• CocoaPods, si un plugin l’exige ;
• les réglages propres à Release plutôt qu’à Debug.

La page Apple consacrée à la préparation d’une application pour la distribution décrit les contrôles à effectuer dans Xcode. Pour le diagnostic, la documentation Apple sur le test d’un build de distribution aide à séparer compilation, exécution et préparation de la version distribuable.

Expérience de maintenance : si l’export Unity réussit mais que Xcode échoue sur un framework, une capacité ou une signature, conservez le log Unity et le log Xcode séparément. Refaire tout l’export sans examiner le premier échec augmente le temps de diagnostic et peut masquer la cause initiale.

Le premier jalon utile n’est pas « Xcode s’ouvre » mais « une archive distribuable est générée avec les bons paramètres ». Utilisez des variables pour les valeurs sensibles :

export ARCHIVE_PATH="<CHEMIN_ARCHIVE>/<NOM_APPLICATION>.xcarchive"
export EXPORT_PATH="<CHEMIN_EXPORT>"
export EXPORT_OPTIONS="<CHEMIN_EXPORT_OPTIONS_PLIST>"

xcodebuild \
  -project "<CHEMIN_PROJET_XCODE>/<NOM_PROJET>.xcodeproj" \
  -scheme "<NOM_SCHEME>" \
  -configuration "Release" \
  -destination "generic/platform=iOS" \
  archive \
  -archivePath "$ARCHIVE_PATH"

xcodebuild \
  -exportArchive \
  -archivePath "$ARCHIVE_PATH" \
  -exportPath "$EXPORT_PATH" \
  -exportOptionsPlist "$EXPORT_OPTIONS"

Ne placez pas le mot de passe du trousseau, la clé privée ou la clé API directement dans le dépôt. Le Mac distant doit disposer d’un stockage de secrets restreint, de journaux qui masquent les valeurs sensibles et d’une procédure de révocation lorsque l’accès n’est plus nécessaire.

Pour approfondir un échec précis, consultez également notre guide consacré au diagnostic des erreurs de signature iOS si votre équipe dispose déjà d’un accès aux ressources techniques de JEXCLOUD.

L’archive obtenue n’est pas encore une version visible par les testeurs. Le flux doit être suivi en quatre états distincts :

1. le projet compile ;
2. l’archive est signée ;
3. le build est envoyé ;
4. App Store Connect termine son traitement.

Apple détaille le flux de distribution dans la page distribuer une application pour les tests bêta et les versions publiques. Pour l’envoi, suivez la procédure officielle de téléversement des builds vers App Store Connect.

Avant l’envoi, contrôlez :

• l’existence de la fiche de l’application dans App Store Connect ;
• la concordance du Bundle ID ;
• le numéro de version ;
• le numéro de build ;
• l’équipe et les droits associés ;
• la destination TestFlight souhaitée.

Si le build n’apparaît pas immédiatement, ne changez pas au hasard de certificat et ne relancez pas tout le pipeline. Consultez le journal de livraison et l’état affiché par App Store Connect. La référence Apple des états de traitement et d’envoi indique comment interpréter un traitement en cours, un échec ou une version disponible.

Pour une application de jeu, vérifiez aussi le comportement d’un build Release sur un appareil réel : les chemins de ressources, les vidéos intégrées, les fichiers audio compressés et les permissions peuvent se comporter différemment d’une exécution dans l’éditeur. Un build TestFlight valide sur le plan administratif ne garantit pas à lui seul que le contenu créatif se charge correctement.

Après le premier envoi, séparez le pipeline en unités relançables :

• export Unity ;
• validation du projet Xcode ;
• compilation ;
• archive ;
• signature et export ;
• envoi ;
• contrôle du traitement App Store Connect.

Chaque étape doit produire un log et un artefact identifiables. Les caches accélèrent parfois les exécutions, mais ils doivent avoir une limite de nettoyage : conservez les caches nécessaires à la répétition, supprimez ceux qui peuvent contenir un état obsolète, et archivez séparément l’archive distribuée ainsi que ses métadonnées de build.

Pendant la première semaine, exécutez trois scénarios contrôlés :

• une modification de code sans changement de plugin ;
• une modification ou un remplacement de plugin natif ;
• une exécution avec un certificat, un profil ou une clé API volontairement indisponible.

Le premier scénario vérifie le chemin nominal. Le second révèle les dépendances cachées dans le post-traitement Xcode. Le troisième confirme que l’échec est explicite et que les secrets peuvent être remplacés sans modifier le projet.

Pour les projets qui publient souvent, notre guide sur la conception d’un serveur de build iOS automatisé et récupérable peut servir de prolongement méthodologique. Si l’équipe ne veut pas administrer elle-même chaque composant de l’environnement, elle peut aussi évaluer une location de Mac distant pour les builds iOS, en commençant par un vrai projet plutôt qu’un exemple vide.

Le transfert d’un projet Xcode reste pertinent lorsque les publications sont rares, que la génération Windows est stable et que le Mac n’a pas à reproduire l’environnement Unity complet. Il devient moins intéressant lorsque chaque livraison impose de refaire manuellement l’export, de corriger des plugins ou de retrouver un état Xcode particulier.

Un Mac distant permanent est plus cohérent lorsque :

• plusieurs versions TestFlight sont produites régulièrement ;
• l’équipe veut conserver les caches et les journaux au même endroit ;
• Unity, Xcode et les outils natifs doivent être rejoués dans un environnement stable ;
• le dépôt doit déclencher une construction sans dépendre du poste Windows d’un seul développeur.

L’achat d’un Mac physique garde du sens pour une charge lourde et durable, pour les tests avec des périphériques physiques ou lorsque l’équipe doit accéder directement à l’appareil et au réseau local. À l’inverse, une solution distante est moins adaptée si le projet exige une interface matérielle particulière, une latence minimale pour des tests interactifs ou une présence locale permanente.

Pour un développeur Unity travaillant sous Windows, le poste actuel présente trois limites concrètes : il ne couvre pas la phase Xcode finale, il oblige à organiser manuellement le passage du projet généré et il rend la signature dépendante d’un environnement Apple qui n’est pas toujours disponible au moment de la livraison. Une location JEXCLOUD permet de réserver cet environnement uniquement lorsque le projet en a besoin, puis de passer à une durée plus longue si les essais montrent qu’un Mac permanent simplifie réellement l’export, l’archive et l’envoi.

La meilleure décision consiste à prendre une version réelle, à vérifier successivement l’export Unity, la compilation Xcode, l’archive signée et le traitement TestFlight, puis à choisir une location temporaire ou permanente selon la fréquence observée. Cette validation évite de payer pour une configuration surdimensionnée tout en évitant de découvrir, le jour de la publication, que le transfert du projet Xcode ne reproduit pas les plugins et les secrets nécessaires.