O Xcode 27 remove o ld64 e passa a exigir nomes de módulo únicos

A Apple aposentou um linker em uma única frase: “O linker ld64 foi removido e a opção -ld_classic não é mais suportada.”¹ A flag que sumiu agora é a mesma que a Apple mandou os desenvolvedores adicionarem. As release notes do próprio Xcode 15 ofereciam -Wl,-ld_classic como contorno para dois bugs do linker.³

Resumo

• O Xcode 27 remove o ld64 e para de aceitar -ld_classic.¹ As notas do Xcode 15 prescreviam a flag para travamentos com símbolos fracos e para bugs de importação em LTO, o Xcode 16 marcou a opção como obsoleta e o Xcode 26 não disse absolutamente nada.³⁴¹⁰
• A segunda quebra está no compilador Swift. A Apple transformou a varredura de dependências em uma única ação compartilhada, então “todo módulo Clang alcançável a partir de uma única ação de varredura de dependências do Swift precisa ter um nome de módulo único.”² A Apple faz duas ressalvas: a varredura “pode reportar um erro” e, antes disso, o varredor “pode ter tolerado nomes duplicados.”²
• As duas quebras disparam na atualização do toolchain, não em uma escolha de deployment target ou de SDK, e nenhuma delas tem componente em tempo de execução. A população exposta: binários de terceiros embarcados, CocoaPods ou uma base de código grande e mista de Swift/Objective-C/C++.
• O “pode” da Apple não é cautela editorial. No Xcode 26.6, coloquei dois module maps declarando o mesmo nome em um único search path e rodei o varredor 20 vezes: nove execuções quebraram com SIGSEGV, cinco abortaram e seis terminaram limpas.⁸
• Um module map embarcado que redeclara um módulo do SDK — o caso que a Apple cita — compila em silêncio hoje e esconde o módulo real. Meu shim SQLite3 embarcado passou na checagem de tipos com exit 0, e sqlite3_open deixou de existir.⁸
• Em sete projetos auditados: zero -ld_classic, OTHER_LDFLAGS sem valor definido em todos eles e zero nomes de módulo duplicados entre 391 module maps, porque nenhum repositório guarda um module map escrito à mão.⁹

As duas notas saíram nas release notes do Xcode 27 beta 4, junto com o Swift 6.4 e os SDKs da linha 27.¹¹ Leia tudo como texto de beta.

A flag que a Apple mandou você adicionar

A história começa com a reescrita de um linker. O Xcode 15 anunciou um linker novo, tornou-o padrão “para todos os binários de macOS, iOS, tvOS e visionOS” e definiu os termos da aposentadoria em uma única oração: “O linker clássico ainda pode ser solicitado explicitamente com -ld64, e será removido em uma versão futura.”³

O linker novo chegou com bugs, e a Apple documentou a saída de emergência duas vezes na mesma página. O primeiro Known Issue: “Binários que usam símbolos com definição fraca travam em tempo de execução no iOS 14/macOS 12 ou anteriores. Isso afeta principalmente projetos C++, pelo uso extensivo que fazem de símbolos fracos.” O contorno da Apple era elevar o deployment target “ou adicionar -Wl,-ld_classic à build setting OTHER_LDFLAGS.”³ O segundo, sobre arquivos-objeto de LTO que linkavam importações de símbolos fracos como não fracas, oferecia “-Wl,-weak_reference_mismatches,weak ou -Wl,-ld_classic” na mesma configuração.³

Os dois bugs pegaram mais pesado em projetos C++, o que explica quem ainda carrega a flag. Ninguém volta a mexer numa configuração que impediu um crash.

O Xcode 16 avisou em uma frase: “a opção de linker -ld_classic está obsoleta e será removida em uma versão futura.”⁴ Depois, silêncio. Procurei ld_classic, ld64 e o linker clássico nas release notes do Xcode 26 e não achei nada.¹⁰

