O Xcode 27 transforma deployment targets antigos em erros de build. Aqui está a linha.

Correção em 19 de outubro de 2026: Corrigimos a afirmação anterior, sem respaldo, de um prazo de abril de 2027 para a Mac App Store. O anúncio da Apple estabelece requisitos de SDK para iOS, iPadOS, tvOS, visionOS e watchOS, sem estabelecer um prazo equivalente para macOS.

Abra um projeto de app para Mac que compila sem problemas há anos, mude para o beta do Xcode 27, aperte build e pare:

The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.13, but the range of supported deployment target versions is 12.0 to 27.0.99.

No Xcode 26, essa frase era um aviso amarelo que dava para simplesmente rolar e ignorar. No Xcode 27, é um erro vermelho e o build não prossegue. Essa é toda a mudança, e ela é menor e maior do que parece: menor porque a documentação da Apple afirma há anos um piso de macOS 11 e iOS 15; maior porque o Xcode nunca aplicou essa regra, e uma quantidade enorme de apps em produção depende silenciosamente disso.

Este artigo detalha o que o Xcode 27 realmente exige (segundo as próprias tabelas e release notes da Apple), o que o Xcode 26 realmente permitia (segundo o SDK no nosso próprio disco), quem é afetado, a configuração não documentada que transforma o erro de volta em aviso, e a diferença entre os deployment targets do Xcode e os requisitos de SDK da App Store para cada plataforma.

Principais Conclusões

• Os deployment targets suportados pelo Xcode 27 são macOS 12–27, iOS/iPadOS/tvOS 15–27, watchOS 9–27, visionOS 1–27, DriverKit 21–27, de acordo com a página de suporte do Xcode da Apple para a beta 6. Abaixo disso, o build falha.
• O Xcode 26 documentava o macOS 11 como piso, mas na prática aceitava o 10.13. Verificamos o arquivo de configurações do SDK do macOS 26.0: 34 deployment targets válidos, começando em 10.13. O Xcode 27 fecha essa lacuna transformando o intervalo documentado no intervalo efetivamente aplicado.
• O piso do macOS mudou durante o período de beta. Em junho, a nota da Apple dizia que o back-deployment Universal ia "up to and including macOS 27"; os desenvolvedores interpretaram isso como Big Sur. A nota da beta 6 diz "macOS 12 and later." Planeje para o Monterey, não para o Big Sur.
• Existe uma válvula de escape não documentada, __DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO, que segundo relatos transforma o erro de volta em aviso. Ela não é suportada oficialmente, pode desaparecer a qualquer momento e não muda o fato de que a Apple não está testando esses targets.
• Os requisitos de SDK da App Store variam por plataforma. A Apple anunciou que, a partir de abril de 2027, as submissões para as plataformas citadas deverão usar os SDKs do iOS 27, iPadOS 27, tvOS 27, visionOS 27 e watchOS 27 ou posteriores, conforme a plataforma. Esse anúncio não estabelece um SDK mínimo do macOS nem um prazo para encerrar o suporte ao macOS 11 na Mac App Store.

Os Números, Oficialmente

A página de suporte do Xcode da Apple publica uma tabela com o que cada versão do Xcode consegue compilar. Esta é a comparação que importa:

Plataforma	Xcode 26.6	Xcode 27 beta 6
macOS	11 – 26.5	12 – 27
iOS / iPadOS	15 – 26.5	15 – 27
tvOS	15 – 26.5	15 – 27
watchOS	8 – 26.5	9 – 27
visionOS	1 – 26.5	1 – 27
DriverKit	20 – 25.5	21 – 27

Leia com atenção, porque a manchete "o Xcode 27 eleva o mínimo" só é verdadeira pela metade. Para o iOS, o piso documentado é 15 desde o Xcode 26 e continua 15 no Xcode 27. Para o macOS, ele avança uma versão, de 11 para 12. Para o watchOS, de 8 para 9. No papel, é um aperto modesto.

O que não está no papel é que os números do Xcode 26 nunca foram, de fato, aplicados.

O Que o Xcode 26 Realmente Permitia

Todo SDK dentro do Xcode traz um arquivo de configurações que declara quais deployment targets ele considera válidos. Na nossa máquina, com o Xcode 26.0.1 (17A400) instalado, esse arquivo fica em:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json

Para lê-lo, basta um comando:

