Xcode 27 abandona o Intel: o que acaba e o que continua sendo distribuído

A Apple registrou em New Features, e não em Deprecations, a mudança relativa ao Intel com maior chance de alterar um binário que você já distribui. As release notes do Xcode 27 trazem uma seção chamada Intel Deprecation com exatamente duas entradas, e justamente aquela que impede um app macOS de ser compilado como Universal por padrão está do lado de New Features.¹²

TL;DR

• Por trás da manchete existem três mudanças distintas, e as próprias frases da Apple as mantêm separadas. O Xcode 27 só instala e roda em Macs com Apple silicon.² O SDK do macOS 27 continua permitindo back deploy de apps Universal para o macOS 12 e versões posteriores.² E o ARCHS_STANDARD deixa de incluir x86_64 assim que o deployment target de macOS ou DriverKit de um target chega a 27.0.¹
• Só a terceira muda o que você distribui, e muda sem emitir nenhum diagnóstico. A Apple descreve a solução na mesma entrada: “a arquitetura x86_64 pode ser adicionada à configuração de build ARCHS caso isso seja necessário.”¹
• O Xcode 26.6 não permite antecipar o novo comportamento. Forcei MACOSX_DEPLOYMENT_TARGET=27.0 em um projeto exclusivo de macOS e o ARCHS_STANDARD continuou resolvendo para arm64 x86_64.¹³
• Dois hábitos de auditoria fabricam respostas erradas. Passar -sdk macosx fez um projeto exclusivo de iOS informar SUPPORTED_PLATFORMS = macosx e ARCHS_STANDARD = arm64 x86_64, e resolver as configurações no nível do projeto escondeu dois targets de macOS dentro de um projeto cujo target padrão é iOS.¹⁴
• Em 11 dos meus projetos Xcode, com 44 targets no total: 21 compilam para macOS, o maior deployment target de macOS entre eles é 26.5 e nenhum define ARCHS ou EXCLUDED_ARCHS.¹⁴ Os 51 archives de macOS no disco são todos x86_64 arm64.¹⁴
• O fim do software Intel acontece no macOS 28, não no Xcode 27, e a frase da Apple traz uma ressalva que vale ler: “todo software baseado em Intel deixará de ser compatível com o macOS 28.0, com exceção de jogos legados.”¹⁰

A Apple publica tudo isso como texto de beta, nas release notes do Xcode 27 beta 4 e do macOS 27 beta 4.³⁶

Três frases, três mudanças diferentes

A seção Intel Deprecation da Apple tem duas entradas. Lê-las como uma afirmação única leva à decisão errada nas duas direções.

A entrada de deprecação trata da máquina que está na sua mesa, e não faz nenhuma ressalva: “o Xcode 27 só será instalado e executado em Macs com Apple silicon.”² Nenhuma configuração de build muda isso. Um Mac Intel deixa de ser uma máquina capaz de rodar o Xcode atual, e a tabela de compatibilidade da Apple soma um piso de software ao piso de hardware, listando macOS Tahoe 26.4 ou posterior como requisito para o Xcode 27 beta 4.⁴

A mesma entrada protege, em seguida, o resultado da compilação: “o SDK do macOS 27 suporta back deploy de apps Universal (Intel e Apple Silicon) para o macOS 12 e versões posteriores.”² A tabela de compatibilidade da Apple concorda, mostrando um intervalo de deployment de macOS 12 a 27 para o Xcode 27 beta 4, contra 11 a 26.5 para o Xcode 26.6.⁴ O piso subiu exatamente uma versão. Os binários Universal sobrevivem.

E a entrada se encerra preservando o próprio fluxo de trabalho: “o desenvolvimento para Intel continua possível em versões do macOS que suportam Rosetta, como o macOS 27.”²

Vem então a entrada em New Features, que é a única capaz de mudar um produto que você já distribui:

