Swift 一直注定会成为操作系统的一部分（2022）

Swift vs .NET 和平台策略

• Apple 将 Swift 定位为操作系统本身中 C/Obj‑C/C++ 的继任者，这与 .NET 最初“更好的 Java / web 服务 / COM 替代品”的愿景不同。
• Microsoft 的路径从与操作系统绑定的 .NET Framework 走向并行、随应用打包的运行时（.NET Core/5+），放弃了 Global Assembly Cache 以及旧式“DLL 地狱”机制中的许多部分。
• Singularity 和 Midori 等研究系统影响了 C#/.NET，但从未成为主流；微软之外也存在一些内核级 C# 实验。

在操作系统中捆绑 Swift/SwiftUI

• 优点：共享的操作系统库带来更好的性能、更小的应用、更一致的 UI，以及当操作系统 UI 组件演进时“免费”获得改进。其精神类似于浏览器中的 JavaScript。
• 优点：Apple 的做法可以减少兼容性负担和长期维护成本，可能最终带来更好的整体系统。
• 缺点：库无法独立更新，会减缓新语言/框架特性的采用；开发者必须等待操作系统普及。
• 缺点：紧耦合会鼓励放弃对旧版操作系统的支持，并间接加速硬件淘汰。
• 有人建议采用混合模式，即按应用按需下载特定 Swift 版本，但也有人指出存储、链接器、内存、DRM 和复杂性方面的担忧。

Apple 软件质量和 UX

• 一些评论批评近期用 SwiftUI 编写的 macOS 应用（例如 System Settings、Music）在 UX 和可靠性上出现退步。
• 另一些人认为问题不在语言/框架本身；他们将责任归咎于组织问题、缺乏 QA 以及不可持续的开发节奏。
• 对于 Swift/SwiftUI 在这种感知中的衰退里到底贡献了多少，存在分歧。

语言设计、性能和内存管理

• Swift 被称赞为一种罕见的组合：兼具强性能（AOT、ARC）、安全性（可选值、边界检查）以及相对易用性。
• 一些人认为与 Apple 的紧密耦合限制了 Swift 的更广泛采用，类似于早期 C# 的 Windows 中心主义。
• 多条评论讨论性能：在微基准测试中，Swift 往往落后于 C#/Java/Rust，引用计数（ARC）被视为显著开销；也有人认为它只是在一个很小的常数因子内，且对典型应用来说“足够快”。
• 有人为引用计数辩护，认为它非常适合内存受限、依赖电池的设备，用 CPU 开销换取更小的堆和更可预测的回收。

兼容性、ABI 与演进

• 有人担忧非 C ABI 的动态链接；一些人希望 Apple 框架能提供稳定的 C 风格接口（类似 COM），以帮助跨语言绑定。
• Swift 现在有不断演进的 ABI 方案，包括 library evolution 文档和互操作工作（例如与 .NET 的互通）。
• 部署目标：应用会设置最低操作系统版本；某些 Swift 特性需要更新的运行时，无法向后移植，但 ABI 预期会保持兼容（例如延续到 Swift 6）。
• 像 @backDeployed 这样的新属性被类比为 polyfill，允许较新的 API 方法在旧操作系统上使用默认实现运行。

生态与工具链备注

• 构建 Swift 应用的体验通常是正面的（快速、少量工作就能做得好看），尽管与较新的 SwiftData 相比，Core Data 被认为比较笨重。
• 一些人称赞 Linux 发行版和包管理器，作为库分发与更新的对照模型。