CodeQL não consegue rastrear builds do Xcode 27 nem analisar Swift 6.4
O GitHub diz que o CodeQL não consegue rastrear builds no Xcode 27 nem analisar Swift 6.4, depois que a Apple removeu código Intel do qual ele dependia. O conselho: ficar no Xcode 26 por enquanto.
3 min de leitura

O GitHub disse em 19 de outubro de 2026 que o CodeQL, seu motor de varredura de código, não consegue rastrear builds feitos com o Xcode 27 e não consegue analisar código Swift 6.4 em nenhuma plataforma. Para equipes de iOS e Mac que rodam varreduras de segurança no pipeline de build, migrar para as ferramentas mais novas da Apple agora significa perder parte dessas varreduras até o GitHub lançar o suporte.
O que o GitHub anunciou
O CodeQL é a ferramenta por trás do code scanning do GitHub. Ele transforma o código-fonte de um projeto em um banco de dados e depois roda consultas sobre ele para encontrar bugs de segurança. Em linguagens compiladas, ele geralmente monta esse banco de dados "rastreando" o build: observa o compilador enquanto ele roda e registra cada arquivo à medida que é compilado.
É esse rastreamento que quebra. A partir do macOS 27 e do Xcode 27, a Apple deixou de incluir código Intel (x86_64) em alguns arquivos de sistema dos quais o CodeQL depende, segundo o changelog do GitHub. Esses arquivos são binários e bibliotecas que o CodeQL usa para rastrear builds. O aviso diz isso com todas as letras: "O CodeQL não pode oferecer suporte a varreduras rastreadas nessas versões nem analisar Swift 6.4."
| Configuração | O que o GitHub diz |
|---|---|
| Xcode 27 instalado | A extração rastreada não está disponível para C/C++, C#, Go, Java, Kotlin ou Swift |
| macOS 27 | A extração rastreada pode não estar disponível para as mesmas seis linguagens |
| Swift 6.4 | Sem suporte em nenhuma plataforma |
| Macs com processador Intel | Suporte do CodeQL descontinuado em meados de dezembro de 2026 |
O changelog não dá data para o suporte ao Swift 6.4.
Por que atualizar o Xcode traz o Swift 6.4
O problema do Swift é difícil de evitar para uma equipe que atualiza suas ferramentas. A página de requisitos do Xcode da Apple lista três versões atuais: Xcode 27, Xcode 27.1 e o Xcode 27.2 beta 3. As três trazem o compilador Swift 6.4. As três exigem um Mac com macOS Tahoe 26.6 ou posterior.
Ou seja, não existe build do Xcode 27 que mantenha um compilador Swift mais antigo. Migrar para o Xcode 27 significa migrar para o Swift 6.4, a versão que trouxe async em defer e tornou o Swift Build o padrão. Também significa perder a análise de Swift do CodeQL. Isso importa para apps que precisam do próprio Xcode 27. O release candidate do Xcode 27.1, por exemplo, foi o que liberou na App Store o envio de apps para o iPhone Duo.
As alternativas que o GitHub sugere
O aviso do GitHub lista três formas de manter as varreduras funcionando:
- Fixe as ferramentas anteriores. Workflows que analisam Swift, ou que dependem de builds rastreados, devem rodar no macOS 26 ou anterior com o Xcode 26 ou anterior.
- Fixe o runner e o toolchain. No GitHub Actions, defina explicitamente a imagem do runner e a versão do toolchain, para que uma atualização de imagem não leve uma varredura para o Xcode 27 sem aviso.
- Evite o rastreamento quando possível. Para C/C++, C# e Java, use o modo de build "none" do CodeQL. Nesse modo, o CodeQL lê os arquivos-fonte diretamente em vez de observar um build, então a falta do código Intel não importa.
O aviso oferece o modo de build "none" só para essas três linguagens. Para Swift, o único conselho é ficar no Xcode 26 ou anterior.
O que isso significa para os desenvolvedores
O risco aqui é uma varredura que continua rodando, mas deixa de cobrir seu código sem avisar. Vale fazer algumas verificações nesta semana:
- Descubra onde o seu job de varredura roda de fato. Se um workflow do CodeQL usa um rótulo de runner flutuante em vez de uma imagem fixada, verifique quais versões do macOS e do Xcode ele recebe hoje. Depois fixe essas versões, como o GitHub recomenda.
- Leia os logs da varredura, não só o resultado. Um check verde significa que o job terminou. Isso não prova que os arquivos Swift foram analisados. Olhe a etapa de extração no log e confirme que seus arquivos-fonte Swift aparecem nela.
- Separe o build da varredura. Equipes que precisam lançar com o Xcode 27 podem continuar gerando as versões nele. Elas podem rodar o job do CodeQL separadamente, em um runner fixado com macOS 26 e Xcode 26. Isso só funciona enquanto o código ainda compila com o Xcode 26, então adotar recursos exclusivos do Swift 6.4 encerra essa opção.
- Planeje os runners Intel desde já. Runners Mac Intel auto-hospedados perdem o suporte do CodeQL em meados de dezembro de 2026. Reserve orçamento para máquinas com Apple silicon antes disso.
- Acompanhe as próximas notas de versão do CodeQL. A versão 2.27.1 adicionou uma consulta de C++ e passou a ler arquivos de lock do Actions. O suporte ao Swift 6.4 chegaria da mesma forma, e esse é o momento de desfixar as versões.
Fontes
- CodeQL changes for macOS 27, Xcode 27, and Swift 6.4 - GitHub Changelog
- Xcode SDKs and system requirements - Apple Developer
Artigos relacionados

Xcode 27.1 RC abre a App Store para apps do iPhone Duo
A Apple agora aceita apps para iPhone Duo compilados com o Xcode 27.1, 18 dias antes de o dobrável chegar aos clientes em 23 de outubro. Capturas de tela do Duo passam a ser obrigatórias em abril de 2027.

Apple restringe o Full Disk Access do macOS por causa de agentes de IA
A Apple disse em 2 de outubro que apps de Mac vão precisar de uma "ação muito explícita do usuário" para obter o Full Disk Access, porque agentes de IA tornam esse acesso mais arriscado.

CodeQL 2.27.1 adiciona uma consulta C++ e lê arquivos de lock do Actions
O CodeQL 2.27.1 traz 498 consultas de segurança padrão cobrindo 170 CWEs, uma nova verificação de C/C++, suporte ao Kotlin 2.4.20 e reconhece arquivos de lock do Actions.