Swift was always going to be part of the OS (2022)

Original Article ↗ Hacker News Discussion ↗

Apple’s decision to tightly integrate Swift into its operating systems sparks debate over the trade-offs between OS-bundled runtimes and app-shipped frameworks. Commenters compare Apple’s approach to .NET, Android, and COM, weighing benefits like performance, consistency, and automatic UI upgrades against downsides such as slower adoption of new features, reduced backward compatibility, and the risk of worsening UX when frameworks like SwiftUI evolve under the hood. The thread also touches on Swift’s performance characteristics, ABI stability, and how Apple’s platform strategy influences hardware longevity and developer ecosystem choices.

Swift vs .NET and platform strategy

  • Swift is positioned by Apple as a successor to C/Obj‑C/C++ for the OS itself, unlike .NET’s original “better Java / web services / COM replacement” vision.
  • Microsoft’s path moved from OS‑bound .NET Framework to side‑by‑side, app‑bundled runtimes (.NET Core/5+), dropping the Global Assembly Cache and much of the old “DLL hell” machinery.
  • Research systems like Singularity and Midori influenced C#/.NET but never became mainstream; some kernel‑level C# experiments existed outside Microsoft.

Bundling Swift/SwiftUI in the OS

  • Pro: Shared OS libraries give better performance, smaller apps, consistent UI, and “free” improvements when OS UI components evolve. Similar in spirit to JavaScript in browsers.
  • Pro: Apple’s approach can reduce compatibility burdens and long‑term maintenance, potentially leading to better systems overall.
  • Con: Libraries can’t be updated independently, slowing adoption of new language/framework features; developers must wait for OS uptake.
  • Con: Tight coupling encourages dropping support for older OS versions and indirectly accelerates hardware obsolescence.
  • Some suggest a hybrid model where specific Swift versions are downloaded on demand per app, but others highlight storage, linker, memory, DRM, and complexity concerns.

Apple software quality and UX

  • Several comments criticize recent macOS apps written with SwiftUI (e.g., System Settings, Music) as regressions in UX and reliability.
  • Others argue the language/framework isn’t the core issue; organizational problems, lack of QA, and unsustainable pace are blamed.
  • There’s disagreement over how much Swift/SwiftUI themselves contribute to this perceived decline.

Language design, performance, and memory management

  • Swift is praised as a rare mix of strong performance (AOT, ARC), safety (optionals, bounds checking), and relative ease of use.
  • Some see tight Apple coupling as limiting Swift’s broader adoption, paralleling early C#’s Windows‑centrism.
  • Multiple comments debate performance: Swift often lags C#/Java/Rust in microbenchmarks, with reference counting (ARC) cited as a significant overhead; others say it’s within a small constant factor and “fast enough” for typical apps.
  • Reference counting is defended as a good fit for memory‑constrained, battery‑powered devices, trading CPU overhead for smaller heaps and more deterministic reclamation.

Compatibility, ABI, and evolution

  • Concerns are raised about dynamic linking of non‑C ABIs; some wish for stable C‑style interfaces to Apple frameworks (COM‑like) to aid cross‑language bindings.
  • Swift now has an evolving ABI story, including library evolution docs and interop work (e.g., with .NET).
  • Deployment targeting: apps set a minimum OS; some Swift features require newer runtimes and won’t back‑deploy, but the ABI is intended to remain compatible (e.g., into Swift 6).
  • New attributes like @backDeployed are likened to polyfills, allowing newer API methods to run with default implementations on older OS versions.

Ecosystem and tooling notes

  • Experiences building Swift apps are often positive (fast, good‑looking with little effort), though Core Data is seen as clunky compared to the newer SwiftData.
  • Some praise Linux distributions and package managers as a contrasting model for library distribution and updates.