O toolchain atual ainda aceita a flag e ainda reclama. No Xcode 26.6, linkei um programa C trivial com ela:⁷

xcrun clang hello.c -o hello -Wl,-ld_classic

ld: warning: -ld_classic is deprecated and will be removed in a future release

Status de saída zero. O binário linka. Trocar por -Wl,-ld64 produz o warning idêntico, citando -ld_classic, ou seja, as duas grafias que a Apple usou chegam hoje ao mesmo caminho de código.⁷ A nota do Xcode 27 cita apenas -ld_classic, e não tive como testar se -ld64 falha do mesmo jeito.

Um detalhe complica a palavra “removido”. O linker do Xcode 26.6, quando é chamado a se identificar com xcrun ld -v, informa quais arquiteturas ele delega:⁷

@(#)PROGRAM:ld PROJECT:ld-1267
BUILD 16:38:58 Jun  8 2026
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em armv8m.main armv8.1m.main
will use ld-classic for: armv6 armv7 armv7s i386 armv6m armv7k armv7m armv7em

O ld-classic existe como binário de verdade no toolchain, com man page própria, e o linker ainda roteia oito arquiteturas para ele.⁷ Nenhuma delas sobrevive em um SDK de app atual: o iPhoneOS 26.5 declara apenas arm64e e arm64, e o SDK do watchOS acrescenta arm64_32.⁷ A lista é de ARM de 32 bits, i386 e alvos embarcados Cortex-M. Ler a ausência dessas arquiteturas nos SDKs como a razão pela qual a remoção é segura para quem faz apps é inferência minha, não afirmação da Apple.

Achar a flag sem confiar no grep

O -ld_classic mora em OTHER_LDFLAGS, então pergunte ao build system qual valor ele resolve, em vez de caçar texto dentro dos arquivos:

xcodebuild -showBuildSettings \
  -project YourApp.xcodeproj \
  -configuration Release -sdk iphoneos 2>/dev/null \
  | grep -E "OTHER_LDFLAGS|SUPPORTED_PLATFORMS"

No projeto Reps, volta uma linha só:⁹

    SUPPORTED_PLATFORMS = appletvos appletvsimulator iphoneos iphonesimulator macosx

O OTHER_LDFLAGS não aparece em lugar nenhum, e essa é a resposta: a configuração está sem valor, então nenhuma flag de linker chega à etapa de link por ela. Ausência nas configurações de build resolvidas carrega uma informação que ausência em busca textual não carrega. Para a pergunta sobre plataformas, leia também SUPPORTED_PLATFORMS, nunca um *_DEPLOYMENT_TARGET, que o Xcode escreve haja ou não um destino real.

Três armadilhas produziram resultados falsamente limpos durante a auditoria, e as três não imprimem nada e saem com sucesso. O timeout não existe no macOS de fábrica, então envolver o xcodebuild nele devolve exit 127 e saída vazia, que se lê como um projeto sem nenhuma flag de linker. No zsh, um --include=*.pbxproj sem aspas sofre expansão de glob antes de o grep vê-lo, então o comando morre com “no matches found” em vez de reportar zero ocorrências. E o find não segue um symlink passado como ponto de partida, o que importa porque xcrun --sdk iphoneos --show-sdk-path devolve justamente um: find "$SDK" -name '*.modulemap' não acha nada, enquanto find -H "$SDK" acha 266 arquivos.⁹ Coloque seus padrões entre aspas, passe -H e confirme que o comando casa com algo que você sabe estar lá antes de confiar em um zero.

Um target mantido à mão guarda a flag em project.pbxproj ou em um .xcconfig; um projeto com CocoaPods também pode recebê-la de um gancho post_install, que nenhum arquivo editado por desenvolvedor registra. A frota que auditei não tem nem um nem outro, então esse último caminho ficou sem verificação.⁹

A regra de nome de módulo e as duas ressalvas da Apple

A segunda quebra chega disfarçada de ganho de performance, arquivada em New Features e não em Deprecations. A entrada de Swift Compiler da Apple, na íntegra:

O varredor de dependências do Swift foi otimizado para evitar trabalho de configuração e buscas de header redundantes ao procurar módulos Clang durante uma única ação de varredura de dependências, melhorando substancialmente a performance da varredura. Como consequência dessa mudança, todo módulo Clang alcançável a partir de uma única ação de varredura de dependências do Swift precisa ter um nome de módulo único. Se dois module maps visíveis para a mesma varredura declararem um módulo Clang com o mesmo nome, a varredura pode reportar um erro. Antes, o varredor pode ter tolerado nomes duplicados. Os casos mais comuns são projetos ou SDKs que fornecem o mesmo nome de módulo Clang a partir de mais de um local no search path de headers, e fontes de terceiros embarcadas que trazem um module.modulemap redeclarando um módulo do SDK.²

Quatro coisas aí merecem ser separadas. A Apple limita a exigência ao que uma varredura consegue alcançar, não ao seu disco inteiro. A Apple descreve a consequência como “pode reportar um erro” e usa a mesma ressalva para o comportamento antigo. A Apple nomeia os dois formatos que disparam o problema: um nome de módulo fornecido a partir de dois locais no search path de headers e um module.modulemap embarcado redeclarando um módulo do SDK. E o gatilho é o toolchain, já que nada ali menciona deployment target nem versão de SDK.

A regra é anterior à otimização. A linguagem de module map do Clang diz isso com todas as letras: “Cada módulo deve ter uma única definição.”⁶ O que a documentação nunca diz é a consequência de quebrar a regra, e esse silêncio se mostra bem merecido: a resposta do toolchain não é um comportamento, são vários.

O que uma colisão faz de verdade

As ressalvas da Apple me deram vontade de ver a falha, então montei a versão mínima: dois diretórios, cada um com um module.modulemap declarando o mesmo módulo.⁸

A/module.modulemap    B/module.modulemap
module Widget {       module Widget {
    header "widget.h"     header "widget.h"
    export *              export *
}                     }

Com os dois diretórios no search path, uma checagem de tipos simples falha do mesmo jeito toda vez, 20 execuções em 20:⁸

B/module.modulemap:1:8: error: redefinition of module 'Widget'
1 | module Widget {
  |        `- error: redefinition of module 'Widget'
A/module.modulemap:1:8: note: previously defined here

redefinition of module é a string a procurar em um build log, e o clang do Xcode 26.6 já a emite. Tirar um dos search paths faz a mesma compilação passar, o que confirma que o gatilho é a visibilidade dentro de uma mesma compilação, não a presença no disco.⁸

O varredor de dependências se comporta de outro jeito, e essa diferença é a razão inteira de a Apple ter escrito “pode”. Passar os mesmos dois module maps por swiftc -scan-dependencies 20 vezes produziu três desfechos: nove quebras com SIGSEGV, cinco abortos e seis sucessos limpos.⁸ Os rastreamentos de pilha das execuções que quebraram passam por performParallelClangModuleLookup, o que combina com uma condição de corrida na busca paralela que a Apple diz estar substituindo. Atribuir o não determinismo a essa corrida é minha leitura do rastreamento, não afirmação da Apple.

O segundo caso citado pela Apple é o silencioso. Escrevi um module map embarcado declarando SQLite3, um módulo real do SDK do iPhoneOS, coloquei no search path e compilei contra ele:⁸

Vendor/module.modulemap
module SQLite3 {
    header "shim.h"
    export *
}

A compilação passou. Exit 0, nenhum warning, nenhuma nota, nenhum diagnóstico de espécie alguma. Aí pedi sqlite3_open à mesma configuração:⁸

error: cannot find 'sqlite3_open' in scope

Sem o diretório embarcado no search path, o arquivo idêntico compila. O module map embarcado sombreou por completo o SQLite3 do SDK, e o toolchain não disse nada. Ou seja, hoje o caso da redeclaração embarcada não falha em alto e bom som; ele falha com API ausente em um módulo que você achava ter importado. A nota da Apple diz que no Xcode 27 a varredura “pode reportar um erro” nesse ponto, o que converteria um sombreamento silencioso em falha de build.

Eu compilo no Xcode 26.6 (build 17F113), então todo diagnóstico acima vem do toolchain anterior.⁷⁸ Não tenho como reportar o texto de erro do Xcode 27 e não inventei nenhum. A maquinaria de diagnóstico, a string para procurar e a tolerância que a Apple descreve estar aposentando já existem hoje.

Auditar nomes de módulo duplicados

Enumerar nomes de módulo declarados parece um grep de uma linha, mas duas construções da linguagem de module map produzem respostas erradas.

extern module Foo "Foo.modulemap" é uma referência antecipada, não uma definição, e o SDK da Apple usa 79 delas em um único module map.⁷ Uma varredura ingênua conta a referência e a definição real como duas declarações de Foo. Segundo, module Darwin.C { ... } usa um module-id com ponto para estender um módulo declarado em outro lugar; 13 module maps do SDK abrem module Darwin.something, e ler o primeiro componente como declaração de topo junta os 13 com a declaração real de Darwin em uma colisão de 14 arquivos.⁷ Os dois falsos positivos apareceram no meu primeiro rascunho.

O que sobreviveu lida com comentários, com profundidade de chaves — para que submódulos explicit module aninhados fiquem de fora — e com caminhos que contêm espaços:

find -H "${1:-.}" \( -name '*.modulemap' -o -name 'module.map' \) \
  -not -path '*/build/*' -not -path '*/.build/*' \
  -not -path '*/DerivedData*/*' -print0 |
while IFS= read -r -d '' map; do
  awk -v f="$map" '
    { line = $0; sub(/\/\/.*/, "", line)
      if (depth == 0 && line !~ /extern[[:space:]]+module/ &&
          match(line, /(^|[[:space:]])module[[:space:]]+[A-Za-z_][A-Za-z0-9_.]*/)) {
        n = substr(line, RSTART, RLENGTH); sub(/.*module[[:space:]]+/, "", n)
        if (n !~ /\./) print n "\t" f
      }
      for (i = 1; i <= length(line); i++) {
        c = substr(line, i, 1)
        if (c == "{") depth++; else if (c == "}") depth--
      }
    }' "$map"
done | sort -u > /tmp/modnames.txt

cut -f1 /tmp/modnames.txt | uniq -d | while read -r n; do
  echo "duplicate: $n"
  awk -F'\t' -v n="$n" '$1==n {print "  " $2}' /tmp/modnames.txt
done

O controle negativo mais forte disponível é o próprio SDK da Apple, que precisa satisfazer a regra para o toolchain sequer funcionar. Apontado para o SDK do iPhoneOS 26.5, o comando encontra 1.099 declarações de topo em usr/include e 205 nos module maps de frameworks, com zero duplicatas nos dois casos.⁷ Apontado para fixtures montadas para colidir, ele nomeia a duplicata e os dois arquivos.⁸

As exclusões pesam. -not -path '*/build/*' não exclui .build/, porque o padrão precisa do nome literal do diretório, e o SwiftPM escreve module maps gerados dentro de .build às dúzias. Deixar o .build no caminho produziu as minhas únicas “duplicatas” nos sete projetos: GrappleCore em seis arquivos e GrappleRender em três, tudo saída do SwiftPM, cobrindo dois targets Swift em build roots diferentes.⁹ Os nove nem sequer são idênticos byte a byte, e o motivo é instrutivo: cada um declara o mesmo nome de módulo apontando para um caminho absoluto até o header gerado do seu próprio build root, então diferem em uma string e em nada que importe. Uma auditoria que chama isso de colisão esgota a própria credibilidade antes de chegar a qualquer coisa real.

O Xcode fabrica o mesmo falso positivo com menos ambiguidade. Dentro de uma única árvore de DerivedData, ele escreve o module map gerado de cada pacote Swift duas vezes, em GeneratedModuleMaps-iphonesimulator/ e nos intermediários do próprio target, com caminho de header relativo nas duas. Na árvore de um dos projetos, 15 nomes aparecem duas vezes cada, e os 15 pares são idênticos byte a byte.⁹ Limite a auditoria ao código-fonte, não à saída de build.

O que sete projetos contêm

Rodei as duas auditorias em sete projetos Xcode no Xcode 26.6. O resultado honesto é um zero limpo.⁹

O OTHER_LDFLAGS está sem valor nos sete projetos, não existe nenhum arquivo .xcconfig em lugar algum da frota, e não há CocoaPods, nem Carthage, nem .framework ou .xcframework embarcado.⁹ A auditoria de nomes de módulo examinou 391 module maps, 204 dentro dos diretórios de projeto e 187 no DerivedData compartilhado onde caem os builds da GUI do Xcode, e todos são saída de build.⁹ Nenhum repositório guarda um module map escrito à mão.

Os dois zeros têm a mesma causa, e é essa a conclusão que vale levar: a população exposta é a dos projetos de linguagem mista, e estes não são. Em 463 arquivos Swift, a frota tem zero fonte Objective-C, zero C++ e zero C, com dois shaders Metal no Water como único código compilado que não é Swift.⁹ Um resultado nulo vindo de uma base de código que nunca esteve em risco é evidência fraca sobre os perigos e evidência forte sobre quem precisa auditar.

Dois detalhes importam mais que os zeros. Os únicos module maps escritos à mão nos pacotes resolvidos pertencem ao swift-crypto, que fornece quatro shims em C chamados CCryptoBoringSSL, CCryptoBoringSSLShims, CXKCP e CXKCPShims, todos distintos.⁹ E nenhum nome declarado pela frota aparece em lugar algum do namespace de módulos Clang do SDK, conferido contra todos os 1.318 nomes de topo que o comando encontra no SDK do iPhoneOS 26.5.⁹ Até os genéricos que chegam pelo Supabase passam longe: o SDK declara módulos Clang chamados Foundation, UIKit e SQLite3, e nenhum chamado Crypto, Storage ou Auth.

O piso de deployment do C++ se movendo por baixo

Uma mudança vizinha atinge exatamente os projetos C++ que guardam -ld_classic. A Apple elevou um piso, citando o macOS e nenhuma outra plataforma: “O deployment target mínimo suportado no macOS para a biblioteca padrão do C++ subiu para 11.0.”⁵

A mesma entrada oferece uma saída de emergência e marca a remoção dela na frase seguinte. A libc++ mudou o resultado de lower_bound e upper_bound em std::map e std::set para comparadores que não são uma ordem fraca estrita, e definir _LIBCPP_ENABLE_LEGACY_TREE_LOWER_UPPER_BOUND “vai reverter para a implementação histórica dessas operações.” Em seguida: “Essa saída de emergência será removida em uma versão próxima (provavelmente na próxima).”⁵ Uma mudança relacionada faz multimap::find e multiset::find deixarem de necessariamente retornar o primeiro elemento igual, comportamento que a Apple observa “nunca ter sido garantido pelo Padrão”, ainda que a libc++ sempre o oferecesse, e vem sem opção de desativar.⁵ Trate a macro como um ticket de migração, não como correção.

FAQ

Por que meu projeto tem -ld_classic?

Quase certamente porque as release notes do Xcode 15 mandaram. Dois Known Issues de lá recomendavam adicionar -Wl,-ld_classic a OTHER_LDFLAGS: um em que binários usando símbolos definidos como fracos travavam em tempo de execução no iOS 14 e no macOS 12 ou anteriores, o que a Apple registrou como algo que “afeta principalmente projetos C++”, e outro em que arquivos-objeto de LTO linkavam importações de símbolos fracos como não fracas.³ A Apple marcou a opção como obsoleta no Xcode 16 e removeu o linker por trás dela no Xcode 27.¹⁴ Se a flag estiver lá, confirme que o bug original ainda se reproduz antes de sair caçando substituto.

Como encontro nomes de módulo Clang duplicados no meu projeto?

Enumere as declarações de módulo de topo em todos os module maps, procure um nome que apareça em dois arquivos e tire os diretórios de build do resultado. Três coisas fazem disso mais que um grep: extern module Foo "path" é uma referência, não uma definição; module Foo.Bar estende um módulo declarado em outro lugar em vez de declarar Foo; e submódulos explicit module aninhados não colidem com nomes de topo.⁶ Exclua .build, build e DerivedData explicitamente, já que -not -path '*/build/*' deixa o .build passar e tanto o SwiftPM quanto o Xcode duplicam module maps gerados o tempo todo.⁹

Como é o erro no Xcode 27?

Não tenho como dizer, e ninguém que compila no Xcode 26 tem. Minha máquina roda o Xcode 26.6 (build 17F113), então não reporto nenhuma saída do Xcode 27.⁷⁸ O que o Xcode 26.6 emite para dois module maps declarando o mesmo nome é error: redefinition of module 'Widget' com uma note: previously defined here, em toda execução de uma checagem de tipos simples.⁸ A formulação da Apple para o Xcode 27 é que a varredura “pode reportar um erro”, então procure redefinition of module nos logs, e não uma string que alguém chutou.

Uma falha de nome de módulo único depende do meu deployment target?

Não. A Apple formula a exigência em torno de uma única ação de varredura de dependências do Swift e não cita versão de sistema, SDK nem deployment target na entrada.² A mudança do linker se lê do mesmo jeito, como remoção do toolchain.¹ As duas caem no primeiro build no Xcode 27, ao lado da macro @State, e não junto das exigências disparadas pelo SDK no mesmo ciclo.

Principais conclusões

Para desenvolvedores iOS: - Consulte OTHER_LDFLAGS via xcodebuild -showBuildSettings -configuration Release -sdk iphoneos em vez de fazer grep por -ld_classic. Ausência nas configurações resolvidas significa que a configuração está sem valor; ausência em busca textual não significa nada.⁹ - Procure redefinition of module nos logs de build — o diagnóstico que o Xcode 26.6 já emite — e não um texto de erro do Xcode 27 inventado.⁸

Para times com dependências C ou C++ embarcadas: - Audite primeiro os arquivos module.modulemap embarcados contra o namespace do SDK: é o caso que a Apple cita, e hoje ele falha em silêncio. Meu shim SQLite3 embarcado compilou com exit 0 e fez sqlite3_open sumir.⁸ - Limite a auditoria ao código-fonte e exclua .build, build e DerivedData. Toda duplicata aparente entre 391 module maps era saída de build gerada para um único target Swift.⁹

Para quem gerencia releases: - Trate as duas mudanças como disparadas pelo toolchain e programe-as para o primeiro build no Xcode 27, não para a migração de SDK. Nenhuma delas menciona deployment target nem tem componente em tempo de execução.¹² - Mantenha as ressalvas da Apple no ticket. A varredura “pode reportar um erro”, e 20 execuções de uma mesma colisão deram três desfechos diferentes, então um build que passa uma vez não prova nada.²⁸

O ciclo 27 continua falhando em lugares diferentes: a chave da launch screen barra um envio, a obrigatoriedade do ciclo de vida de cenas barra a inicialização e a macro @State barra o build no nível do código-fonte. A remoção do linker e a regra de nome de módulo barram uma camada abaixo, nas partes do toolchain que ninguém configura de propósito. O hub completo é a Série Ecossistema Apple.

Referências