python3 -c '
import json
d = json.load(open("/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json"))
t = d["SupportedTargets"]["macosx"]
print(t["MinimumDeploymentTarget"], "->", t["MaximumDeploymentTarget"])
print(len(t["ValidDeploymentTargets"]), "valid:", t["ValidDeploymentTargets"][:6], "...")
'

Saída no Xcode 26.0.1:

10.13 -> 26.0.99
34 valid: ['10.13', '10.14', '10.15', '11.0', '11.1', '11.2'] ...

Então, enquanto a tabela da Apple dizia "macOS 11," o SDK dizia "10.13," e o Xcode deixava você digitar 10.13 no campo de deployment target, emitia um aviso e compilava mesmo assim. Michael Tsai descreve a prática sem rodeios: os desenvolvedores "have been able to enter older targets manually," e boa parte do software independente para Mac fazia exatamente isso para manter usuários de High Sierra, Mojave e Catalina na build atual.

Se você tem a beta do Xcode 27 instalada, rode o mesmo comando contra o SDK dela (substituindo por Xcode-beta.app) e verá o novo piso. Não temos a beta nesta máquina, então estamos nos baseando na tabela da Apple e nos relatos de desenvolvedores para o número 12.0, em vez de lê-lo diretamente do arquivo.

De Aviso a Erro

O diagnóstico em si não é novo. O sistema de build da Apple emite "the range of supported deployment target versions is X to Y" há anos, como aviso. A mudança do Xcode 27 é a severidade dele.

Uma matéria no bleepingswift.com cita a forma como aparece para o iOS no Xcode 27:

The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to xx.x, but the range of supported deployment targets versions is 15.0 to 27.0.x

A forma para macOS é a mesma mensagem, com MACOSX_DEPLOYMENT_TARGET e um intervalo de 12.0 a 27.0.99. Ela dispara por target, então um app com uma extensão, um widget e um bundle de testes que herdam todos um target antigo vai exibi-la quatro vezes, e corrigir apenas o app principal não limpa o build.

Os mantenedores do Vienna RSS esbarraram nisso em 10 de junho, dois dias depois do lançamento da beta: o target deles era 10.13, compilava sem avisos nem erros no Xcode 26, e no Xcode 27 "it's a hard requirement (build error)." A preocupação seguinte deles é a mesma de todo desenvolvedor Mac nessa posição: não se espera que o Xcode 26 seja suportado no macOS 27, então a saída de "manter o Xcode antigo" tem prazo de validade.

O Que Mudou Entre Junho e a Beta 6

O piso do macOS não se manteve estável ao longo do período de beta, e vale a pena saber qual versão da história você está lendo.

Em junho, a release note sobre Intel dizia, conforme citado nos Apple Developer Forums:

Xcode 27 will only install and run on Apple silicon Macs. The macOS SDK is still Universal for back deployment up to and including macOS 27. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

Isso não diz nada sobre um mínimo. O resumo do primeiro dia de Tsai interpretou a situação como "the minimum you can target is now Big Sur (or Monterey for Apple Silicon Macs)," e a issue do ViennaRSS afirmou diretamente macOS 12. As release notes atuais da beta 6 resolvem a questão:

Xcode 27 will only install and run on Apple silicon Macs. The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

Mesmo número de issue, reformulado para citar o macOS 12. A atualização de setembro de Tsai registra a mesma coisa: "Xcode 27 Beta 6 documents macOS 12.0 as the minimum deployment target now." Se o seu plano de migração foi construído em cima do Big Sur, revise-o para o Monterey.

Quem Isso Realmente Afeta

Três grupos, em ordem decrescente de dor.

Apps para Mac que ainda suportam do High Sierra ao Big Sur

Esse é o grupo sobre o qual trata o post de Tsai, e o grupo que recebe menos simpatia da plataforma. Matthias Gansrigler-Hrad, da Eternal Storms, colocou isso de forma direta no Mastodon:

I don't appreciate being forced by Xcode 27 to drop support for macOS 10.13-11.0. It's my decision

Para esses desenvolvedores, o Xcode 27 é uma escolha forçada: elevar o piso e cortar usuários de sistemas de 2017–2020, ou permanecer no Xcode 26 e abrir mão do SDK do macOS 27 e de tudo que depende dele.

