CodeQL kann Xcode-27-Builds nicht tracen und Swift 6.4 nicht scannen
GitHub sagt, CodeQL kann Builds unter Xcode 27 nicht tracen und Swift 6.4 nicht analysieren, weil Apple Intel-Code entfernt hat, auf den es angewiesen war. Der Rat: vorerst bei Xcode 26 bleiben.
3 Min. Lesezeit

GitHub hat am 19. Oktober 2026 mitgeteilt, dass CodeQL, seine Engine für Code-Scans, mit Xcode 27 erstellte Builds nicht tracen und Swift-6.4-Code auf keiner Plattform analysieren kann. Für iOS- und Mac-Teams, die Sicherheitsscans in ihrer Build-Pipeline ausführen, bedeutet der Umstieg auf Apples neueste Werkzeuge nun, einen Teil dieser Scans zu verlieren, bis GitHub Unterstützung nachliefert.
Was GitHub angekündigt hat
CodeQL ist das Werkzeug hinter GitHubs Code-Scanning. Es verwandelt den Quellcode eines Projekts in eine Datenbank und führt dann Abfragen darauf aus, um Sicherheitslücken zu finden. Bei kompilierten Sprachen baut es diese Datenbank meist, indem es den Build per „Tracing“ verfolgt: Es beobachtet den Compiler während des Laufs und erfasst jede Datei, sobald sie kompiliert wird.
Genau dieses Tracing funktioniert nicht mehr. Ab macOS 27 und Xcode 27 enthält Apple in einigen Systemdateien, auf die CodeQL angewiesen ist, keinen Intel-Code (x86_64) mehr, so GitHubs Changelog. Diese Dateien sind Binärdateien und Bibliotheken, die CodeQL zum Tracen von Builds nutzt. Der Hinweis sagt es klar: „CodeQL kann auf diesen Versionen keine getracten Scans unterstützen und Swift 6.4 nicht analysieren.“
| Konfiguration | Was GitHub sagt |
|---|---|
| Xcode 27 installiert | Getracte Extraktion ist für C/C++, C#, Go, Java, Kotlin und Swift nicht verfügbar |
| macOS 27 | Getracte Extraktion ist für dieselben sechs Sprachen möglicherweise nicht verfügbar |
| Swift 6.4 | Auf keiner Plattform unterstützt |
| Intel-basierte Macs | CodeQL-Unterstützung wird Mitte Dezember 2026 abgekündigt |
Der Changelog nennt kein Datum für die Unterstützung von Swift 6.4.
Warum ein Xcode-Upgrade Swift 6.4 mit sich bringt
Das Swift-Problem ist für ein Team, das seine Werkzeuge aktualisiert, schwer zu umgehen. Apples Seite mit den Xcode-Anforderungen nennt drei aktuelle Versionen: Xcode 27, Xcode 27.1 und die Beta 3 von Xcode 27.2. Alle drei liefern den Swift-6.4-Compiler mit. Alle drei brauchen einen Mac mit macOS Tahoe 26.6 oder neuer.
Es gibt also keinen Xcode-27-Build, der einen älteren Swift-Compiler behält. Der Umstieg auf Xcode 27 bedeutet den Umstieg auf Swift 6.4, die Version, die async defer brachte und Swift Build zum Standard machte. Er bedeutet auch den Verlust der Swift-Analyse von CodeQL. Das ist wichtig für Apps, die Xcode 27 selbst brauchen. Der Release Candidate von Xcode 27.1 etwa hat die Einreichung von iPhone-Duo-Apps im App Store geöffnet.
Die Workarounds, die GitHub vorschlägt
GitHubs Hinweis nennt drei Wege, Scans am Laufen zu halten:
- Bei den bisherigen Werkzeugen bleiben. Workflows, die Swift scannen oder auf getracte Builds angewiesen sind, sollten auf macOS 26 oder älter mit Xcode 26 oder älter laufen.
- Runner und Toolchain festlegen. Legen Sie in GitHub Actions das Runner-Image und die Toolchain-Version ausdrücklich fest, damit ein Image-Update einen Scan nicht ohne Vorwarnung auf Xcode 27 verschieben kann.
- Tracing wo möglich auslassen. Für C/C++, C# und Java nutzen Sie CodeQLs Build-Modus „none“. In diesem Modus liest CodeQL die Quelldateien direkt, statt einen Build zu beobachten, sodass der fehlende Intel-Code keine Rolle spielt.
Der Hinweis bietet den Build-Modus „none“ nur für diese drei Sprachen an. Für Swift lautet sein einziger Rat, bei Xcode 26 oder älter zu bleiben.
Was das für Entwickler bedeutet
Das Risiko ist hier ein Scan, der weiterläuft, aber Ihren Code unbemerkt nicht mehr abdeckt. Ein paar Prüfungen lohnen sich diese Woche:
- Finden Sie heraus, worauf Ihr Scan-Job wirklich läuft. Wenn ein CodeQL-Workflow ein gleitendes Runner-Label statt eines festgelegten Images nutzt, prüfen Sie, welche macOS- und Xcode-Versionen er heute bekommt. Legen Sie diese dann fest, wie GitHub es empfiehlt.
- Lesen Sie die Scan-Logs, nicht nur das Ergebnis. Ein grünes Häkchen bedeutet, dass der Job durchgelaufen ist. Es beweist nicht, dass Swift-Dateien analysiert wurden. Sehen Sie sich den Extraktionsschritt im Log an und prüfen Sie, ob Ihre Swift-Quellen darin auftauchen.
- Trennen Sie Build und Scan. Teams, die mit Xcode 27 ausliefern müssen, können ihre Releases weiter damit bauen. Den CodeQL-Job können sie separat auf einem festgelegten Runner mit macOS 26 und Xcode 26 ausführen. Das funktioniert nur, solange der Code noch mit Xcode 26 baut, also beendet die Nutzung von Funktionen, die nur Swift 6.4 bietet, diesen Weg.
- Planen Sie jetzt für Intel-Runner. Selbst gehostete Intel-Mac-Runner verlieren Mitte Dezember 2026 die CodeQL-Unterstützung. Planen Sie bis dahin Budget für Rechner mit Apple Silicon ein.
- Verfolgen Sie die nächsten CodeQL-Release-Notes. Das Release 2.27.1 fügte eine C++-Abfrage hinzu und liest Lock-Dateien von Actions. Unterstützung für Swift 6.4 käme auf demselben Weg, und dann ist der Zeitpunkt, die Festlegung wieder aufzuheben.
Quellen
- CodeQL changes for macOS 27, Xcode 27, and Swift 6.4 - GitHub Changelog
- Xcode SDKs and system requirements - Apple Developer
Ähnliche Artikel

Xcode 27.1 RC öffnet den App Store für iPhone-Duo-Apps
Apple nimmt jetzt iPhone-Duo-Apps an, die mit Xcode 27.1 gebaut wurden, 18 Tage bevor das Foldable am 23. Oktober erscheint. Duo-Screenshots werden im April 2027 Pflicht.

Apple verschärft macOS Full Disk Access wegen KI-Agenten
Apple hat am 2. Oktober erklärt, dass Mac-Apps für Full Disk Access eine „sehr ausdrückliche Nutzeraktion“ brauchen werden, weil KI-Agenten diesen Zugriff riskanter machen.

CodeQL 2.27.1 bringt eine C++-Abfrage und liest Actions-Lock-Dateien
CodeQL 2.27.1 liefert 498 Standard-Sicherheitsabfragen für 170 CWEs, eine neue C/C++-Prüfung, Unterstützung für Kotlin 2.4.20 und kennt Actions-Lock-Dateien.