Swift siempre iba a formar parte del sistema operativo (2022)

Artículo original ↗ Discusión en Hacker News ↗

La decisión de Apple de integrar estrechamente Swift en sus sistemas operativos suscita debate sobre los compromisos entre runtimes incluidos en el sistema y frameworks empaquetados con la app. Los comentaristas comparan el enfoque de Apple con .NET, Android y COM, sopesando ventajas como rendimiento, consistencia y actualizaciones automáticas de la UI frente a desventajas como una adopción más lenta de nuevas funciones, menor compatibilidad con versiones anteriores y el riesgo de empeorar la UX cuando frameworks como SwiftUI evolucionan internamente. El hilo también trata las características de rendimiento de Swift, la estabilidad de su ABI y cómo la estrategia de plataforma de Apple influye en la longevidad del hardware y en las decisiones del ecosistema de desarrolladores.

Swift vs .NET y estrategia de plataforma

  • Swift está posicionado por Apple como un sucesor de C/Obj‑C/C++ para el propio sistema operativo, a diferencia de la visión original de .NET de “mejor Java / servicios web / reemplazo de COM”.
  • El camino de Microsoft pasó de .NET Framework, ligado al sistema operativo, a runtimes empaquetados junto con la aplicación y en paralelo (.NET Core/5+), eliminando el Global Assembly Cache y gran parte de la antigua maquinaria de “DLL hell”.
  • Sistemas de investigación como Singularity y Midori influyeron en C#/.NET, pero nunca se volvieron mainstream; también existieron algunos experimentos de C# a nivel de kernel fuera de Microsoft.

Incluir Swift/SwiftUI en el sistema operativo

  • Pro: Las bibliotecas compartidas del sistema operativo ofrecen mejor rendimiento, aplicaciones más pequeñas, una UI coherente y mejoras “gratis” cuando evolucionan los componentes de UI del sistema. Similar, en espíritu, a JavaScript en los navegadores.
  • Pro: El enfoque de Apple puede reducir las cargas de compatibilidad y el mantenimiento a largo plazo, potencialmente llevando a sistemas mejores en general.
  • Contra: Las bibliotecas no pueden actualizarse de forma independiente, lo que ralentiza la adopción de nuevas funciones del lenguaje/framework; los desarrolladores deben esperar a que el sistema operativo las incorpore.
  • Contra: El acoplamiento estrecho fomenta dejar de dar soporte a versiones antiguas del sistema operativo y acelera indirectamente la obsolescencia del hardware.
  • Algunos proponen un modelo híbrido en el que versiones concretas de Swift se descarguen bajo demanda por aplicación, pero otros señalan preocupaciones de almacenamiento, enlazado, memoria, DRM y complejidad.

Calidad del software de Apple y UX

  • Varios comentarios critican las apps recientes de macOS escritas con SwiftUI (por ejemplo, Ajustes del Sistema, Música) como regresiones en UX y fiabilidad.
  • Otros sostienen que el lenguaje/framework no es el problema central; se culpan problemas organizativos, falta de QA y un ritmo insostenible.
  • Hay desacuerdo sobre cuánto contribuyen Swift/SwiftUI en sí a este declive percibido.

Diseño del lenguaje, rendimiento y gestión de memoria

  • Swift recibe elogios por su rara combinación de alto rendimiento (AOT, ARC), seguridad (optionals, comprobación de límites) y relativa facilidad de uso.
  • Algunos ven el fuerte acoplamiento con Apple como una limitación para su adopción más amplia, en paralelo al primer C# centrado en Windows.
  • Varios comentarios debaten el rendimiento: Swift a menudo queda por detrás de C#/Java/Rust en microbenchmarks, y la contabilidad de referencias (ARC) se cita como una sobrecarga significativa; otros dicen que está dentro de un pequeño factor constante y que es “lo bastante rápido” para las apps típicas.
  • La contabilidad de referencias se defiende como una buena opción para dispositivos con memoria limitada y alimentados por batería, intercambiando sobrecarga de CPU por heaps más pequeños y una liberación más determinista.

Compatibilidad, ABI y evolución

  • Surgen preocupaciones sobre el enlazado dinámico de ABI que no sean C; algunos desearían interfaces estables estilo C para los frameworks de Apple (tipo COM) para ayudar a los bindings entre lenguajes.
  • Swift ahora tiene una historia de ABI en evolución, incluyendo documentación de library evolution y trabajo de interoperabilidad (por ejemplo, con .NET).
  • Objetivo de despliegue: las apps fijan un OS mínimo; algunas funciones de Swift requieren runtimes más nuevos y no se pueden back-deploy, pero la ABI está pensada para seguir siendo compatible (por ejemplo, hasta Swift 6).
  • Nuevos atributos como @backDeployed se comparan con polyfills, permitiendo que métodos de API más nuevos funcionen con implementaciones por defecto en sistemas operativos antiguos.

Notas sobre ecosistema y herramientas

  • Las experiencias construyendo apps en Swift suelen ser positivas (rápidas, atractivas con poco esfuerzo), aunque Core Data se ve como torpe en comparación con el más reciente SwiftData.
  • Algunos elogian las distribuciones Linux y los gestores de paquetes como un modelo contrastante para la distribución y actualización de bibliotecas.