Apps iOS e, principalmente, bibliotecas iOS abaixo da versão 15

O piso da Apple para iOS é 15 desde o Xcode 26, então um app que já está em 15 não sente nada. Mas o ecossistema estava cheio de bibliotecas declarando mínimos mais baixos, e cada uma delas agora gera o diagnóstico em todo projeto que a importa. Os issue trackers do GitHub encheram na primeira semana de junho com pedidos praticamente idênticos, intitulados "Support Xcode 27: raise minimum iOS deployment target to 15" — contra o Facebook iOS SDK, que declarava .iOS(.v12) em seu Package.swift, contra Adjust, DataDog, SDWebImage e outros. Se você depende de um pacote cujo mantenedor ainda não respondeu, você fica bloqueado até que ele responda ou até que você faça um fork.

Qualquer um com um target antigo enterrado numa dependência

O caso sutil. Seu app tem target 15. Um pacote Swift transitivo tem target 13. O Xcode 27 compila esse pacote com o seu toolchain, vê o 13 e derruba o seu build. Não existe uma forma de sobrescrever isso do lado do consumidor no Swift Package Manager: a conclusão do bleepingswift, que coincide com a nossa, é que "packages declaring older minimums in their platforms declaration require either upgrading to a newer package version or forking and updating the requirement yourself."

A Válvula de Escape Oculta

Ela existe, e você deveria conhecê-la e ter cuidado com ela.

Ighor July, escrevendo em 24 de julho num texto que Tsai cita, relata que na beta do Xcode 27 "a hidden setting changed those errors back into warnings, and the compiler still produced the older targets I tested." Ele descreve a configuração como "undocumented, absent from the normal Xcode interface, and currently being tested only" num toolchain de beta. Um leitor do post de Tsai, Harald Striepe, dá o nome dela:

__DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO

Essa é uma build setting, então ela vai onde as build settings costumam ir: um arquivo .xcconfig associado à configuração, ou uma configuração User-Defined adicionada ao final do painel Build Settings do target. Defina-a, e a verificação de deployment target volta ao comportamento do Xcode 26.

Agora as ressalvas, que não são pequenas.

Ela não é suportada oficialmente. Dois underscores no início são a convenção da Apple para configurações internas. Ela pode ser renomeada ou removida em qualquer beta, inclusive na seguinte àquela em que você começou a depender dela.

Ela restaura o aviso, não os testes. A avaliação de Tsai sobre a mudança como um todo vale a pena citar na íntegra, porque é a moldura honesta do assunto:

I'm frustrated, too, but it's more honest than the recent releases that claimed to support deployment on older macOS versions when Apple clearly hadn't tested that it actually worked.

Desligar o erro te devolve a compilar para um target que a Apple já não testava antes e agora deixa explícito que não suporta. O que quer que estivesse quebrado no Catalina no Xcode 26 continuará quebrado.

A configuração oculta não comprova que a App Store aceitará o build. Os requisitos de SDK e de submissão precisam ser verificados separadamente para cada plataforma.

Os Requisitos de SDK da App Store São Específicos por Plataforma

No anúncio de 9 de setembro de 2026, a Apple definiu abril de 2027 como o início da exigência dos SDKs do iOS 27, iPadOS 27, tvOS 27, visionOS 27 e watchOS 27 ou posteriores para submissões nas respectivas plataformas. O anúncio não especifica um dia de abril e não inclui um SDK mínimo do macOS.

A página de requisitos futuros da Apple registra os requisitos de SDK que entraram em vigor em 28 de abril de 2026 para essas mesmas plataformas, sem incluir o Mac nessa exigência. A página também lista requisitos separados para apps de Mac; a ausência do macOS no anúncio de abril de 2027 não isenta esses apps de todos os requisitos da loja.

O SDK usado para compilar um app e a versão mínima do sistema em que ele pode rodar são coisas diferentes. Os requisitos de sistema do Xcode listam os deployment targets suportados pelo Xcode 27, incluindo macOS 12–27 e iOS/iPadOS 15–27. Esses são limites da ferramenta de build, não prazos de submissão à loja por si só.

Portanto, o anúncio da Apple não estabelece um prazo de abril de 2027 para atualizar apps da Mac App Store que suportam macOS 11 ou anterior. A inferência anterior de que o piso do Xcode 27 criava esse prazo não tinha respaldo e foi corrigida aqui.

