![Imagem de capa de [Swift avançado #9] ABI estável: por que os apps ficaram menores](/assets/images/posts/150f67d8-49bc-4461-8f04-26b5e8fc56e3/swift-abi-stability-app-size.jpg)
Na primavera de 2019, quando o iOS 12.2 foi distribuído com o Swift 5, algo estranho aconteceu. Sem fazer nada, os apps ficaram vários MB menores. Swift ABI Stability and More
Este texto dá continuidade ao anterior Swift avançado #8.
O segredo estava em uma linha seca das notas de lançamento: estabilidade do ABI (ABI stability) alcançada.
O último capítulo da série sobre Swift conta toda a história: o que é ABI, por que levou cinco anos e o que isso tornou possível.
É um tema perfeito para encerrar a série, pois conecta a história da linguagem à sua estrutura interna.
O que é ABI — o contrato entre binários
Todo mundo conhece API. É o contrato no nível do código-fonte: qual é o nome das funções e quais são seus argumentos.
ABI (Application Binary Interface) é o contrato, na camada inferior, entre binários compilados.
Inclui em quais registradores colocar os argumentos ao chamar uma função, como um struct é disposto na memória (as dimensões que vimos na parte sobre layouts), como nomear símbolos (name mangling) e onde encontrar metadados.
Por que esse contrato é importante? Porque dois binários compilados em momentos diferentes e com compiladores diferentes precisam funcionar juntos.
Essa é exatamente a relação entre um app e as bibliotecas incorporadas ao sistema operacional. Se o ABI variasse entre versões, um app compilado com Swift 5.0 não conseguiria conversar com o runtime do Swift 5.5. Swift ABI Stability and More
Foi assim no início do Swift. O ABI mudava a cada versão, então cada app precisava carregar o runtime do Swift e a biblioteca padrão da versão usada.
Eram vários MB de bagagem duplicada por app, e o sistema operacional não podia usar Swift em seus próprios frameworks. Os frameworks do sistema também precisavam conversar com apps futuros, mas não havia essa garantia.
A declaração de estabilidade do ABI do Swift 5 congelou esse contrato. A convenção de chamadas, o layout de tipos e o name mangling foram definidos, e as versões seguintes evoluem respeitando esse contrato. Swift ABI Stability and More
Imediatamente, a biblioteca padrão se mudou para o sistema operacional (ao sair dos apps, o tamanho diminuiu). Isso também abriu caminho para a Apple criar frameworks do sistema, como o SwiftUI, em Swift.
A redução de tamanho de 2019 foi um sinal de que a linguagem havia amadurecido. Swift ABI Stability and More
Por que cinco anos — o peso do congelamento
Para a pergunta “por que não congelar logo?”, é preciso considerar o custo do congelamento. Definir o ABI significa carregar para sempre até os erros de design daquele momento.
Depois que o layout e a convenção são definidos, eles não podem mudar enquanto existirem binários antigos no mundo.
Lembre como foram turbulentos os dias do Swift 1–4. A sintaxe era refeita a cada versão. Se o ABI tivesse sido congelado naquela época, o Swift atual estaria preso à prisão do design inicial. Swift ABI Stability and More
Esperaram a implementação de genéricos se estabilizar e a estratégia de layout dos tipos por valor ser validada. Foram cinco anos até os grandes debates de design serem organizados pelo processo Evolution (parte 4, filosofia).
Os casos em que o C++ rejeita melhorias por causa da inércia de um ABI com décadas de existência mostram o valor dessa cautela.
O segundo contrato — estabilidade de módulos e evolução de bibliotecas
Mas a estabilidade do ABI ainda deixa uma questão em aberto: a distribuição de frameworks binários.
Antes do Swift 5.0, os compiladores trocavam interfaces de módulo em um formato binário chamado swiftmodule, vinculado à versão do compilador. Swift ABI Stability and More
Cada atualização do Xcode tornava inúteis todos os SDKs distribuídos.
A estabilidade de módulos (module stability) do Swift 5.1 resolve esse problema. Foi introduzido um arquivo de interface estável baseado em texto (.swiftinterface), permitindo ler frameworks compilados com outra versão do compilador. Swift ABI Stability and More
O ecossistema que distribui SDKs por meio de XCFramework (SDKs de pagamentos, analytics e mapas) se apoia nisso.
O conceito complementar é o modo de evolução de bibliotecas (library evolution). É uma opção para compilar um framework de modo que um app existente não quebre mesmo se propriedades armazenadas forem adicionadas depois, mas o custo é interessante.
O public struct nesse modo se torna um tipo cujo layout não está definido (resilient type). O cliente não consegue saber seu tamanho em tempo de compilação e paga o custo do acesso indireto.
É a contraparte exata de “se você conhece o tamanho, é mais rápido”, que vimos na parte sobre layouts.
Por isso, o modo de evolução oferece uma saída: @frozen. É a declaração “congelo o layout deste tipo, mas permito acesso direto”. Int e Optional da biblioteca padrão são @frozen por esse motivo.
Para desenvolvedores de apps, o significado prático é: targets de app e pacotes distribuídos como código-fonte (a maioria do SwiftPM) não precisam desse modo, e ativá-lo traz prejuízo.
É uma opção para quem distribui SDKs como binários. A resposta à pergunta “o que é BUILD_LIBRARY_FOR_DISTRIBUTION?” está neste parágrafo.
Conclusão — uma história que atravessa toda a série
Há um motivo para a história do ABI ser o capítulo final da série sobre Swift: todos os conceitos vistos até aqui convergem neste ponto.
O layout dos tipos por valor (partes sobre valores e layouts) foi congelado, por isso um struct atravessa a fronteira binária. O formato da witness table (parte sobre dispatch) foi definido, por isso os protocolos se tornaram API de frameworks.
E, como o processo Evolution (parte 4, filosofia) amadureceu o design, havia confiança para congelá-lo.
Segurança expressa por tipos (optionals, ARC, Sendable); custos explícitos (unsafe, any, @unchecked); e complexidade organizada em níveis (Progressive Disclosure).
A ideia central de toda a série é que esses princípios atravessam consistentemente a camada de sintaxe até a camada binária.
O Swift continua construindo o próximo nível nos fóruns de Evolution. Espero que esta série tenha se tornado um mapa para você interpretar essas mudanças por conta própria. Encerramos aqui.
Resumo
- ABI é o contrato entre binários (convenção de chamadas, layout e name mangling) e foi congelado no Swift 5 (2019). Graças a isso, a biblioteca padrão se mudou para o sistema operacional, os apps ficaram menores e a Apple pôde criar o SwiftUI em Swift.
- O congelamento levou cinco anos porque significava carregar para sempre até os erros. Foi o tempo necessário para amadurecer genéricos, layouts e o processo Evolution.
- A estabilidade de módulos do Swift 5.1 (.swiftinterface) abriu o ecossistema de frameworks binários (XCFramework).
- O modo de evolução de bibliotecas troca a garantia de que o app não quebre quando o framework evolui pelo custo do acesso indireto, e @frozen oferece uma saída. É uma opção desnecessária para targets de app.
- Conclusão da série: os princípios do Swift — segurança expressa por tipos, custos explícitos e complexidade organizada em níveis — são consistentes da sintaxe aos binários. Swift ABI Stability and More
Fontes e critérios de verificação
- Swift ABI Stability and More — Swift.org · anúncio oficial · verificado em 2026-08-17 · base: estabilidade do ABI do Swift 5, inclusão do runtime no sistema operacional e mudança no tamanho dos apps