Targets de build com deployment target mínimo definido como macOS 27.0 ou DriverKit 27.0 não serão compilados como Universal por padrão. A configuração de build ARCHS_STANDARD deixará de incluir x86_64 quando MACOSX_DEPLOYMENT_TARGET ou DRIVERKIT_DEPLOYMENT_TARGET >= 27.0. A arquitetura x86_64 pode ser adicionada à configuração de build ARCHS caso isso seja necessário.¹

Quatro detalhes aí merecem ser separados. A Apple cita duas configurações e nenhuma outra, então IPHONEOS_DEPLOYMENT_TARGET e seus irmãos ficam fora da regra. A Apple cita um limiar, e não uma versão de toolchain, então o gatilho é o seu próprio deployment target cruzar 27.0. A Apple diz “não serão compilados como Universal por padrão”, o que descreve um padrão, não uma proibição. E a Apple oferece a saída na mesma frase, apontando ARCHS como o lugar onde recolocar o x86_64.

O padrão que muda sem gerar erro

O mecanismo é banal, e é exatamente isso que o torna silencioso. A referência de configurações de build da Apple descreve ARCHS como “uma lista das arquiteturas para as quais o produto será compilado. Normalmente isso é definido por uma configuração de build predefinida fornecida pela plataforma. Se mais de uma arquitetura for especificada, um binário universal será produzido.”⁵ A configuração predefinida é o ARCHS_STANDARD, e a Apple confirma a dependência em outro ponto da mesma referência, ao observar que a autenticação de ponteiros “não tem efeito se ARCHS tiver sido sobrescrito de modo a não se basear em ARCHS_STANDARD.”⁵

Ou seja: um target que nunca menciona ARCHS herda o que a plataforma entregar. Mude o que a plataforma entrega e o produto muda de forma sem que nenhum arquivo sob controle de versão seja editado.

Nada nessa mudança produz falha. O compilador roda, o linker roda e o archive passa na validação. Nada na toolchain trata um build de macOS com uma única slice arm64 como erro, porque não é erro. O resultado é um app macOS correto e assinado, carregando uma slice de arquitetura onde antes carregava duas. Em um Mac com Apple silicon — a máquina que todo desenvolvedor de Xcode 27 agora usa por obrigação — o build só arm64 abre e se comporta de forma idêntica. A regressão só aparece em hardware que ninguém mais tem à mão.

Chamar esse modo de falha de silencioso é caracterização minha, não da Apple; a Apple descreve o padrão e para por aí. O que a Apple de fato diz é que a correção é aditiva, e a formulação importa para o planejamento: o x86_64 “pode ser adicionado à configuração de build ARCHS caso isso seja necessário.”¹ A Apple deixa para você o julgamento sobre a necessidade.

O que o Xcode 26.6 conta e o que ele não conta

Minha máquina roda o Xcode 26.6 (build 17F113) no macOS 26.5.2, então nenhum comportamento do Xcode 27 aparece em lugar algum deste artigo.¹³ A pergunta útil que uma toolchain anterior consegue responder é se ela já se comporta do jeito novo. Não se comporta.

Apontar o xcodebuild para um projeto exclusivo de macOS e sobrescrever o deployment target acima do limiar que a Apple indica deixa a lista de arquiteturas intacta:¹³

xcodebuild -showBuildSettings -project Cels.xcodeproj \
  -configuration Release -sdk macosx \
  MACOSX_DEPLOYMENT_TARGET=27.0 2>/dev/null \
  | grep -E "^ +(ARCHS|ARCHS_STANDARD|MACOSX_DEPLOYMENT_TARGET) ="

    MACOSX_DEPLOYMENT_TARGET = 27.0
    ARCHS = arm64 x86_64
    ARCHS_STANDARD = arm64 x86_64
    MACOSX_DEPLOYMENT_TARGET = 27.0