Antes de definir uma data de encerramento de suporte, confira os requisitos atuais de submissão para a plataforma, o toolchain e o canal de distribuição em questão. Compilar com sucesso usando a configuração oculta também não comprova que o build será aceito na App Store.

A distribuição direta com Developer ID também exige verificar a compatibilidade do toolchain e do sistema operacional, além dos requisitos de assinatura e notarização. A ausência de um prazo para macOS nesse anúncio não garante que o Xcode 26, builds com targets antigos ou esse canal de distribuição continuarão válidos indefinidamente.

Manter o Xcode 26 por Perto, e Por Que Isso Deixa de Funcionar

A mitigação óbvia é instalar os dois. Ferramentas como xcodes facilitam manter o Xcode 26.6 ao lado da beta do 27 e alternar com xcode-select. Para um projeto com target 10.13 que você ainda precisa lançar este ano, essa é a decisão certa.

Mas isso tem prazo de validade. A tabela de suporte da Apple lista o Xcode 26.6 como exigindo "macOS Tahoe 26.2 – macOS Tahoe 26.x." Nada diz que ele roda no macOS 27, e a leitura de Tsai é que "using old versions of Xcode isn't a great solution because they aren't supported on Golden Gate." Ele pode até abrir; a Apple não vai consertar se não abrir. E ele acrescenta um custo mais sutil:

Swift also makes it more difficult to call newer APIs when using an older SDK.

Continuar no Xcode 26 significa continuar no SDK do macOS 26, o que significa que as APIs do macOS 27 só ficam acessíveis por dynamic lookup, ou nem isso. Para um app em modo de manutenção, tudo bem. Para qualquer coisa que você esteja desenvolvendo ativamente, é um estrangulamento lento.

O Próprio Xcode 27 É Exclusivo para Apple Silicon

Essa é uma mudança separada que chega na mesma release e acaba se misturando com a história do deployment target, então vale deixar claro qual é qual.

As release notes são inequívocas: "Xcode 27 will only install and run on Apple silicon Macs." O binário é exclusivamente arm64, como confirmou nos fóruns o dono de um MacBook Pro Intel, depois que a linha "requires macOS Tahoe 26.4 or later" nas notas o levou a esperar o contrário — o Tahoe roda em um punhado de Macs Intel, o Xcode 27 não.

O SDK continua Universal. Dá para compilar slices x86_64 e binários Universal a partir do Xcode 27; só que precisa ser num Apple silicon. É uma exigência de hardware para o desenvolvedor, não uma restrição de distribuição para o app.

A Outra Mudança Relacionada à Intel: o Universal Deixa de Ser o Padrão a Partir do 27.0

Mais um item relacionado à Intel nas notas da beta 6, catalogado sob "Intel Deprecation," que a maior parte da cobertura deixou passar:

Build targets with a min deployment target set to macOS 27.0 or DriverKit 27.0 will not build Universal by default. The ARCHS_STANDARD build setting will no longer include x86_64 when MACOSX_DEPLOYMENT_TARGET or DRIVERKIT_DEPLOYMENT_TARGET >= 27.0. The x86_64 architecture can be added to the ARCHS build setting if this is needed. (161837535)

Isso é lógico — o macOS 27 não roda em nenhum Mac Intel, então um target exclusivo para 27.0 não tem em quais máquinas Intel rodar — mas tem um efeito colateral. O Rosetta ainda está presente no macOS 27, e a nota para desenvolvedores de 1º de setembro da Apple reafirmou que a versão 27 é sua release final. Um app exclusivo para 27.0 que descarta o x86_64 por padrão também deixa de conseguir rodar sob o Rosetta em Apple silicon, o que só importa se você distribuía um host de plug-ins exclusivo para Intel ou algo do tipo. Adicione x86_64 ao ARCHS explicitamente se precisar dele.

Um Terceiro Piso Que Ninguém Menciona: o libc++ em 11.0

Enterrado na mesma lista de Deprecations: "The minimum supported deployment target on macOS for the C++ standard library has been increased to 11.0." Esse é um piso diferente, mais baixo que o piso de 12.0 do sistema de build, e se aplica ao runtime de C++ contra o qual você faz o link, não ao deployment target que você declara. Na prática, ele só aparece se você já contornou a verificação do sistema de build — com a configuração oculta, por exemplo — e ainda tem código C++ mirando 10.15 ou anterior. Nesse caso, o próprio libc++ é a próxima coisa que barra você.

