À partir de la version 5.3, l'Unreal Engine (UE) met à jour le flux de travail des projets Xcode pour améliorer la cohérence avec les projets d'application Xcode standard. La nouvelle configuration de projet optimise l'organisation et la qualité de vie des développeurs Xcode. Elle leur donne accès à divers outils intégrés qui simplifient la signature de code et le provisionnement, notamment :
La signature de code automatique
La gestion des droits
La modification de fichiers
.plistGestion du framework Xcode standard
Cette page offre un aperçu des changements pour les utilisateurs qui passent à UE 5.3 ou à une version ultérieure (5.3+).
Conditions préalables
Le flux de travail relatif à Xcode mis à jour est disponible dans UE 5.3 et les versions ultérieures. Il est activé par défaut pour les nouveaux projets. Pour l'activer manuellement, procédez comme suit :
Ouvrez le répertoire d'installation du moteur, puis ouvrez
Engine/Config/BaseEngine.iniet veillez à sélectionner la variable de configuration suivante :Engine/Config/BaseEngine.ini
C++[/Script/MacTargetPlatform.XcodeProjectSettings] bUseModernXcode=trueRégénérez les fichiers de projet Xcode pour le moteur et pour le projet. Si vous utilisez une compilation source de l'UE, exécutez le script
GenerateProjectFiles.commandsitué dans le répertoire d'installation du moteur afin de régénérer les fichiers de projet pour le code source de l'UE. Dans le répertoire de votre projet, vous devriez voir les trois fichiers d'espace de travail Xcode suivants :UE5 (Mac).xcworkspaceUE5 (TVOS).xcworkspaceUE5 (IOS).xcworkspace
Vous pouvez à présent utiliser la nouvelle configuration de Xcode. Dans les sections suivantes, vous trouverez une description des nouveautés par rapport à l'ancien projet.
Projets, schémas et configurations de compilation
Dans les versions antérieures, les projets Xcode de l'UE combinaient des cibles et des configurations de compilation sous les schémas. Par exemple, sous un même projet (MyProject), les utilisateurs disposaient d'un schéma "Development Editor" qui permettait de générer le build de développement d'une cible d'éditeur.
À partir de la version 5.3, l'UE fournit un projet Xcode distinct (dans le même espace de travail Xcode) pour chaque type de cible. Par exemple, l'espace de travail Xcode pour un projet intitulé "MyProject" aura un projet distinct pour MyProjectEditor, MyProjectGame, MyProjectClient et MyProjectServer.
Chaque cible est uniquement dotée des configurations de compilation qu'elle prend en charge. Par exemple, la plupart des éditeurs ne prennent pas en charge la configuration de test ou de livraison ; elles ne sont donc pas disponibles dans les projets d'éditeur.
Les espaces de travail mis à jour proposent un grand nombre de schémas. Lorsque vous les parcourez, utilisez le filtre et la section Récent pour affiner la liste si besoin.
Espaces de travail par plateforme
Dans les versions antérieures, lorsque l'UE générait des fichiers de projet, un espace de travail monolithique était créé pour inclure des cibles pour chaque plateforme Apple.
À partir de la version 5.3, lorsque l'UE génère des fichiers de projet, un espace de travail distinct est créé pour chacune d'elle.
Cela simplifie les espaces de travail et les projets, et puisque Xcode peut ouvrir plusieurs espaces de travail, vous pouvez basculer d'une plateforme à l'autre en appuyant sur Cmd + `(accent grave).
Chaque espace de travail contient uniquement que les cibles prenant en charge une plateforme spécifique. C'est pourquoi iOS et tvOS proposent moins de schémas. Ils sont bien dotés d'une cible UnrealEditor, mais elle ne permet pas de compiler. Ces cibles sont présentes pour rendre le code source accessible à la recherche.
Applications autonomes
Dans les versions antérieures, l'UE regroupait toutes les données nécessaires à l'exécution des applications iOS, iPadOS et tvOS dans leurs fichiers .app respectifs, ce qui les rendait autonomes. Cependant, les projets macOS répartissent les données entre le fichier .app, le répertoire Saved/Cooked/Mac et d'autres emplacements sous les répertoires du moteur et du projet.
À partir de la version 5.3, toutes les plateformes Mac utilisent le même flux de travail, qui rassemble les données nécessaires en un seul endroit et les regroupe dans un fichier .app que vous pouvez exécuter manuellement ou avec Xcode. Pour cela, vous devez utiliser l'étape Stage (Intermédiaire) du processus de préparation.
Les compilations de l'éditeur ne sont pas encore préparées ni contenues dans des dossiers distincts.
Empaqueter et distribuer
Les processus d'empaquetage pour macOS et iOS/tvOS/iPadOS sont désormais parfaitement cohérents.
UE ne génère plus de fichier .ipa. pour iOS , car il n'est pas nécessaire sur macOS et n'est utile que sous Windows.
Distribution
Le mode de distribution n'utilise plus de certificat de distribution pour signer du code. Il crée à la place une archive Xcode standard (.xcarchive), que vous pouvez utiliser pour distribuer l'application vers différentes destinations, telles que l'App Store ou votre équipe. Lorsqu'il crée un build de distribution, Xcode génère également un fichier .dysm à ajouter à l'archive Xcode. Ce fichier est utile en cas de débogage de pannes et peut être envoyé à Apple pour déboguer des plantages en temps réel. Vous soumettez votre fichier .dysm avec votre application lors de son chargement auprès d'Apple.
La génération du fichier .dsym peut prendre quelques minutes.
Pour effectuer un empaquetage normal, cliquez sur Plateformes > Empaqueter le projet dans l'Unreal Editor ou ajoutez -package -clientconfig=Shipping à la ligne de commande BuildCookRun.
Pour effectuer un empaquetage pour la distribution, cochez la case Distribution dans les paramètres du projet ou ajoutez -package -clientconfig=Shipping -distribution à la ligne de commande BuildCookRun.
Vous pouvez également cliquer sur Produit > Archive dans Xcode.
Xcode utilise le flux standard pour générer un fichier .xcarchive, y compris l'intégration du répertoire Staged et des frameworks de signature de code. La configuration de livraison est utilisée, même si vous définissez le schéma sur Développement.
Si vous utilisez Archive in Xcode, la fenêtre Archives s'ouvre automatiquement et la nouvelle archive est sélectionnée. Si vous utilisez d'autres méthodes de création dans l'UE, vous devrez ouvrir manuellement la fenêtre en cliquant sur Fenêtre > Organiseur, puis sélectionner votre projet et Archives en haut à gauche.
Utilisez les boutons situés à droite de la fenêtre Archives pour valider ou distribuer votre application. Vous pouvez ainsi créer un fichier .ipa iOS en suivant les instructions pour chaque option. Pour la validation/distribution de l'App Store, vous devez créer une entrée d'application sur appstoreconnect.apple.com.
Les invites de distribution ou de validation de votre application peuvent vous demander de choisir un certificat de distribution ou de suivre d'autres étapes de provisionnement. Pour en savoir plus, consultez la documentation d'Apple.
L'archivage dans Xcode utilise la configuration de livraison, car c'est la configuration par défaut de l'action Archive dans le schéma généré par l'UE. De plus, la commande -package -distribution utilisera l'action d'archive de Xcode en arrière-plan au lieu de l'action de compilation.
Vous pouvez modifier ce comportement pour effectuer des tests, mais nous vous recommandons de ne distribuer que les versions de livraison.
Configurer le nom d'affichage de votre application sur macOS
Le nom d'affichage de votre application correspond au nom de votre fichier .app Mac lors de la création d'une compilation archivée. Lorsque vous effectuez un empaquetage pour la distribution (ou que utilisez le menu Archive dans Xcode), le nom d'affichage est le nom du fichier .app que les utilisateurs voient lorsqu'ils utilisent Finder. S'il n'est pas défini, le fichier .app aura le même nom que le fichier .uprojec . Pour modifier le nom d'affichage dans UE 5.3.2 et versions ultérieures, ouvrez le fichier MacEngine.ini et définissez la variable de configuration ApplicationDisplayName :
MacEngine.ini
[Xcode]
ApplicationDisplayName="Friendly Application Name"La variable ApplicationDisplayName est différente du nom d'affichage du pack utilisé pour iOS. Vous devez donc les configurer séparément pour les applications exécutées sur macOS et iOS.
Projets de contenu/blueprint uniquement
Dans la mesure où les projets de contenu uniquement (ou les projets de blueprint uniquement) ne disposent pas de projet Xcode ni de fichier source de cible de compilation, ils réutilisent les cibles génériques UnrealGame du moteur combinées à leurs données spécifiques pour créer une version.
Pratiques standard de Xcode
Le flux de travail relatif à Xcode mis à jour utilise Xcode pour gérer autant de composants que possible conformément au flux de travail Xcode standard, notamment :
La signature de code
Des fichiers
.plistDes fichiers de droits
Des frameworks
Signature de code
Dans les versions antérieures, seuls iOS/ iPadOS/tvOS nécessitaient la signature de code. Depuis 2023, Apple exige également la signature de code pour les projets sous macOS. Par défaut, le flux de travail mis à jour utilise la signature de code automatique de Xcode pour toutes les plateformes.
Pour utiliser la signature de code automatique, procédez comme suit :
Connectez-vous à votre compte de développeur Apple dans Xcode.
Ouvrez les paramètres du projet, puis sélectionnez Plateformes > Projets Xcode et définissez les propriétés suivantes :
| Nom du paramètre | CVar | Description |
|---|---|---|
Utiliser la signature de code moderne |
| Activer la signature de code automatique dans votre projet UE Les deux paramètres suivants doivent être configurés. |
Préfixe de signature moderne |
| Nom de domaine inversé pour votre entreprise. Par exemple : |
Équipe de signature moderne | `ModernSigningTeam | L'identifiant d'équipe utilisé par votre application lors de la signature. Il est identique à celui de la section Signature et fonctionnalités de Xcode. Pour en savoir plus, consultez la section Rechercher votre identifiant d'équipe ci-après. |
Rechercher votre identifiant d'équipe
Pour rechercher votre identifiant d'équipe pour le paramètre Équipe de signature moderne, ouvrez la page Développeur Apple, connectez-vous à votre compte et cliquez sur Détails de l'adhésion. Votre identifiant d'équipe s'affiche.
Fichiers .plist
Chaque application doit inclure un fichier .plist intégré . Le dernier fichier .plist est généralement créé à partir d'un modèle partiel que Xcode modifiera en fonction des paramètres du projet Xcode. Ce processus peut être compliqué, car l'UE génère des projets Xcode.
Le flux de travail Xcode mis à jour offre un contrôle complet sur la gestion des fichiers .plist . De plus, la modification des paramètres de fichier .plist dans Xcode sont désormais pris en charge.
Par défaut, vous perdrez les modifications iOS si vous changez les paramètres .plist . Pour en savoir plus, consultez la section Comparaison entre macOS et iOS ci-après.
Comparaison entre modèle et préconception
Il est recommandé de laisser Xcode finaliser le fichier .plist dans l'application à l'aide des paramètres du projet Xcode généré par l'UE. Toutefois, l'UE prend aussi en charge les fichiers .plist préconçus que Xcode ne modifiera pas. S'agissant d'une fonctionnalité avancée, elle n'est pas disponible dans les paramètres du projet Xcode et nécessite la modification d'un fichier de configuration. Consultez la section Utiliser un fichier .plist préconçu ci-dessous pour obtenir des instructions.
La configuration .plist dans les paramètres du projet (éléments Info.plist cible Mac et Info.plist cible iOS) permet de spécifier le modèle .plist par défaut ou votre propre modèle .plist personnalisé.
Par défaut, les fichiers Template.plist sont disponibles dans le répertoire Build/IOS de votre projet. Lorsque l'UE génère les fichiers de projet Xcode pour votre projet, il vérifie si votre projet contient un modèle .plist et, si ce n'est pas le cas, il copie un fichier .plist depuis le moteur vers le dossier de votre projet.
Si vous modifiez les paramètres .plist dans Xcode et qu'ils pointent vers un fichier .plist dans votre répertoire d'installation dans l'UE (non dans le répertoire de votre projet), Xcode le rendra accessible en écriture et le modifiera, affectant ainsi tous les projets UE utilisant cette installation. C'est pourquoi l'UE copie le fichier .plist du moteur dans votre projet. Vous pouvez comparer le fichier .plist des futures versions du moteur pour vérifier si les paramètres par défaut ont été mis à jour.
Si tel est le cas, consultez les instructions plus bas sur la restauration des valeurs par défaut d'un fichier .plist.
La cible de l'Unreal Editor possède un fichier .plist unique, car le fichier .app est partagé par tous les projets. La plupart des utilisateurs n'auront pas à gérer cette situation.
Utiliser un fichier .plist préconçu
Pour utiliser un fichier .plist préconçu, modifiez votre fichier DefaultEngine.ini et définissez l'un des paramètres suivants (ou les deux) avec les chemins d'accès aux fichiers à utiliser :
DefaultEngine.ini
[/Script/MacTargetPlatform.XcodeProjectSettings]
PremadeMacPlist=(FilePath="/Game/Build/Mac/Resources/MyGameMac.plist")
PremadeIOSPlist=(FilePath="/Game/Build/IOS/Resources/MyGameIOS.plist")Restaurer les valeurs par défaut d'un fichier .plist
Vous pouvez également utiliser le bouton Restaurer les valeurs Info.plist par défaut pour recopier le fichier modèle .plist Mac par défaut du répertoire du moteur vers votre projet et définir les valeurs appropriées. Cela peut être utile si vous voulez utiliser des fichiers .plist par défaut mis à jour dans les futures versions de l'UE.
Vous pouvez extraire un fichier .plist depuis une application générée et l'utiliser comme source pour un fichier .plist préconçu.
Manifestes de confidentialité
Xcode utilise des manifestes de confidentialité pour résumer le type de données utilisateur que votre application collecte et à quelles fins. Sont comprises les données collectées par votre propre code ainsi que par les SDK tiers que vous utilisez. Lorsque vous distribuez votre application, Xcode combine les manifestes de confidentialité de vos SDK et de votre application en un seul rapport, ce qui permet de présenter facilement aux utilisateurs des informations claires sur les pratiques de confidentialité de votre application.
L'UE fournit des manifestes de confidentialité par défaut aux emplacements suivants :
MacOS :
Engine/Build/Mac/Resources/UEMetadata/PrivacyInfo.xcprivacyiOS, tvOS et iPadOS :
Engine/Build/iOS/Resources/UEMetadata/PrivacyInfo.xcprivacy
Les projets faisant appel à d'autres fonctions de confidentialité doivent fournir un fichier PrivacyInfo.xcprivacy supplémentaire à l'emplacement spécifié dans les paramètres du projet UE. Par défaut, ces emplacements sont :
MacOS :
/Game/Build/Mac/Resources/PrivacyInfo.xcprivacyiOS, tvOS et iPadOS :
/Game/Build/IOS/Resources/PrivacyInfo.xcprivacy
Pour en savoir plus, consultez la documentation d'Apple sur les manifestes de confidentialité.
Comparaison entre MacOS et iOS iOS
L'utilisation des fichiers .plist diffère entre macOS et iOS dans le nouveau flux de travail Xcode, car UBT intègre une logique de génération de fichiers .plist iOS . Transférer cette logique au générateur de projet/Xcode n'était pas envisageable.
Si vous examinez les paramètres par défaut d'UBT, vous constaterez qu'ils pointent vers /Game/Build/IOS/UBTGenerated/Info.Template.plst**,** ce qui indique qu'à chaque exécution d'UBT, le contenu des fichiers .plistiOS peut être modifié.
Cependant, vous pouvez modifier les paramètre du projet pour utiliser votre modèle .plist (ou votre fichier préconçu) , qui ignorera ce que UBT génère. Dans ce cas, vous pouvez utiliser Xcode pour modifier le fichier .plist .
Voici un aperçu des différences entre les fichiers .plist sur Mac et iOS :
| Mac | iOS | |
|---|---|---|
Fichier .plist par défaut | Modèle copié depuis le répertoire du moteur | Modèle généré par UBT |
Modification du fichier Xcode .plist | Oui | Pas si vous utilisez la génération UBT |
Droits d'utilisation
Chaque application définit des droits dans le cadre de la signature de code. Ces droits contrôlent certaines fonctionnalités ou restrictions conçues par Apple, telles que la prise en charge de GameCenter ou l'exécution dans le bac à sable de sécurité du Mac.
La génération de projets Xcode de l'UE traite les droits de la même manière que les fichiers .plist (Mac) ci-dessus. L'UE génère un projet Xcode et, si aucun fichier relatif aux droits d'utilisation ne se trouve à l'emplacement par défaut du projet, le fichier par défaut est copié depuis le répertoire du moteur. Vous pouvez ensuite utiliser Xcode (ou un éditeur de texte) pour modifier les droits, qui se trouvent sous Build/Mac/Entitlements ou Build/iOS/Entitlements dans votre projet.
Si le bac à sable contient des restrictions différentes ou que les éléments que vous livrez aux utilisateurs finaux présentent des divergences, vous pouvez définir des droits distincts pour la livraison et le développement. Si vous n'avez pas besoin de fonctionnalités distinctes, il est recommandé de les faire pointer vers le même fichier.
Actuellement, seuls les droits Mac sont affichés dans les paramètres du projet.
Voici les paramètres des droits par défaut pour macOS et iOS :
| Paramètre de droits d'utilisation | Mac | iOS |
|---|---|---|
Développement par défaut | En bac à sable, autorise les connexions réseau client/serveur. | Aucun droit spécifique n'est défini. |
Livraison par défaut | En bac à sable, autorise les connexions réseau client. | Aucun droit spécifique n'est défini. |
Le rapporteur de plantage n'est pas compatible avec les jeux empaquetés qui activent le droit d'utilisation en bac à sable (par défaut depuis UE 5.3).
Frameworks
Les frameworks sont un système Xcode permettant de collecter des en-têtes, des bibliothèques et du contenu. Le nouveau flux de travail Xcode permet désormais de gérer les frameworks à l'aide des méthodes Xcode standard, au lieu de copier et d'effectuer la signature de code manuellement comme avec le flux de travail précédent. Lorsque l'UE génère un projet Xcode, il utilise le système de compilation pour rechercher les frameworks référencés définis dans différents fichiers sources de version. Puis, il configure le projet Xcode pour copier les bibliothèques dynamiques et le contenu dans le pack de l'application, et procéder à la signature de code si nécessaire.
Journaux d'accès
Les fichiers journaux peuvent apparaître à différents emplacements selon les paramètres de votre bac à sable et le mode d'exécution de votre application :
Si le bac à sable est activé :
Exécution via Xcode : ~/Library/Logs/[nom du projet]
Exécution par double-clic ou via le terminal : ~/Library/Containers/[identifiant du pack de votre application]/Data/Library/Logs
Si le bac à sable est désactivé :
~/Library/Logs/[nom du projet]