A primeira linha é o xcodebuild devolvendo o override; o resto vem resolvido. O mesmo comando com 26.0 retorna linhas de arquitetura idênticas.¹³ O Xcode 26.6 não implementa o limiar, então ninguém consegue ensaiar a mudança na toolchain atual; qualquer comparação antes e depois depende do Xcode 27 em um Mac com Apple silicon.

O escopo por plataforma, esse sim, se reproduz hoje. O mesmo projeto resolvido contra o SDK do iOS retorna ARCHS_STANDARD = arm64, sem nenhum x86_64 a perder, enquanto o SDK do macOS retorna arm64 x86_64.¹³ A entrada da Apple cita apenas os deployment targets de macOS e DriverKit, e o lado iOS de um projeto multiplataforma não tem nada em jogo.

Auditando sua própria exposição sem inventá-la

Dois hábitos produzem respostas erradas com ares de certeza. Caí nos dois.

O primeiro é passar -sdk macosx para descobrir se um projeto compila para macOS. A flag sobrescreve o próprio SDK do projeto, então o Xcode responde a uma pergunta sobre a flag, e não sobre o projeto. Sem override, um projeto meu de browser exclusivo de iOS informa sua plataforma real; com -sdk macosx, o mesmo projeto informa SUPPORTED_PLATFORMS = macosx e ARCHS_STANDARD = arm64 x86_64, o que é puro artefato.¹⁴ Comece sem nenhum -sdk:

xcodebuild -showBuildSettings -project YourApp.xcodeproj \
  -configuration Release 2>/dev/null \
  | grep -E "^ +(SUPPORTED_PLATFORMS|SDKROOT) ="

No meu único app exclusivo de macOS, voltam duas linhas:¹⁴

    SDKROOT = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.5.sdk
    SUPPORTED_PLATFORMS = macosx

Leia as duas linhas, nunca uma só. Esse projeto declara SDKROOT = macosx e nenhuma linha SUPPORTED_PLATFORMS, então uma busca textual por SUPPORTED_PLATFORMS nos arquivos de projeto dá zero e pula o único app exclusivo de macOS que eu tenho.¹⁴ As configurações resolvidas preenchem essa lacuna a partir do SDK; o grep não consegue. Ignore MACOSX_DEPLOYMENT_TARGET nesta etapa, porque o Xcode fornece um de qualquer jeito: três dos meus projetos exclusivos de iOS ainda informam um deployment target de macOS, dois em 26.5 e um em 26.2.¹⁴

O segundo hábito é resolver as configurações no nível do projeto. O xcodebuild -showBuildSettings sem -target responde por um único target, e um projeto misto enterra os demais. Meu projeto de extensão do Safari resolveu para SUPPORTED_PLATFORMS = iphoneos iphonesimulator e ARCHS_STANDARD = arm64, o que se lê como um projeto exclusivo de iOS, sem exposição ao Intel. Enumerar seus targets revelou quatro, dois deles de macOS, ambos resolvendo arm64 x86_64:¹⁴

xcodebuild -list -project YourApp.xcodeproj
for t in TargetA TargetB; do
  xcodebuild -showBuildSettings -project YourApp.xcodeproj \
    -target "$t" -configuration Release 2>/dev/null \
    | grep -E "^ +(SUPPORTED_PLATFORMS|MACOSX_DEPLOYMENT_TARGET|ARCHS_STANDARD) ="
done

Uma peculiaridade a esperar: um target com SDKROOT = auto não resolve nenhum ARCHS_STANDARD enquanto você não indicar um SDK, então 15 dos meus 21 targets de macOS não imprimem nada nessa linha até o comando incluir -sdk macosx, e aí seus projetos resolvem arm64 x86_64.¹⁴ Em branco significa não resolvido, não vazio.

Depois, pare de confiar em configurações e leia um binário. As configurações de build descrevem intenção; o lipo descreve o artefato que você realmente distribuiu:

lipo -archs YourApp.xcarchive/Products/Applications/YourApp.app/Contents/MacOS/YourApp