Corrigindo: Dependências

Para os seus próprios targets, a correção é um número num campo de texto. Para dependências:

CocoaPods. Adicione um hook post_install que reescreve o deployment target de todos os pod targets para o piso, depois rode pod install e limpe a pasta de build. A versão do hook do bleepingswift tem o formato padrão; o ponto é que ele se aplica a todos os pod targets, não só aos que reclamam hoje.

Swift Package Manager. Não existe override. Suas opções são: atualizar para uma versão do pacote que já elevou seu platforms; abrir ou dar upvote na issue; ou fazer um fork, editar o Package.swift, e apontar seu projeto para o fork até o upstream se atualizar. Confira o issue tracker primeiro — para os SDKs principais, alguém já abriu o pedido na primeira semana de junho, geralmente com um pull request anexado.

Frameworks vendored e XCFrameworks. Eles carregam seu próprio mínimo no Info.plist e nos load commands do Mach-O. O Xcode 27 não se recusa a fazer o link de um framework binário antigo, mas o linker vai avisar sobre a incompatibilidade de versão, e o comportamento no target antigo é exatamente igual ao nível de testes que ele recebeu, ou seja, nenhum.

O Que "Honesto" Significa Aqui

Vale a pena parar um momento na moldura que Tsai propõe, porque ela muda com o que você deveria estar bravo.

O Xcode 26 não suportava o macOS 10.13. Ele permitia que você digitasse 10.13, e gerava código, e a Apple não testava se os frameworks do SDK 26 se comportavam corretamente num sistema operacional de 2017. Os desenvolvedores que lançavam essas builds estavam fazendo o próprio QA contra um SO que a Apple já havia deixado para trás, e na maior parte das vezes funcionava, porque os frameworks são retrocompatíveis por design. Mas "na maior parte das vezes" carregava um peso real nessa frase, e a cada ano a distância entre o SDK e o target aumentava.

O Xcode 27 transforma o intervalo documentado no intervalo real. Isso é uma perda para usuários de Macs antigos e para os desenvolvedores que os atendiam. Não é a perda de algo que a Apple algum dia tenha prometido.

A Complicação Regulatória

Mais um fio solto. Em 26 de agosto, Tsai reuniu comentários sobre o Cyber Resilience Act da UE, cujas obrigações principais entram em vigor em 11 de dezembro de 2027 e que exige atualizações de segurança por pelo menos cinco anos. Um leitor identificado como Frederik levantou a interação com a App Store:

