Resposta curta: o macOS 27 será executado apenas em Macs com Apple silicon, e o Xcode 27 também passa a exigir um Mac com Apple silicon para instalar e rodar. Para um target cujo deployment target mínimo seja macOS 27.0, o Xcode 27 deixa de incluir x86_64 em ARCHS_STANDARD por padrão. Isso não significa, porém, que todo desenvolvedor deva apagar imediatamente a fatia Intel: se o app ainda precisa atender Macs Intel no macOS 26 ou anterior, o binário universal continua sendo a escolha coerente.
A mudança mais importante é separar três decisões que costumam ser misturadas: em quais Macs o sistema operacional roda, quais arquiteturas o seu executável contém e qual é o deployment target mínimo do app. A Apple abriu em 9 de setembro de 2026 as submissões com os SDKs mais recentes e orientou desenvolvedores a otimizar seus apps para o macOS 27. A regra prática é simples: macOS 27 como mínimo aponta para arm64; suporte a Macs Intel no macOS 26 ou anterior aponta para binário universal. Veja o aviso de submissões da Apple.
O que muda de verdade no macOS 27
O primeiro corte é de hardware. A Apple informa que o macOS 26 é a última grande versão compatível com Macs Intel e que o macOS 27 será apenas para Apple silicon. Em paralelo, as notas do Xcode 27 dizem que a própria ferramenta só instala e executa em Macs com Apple silicon.
O segundo corte está no build. No Xcode 27, quando MACOSX_DEPLOYMENT_TARGET é 27.0 ou superior, ARCHS_STANDARD deixa de incluir x86_64 por padrão. É uma mudança de default, não uma proibição absoluta de compilar código Intel: as notas permitem adicionar x86_64 manualmente a ARCHS quando houver necessidade. Na prática, entretanto, uma fatia x86_64 não cria compatibilidade de hardware com macOS 27, porque não haverá Mac Intel rodando essa versão do sistema.
O terceiro corte é de ferramenta. Usar o SDK do macOS 27 não obriga você a definir macOS 27 como deployment target. Um projeto pode ser compilado com o Xcode 27 e o SDK mais novo, mas continuar declarando uma versão mínima anterior para manter compatibilidade com máquinas e sistemas antigos. Essa distinção entre Base SDK e deployment target é decisiva para escolher entre universal e arm64-only.
Rosetta: por que a redação oficial exige cautela
As páginas oficiais publicadas pela Apple em setembro de 2026 não usam formulações perfeitamente alinhadas. O aviso de 1º de setembro afirma que o macOS 27 é a última versão de uso geral a oferecer Rosetta e que a transição está sendo encerrada; a documentação técnica também diz que Rosetta permanece disponível durante o macOS 27. Já o comunicado de 9 de setembro descreve o macOS 26 como a última versão com suporte a Macs Intel e Rosetta, ao mesmo tempo em que reforça que o macOS 27 será Apple silicon only.
Para planejamento de produto, a conclusão segura não depende de resolver essa diferença de redação: não trate Rosetta como estratégia de compatibilidade para um app Intel-only no ciclo do macOS 27. A orientação da Apple é adicionar suporte nativo a Apple silicon agora. Em macOS 26.4 ou posterior, usuários de apps que dependem de Rosetta podem receber alertas do sistema recomendando uma versão nativa. Leia o aviso sobre a transição do Rosetta e a documentação do ambiente de tradução.
A Apple também informa que, depois do período de transição de uso geral, manterá um subconjunto de funcionalidades do Rosetta voltado a jogos antigos e não mantidos que dependem de frameworks Intel. Isso é uma exceção específica e não deve ser interpretado como garantia de execução para aplicativos Intel genéricos.
Checklist por cenário: Intel-only, universal ou já nativo
| Cenário atual | O que fazer agora | Resultado recomendado |
|---|---|---|
| App Intel-only (x86_64) | Auditar bibliotecas, frameworks, plug-ins, helpers e ferramentas; adicionar arm64; testar em Apple silicon; revisar qualquer dependência de Rosetta. | Universal se ainda houver suporte a Macs Intel no macOS 26 ou anterior; arm64-only se o novo mínimo for macOS 27. |
| Binário universal (arm64 + x86_64) | Confirmar que todas as dependências continuam universais e que a fatia arm64 roda nativamente sem Rosetta. | Manter universal enquanto o produto ainda atender Intel; remover x86_64 quando essa compatibilidade deixar de fazer parte da política de suporte. |
| App já nativo arm64 | Verificar componentes incorporados e pipeline de CI; atualizar deployment target apenas quando fizer sentido para a base de usuários. | Continuar arm64. Se o mínimo passar a macOS 27, o default do Xcode 27 já converge para essa arquitetura. |
Quando manter o binário universal
O binário universal continua útil se você ainda distribui o mesmo app para usuários de Macs Intel no macOS 26 ou anterior. Um executável universal contém as fatias arm64 e x86_64, e o sistema escolhe a apropriada para a máquina. Em Apple silicon, a fatia arm64 roda nativamente; em um Mac Intel compatível, roda a fatia x86_64. A Apple mantém documentação específica sobre como criar e verificar binários universais.
Também faz sentido manter universal durante uma janela de transição empresarial, quando clientes têm ciclos de atualização mais lentos ou quando o suporte oficial do seu produto ainda inclui hardware Intel. O ponto central é não confundir “compilar com o SDK 27” com “exigir macOS 27”. Você pode adotar o Xcode 27, aproveitar correções e SDKs atuais e ainda escolher um deployment target anterior.
Quando limitar o build a arm64
Se o seu app passa a exigir macOS 27, não há benefício prático em carregar uma fatia x86_64 para alcançar Macs Intel, porque esses Macs não executarão o sistema. O aviso de 9 de setembro orienta explicitamente que, para limitar o app a Macs com Apple silicon, o desenvolvedor defina a arquitetura de build como arm64, reconstrua e reenvie o app.
Arm64-only também pode ser uma decisão de produto antes de elevar o deployment target, desde que você esteja disposto a encerrar o suporte a Macs Intel. Essa escolha reduz combinações de teste e pode simplificar dependências, mas deve ser tratada como mudança de compatibilidade: usuários em Intel precisam saber qual é a última versão que continuará funcionando.
O que revisar no Xcode 27
- Architectures (ARCHS): prefira os padrões do Xcode salvo quando houver motivo claro para personalizar. Para deployment target 27.0 ou superior, o padrão já deixa x86_64 de fora.
- Build Active Architecture Only: builds de Debug normalmente focam a arquitetura da máquina ativa, enquanto Release deve produzir o conjunto de arquiteturas definido para distribuição.
- Excluded Architectures: remova workarounds antigos usados apenas para contornar dependências que não suportavam Apple silicon. Eles podem esconder um problema em vez de resolvê-lo.
- CI e máquinas de build: como o Xcode 27 só roda em Apple silicon, runners Intel precisam ser migrados se a pipeline depender dessa versão do Xcode.
- Deployment target: aumente para 27 apenas quando você aceitar abandonar sistemas anteriores; não faça isso só porque está usando o SDK 27.
A recomendação geral da Apple é conservar os build settings de arquitetura nos valores padrão sempre que possível, pois esses defaults acompanham as arquiteturas recomendadas da plataforma. O TN3117 detalha esses ajustes.
Dependências, plug-ins e helpers são o ponto em que a migração costuma quebrar
Adicionar arm64 apenas ao executável principal não basta. Código carregado no mesmo processo precisa oferecer uma arquitetura compatível. Isso inclui frameworks próprios e de terceiros, bibliotecas estáticas e dinâmicas, plug-ins, extensões, ferramentas de linha de comando, daemons, launch agents e outros binários empacotados com o app. A documentação de portabilidade da Apple destaca que uma dependência sem a arquitetura necessária pode impedir a criação ou execução correta do build nativo. Consulte o guia de portabilidade.
Se o projeto usa código de baixo nível, revise ainda suposições específicas de processador, assembly, intrinsics, JIT, tamanhos de página de memória e outros detalhes arquiteturais. Muitos apps baseados em frameworks de alto nível precisam apenas recompilar, mas software que conversa diretamente com detalhes de hardware exige testes adicionais.
Como verificar se o artefato final tem as arquiteturas certas
Depois do Archive ou do build de distribuição, verifique o executável real dentro do bundle, e não apenas as configurações do projeto. A Apple recomenda usar ferramentas como lipo ou file. Com lipo -archs, um binário universal deve listar arm64 e x86_64; um build restrito a Apple silicon deve listar apenas arm64.
Faça a mesma verificação nos componentes críticos incorporados. Um app pode parecer universal no executável principal e ainda falhar ao carregar um plug-in ou framework que só tenha x86_64. Para quem mantém universal, teste tanto a execução nativa arm64 quanto a fatia x86_64 no ambiente de tradução disponível durante a transição.
Plano de distribuição para não confundir macOS 26 com 27
- Defina primeiro a sua política de suporte: a próxima versão ainda precisa atender Macs Intel?
- Se a resposta for sim, mantenha deployment target compatível com macOS 26 ou anterior e distribua universal.
- Se a resposta for não e o mínimo passar a macOS 27, deixe o build convergir para arm64-only.
- Atualize todas as dependências antes de remover Rosetta da equação de teste.
- Migre CI e máquinas de desenvolvimento que ainda dependam de Xcode em Macs Intel, porque o Xcode 27 exige Apple silicon.
- Avise usuários de versões Intel-only sobre a versão nativa e sobre a última release compatível com o ambiente antigo.
Três erros que vale evitar
Erro 1: achar que “macOS 27 é Apple silicon only” obriga todo app a ser arm64-only hoje. Se você ainda suporta macOS 26 em Macs Intel, o universal continua atendendo os dois grupos.
Erro 2: tratar universal e Intel-only como a mesma coisa. Universal já contém arm64 e roda nativamente em Apple silicon; Intel-only depende da camada de tradução durante a transição.
Erro 3: confundir SDK com deployment target. Compilar no Xcode 27 não significa exigir macOS 27. O deployment target é que determina a versão mínima do sistema que o app declara suportar.
Decisão prática para cada projeto
Se o projeto ainda tem usuários em Macs Intel, a melhor transição é universal agora e arm64-only quando o suporte a Intel terminar. Se já não há compromisso com Intel e o próximo release exige macOS 27, simplifique para arm64 e valide todas as dependências nativas. Para um app que ainda é Intel-only, a prioridade não é descobrir por quanto tempo Rosetta poderá quebrar o galho: é produzir e testar uma versão arm64 antes que a mudança do sistema transforme uma dívida técnica em incompatibilidade para o usuário.
