Die Unreal Engine (UE) aktualisiert ab 5.3 den Xcode-Projekt-Workflow für die Unreal Engine, um ihn konsistenter mit standardmäßigen Projekten der Xcode App zu machen. Das neue Projekt-Setup verbessert die Organisation und Lebensqualität für Xcode-Entwickler und bietet Zugang zu verschiedenen Werkzeugen innerhalb von Xcode, um Codesignatur und die Bereitstellung zu optimieren, darunter:
Automatische Code-Signierung
Berechtigungen verwalten
.plist-Dateien bearbeitenHandhabung von Standard-Xcode-Framework
Diese Seite bietet einen Überblick über die Änderungen für Nutzer, die von früheren Versionen auf UE 5.3 und neuer (5.3+) umsteigen.
Voraussetzungen
Der aktualisierte Xcode-Workflow ist für UE 5.3 und neuer verfügbar und für neue Projekte standardmäßig aktiviert. Wenn Sie die Funktion manuell aktivieren müssen, befolgen Sie diese Schritte:
Öffnen Sie das Verzeichnis Ihrer Engine, öffnen Sie
Engine/Konfiguration/BaseEngine.iniund stellen Sie sicher, dass Sie die folgende Konfiguration-Variable festlegen:Engine/Konfiguration/BaseEngine.ini
C++[/Script/MacTargetPlatform.XcodeProjectSettings] bUseModernXcode=trueRegenerieren Sie Ihre Xcode-Projektdateien für die Engine und Ihr Projekt. Sollten Sie einen Quell-Build der UE verwenden, führen Sie das Script
GenerateProjectFiles.commandin Ihrem Engine-Installationsverzeichnis aus, um die Projektdateien für den Quellcode der UE erneut zu generieren. Sie sollten drei Xcode-Arbeitsbereichdateien im Verzeichnis Ihres Projekts sehen:UE5 (Mac).xcworkspaceUE5 (TVOS).xcworkspaceUE5 (IOS).xcworkspace
Das neue Xcode-Setup ist nun einsatzbereit. In den folgenden Abschnitten werden die Neuerungen im Vergleich zum alten Projekt-Setup erläutert.
Projekte, Schemen und Build-Konfigurationen
Zuvor kombinierten UE-Xcode-Projekte Ziele und Build-Konfigurationen unter Schemen. Beispielsweise hatten Nutzer in einem einzigen Projekt (MyProject) ein "Entwicklungs-Editor"-Schema, das einen Entwicklungs-Build eines Editor-Ziels erstellte.
UE 5.3+ bietet ein separates Xcode-Projekt (innerhalb desselben Xcode-Arbeitsbereichs) für jeden Zieltyp. Beispielsweise würde ein Xcode-Arbeitsbereich für ein Projekt namens "MyProject" separate Projekte für MyProjectEditor, MyProjectGame, MyProjectClient und MyProjectServer haben.
Jedes Ziel hat nur die Build-Konfigurationen, die es unterstützt. Beispielsweise unterstützen die meisten Editoren keine Test- oder Auslieferungskonfiguration, daher sind diese in Editor-Projekten nicht verfügbar.
Aktualisierte Arbeitsbereiche haben eine Vielzahl von Schemen. Verwenden Sie beim Durchsuchen der Dateien die Sektion Filter und Neueste, um Ihre Liste nach Bedarf einzuschränken.
Plattformabhängige Arbeitsbereiche
Früher erstellte die UE bei der Generierung von Projektdateien einen monolithisch Arbeitsbereich, der Ziele für jede der Apple-Plattformen bot.
In UE 5.3+ erstellt die UE bei der Erstellung von Projektdateien einen separaten Arbeitsbereich für jede Apple-Plattform.
Das vereinfacht Arbeitsbereiche und Projekte, und da Xcode mehrere Arbeitsbereiche öffnen kann, haben Sie die Möglichkeit, zwischen Plattformen umzuschalten, indem Sie die Befehlstaste + ` (Backtick) drücken.
Jeder Arbeitsbereich enthält nur die Ziele, die diese Plattform unterstützen, daher stehen für iOS und tvOS weniger Schemen zur Verfügung. Sie haben ein UnrealEditor-Ziel, aber es kann nicht erfolgreich gebaut werden. Stattdessen sind diese Ziele präsent, um den Quellcode für die Suche verfügbar zu machen.
Eigenständige Apps
Zuvor packte die UE alle zur Ausführung von iOS, iPadOS- und tvOS-Apps benötigten Daten in ihre jeweiligen .app-Dateien , wodurch sie eigenständig wurden. Allerdings teilen macOS-Projekte die Daten zwischen der .app, dem Verzeichnis Gespeichert/Gecookt/Mac und anderen Speicherorten in den Engine- und Projektverzeichnissen auf.
In UE 5.3+ verwenden alle Mac-Plattformen denselben Workflow, der die benötigten Daten an einem Ort sammelt und in eine .app bündelt, die Sie manuell oder mit Xcode ausführen können. Dazu müssen Sie den Bühnenschritt im Cooking verarbeiten verwenden.
Editor-Builds sind noch immer nicht gecookt und in losen Ordnern enthalten.
Verpacken und Verteilen
Die Paketierungsprozesse für macOS und iOS/tvOS/iPadOS sind nun vollständig konsistent miteinander.
Die UE generiert keine .ipa-Datei mehr automatisch für iOS, da sie auf macOS nicht nötig und nur unter Windows nützlich ist.
Vertrieb
Der Modus verwendet kein Vertriebszertifikat mehr für die Codesignatur. Stattdessen erstellt sie ein Standard-Xcode-Archiv (.xcarchive), das Sie verwenden können, um die .app an verschiedene Ziele zu verteilen, etwa in den App Store oder an Ihr Team. Bei Erstellung von Veröffentlichungs-Builds erstellt Xcode auch eine .dSYM-Datei, die in das Xcode-Archiv aufgenommen werden kann, was für das Debugging von Abstürzen nützlich ist und an Apple zum Debuggen von Live-Abstürzen gesendet werden kann. Sie senden Ihre .dysm zusammen mit Ihrer App, wenn Sie Ihre App bei Apple zur Einreichung hochladen.
Die Generierung von .dSYM dauert mehrere Minuten.
Um normal zu packen, klicken Sie im Unreal Editor auf Plattformen > Paket-Projekt oder fügen Sie -package -clientconfig=Shipping zu Ihrer BuildCookRun-Befehlszeile hinzu.
Um für die Verteilung zu verpacken, prüfen Sie das Kästchen Distribution in Ihren Projekteinstellungen oder fügen Sie -package -clientconfig=Auslieferung -distribution zu Ihrer BuildCookRun-Befehlszeile hinzu.
Sie können alternativ auf Produkt > Archiv in Xcode klicken.
Xcode verwendet den Standardablauf, um eine .xcarchive zu generieren, wobei auch das Staging-Verzeichnis und Codesignatur-Frameworks eingebracht werden. Dies verwendet die Auslieferungskonfiguration, auch wenn Sie das Schema auf Entwicklung eingestellt haben.
Wenn Sie in Xcode Archive verwenden, öffnet sich automatisch das Archive-Fenster und wählt das neue Archiv aus. Wenn Sie andere UE-Methoden nutzen, um es zu erstellen, müssen Sie das Fenster manuell öffnen, indem Sie auf Fenster > Organizer klicken und dann Ihr Projekt und Archive oben links auswählen.
Verwenden Sie die Schaltflächen auf der rechten Seite des Archive-Fensters, um Ihre App zu validieren oder zu verteilen. Sie können damit arbeiten, um eine iOS .ipa zu erstellen Datei für interne Verwendung, indem Sie den Aufforderungen für jede Option folgen. Für die Validierung / den Vertrieb im App Store müssen Sie unter appstoreconnect.apple.com einen App-Eintrag erstellen.
Die Aufforderungen zum Verteilen oder Validieren Ihrer App können dich auffordern, ein Zertifikat zu wählen oder anderen Bereitstellungsschritten zu folgen. Mehr Informationen dazu finden Sie in der Apple-Dokumentation.
Archivierung in Xcode verwendet Shipping, da es die Konfiguration für die Archivierungsaction in dem Schema ist, das die UE generiert. Zusätzlich verwenden -package-Distributionen die Xcode-Action archivieren im Hintergrund anstatt der Action bauen.
Sie können dies im Schema ändern, wenn es für Testen benötigt wird, aber wir empfehlen, nur Auslieferung-Builds zu Verteilen.
Konfigurieren Sie den Anzeigenamen Ihrer App auf MacOS
Der Anzeigename ist der Name der Mac .app beim Erstellen eines archivierten Builds. Wenn Sie ein Paket für die Verteilung erstellen (oder das Archivmenü in Xcode verwenden), ist der Anzeigename der Name der .app, die Nutzer im Finder sehen. Wenn dies nicht gesetzt ist, verwendet die .app denselben Namen wie die .uproject-Datei . Um Ihren Anzeigennamen in UE 5.3.2 und neuer zu ändern, öffnen Sie Ihre MacEngine.ini-Datei und legen die ApplicationDisplayName-Konfigurationsvariable fest:
MacEngine.ini
[Xcode]
ApplicationDisplayName="Friendly Application Name"Der ApplicationDisplayName ist nicht derselbe wie der für iOS verwendete Paket-Name und Sie müssen diese für Apps, die auf MacOS und iOS laufen, separat konfigurieren.
Nur-Inhalt-/Nur-in-Blueprint-Projekte
Da Nur-Inhalt-Projekte (oder Nur-in-Blueprint-Projekte) kein Xcode-Projekt oder Build-Ziel-Quelldateien haben, verwenden sie die generischen UnrealGame-Ziele aus der Engine kombiniert mit ihren projektspezifischen Daten, um einen Build zu erstellen.
Standard-Xcode-Praktiken
Der aktualisierte Xcode-Workflow verwendet Xcode, um so viele Komponenten wie möglich entsprechend dem Standard-Xcode-Workflow zu verarbeiten, darunter:
Codesignatur.
.plist-Dateien.Berechtigungsdateien.
Frameworks.
Codesignatur
Bisher erforderte nur iOS/iPadOS/tvOS eine Codesignatur. Seit 2023 verlangt Apple zudem Codesignatur für macOS. Der aktualisierte Workflow verwendet standardmäßig die automatische Codesignatur von Xcode für alle Plattformen.
Befolgen Sie diese Schritte, um die automatische Codesignatur zu verwenden:
Loggen Sie sich in Xcode in Ihrem Apple Entwickler-Konto ein.
Öffnen Sie Ihre Projekteinstellungen, suchen dann nach Plattformen > Xcode-Projekte und legen die folgenden Eigenschaften fest:
| Einstellungsname | CVar | Beschreibung |
|---|---|---|
Moderne Code-Signierung nutzen |
| Aktiviert die automatisch Codesignatur für Ihr UE-Projekt. Erfordert die Einrichtung der folgenden zwei Einstellungen. |
Modern Signing-Präfix |
| Ein umgekehrter Domänenname für Ihr Unternehmen. Ein Beispiel: |
Modern Signing-Team | `ModernSigningTeam | Die Team-ID, die Ihre Anwendung beim Unterzeichnen verwendet. Dies entspricht der Team-ID in der Sektion Signatur und Fähigkeiten von Xcode. Weitere Informationen finden Sie unter Finden Ihrer Team-ID. |
Finden Ihrer Team-ID
Ihre Team-ID für die Einstellung Modern Signing finden Sie unter Apple-Entwicklerseite. Loggen Sie sich bei Ihrem Konto an und klicken Sie auf Mitgliedschaftsdetails. Ihre Team-ID wird angezeigt.
.plist-Dateien
Jede App muss eine eingebettete .plist-Datei umfassen. Die finale .plist-Datei wird normalerweise aus einer Vorlage erstellt, die Xcode basierend auf den Projekteinstellungen modifiziert. Da die UE Xcode-Projekte generiert, kann dies ein komplizierter Prozess sein.
Der aktualisierte Xcode-Workflow bietet umfassende Kontrolle über den Umgang mit .plist-Dateien . Außerdem wird jetzt die Bearbeitung von .plist-Einstellungen in Xcode unterstützt
Standardmäßig gehen Ihnen iOS-Änderungen verloren, wenn Sie die .plist-Einstellungen bearbeiten. Weitere Informationen finden Sie im Sektion MacOS vs. iOS weiter unten.
Vorlage vs. vorgefertigt
Xcode sollte die .plist in der App mit Einstellungen aus dem UE-generierten Xcode-Projekt finalisieren. Allerdings unterstützt die UE auch vorgefertigte .plist-Dateien, die Xcode nicht modifiziert. Da es sich um eine erweiterte Funktion handelt, wird sie nicht in den Xcode-Projekteinstellungen angezeigt und erfordert die Bearbeitung einer Konfigurationsdatei. Detailliertere Informationen dazu finden Sie unter Verwenden einer vorgefertigten .plist weiter unten.
Die .plist-Einstellungen in Ihren Projekt-Einstellungen (die Elemente Mac Ziel Info.plist und iOS Ziel Info.plist) bieten eine Möglichkeit, entweder die Standard-Vorlage .plist, oder Ihre eigene benutzerdefinierte Vorlage .plist zu bestimmen.
Die Standard-Speicherorte für die Dateien Template.plist befinden sich im Verzeichnis Build/IOS Ihres Projekts. Wenn die UE Xcode-Projektdateien für Ihr Projekt erstellt, wird überprüft, ob Sie über eine Vorlage .plist-Datei in Ihrem Projekt verfügen, und wenn nicht, wird eine .plist aus der Engine in Ihren Projektordner kopiert.
Wenn Sie .plist-Einstellungen im Xcode bearbeiten, und es besteht ein Verweis auf eine .plist-Datei in Ihrem UE-Installationsverzeichnis (nicht im Verzeichnis Ihres Projekts), markiert Xcode sie als nicht schreibgeschützt und modifiziert sie. Alle UE-Projekte, die diese Installation verwenden, sind davon betroffen. Deswegen kopiert die UE die .plist-Datei der Engine in Ihr Projekt. Sie möchten vielleicht die .plist-Datei zukünftiger Engine-Versionen vergleichen, um zu sehen, ob wir die Standardeinstellungen aktualisiert haben.
Sollte das passieren, finden Sie unten den Befehl zum Wiederherstellen einer .plist auf die Standardwerte.
Das UnrealEditor-Ziel hat eine einzigartige .plist, da die .app von allen Projekten verwendet wird. Die meisten Nutzer werden sich damit nicht herumschlagen müssen.
Nutzen einer vorgefertigten .plist
Wenn Sie eine vorgefertigte .plist verwenden möchten, ändern Sie Ihre DefaultEngine.ini-Datei und legen Sie eine oder beide der folgenden Einstellungen mit Pfaden zu den Dateien fest, die Sie verwenden möchten:
DefaultEngine.ini
[/Script/MacTargetPlatform.XcodeProjectSettings]
PremadeMacPlist=(FilePath="/Game/Build/Mac/Resources/MyGameMac.plist")
PremadeIOSPlist=(FilePath="/Game/Build/IOS/Resources/MyGameIOS.plist")Eine .plist auf den Standard zurücksetzen
Sie können auch die Schaltfläche Info.plist auf den Standard zurücksetzen nutzen, um die Mac-Vorlage der .plist-Datei des Engine-Verzeichnisses erneut auf Ihr Projekt zu kopieren und die Werte entsprechend festzulegen. Dies kann nützlich sein, wenn Sie aktualisierte standardmäßige .plist -Dateien in zukünftigen UE-Versionen benutzen möchten.
Sie können eine .plist-Datei aus einer generierten App nehmen und diese als Quelle für eine vorgefertigte .plist verwenden.
Datenschutzmanifeste
Xcode verwendet Datenschutzmanifeste, um zusammenzufassen, welche Art von Daten Ihre App über ihre Nutzer sammelt und warum sie diese Daten sammelt. Das umfasst Daten, die durch deinen eigenen Code erfasst werden, sowie SDKs von Dritten, die Sie verwenden. Wenn Sie Ihre App verteilen, kombiniert Xcode die Datenschutzmanifeste Ihrer SDKs und Ihrer App in einem einzigen Datenschutzbericht, wodurch es einfach ist, Nutzern transparent Informationen über die Datenschutzpraktiken Ihrer App zu liefern.
Die EU bietet Standard-Datenschutzmanifeste an folgenden Orten:
MacOS:
Engine/Build/Mac/Ressourcen/UEMetadata/PrivateInfo.xcprivacyiOS, tvOS und iPadOS:
Engine/Build/iOS/Ressourcen/UEMetadata/PrivateInfo.xcprivacy
Projekte, die zusätzliche Datenschutzfunktionen verwenden, müssen eine zusätzliche Datei PrivacyInfo.xcprivacy an dem Ort bereitstellen, der durch Ihre Projekt-Einstellungen spezifiziert wurde. Standardmäßig sind diese:
MacOS:
/Spiel/Build/Mac/Ressourcen/Privatinfo.xcprivacyiOS, tvOS und iPadOS:
/Spiel/Build/IOS/Ressourcen/Privatinfo.xcprivacy
Weitere Informationen finden Sie in Apple-Dokumentation zu Datenschutzmanifesten.
MacOS vs. iOS
Arbeiten mit .plist-Dateien unterscheidet sich im neuen Xcode-Workflow zwischen macOS und iOS, da UBW (UnrealBauWerkzeug) über eine tief eingebettete Logik zur Erstellung von iOS .plist-Dateien hat. Diese Logik in den Projektgenerator/Xcode zu übertragen, war nicht realisierbar.
Wenn Sie sich die Einstellungen für UBW (UnrealBauWerkzeug) anschauen, sehen Sie, dass sie auf /Spiel/Build/IOS/UBTGenerated/Info.Template.plst** verweist,** was bedeutet, dass bei jeder Ausführung von UBW die Inhalte für iOS .plist-en geändert werden können.
Allerdings können Sie die Projekt-Einstellungen ändern, um Ihre Vorlage (oder vorgefertigte) .plist-Dateien zu verwenden, was ignoriert, was von UBW erstellt wird. Wenn Sie das tun können, können Sie Xcode verwenden, um die .plist-Datei zu bearbeiten.
Es folgt eine Übersicht über die Unterschiede zwischen Mac- und iOS .plist-Dateien :
| Mac | IOS | |
|---|---|---|
Standard .plist | Vorlage aus dem Engine- Verzeichnis kopiert. | UBW-Generierte Vorlage. |
Xcode .plist-Modifikation | Ja | Nicht, wenn UBW-Generiert verwendet wird |
Berechtigungen
Jede App legt im Rahmen dere CodesignaturBerechtigungen fest. Berechtigungen steuern einige von Apple erstellte Funktionen oder Einschränkungen, wie GameCenter-Support oder die Ausführung in der Mac-Sicherheits-Sandbox.
Die Xcode-Projektgenerierung der UE behandelt Berechtigungen ähnlich wie die (Mac-).plist-Dateien oben. Die UE erstellt ein Xcode-Projekt. Wenn sich am Standard-Speicherort des Projekts keine Berechtigungen-Datei befindet, wird der Standard aus dem Engine-Verzeichnis kopiert. Sie können anschließend Xcode (oder einen Text-Editor) verwenden, um die Berechtigungen zu ändern. Sie finden diese unter Build/Mac/Berechtigungen oder Build/iOS/Berechtigungen in Ihrem Projekt.
Wenn Sie verschiedene Sandbox-Einschränkungen oder andere Unterschiede in dem haben, was Sie an Endverbraucher ausliefern, können Sie separate Berechtigungen für Auslieferung und Entwicklung einrichten. Sie sollten sie auf dieselbe Datei verweisen, wenn Sie keine unterschiedlichen Funktionen benötigen.
Aktuell sind in den Projekteinstellungen nur Mac-Berechtigungen offengelegt.
Im Folgenden finden Sie die Standard-Einstellungen für macOS und iOS:
| Berechtigungseinstellungen | Mac | IOS |
|---|---|---|
Standard-Entwicklung | Sandboxed, erlaubt Client/Server-Netzwerkverbindungen. | Keine speziellen Berechtigungen gesetzt. |
Standardauslieferung | Sandboxed, erlaubt Client-Netzwerkverbindungen. | Keine speziellen Berechtigungen gesetzt. |
Der Absturz-Reporter ist nicht kompatibel mit verpackten Spielen, welche die Sandbox-Berechtigung aktivieren (Standard seit UE 5.3).
Frameworks
Frameworks sind ein Xcode-System zum Sammeln von Headern, Bibliotheken und Inhalten. Der neue Xcode-Workflow handhabt Frameworks nun mit den Standard Xcode-Methoden anstatt manuellem Kopieren und Codesignatur wie im vorherigen Workflow. Wenn die UE ein Xcode-Projekt generiert, verwendet sie das Build-System, um die referenzierten Frameworks in verschiedenen Build-Quelldateien zu finden. Anschließend wird das Xcode-Projekt eingerichtet, um dynamische Bibliotheken und Inhalt in das App-Paket zu kopieren und nach Bedarf die Codesignatur anzuwenden.
Auf Logs zugreifen
Log-Dateien können abhängig von Ihren Einstellungen und der Ausführung Ihrer Anwendung an verschiedenen Speicherorten erscheinen:
Wenn Sandbox aktiviert ist:
Ausführung über xcode: ~/Bibliothek/Logs/[Projektname]
Ausführung durch Doppelklick oder über Terminal: ~/Bibliothek/Container/[Paket-ID Ihrer App]/Daten/Bibliothek/Logs
Mit deaktivierter Sandbox:
~/Bibliothek/Logs/[Projektname]