Once you update the minimum supported OS version of your app (which you might be forced to by newer Xcode versions… you can no longer provide updates for your older app versions on the App Store.

O planejamento de atualizações de segurança pode depender das decisões sobre deployment target, toolchain e distribuição. Mas o anúncio dos requisitos de SDK para abril de 2027 não obriga, por si só, a encerrar o suporte ao macOS 11 naquele mês. Verifique as opções reais de manutenção do seu app sob os requisitos atuais e consulte um profissional jurídico qualificado sobre as obrigações que possam se aplicar.

Checklist de Migração

Para um app de Mac com um target antigo, em ordem:

1. Faça um inventário dos seus usuários reais. Se os seus analytics mostram que ninguém está abaixo do macOS 12, isso é uma mudança de uma linha e uma nota de release. A maioria dos apps está nessa situação.
2. Defina o deployment target como 12.0 (macOS) ou 15.0 (iOS) em todos os targets, incluindo extensões, helpers e testes. Compile com a beta do Xcode 27 e elimine todas as ocorrências do diagnóstico.
3. Audite as dependências em busca de declarações platforms e podspecs abaixo do piso. Faça fork do que for necessário.
4. Defina o suporte aos sistemas antigos. Se você precisa continuar entregando para usuários de macOS 10.13–11, verifique os requisitos de toolchain, runtime e distribuição, escolha e teste um plano de suporte e comunique a decisão real aos usuários. Não presuma um prazo para uma build final de Mac em abril de 2027.
5. Não leve a configuração oculta para produção, a menos que você mesmo tenha testado o resultado no SO antigo e aceite que a configuração pode desaparecer na próxima beta.
6. Se o seu target é exclusivamente 27.0, verifique o ARCHS. Você pode ter descartado o x86_64 sem perceber.

Solução de Problemas Comuns

O erro persiste depois que elevei o target do app

Outro target no projeto ainda tem o valor antigo. Selecione o projeto (não um target) no navigator, verifique o deployment target no nível do projeto, e depois cada target e cada bundle de testes. Widgets e extensões de app costumam ser os culpados.

O erro cita um pacote do qual eu não dependo diretamente

Uma dependência transitiva. Use swift package show-dependencies (ou o package graph do Xcode) para descobrir quem o traz, e então atualize esse pacote intermediário ou faça fork da folha.

O xcodebuild pela linha de comando falha, mas a interface do Xcode compila

Verifique qual toolchain a linha de comando está usando: xcode-select -p. Você pode estar com a interface na versão 26 e a CLI na 27, ou vice-versa.

Defini a flag oculta e não fez diferença

A flag precisa estar visível para o sistema de build no nível em que a verificação roda — o xcconfig no nível do projeto é o lugar mais seguro. Se ela estiver definida só num target, os outros continuam dando erro. Se mesmo assim não fizer diferença, a beta que você está usando pode tê-la removido.

Meus CI runners são Intel

O Xcode 27 não vai instalar neles. Isso é uma migração de hardware, não um problema de configuração. Os provedores hospedados migraram para runners Apple silicon há um tempo; Mac minis Intel self-hosted agora chegaram ao fim de linha para builds com o toolchain atual.

Perguntas Frequentes

O Xcode 27 eleva o mínimo do iOS?

Não no papel — a tabela da Apple diz iOS 15 desde o Xcode 26. O que muda é a aplicação da regra: targets abaixo de 15 que compilavam com aviso no Xcode 26 falham no Xcode 27.

Qual é o mínimo do macOS no Xcode 27?

macOS 12 Monterey, de acordo com a página de suporte do Xcode da Apple e as release notes da beta 6. No início do ciclo de beta, a nota foi interpretada como Big Sur; essa leitura está desatualizada.

Ainda dá para compilar apps Universal (Intel + Apple silicon)?

Sim, a partir de um Mac Apple silicon. O SDK do macOS 27 suporta back-deployment Universal até o macOS 12 e versões posteriores. O único caso em que o x86_64 é descartado por padrão é um target definido para 27.0 ou mais recente.

Quando eu preciso migrar para o Xcode 27?

Depende da plataforma e do canal de distribuição. O anúncio da Apple de 9 de setembro de 2026 exige, a partir de abril de 2027, os SDKs de versão 27 ou posteriores para iOS, iPadOS, tvOS, visionOS e watchOS, mas não estabelece um prazo equivalente para macOS. A distribuição direta ainda requer verificar a compatibilidade do toolchain e do sistema operacional, a assinatura e a notarização; não é uma garantia de poder permanecer no Xcode 26 indefinidamente.

A configuração oculta é segura para builds da App Store?

Desconhecido. Ninguém relatou uma submissão compilada com ela, e é uma flag interna não documentada. Trate-a como uma ferramenta para builds locais e branches legadas, não para o seu pipeline de release.

Conclusão

A mudança de deployment target do Xcode 27 é uma edição pequena com uma cauda longa. A Apple não elevou muito o piso — uma versão no macOS, nenhuma no iOS — mas parou de fingir que o piso era opcional, e uma década de software independente para Mac foi construída em cima dessa ficção. O erro de build que você recebe hoje é fácil de corrigir se seus usuários estão em sistemas modernos, e impossível de corrigir de verdade se não estiverem.

Saiba em qual grupo você está. Se você ainda entrega para macOS 11 ou anterior, avalie seus usuários e as opções viáveis de toolchain e distribuição, e teste o plano de suporte antes de anunciar uma data de encerramento. O anúncio de abril de 2027 não inicia uma contagem regressiva de sete meses para apps da Mac App Store. Se você não precisa mais atender esses sistemas, eleve o deployment target, corrija as dependências, verifique o ARCHS se você é exclusivamente 27, e siga em frente.

Leitura relacionada: audite seus apps Intel antes do fim do Rosetta, o corte de compatibilidade Intel do macOS 27, corrigindo uma configuração de desenvolvimento no macOS Tahoe, e as melhores ferramentas de desenvolvimento para Mac deste ano.