x86_64 arm64

Prefira o lipo aos metadados do próprio archive. Dois dos meus archives não trazem lista alguma de arquiteturas em ApplicationProperties no Info.plist, então uma consulta com plutil ao archive não retorna nada, enquanto o lipo no binário lá dentro retorna x86_64 arm64.¹⁴ Ausência nos metadados significa que o archive foi gravado de outro jeito, não que o app perdeu uma slice.

O que 11 projetos realmente contêm

Rodei a auditoria em 11 projetos Xcode, com 44 targets no total. Oito projetos contêm ao menos um target de macOS, 21 targets compilam para macOS e a exposição ao novo padrão é zero hoje.¹⁴

O maior deployment target de macOS na frota é 26.5; o menor, 13.0, em uma extensão do Safari que ninguém revisita há um bom tempo. Nenhum target chega a 27.0, então nenhum entra no regime do padrão alterado enquanto alguém não subir um número na mão. Zero targets definem ARCHS, zero definem EXCLUDED_ARCHS e a frota não contém nenhum arquivo .xcconfig, então toda decisão de arquitetura nos 44 targets vem do ARCHS_STANDARD.¹⁴

A evidência dos archives é mais forte que a das configurações, porque archives registram o que de fato foi distribuído. Minha máquina guarda 79 archives compilados entre abril e julho de 2026. Todos os 51 archives de macOS, distribuídos por sete produtos diferentes, reportam x86_64 arm64. Todos os 28 archives da família iOS reportam arm64.¹⁴ Ninguém, em nenhum desses projetos, escolheu Universal; o padrão produziu isso, todas as vezes. É essa a população sobre a qual a mudança da Apple age — e exatamente por isso ninguém vai perceber.

Uma lacuna honesta: subir um deployment target para 27.0 é um ato deliberado, e nenhum dos meus projetos tem motivo para isso ainda. O resultado limpo da frota mede um momento, não uma política.

Onde o software Intel realmente acaba

A mudança no Xcode diz respeito a arquiteturas dentro de um build. O fim do software Intel como categoria está no macOS 28, e a Apple registrou isso tanto na documentação do Rosetta quanto nas release notes do macOS 27, que concordam entre si.

A documentação do Rosetta define o prazo diretamente. O Rosetta “foi projetado para facilitar a transição para o Apple silicon e estará disponível até o macOS 27” como ferramenta de uso geral para apps Intel, e “depois desse prazo, manteremos um subconjunto das funcionalidades do Rosetta voltado a dar suporte a títulos de jogos antigos e sem manutenção, que dependem de frameworks baseados em Intel.”⁷ As release notes do macOS 27 afirmam a consequência com a mesma ressalva: “todo software baseado em Intel deixará de ser compatível com o macOS 28.0, com exceção de jogos legados.”¹⁰ Um comando exclusivo de beta, em outro ponto das mesmas notas, dá forma a essa ressalva: sudo game-test-tool enable liga o suporte a jogos Intel legados, e a Apple avisa que “habilitar o suporte a jogos legados desabilita o Rosetta.”¹⁵

O macOS 27 usa esse intervalo para nomear o que não vai sobreviver. A seção Deprecation Information da Apple informa que “aplicativos baseados em Intel que deixarão de rodar no macOS 28.0 agora exibem um aviso em Obter Informações”, e uma entrada separada acrescenta que “Ajustes > Geral agora lista os apps baseados em Intel que serão incompatíveis com o macOS 28.0”, incluindo “software baseado em Intel sem uso encontrado no sistema.”⁸⁹

Três entradas mais discretas importam mais para quem distribui um produto para Mac.

