Die offizielle Godot-4.7-Dokumentation zum iOS-Export nennt einen macOS-Rechner mit installiertem Xcode als Voraussetzung. Daraus folgt die klare Entscheidung: Die Entwicklung eines Godot-Projekts kann auf Windows oder Linux bleiben, der vollständige iOS-Export muss jedoch auf einem Mac erfolgen. Für kurze oder unregelmäßige Veröffentlichungen ist ein gemieteter Remote-Mac meist der risikoärmere Einstieg. Bei dauerhaft hoher Auslastung kommt gekaufte Hardware infrage. Für Teams ist ein allgemeiner Buildknoten mit einem getrennten Mac-Veröffentlichungsknoten häufig die sauberste Architektur.
[ SECTION_01 ] Zielgruppe und Entscheidungsrahmen
Dieser Beitrag richtet sich an Windows- oder Linux-Entwickler, die ihre Hauptarbeitsumgebung nicht wechseln und trotzdem iOS-Versionen veröffentlichen möchten. Ebenso ist er für Build- und Release-Engineers gedacht, die Apple-spezifische Aufgaben von allgemeinen CI-Jobs trennen müssen.
Technische Verantwortliche erhalten Kriterien für die Wahl zwischen Remote-Mac, eigener Hardware und einer hybriden CI. Entscheidend sind nicht nur die Kosten. Werkzeugkontrolle, Signatursicherheit, Testnachweise, Wiederherstellung und tatsächliche Auslastung bestimmen, ob eine Lösung im Alltag tragfähig ist.
Letzte Aktualisierung: 16.09.2026. Die Aussagen wurden anhand der Godot-4.7-Dokumentation, des offiziellen Versionsarchivs sowie der Apple-Dokumentation zu Xcode, Gerätestests und App Store Connect geprüft. Godot führt 4.7.2 im offiziellen Archiv als stabile 4.7-Wartungsversion. Apple hat am 14.09.2026 bestätigt, dass App Store Connect Einreichungen akzeptiert, die mit Xcode 27 und dem zugehörigen veröffentlichten SDK erstellt wurden. Änderungen an späteren Vorschauversionen, Plugins oder Anforderungen müssen vor einer produktiven Umstellung erneut geprüft werden.
[ SECTION_02 ] Die eigentliche Grenze zwischen Entwicklungsrechner und Mac
„iOS exportieren“ beschreibt mehrere technische Vorgänge. Sie sollten nicht als ein einziger Knopf betrachtet werden:
- Das Godot-Projekt wird bearbeitet und versioniert.
- Exportvorlagen erzeugen aus dem Projekt ein iOS-Xcode-Projekt.
- Xcode kompiliert dieses Projekt mit dem installierten Apple-SDK.
- Signaturdaten verbinden Bundle ID, Team ID, Zertifikate und Provisioning Profile.
- Ein Archive wird für Verteilung oder Tests erzeugt.
- Das fertige Produkt wird auf ein Gerät, in einen Testkanal oder zu App Store Connect übertragen.
Die ersten Aufgaben können je nach Projekt auf Windows oder Linux bleiben. Die Apple-spezifischen Schritte benötigen dagegen macOS und Xcode. Die Godot-4.7-Anleitung für den iOS-Export ist hier die maßgebliche Grenze. Ein Windows-Editor, der ein Projekt öffnet, beweist nicht, dass anschließend ein signierbares iOS-Produkt entsteht.
Auch ein erzeugtes Xcode-Projekt ist nur ein Zwischenprodukt. Es kann fehlerhafte Exportvorlagen, fehlende native Erweiterungen, falsche Zielparameter oder nicht passende Signaturinformationen enthalten. Wer lediglich prüft, ob ein Verzeichnis angelegt wurde, prüft nicht die Lieferfähigkeit.
GDScript und C# als getrennte Prüfpfade
Bei GDScript-Projekten liegt der Schwerpunkt auf Exportvorlagen, Projektkonfiguration, nativen Plugins, Eingabeverhalten und Grafikfunktionen. Bei C#-Projekten kommen weitere Abhängigkeiten hinzu. Die verwendete Godot-Ausgabe, Laufzeit, Exportvorlage und jedes native oder .NET-bezogene Plugin müssen mit dem iOS-Ziel zusammenspielen.
Die richtige Entscheidung lautet deshalb nicht „C# funktioniert grundsätzlich“ oder „C# funktioniert grundsätzlich nicht“. Ein konkretes C#-Projekt muss auf dem vorgesehenen Mac bis zum Xcode-Build geprüft werden. Wenn die Dokumentation für eine Komponente nur einen experimentellen oder eingeschränkten Status nennt, darf dieser Status nicht als produktionsreife Zusage behandelt werden.
[ SECTION_03 ] Werkzeugkette und Verantwortungsgrenzen
Vor einer Miet- oder Kaufentscheidung sollte die gesamte Umgebung als Lieferkette beschrieben werden. Die folgende Tabelle trennt die Verantwortlichkeit bewusst:
| Arbeitsschritt | Windows/Linux | macOS mit Xcode | Abnahmekriterium |
|---|---|---|---|
| Godot-Szenen, Skripte und Ressourcen | Geeignet | Möglich | Projekt lässt sich reproduzierbar aus dem Repository laden |
| Allgemeine Assets und Plattform-Builds | Geeignet | Möglich | Artefakte werden versioniert und prüfbar erzeugt |
| Godot-iOS-Export | Nicht als vollständiger Lieferweg | Erforderlich | Xcode-Projekt entsteht mit erwarteten Einstellungen |
| Xcode-Kompilierung | Nicht verfügbar | Erforderlich | Build endet ohne Fehler und erzeugt ein verwertbares Produkt |
| Signierung und Archive | Nicht verfügbar | Erforderlich | Alle relevanten Targets haben eine gültige Signatur |
| Upload zu App Store Connect | Nicht verfügbar | Erforderlich | Upload wird mit nachvollziehbarem Status protokolliert |
| Nicht-Apple-Aufgaben | Geeignet | Möglich | Mac bleibt von allgemeinen Jobs entlastet |
Diese Aufteilung beantwortet auch die Frage nach einer gemischten CI: Nicht jede Aufgabe muss auf dem Mac laufen. Der Mac sollte dort eingesetzt werden, wo Apple-Werkzeuge, Signatur oder ein Apple-SDK tatsächlich gebraucht werden.
[ SECTION_04 ] Auswahl des Mac-Knotens
Ein Remote-Mac ist nicht automatisch ein geeigneter Buildknoten. Vor der Buchung müssen mindestens fünf Eigenschaften geprüft werden.
Erstens: Werkzeugkontrolle. Das Team muss die benötigte Godot-Version, die passenden Exportvorlagen, Xcode-Komponenten und Projekt-Plugins installieren oder aktualisieren können. Ein Knoten, auf dem nur eine vorgegebene Editor-Version geöffnet werden darf, ist für reproduzierbare Builds ungeeignet.
Zweitens: Systemrechte. Die Initialisierung kann Pfade, Entwicklerwerkzeuge, Schlüsselbundzugriff und Shell-Konfiguration betreffen. Vollständige Root-Rechte sind nicht für jede Pipeline zwingend, aber fehlende Rechte dürfen den vorgesehenen Ablauf nicht blockieren. Für NOVAKVM bedeutet eine verwertbare Mietumgebung daher nicht nur „Desktop erreichbar“, sondern ein kontrollierbarer macOS-Arbeitsplatz mit SSH- und Remote-Zugriff.
Drittens: Versionsfixierung. Die Pipeline sollte festhalten, welche Godot-Ausgabe, welche Exportvorlage und welche Xcode-Version verwendet werden. Der Befehl xcode-select muss auf die beabsichtigte Entwicklerumgebung zeigen. Ohne diese Fixierung kann ein scheinbar unveränderter Job nach einem Werkzeugwechsel anders reagieren.
Viertens: Nichtinteraktive Ausführung. Ein CI-Job darf nicht an einem Dialogfenster, einer unbekannten Schlüsselbundabfrage oder einer abgelaufenen Sitzung hängen. Jeder interaktive Schritt muss vorab identifiziert, dokumentiert und entweder automatisiert oder bewusst in einen kontrollierten Veröffentlichungsprozess verschoben werden.
Fünftens: Saubere Arbeitsbereiche. Ein Build aus einem verschmutzten Verzeichnis kann lokale Dateien, alte Archive oder zwischengespeicherte Signaturinformationen verwenden. Ein neuer Arbeitsbereich aus einem definierten Commit ist deshalb aussagekräftiger als ein manueller Build, der nur auf einem einzelnen Rechner funktioniert.
Die Godot-Dokumentation zum Kommandozeilenexport ist für die Automatisierung relevant. Sie ersetzt jedoch nicht die Xcode-Prüfung nach dem Export.
[ SECTION_05 ] Lösungsmodelle im Vergleich
Die drei Grundmodelle unterscheiden sich vor allem bei Kontrolle, Bindung und Wartungsverantwortung. Die Bewertung ist eine redaktionelle Entscheidungshilfe, keine Leistungs- oder Preiszusage.
| Modell | Werkzeugkontrolle | Signaturschutz | Geeignete Auslastung | Wartungsaufwand | Redaktionelle Bewertung |
|---|---|---|---|---|---|
| Remote-Mac mieten | Hoch, wenn Installation und Rechte erlaubt sind | Gut bei getrenntem Veröffentlichungszugang | Kurzfristig, wechselnd oder unsicher | Gering bis mittel | Sehr passend für den Einstieg |
| Mac kaufen | Sehr hoch | Gut bei eigener Sicherheitsarchitektur | Dauerhaft hoch | Mittel bis hoch | Passend bei stabiler Nutzung |
| Hybrid: allgemeiner Knoten plus Mac-Knoten | Hoch, mit klarer Trennung | Sehr gut bei separatem Release-Knoten | Regelmäßig, aber ungleich verteilt | Mittel | Meist passend für Teams |
Ein Kauf ist nicht automatisch günstiger. Neben der Hardware zählen Einrichtung, Ausfallersatz, Speicher, Stromversorgung, Fernzugriff, Systempflege und die Arbeitszeit der verantwortlichen Person. Eine gemietete Umgebung verschiebt diese Verantwortung teilweise zum Anbieter, beseitigt aber nicht die Pflicht zur eigenen Versions- und Signaturkontrolle.
Für eine Entscheidung sollten folgende Bedingungen gelten:
- Remote-Mac wählen, wenn ein Projekt kurzfristig portiert wird, Veröffentlichungen unregelmäßig sind oder die künftige Auslastung noch nicht bekannt ist.
- Hardware kaufen, wenn der Mac dauerhaft stark genutzt wird, ein Team die Wartung übernehmen kann und physische Verfügbarkeit langfristig wichtig ist.
- Hybridbetrieb wählen, wenn allgemeine Jobs bereits auf Windows- oder Linux-Knoten laufen und nur Export, Xcode, Signierung und Veröffentlichung Apple-Werkzeuge benötigen.
Bei einer Kaufentscheidung kann die Übersicht zum Mac mini für Entwicklerteams als zusätzlicher Vergleichspunkt dienen. Sie ersetzt keine Auslastungsrechnung. Ein Knoten, der nur selten signiert, bindet trotzdem Wartungs- und Sicherheitsverantwortung.
[ SECTION_06 ] Signierung und Veröffentlichung
Die Signierung sollte als eigener Verantwortungsbereich behandelt werden. Für ein iOS-Projekt müssen mindestens folgende Elemente zusammenpassen:
- Bundle ID des Produkts;
- Team ID des zuständigen Entwicklerkontos;
- Zertifikat und zugehöriger privater Schlüssel;
- Provisioning Profile;
- Xcode-Projekt und seine Build-Konfiguration;
- Archive für den vorgesehenen Verteilungskanal;
- Zugang und Berechtigung für App Store Connect.
Diese Werte sollten im Repository nicht als echte Geheimnisse abgelegt werden. Platzhalter wie <BUNDLE_ID>, <TEAM_ID>, <CERTIFICATE> und <PROFILE> machen die Pipeline verständlich, ohne Zugangsdaten zu verteilen.
Automatische Signierung reduziert manuelle Konfiguration, setzt aber passende Kontoberechtigungen und eine kontrollierte Xcode-Umgebung voraus. Manuelle Signierung bietet mehr Kontrolle über Zertifikate und Profile, erfordert dafür einen Ablauf zur Erneuerung und sicheren Hinterlegung. Für unbeaufsichtigte Builds ist die entscheidende Frage nicht, ob ein Schalter auf „automatisch“ steht. Entscheidend ist, ob der Job ohne unkontrollierten Zugriff auf private Schlüssel reproduzierbar endet.
Anwendung und Erweiterungen müssen separat geprüft werden. Ein Haupt-Target kann korrekt signiert sein, während ein natives Plugin oder ein zusätzliches Target eine andere Bundle ID oder ein anderes Profile benötigt. Der Apple-Leitfaden zur Verteilung auf registrierte Geräte beschreibt die relevanten Verteilungsschritte. Für die Veröffentlichung ist außerdem die Apple-Dokumentation zu App Store Connect maßgeblich.
Sensible Signaturmaterialien gehören ausschließlich auf einen kontrollierten Veröffentlichungs- oder Releaseknoten. Ressourcenverarbeitung, allgemeine Tests und nicht-Apple-spezifische Builds sollten dort nicht stattfinden. Diese Trennung begrenzt den Schaden bei einem kompromittierten allgemeinen Buildjob.
[ SECTION_07 ] Testnachweise statt Exportordner
Ein erfolgreicher Godot-Export ist noch kein Beweis für ein funktionierendes Spiel. Ein belastbarer Abnahmetest folgt der Artefaktkette:
- Repository auf einem sauberen Mac-Arbeitsbereich auschecken.
- Exakte Godot-Version und passende Exportvorlage prüfen.
- iOS-Projekt mit dem vorgesehenen Exportpreset erzeugen.
- Xcode-Projekt ohne manuelle Korrektur öffnen und bauen.
- Archive oder Testprodukt mit nachvollziehbarem Namen erzeugen.
- Signatur jedes relevanten Targets kontrollieren.
- Simulator- oder Gerätetest gemäß Projektrisiko ausführen.
- Logs und das finale Artefakt außerhalb des Arbeitsbereichs sichern.
Ein Apple-Silicon-Mac kann zeigen, ob der Build auf der vorgesehenen Mac-Architektur kompiliert und läuft. Ein iOS-Simulator prüft viele Laufzeit- und Bedienpfade, ersetzt aber keinen Test auf echter Hardware. Ein physisches iPhone kann Geräteberechtigungen, Eingabe, Sensoren, Grafikverhalten und bestimmte Plattformdienste sichtbar machen, ist aber ebenfalls kein vollständiger Ersatz für andere Testebenen. Die Apple-Erklärung zu simulierten und physischen Geräten beschreibt diese Unterscheidung.
Bei Godot-Projekten sollten Plugins, native Erweiterungen, Touch-Eingaben, Grafikpfade, Audio, Hintergrundverhalten und Plattformdienste nach Risiko geprüft werden. Ein kleines 2D-Projekt ohne native Erweiterung kann mit einer schlankeren Abnahme auskommen. Ein Spiel mit SDK-Plugins oder gerätespezifischen Funktionen benötigt dagegen einen echten Gerätetest und eine überprüfte Signaturkette.
[ SECTION_08 ] Automatisierung und Wiederherstellung
Eine CI auf einem Mac ist erst dann produktionsfähig, wenn auch Fehlerfälle definiert sind. Der Ablauf sollte mindestens diese Zustände unterscheiden:
- Exportvorlage fehlt;
- Godot-Export bricht ab;
- Xcode-Build scheitert;
- Signatur oder Profile passen nicht;
- Upload wird abgelehnt;
- SSH-Verbindung bricht während des Jobs ab;
- Arbeitsbereich enthält alte Artefakte;
- Mac startet neu oder ist vorübergehend nicht verfügbar.
Für GitHub Actions beschreibt die Dokumentation zu selbst gehosteten Runnern die grundlegende Einbindung. Unabhängig vom CI-System sollte der Runner keine produktiven Geheimnisse in frei zugänglichen Logs ausgeben. Exportpresets gehören in versionierte Konfiguration. Signaturdaten und Zugangstoken müssen getrennt verwaltet werden.
Ein robuster Ablauf führt nach einem abgebrochenen SSH-Aufruf nicht automatisch zu einem neuen Upload. Zuerst wird geprüft, ob der vorherige Prozess beendet wurde, ob ein Archive vollständig ist und ob der Arbeitsbereich verworfen werden muss. Danach startet der Job in einem neuen Verzeichnis. Ein wieder erreichbarer Mac ist deshalb nicht gleichbedeutend mit einem ausführbaren Build.
Bei einer einzelnen langfristig gemieteten Maschine liegt der gesamte Releasepfad auf einem Knoten. Das ist einfach, aber ein Neustart oder eine beschädigte Umgebung kann alle Veröffentlichungen blockieren. Ein separater Veröffentlichungs-Mac reduziert die Exposition von Signaturmaterial. Ein allgemeiner Knoten plus Mac-Knoten verteilt die Aufgaben besser, benötigt aber klare Artefaktübergaben und zusätzliche Pipelinepflege.
[ SECTION_09 ] Kosten- und Betriebsmodell
Eine seriöse Rechnung sollte keine erfundenen Pauschalpreise verwenden. Stattdessen werden die tatsächlichen Variablen des eigenen Teams eingesetzt:
Gesamtkosten = Miet- oder Anschaffungskosten + Einrichtungszeit + Leerlauf + Ersatzkapazität + Signaturverwaltung + Betriebsstunden
Bei einer Miete zählen insbesondere der gebuchte Zeitraum, die Vorbereitung der Werkzeuge, die Aufbewahrung von Arbeitsdaten und der Aufwand für einen Ersatzknoten. Beim Kauf kommen Beschaffung, Abschreibung, Reparatur, Strom, Fernzugriff und die interne Administration hinzu. Beim Hybridmodell entstehen zusätzlich Pipeline- und Artefaktverwaltung, dafür bleibt der Mac von allgemeinen Aufgaben entlastet.
Die Nutzung sensibler Kontodaten sollte außerdem unter Datenschutz- und Sicherheitsgesichtspunkten geprüft werden. Werden Zugangsdaten, Logs oder Projektdateien außerhalb der eigenen Infrastruktur verarbeitet, müssen Verantwortlichkeiten, Aufbewahrung und Zugriffsrechte dokumentiert werden. Für Teams mit DSGVO-Anforderungen ist die Standort- und Zugriffspolitik des gewählten Rechenzentrums ein Entscheidungskriterium, nicht nur ein Vertragstext.
[ SECTION_10 ] Entscheidungsmatrix für die Praxis
Die folgende Matrix verdichtet die Entscheidung ohne eine bestimmte Hardware oder einen bestimmten Preis vorauszusetzen:
| Situation | Bevorzugte Lösung | Begründung | Rückfalloption |
|---|---|---|---|
| Einmalige iOS-Portierung oder unklare Nachfrage | Remote-Mac | Geringere langfristige Bindung und schneller kontrollierbarer Versuch | Bei hoher Wiederholung später Kauf prüfen |
| Regelmäßige Veröffentlichungen mit schwankender Last | Remote-Mac oder Hybridbetrieb | Kapazität bleibt flexibel, Mac-Aufgaben sind klar begrenzt | Zusätzlicher Releaseknoten bei Engpässen |
| Hohe, dauerhaft planbare Auslastung | Gekaufter Mac | Eigene Werkzeug- und Kapazitätskontrolle kann sich lohnen | Mietknoten als Ausfallersatz |
| Viele allgemeine CI-Jobs, wenige iOS-Releases | Hybridbetrieb | Windows/Linux übernehmen Standardaufgaben, Mac bleibt Releaseknoten | Einzelner Remote-Mac für kleine Teams |
| Strenge Trennung von Geheimnissen und Veröffentlichungen | Separater kontrollierter Mac | Signaturmaterial bleibt außerhalb allgemeiner Jobs | Manuelle Freigabe vor dem Upload |
| Kein Zugriff auf Godot-Version, Xcode oder Exportvorlagen | Keine produktive Nutzung | Reproduzierbarkeit ist nicht gegeben | Anbieter oder Umgebung wechseln |
Wer eine Lösung auswählt, sollte vor der langfristigen Bindung einen realen, rücksetzbaren Test durchführen. Dabei werden nicht nur das Öffnen des Editors, sondern Exportvorlage, Xcode-Build, Signatur, Testgerät oder Simulator, Artefaktsicherung und Wiederherstellung nach einem Neustart geprüft.
[ SECTION_11 ] Unabhängige FAQ
Die häufigsten Fehlentscheidungen entstehen, wenn ein erzeugtes Xcode-Projekt mit einem fertigen iOS-Produkt verwechselt wird. Die folgenden Antworten trennen deshalb Entwicklungsumgebung, Apple-Werkzeuge und Veröffentlichungsrechte.
Windows- oder Linux-Entwicklung
Ein Godot-Projekt kann auf Windows oder Linux entwickelt, versioniert und für allgemeine Plattformen gebaut werden. Der iOS-Teil wird anschließend auf den Mac übertragen. Dort müssen Export, Xcode-Build und Signatur stattfinden. Für ein Team ist es sinnvoll, nur definierte Artefakte oder einen Commit an den Mac zu übergeben, statt den gesamten Arbeitsplatz dauerhaft zu spiegeln.
Vollständige Xcode-Installation
Die iOS-Exportdokumentation von Godot nennt einen macOS-Rechner mit Xcode. Eine reine Prüfung auf vorhandene Kommandozeilenwerkzeuge ist daher kein ausreichender Abnahmetest. Je nach Projekt können SDKs, Plattformkomponenten, Simulatorbestandteile und native Plugins relevant sein. Der konkrete Xcode-Umfang muss mit dem Zielprojekt und der vorgesehenen Teststufe abgeglichen werden.
Remote-Mac für Signierung
Ein Remote-Mac kann Signierung und App-Store-Veröffentlichung übernehmen, wenn das Team die Umgebung kontrollieren kann. Dazu gehören passende Xcode-Werkzeuge, Godot-Exportvorlagen, Bundle ID, Team ID, Profile und Zertifikate. Für die Sicherheit sollte ein separater Veröffentlichungsjob verwendet werden. SSH-Zugang allein beweist weder funktionierende Signierung noch eine ausreichende Kontoberechtigung.
Mac-Anteil in der CI
Eine vollständige Mac-CI ist nicht zwingend. Allgemeine Tests, Asset-Verarbeitung und Nicht-Apple-Builds können auf vorhandenen Knoten bleiben. Der Mac übernimmt die Apple-spezifische Kette. Diese Aufteilung spart keine Kosten automatisch, kann aber Mac-Zeit, Geheimniszugriff und Fehlerumfang begrenzen. Der Übergang zwischen den Knoten muss über versionierte Artefakte und reproduzierbare Pfade erfolgen.
Grenzen von C# unter iOS
Ein C#-Projekt benötigt eine eigene Kompatibilitätsprüfung. Neben Godot und Xcode können Laufzeit, Exportvorlagen, native Erweiterungen und zusätzliche Abhängigkeiten den Ablauf beeinflussen. Daher sollte der zuständige Mac ein echtes Projekt kompilieren und signieren. Eine allgemeine Aussage über C# reicht nicht aus, wenn Plugins oder experimentelle Komponenten beteiligt sind.
[ SECTION_12 ] Schlussfolgerung für NOVAKVM und die Betriebsentscheidung
Ein Mac mini oder ein eigener Mac ist nicht automatisch die beste Antwort. Für kurzfristige Portierung, unregelmäßige Releases und noch unbekannte Auslastung bindet ein Kauf unnötig Kapital und erzeugt dauerhafte Wartungsarbeit. Ein einzelner, dauerhaft gemieteter Knoten kann dagegen bei hoher Nutzung, strengen Latenzanforderungen oder physischem Gerätezugriff zu begrenzt sein. Eine reine Windows- oder Linux-CI scheitert an macOS, Xcode und der Apple-Signaturkette.
Für viele Teams ist deshalb ein Remote-Mac von NOVAKVM der vernünftige erste Prüfpunkt: Die allgemeine Entwicklung bleibt unverändert, während der Mac gezielt für Godot-Export, Xcode, Signierung und Veröffentlichung eingesetzt wird. Nach einem erfolgreichen Testprojekt kann das Team anhand realer Releasehäufigkeit entscheiden, ob eine längere Mietdauer, ein eigener Mac oder ein hybrider Aufbau wirtschaftlich und organisatorisch besser passt. Die verfügbaren Remote-Mac-Optionen von NOVAKVM sollten dabei erst nach der technischen Abnahme bewertet werden, nicht davor.
Häufige Fragen
Wie wird ein Godot-Projekt von Windows oder Linux für iOS exportiert?
Die Projektentwicklung kann auf Windows oder Linux stattfinden. Für den eigentlichen iOS-Export muss das Projekt jedoch auf einen laufenden macOS-Rechner mit installiertem Xcode gelangen. Dort erzeugt Godot das iOS-Projekt, anschließend übernimmt Xcode Kompilierung, Signierung, Archivierung und je nach Berechtigung den Upload. Ein erzeugtes Projektverzeichnis allein ist noch kein auslieferbares iOS-Produkt.
Reicht für den Godot-iOS-Export nur die Xcode-Kommandozeile aus?
Für eine belastbare iOS-Lieferkette sollte Xcode vollständig installiert und für das Zielprojekt initialisiert sein. Godot verweist für den iOS-Export ausdrücklich auf einen macOS-Rechner mit Xcode. Zusätzlich können SDKs, Plattformkomponenten, Simulator-Runtimes, Zertifikate und Projektziele relevant sein. Welche Bestandteile nötig sind, hängt vom Export, den nativen Erweiterungen und dem Testziel ab.
Kann ein gemieteter Remote-Mac Godot-Projekte signieren und veröffentlichen?
Ja, sofern der Remote-Mac echte macOS-Ausführung, die benötigte Xcode-Version, Godot-Exportvorlagen und ausreichende Rechte für die Initialisierung bietet. Für die Veröffentlichung müssen Bundle ID, Team ID, Zertifikate und Provisioning Profiles korrekt zusammenpassen. Private Schlüssel und Zugangsdaten sollten ausschließlich auf einem kontrollierten Veröffentlichungsrechner verwendet und nicht dauerhaft in gewöhnlichen Build-Arbeitsplätzen abgelegt werden.
Soll eine iOS-CI mit Godot vollständig auf dem Mac laufen?
Nein. Ressourcenverarbeitung, allgemeine Tests, Linux- oder Windows-Builds und viele Skripte können auf vorhandenen Standardknoten bleiben. Auf den Mac gehören mindestens die Apple-spezifischen Aufgaben: iOS-Export, Xcode-Build, Signierung, Archivierung und der kontrollierte Upload. Diese Aufteilung senkt die Mac-Auslastung und begrenzt das Risiko, dass allgemeine Build-Aufgaben auf dem signierten Veröffentlichungsrechner laufen.
Welche zusätzlichen Grenzen gelten für ein Godot-C#-Projekt unter iOS?
Bei C#-Projekten muss neben der normalen iOS-Exportkette geprüft werden, ob die verwendete Godot-Ausgabe, die Exportvorlagen, die Laufzeit und alle nativen oder .NET-bezogenen Erweiterungen das konkrete Ziel unterstützen. Die C#-Unterstützung darf deshalb nicht pauschal wie ein identischer GDScript-Export behandelt werden. Vor der Pipeline-Entscheidung sollte ein echtes Projekt auf dem vorgesehenen Mac bis zum Xcode-Build getestet werden.