![Imagen de portada de [Swift avanzado #9] ABI estable: por qué las apps redujeron su tamaño](/assets/images/posts/150f67d8-49bc-4461-8f04-26b5e8fc56e3/swift-abi-stability-app-size.jpg)
En la primavera de 2019, cuando iOS 12.2 se distribuyó junto con Swift 5, ocurrió algo extraño. Sin hacer nada, las apps redujeron su tamaño varios MB. Swift ABI Stability and More
Este artículo continúa el anterior Swift avanzado #8.
El secreto estaba en una seca línea de las notas de la versión: estabilidad del ABI (ABI stability) conseguida.
La última entrega de la serie sobre Swift cuenta toda la historia: qué es el ABI, por qué tardó cinco años y qué hizo posible.
Es un tema perfecto para cerrar la serie, porque conecta la historia del lenguaje con su estructura interna.
Qué es el ABI: el contrato entre binarios
Todos conocen el API. Es el contrato a nivel del código fuente: cómo se llaman las funciones y cuáles son sus argumentos.
ABI (Application Binary Interface) es el contrato de la capa inferior entre binarios compilados.
Incluye en qué registros se colocan los argumentos al llamar a una función, cómo se dispone un struct en memoria (esas dimensiones que vimos en la parte sobre layouts), cómo se nombran los símbolos (name mangling) y dónde se encuentra la metadata.
¿Por qué importa este contrato? Porque dos binarios compilados en momentos distintos y con compiladores distintos deben funcionar juntos.
Eso describe exactamente la relación entre una app y las bibliotecas integradas en el sistema operativo. Si el ABI cambiara entre versiones, una app compilada con Swift 5.0 no podría comunicarse con el runtime de Swift 5.5. Swift ABI Stability and More
Así era realmente al principio de Swift. El ABI cambiaba en cada versión, por lo que cada app debía incluir el runtime de Swift y la biblioteca estándar de la versión que usaba.
Era equipaje duplicado de varios MB por app, y el sistema operativo no podía usar Swift en sus propios frameworks. Los frameworks del sistema debían comunicarse también con las apps futuras, y no había ninguna garantía.
La declaración de estabilidad del ABI de Swift 5 congeló este contrato. Se fijaron la convención de llamadas, el layout de tipos y el name mangling; las versiones posteriores evolucionan respetándolo. Swift ABI Stability and More
Inmediatamente, la biblioteca estándar se mudó al sistema operativo (al salir de las apps, redujo su tamaño). También se abrió el camino para que Apple creara frameworks del sistema como SwiftUI en Swift.
La reducción de tamaño de 2019 fue una señal de que el lenguaje había alcanzado la madurez. Swift ABI Stability and More
Por qué tardó cinco años: el peso de congelar
Ante la pregunta «¿por qué no congelarlo antes?», hay que considerar el coste de congelar. Fijar el ABI significa cargar para siempre incluso con los errores de diseño de ese momento.
Una vez acordados, el layout y la convención no pueden cambiar mientras existan binarios antiguos en el mundo.
Recuerda lo turbulentos que fueron Swift 1–4. La sintaxis se rehacía en cada versión. Si se hubiera congelado entonces, el Swift actual estaría encerrado en la prisión de su diseño inicial. Swift ABI Stability and More
Esperaron hasta estabilizar la implementación de genéricos y validar la estrategia de layout de los tipos por valor. Fueron cinco años hasta ordenar los grandes debates de diseño mediante el proceso Evolution (parte 4, filosofía).
Los casos de C++ que rechaza mejoras por la inercia de un ABI con décadas de antigüedad muestran el valor de esta prudencia.
El segundo contrato: estabilidad de módulos y evolución de bibliotecas
Pero la estabilidad del ABI deja pendiente un aspecto: la distribución de frameworks binarios.
Antes de Swift 5.0, los compiladores intercambiaban las interfaces de módulo en un formato binario llamado swiftmodule, ligado a la versión del compilador. Swift ABI Stability and More
Cada actualización de Xcode hacía inútiles todos los SDK distribuidos.
La estabilidad de módulos (module stability) de Swift 5.1 resuelve este problema. Introdujo un archivo de interfaz estable basado en texto (.swiftinterface), que permite leer frameworks compilados con otra versión del compilador. Swift ABI Stability and More
El ecosistema que distribuye SDK mediante XCFramework (SDK de pagos, analítica y mapas) se apoya en esto.
El concepto complementario es el modo de evolución de bibliotecas (library evolution). Es una opción para compilar un framework de modo que una app existente no se rompa aunque después se añadan propiedades almacenadas, pero tiene un coste interesante.
El public struct de este modo se convierte en un tipo cuyo layout no está fijado (resilient type). El cliente no puede conocer su tamaño en tiempo de compilación y paga el coste del acceso indirecto.
Es la contrapartida exacta de «si conoces el tamaño, es más rápido», que vimos en la parte sobre layouts.
Por eso el modo de evolución ofrece una salida: @frozen. Es la declaración «congelo el layout de este tipo, pero permito el acceso directo». Int y Optional de la biblioteca estándar son @frozen por esta razón.
En términos prácticos para los desarrolladores de apps: los targets de app y los paquetes distribuidos como código fuente (la mayoría de SwiftPM) no necesitan este modo, y activarlo perjudica.
Es una opción para quienes distribuyen SDK como binarios. La respuesta a la pregunta «¿qué es BUILD_LIBRARY_FOR_DISTRIBUTION?» está en este párrafo.
Conclusión: una historia que atraviesa toda la serie
Hay una razón para que la historia del ABI cierre la serie sobre Swift: todos los conceptos vistos hasta aquí convergen en este punto.
El layout de los tipos por valor (partes sobre valores y layouts) está congelado, por eso un struct cruza la frontera binaria. El formato de la witness table (parte sobre dispatch) está fijado, por eso los protocolos se convirtieron en API de frameworks.
Y como el diseño había madurado gracias al proceso Evolution (parte 4, filosofía), había confianza para congelarlo.
Seguridad expresada mediante tipos (optionals, ARC, Sendable); costes explícitos (unsafe, any, @unchecked); y complejidad organizada por niveles (Progressive Disclosure).
La historia que quería contar toda la serie es que estos principios atraviesan coherentemente desde la capa de sintaxis hasta la capa binaria.
Swift sigue construyendo el siguiente nivel en los foros de Evolution. Espero que esta serie se haya convertido en un mapa para interpretar esos cambios por cuenta propia. Aquí termina.
Resumen
- El ABI es el contrato entre binarios (convención de llamadas, layout y name mangling) y se congeló en Swift 5 (2019). Gracias a ello, la biblioteca estándar se mudó al sistema operativo, las apps redujeron su tamaño y Apple pudo crear SwiftUI en Swift.
- El congelamiento tardó cinco años porque implicaba cargar para siempre incluso con los errores. Fue tiempo para que maduraran los genéricos, los layouts y el proceso Evolution.
- La estabilidad de módulos de Swift 5.1 (.swiftinterface) abrió el ecosistema de frameworks binarios (XCFramework).
- El modo de evolución de bibliotecas intercambia que las apps no se rompan cuando evoluciona el framework por el coste del acceso indirecto, y @frozen ofrece una salida. Es una opción innecesaria para los targets de app.
- Conclusión de la serie: los principios de Swift —seguridad expresada mediante tipos, costes explícitos y complejidad organizada por niveles— son coherentes desde la sintaxis hasta los binarios. Swift ABI Stability and More
Fuentes y criterios de verificación
- Swift ABI Stability and More — Swift.org · anuncio oficial · verificado el 2026-08-17 · fundamento: estabilidad del ABI de Swift 5, incorporación del runtime al sistema operativo y cambio en el tamaño de las apps
Seguir leyendo
Serie avanzada de Swift
- Artículo anterior: [Swift avanzado #8] ~Copyable y ownership, tipos cuya copia está prohibida
- Artículo anterior: [Swift avanzado #7] Resumen de las macros de Swift: la verdadera naturaleza de @Observable
- Artículo anterior: [Swift avanzado #6] Layout de memoria de Swift: el orden de las propiedades cambia el tamaño