O próprio Rosetta deixa de ser persistente: “se o Rosetta estava instalado anteriormente, ele não é restaurado automaticamente após a atualização para o macOS 27.0.”¹¹ A documentação da Apple dá o contexto, observando que o macOS 27 “integra diretamente o suporte à tradução de binários Intel, sem necessidade de instalar o Rosetta”, o que viabiliza binários Linux Intel rodando em máquinas virtuais ARM e contêineres Linux Intel.⁷ Os apps que o usuário havia fixado também mudam: aplicativos antes configurados como “Abrir usando Rosetta” agora “são iniciados nativamente”, e a Apple recomenda que “qualquer problema de compatibilidade que exigia o Rosetta no passado seja reavaliado no macOS 27.”¹²

Os instaladores mudam de padrão: “pacotes de instalação que não especificam hostArchitecture passarão a assumir arm64 por padrão”, e a Apple pede que você “garanta que quaisquer scripts de pré e pós-instalação se comportem como esperado sob arm64.”¹¹ Todo produto para Mac distribuído fora da App Store herda essa mudança, sendo o app Universal ou não.

Quem hospeda plugins enfrenta o caso mais delicado. A Apple avisa que “plugins e loaders baseados em Intel podem não aparecer nos Ajustes nem gerar notificações de incompatibilidade” e nomeia os diretórios a conferir na mão, entre eles ~/Library/Audio/Plug-Ins/, ~/Library/Printers/ e ~/Library/ColorPickers/.¹⁰ O motivo pelo qual um plugin consegue travar um app que de resto é nativo aparece na documentação do Rosetta: “o sistema impede que você misture código arm64 e código x86_64 no mesmo processo. A tradução do Rosetta se aplica a um processo inteiro, incluindo todos os módulos de código que o processo carrega dinamicamente.”⁷ Um plugin Intel, portanto, obriga seu host a rodar traduzido, transformando um único componente sem manutenção numa dependência do app inteiro em relação a um recurso que a Apple já programou para encolher.

O Universal existe para alcançar Macs Intel rodando do macOS 12 ao 27, o intervalo que a tabela de compatibilidade da Apple publica para o Xcode 27.⁴ A Apple datou o fim do software Intel no macOS 28 e deixou o intervalo de deployment intacto, então a pergunta real de um time de macOS é quantos dos seus usuários ainda rodam um Mac que precisa dessa slice.

Duas coisas que verifiquei e não encontrei: nem as release notes do Xcode 27 nem as do macOS 27 dizem qualquer coisa sobre mudança nos requisitos de Universal Purchase da Mac App Store, e nenhuma delas fixa uma data de calendário para o macOS 28.³⁶ Trate qualquer data que você ler como inferência.

Perguntas frequentes

O Xcode 27 me impede de distribuir apps Intel?

Não, e a Apple diz o contrário na mesma entrada que deprecia os Macs Intel como máquinas de desenvolvimento: “o SDK do macOS 27 suporta back deploy de apps Universal (Intel e Apple Silicon) para o macOS 12 e versões posteriores.”² A tabela de compatibilidade da Apple confirma o intervalo, listando macOS 12 a 27 como deployment targets do Xcode 27 beta 4.⁴ O que muda é o padrão. Um target cujo deployment target de macOS chega a 27.0 para de receber x86_64 do ARCHS_STANDARD, e a correção indicada pela Apple é você mesmo adicionar x86_64 ao ARCHS.¹ Distribuir para Intel passa a ser uma escolha que você declara, não uma que você herda.

Meu build vai falhar se o ARCHS_STANDARD remover o x86_64?

Nada na entrada da Apple descreve erro, aviso ou diagnóstico de qualquer tipo. A Apple descreve a mudança de um padrão: targets em macOS ou DriverKit 27.0 ou acima “não serão compilados como Universal por padrão.”¹ Um build que compila, linka e assina com uma slice de arquitetura em vez de duas é um build válido, e no Mac com Apple silicon que o Xcode 27 obriga você a usar, a diferença é invisível em tempo de execução.² A Apple enuncia o padrão e não registra a consequência, então a palavra silencioso é minha, não dela. Verifique com lipo -archs no binário arquivado, em vez de esperar que um log de build levante o assunto.

