CodeQL on Xcode 27: How to Keep Swift Scanning on a Supported Toolchain
In Xcode 27 the app builds fine, but CodeQL no longer traces the Swift build on the same macOS runner. Which toolchain combination keeps the scans running?
- Keep Swift scans on a supported combination of macOS 26 or earlier and Xcode 26 or earlier.
- The build-mode none option offered for C/C++, C#, and Java does not apply to Swift.
- Check the runner OS, selected Xcode installation, and source compatibility together.
Keep the scan on an older supported combination
GitHub’s October 19 guidance is to pin both macOS and Xcode to version 26 or earlier for Swift scans and other traced builds. CodeQL does not support Swift 6.4 on any platform.
GitHub attributes the limitation to the removal of Intel code from some system binaries and libraries used by its build tracing. A successful application build therefore does not establish that CodeQL supports tracing that build.
The selected Xcode matters even on macOS 26
The platform requirements explicitly restrict macOS 26 with Xcode 27 selected to build mode none. Pinning only the runner’s operating system leaves a critical part of the configuration unresolved.
| Environment | Implication for Swift scanning |
|---|---|
| Supported macOS 26 or earlier and Xcode 26 or earlier | The route for retaining current scans, provided the source and Swift version remain compatible. |
| macOS 26 with Xcode 27 selected | Limited to none mode, which provides no Swift fallback. |
| macOS 27 | Limited to Apple Silicon and none mode; not a supported Swift-scanning setup. |
Moving a runner to Apple Silicon alone cannot resolve the analysis-mode restriction.
A Java workaround does not transfer to Swift or Kotlin
The build-mode reference lists autobuild and manual for Swift, Go, and Kotlin. None of those languages has the none fallback offered for C/C++, C#, and Java.
Even where available, switching modes changes how the analysis database is produced. For Java, missing generated code or inaccurate dependency information can reduce analysis accuracy. A mixed Java/Kotlin repository also cannot be treated as a Java-only project when choosing a mode.
Verify the active installation and the source requirements
On a runner with several Xcode installations, inventory is not enough: the selected developer directory matters. Apple documents this command for inspecting that selection:
xcode-select --print-pathIdentify the Xcode version at that path, then pin the runner image and toolchain together. CodeQL’s current language table lists Swift 5.4–6.3. The application must still build with the supported tools; an older machine cannot make incompatible source compile.
Projects that require Swift 6.4 do not gain support by adding a none setting. Teams retaining current Swift scans need an explicit supported toolchain and must consider analyzer compatibility when adopting newer language features.