Dá para testar o novo comportamento no Xcode 26?

Não. Rodei a verificação direto no Xcode 26.6 (build 17F113): sobrescrever MACOSX_DEPLOYMENT_TARGET para 27.0 em um projeto exclusivo de macOS continua resolvendo ARCHS_STANDARD = arm64 x86_64, idêntico ao mesmo comando com 26.0.¹³ A toolchain anterior não implementa o limiar, então nenhuma dose de experimentação com configurações de build no Xcode 26 antecipa a mudança. O que o Xcode 26.6 reproduz, sim, é o escopo: o mesmo projeto resolve ARCHS_STANDARD = arm64 contra o SDK do iOS e arm64 x86_64 contra o SDK do macOS, o que bate com uma entrada que cita os deployment targets de macOS e DriverKit e nada mais.¹¹³

Preciso de um Mac com Apple silicon agora?

Para rodar o Xcode 27, sim, sem ressalvas: “o Xcode 27 só será instalado e executado em Macs com Apple silicon.”² A Apple soma um piso de software ao de hardware, exigindo macOS Tahoe 26.4 ou posterior para o Xcode 27 beta 4.⁴ O desenvolvimento para Intel sobrevive em toolchains mais antigas, que é como a Apple coloca a questão: “o desenvolvimento para Intel continua possível em versões do macOS que suportam Rosetta, como o macOS 27.”² A documentação do Rosetta impõe um limite a esse caminho, afirmando que o Rosetta “estará disponível até o macOS 27” como ferramenta de uso geral, com um subconjunto reduzido depois disso, voltado a jogos antigos e sem manutenção.⁷

Principais conclusões

Para quem desenvolve apps de macOS: - Audite primeiro sem a flag -sdk, leia SUPPORTED_PLATFORMS e SDKROOT juntos e ignore MACOSX_DEPLOYMENT_TARGET quando a pergunta for se o target compila para macOS. O Xcode grava um deployment target de macOS em projetos exclusivos de iOS: três dos meus informam um (26.5, 26.5 e 26.2) sem compilar para Mac nenhum.¹⁴ - Enumere os targets com xcodebuild -list antes de resolver as configurações. Uma consulta em nível de projeto na minha extensão do Safari reportou um projeto exclusivo de iOS e escondeu dois targets de macOS.¹⁴

Para times cujos usuários incluem Macs Intel: - Decida sobre o x86_64 explicitamente, em vez de herdá-lo. Defina ARCHS quando subir um deployment target de macOS para 27.0, porque a entrada da Apple oferece exatamente essa solução e nenhum aviso caso você a ignore.¹ - Verifique com lipo -archs no binário arquivado, não nas configurações de build nem no Info.plist do archive. Dois dos meus archives não carregam metadado algum de arquitetura, embora seus binários sejam Universal.¹⁴

Para quem gerencia releases: - Separe o prazo de hardware do prazo de distribuição. O Xcode 27 exige um Mac com Apple silicon desde o primeiro dia; a saída Universal continua alcançando o macOS 12 e versões posteriores, e a Apple não publicou nenhuma data de calendário para o macOS 28.²⁴ - Inventarie plugins e pacotes de instalação Intel, não só apps. A Apple avisa que plugins Intel “podem não aparecer nos Ajustes”, e um plugin Intel obriga todo o processo hospedeiro a rodar traduzido.⁷¹⁰

O ciclo 27 insiste em esconder mudanças consequentes em lugares banais. A remoção do linker e a regra de nome de módulo quebram builds de cara na atualização da toolchain, a macro @State os quebra no nível do código-fonte e a chave da launch screen bloqueia um envio. O padrão do Intel não quebra nada e mesmo assim muda o produto, o que faz dele algo a auditar antes de atualizar, e não depois. A série completa está reunida na Série Ecossistema Apple.

Referências