SwiftUI 七年仍像测试版：声明式 UI 的成本最终落到兼容层
作者：林岚｜OC 开发者生态编辑
林岚
一名长期使用者在文章 SwiftUI: A Story of Mediocrity 中批评，SwiftUI 发布七年后仍在布局、性能、数据流、API 变动和旧系统兼容上给开发者制造大量工作。这是一篇个人工程复盘，不是对所有 SwiftUI 应用的统计调查。
一句话结论：SwiftUI 最大的长期成本不只是某个控件有 Bug，而是框架跟着操作系统发布，团队必须同时维护新声明式接口和旧系统上的条件分支、替代组件与行为差异。
声明式 UI 的承诺很吸引人：开发者描述状态和界面关系，框架负责计算更新。对于标准列表、表单、导航和跨苹果平台界面，SwiftUI 确实能减少大量样板代码。Apple 也持续加入 Observation 等机制，改善状态追踪和刷新范围。
但声明式抽象会隐藏执行过程。布局抖动、视图身份变化或意外重复计算出现时，开发者需要理解框架内部如何比较状态和重建视图。原文作者给出了自己的性能测试和失败案例，它们能证明这些问题会发生，却不能单独证明 UIKit 在所有项目里更快或更可靠。
更结构性的难点是分发。SwiftUI 能力随 iOS 和 macOS 更新，应用却往往要支持数年前的系统。新 API 不能靠更新一个 npm 包带给旧设备，团队只能加 available 判断、包装兼容层，必要时退回 UIKit 或 AppKit。框架升级越快，版本矩阵越复杂。
Apple 自己的教程也在变化。Landmarks 教程页面现在明确提示，旧内容不再代表当前 SwiftUI 和 Xcode 的最佳实践。这并不等于框架失败，却说明学习材料、工具链和推荐架构正在持续迁移。对长期维护产品来说，迁移成本和新功能同样真实。
合理选择不是“全用 SwiftUI”或“永远不用”。新界面可以优先使用 SwiftUI，把滚动、富文本、复杂输入和性能敏感组件保留在成熟框架中；同时用测量工具定位刷新和布局成本。声明式语法省下的代码，不能预支为未来一定省下的维护时间。
关键事实
- 批评范围：布局、刷新性能、状态管理、API 变化和旧系统兼容
- 证据性质：来自一名开发者的案例和测试，不是全生态统计
- Apple 改进：持续增加 Observation、性能分析文档和新组件
- 结构限制：SwiftUI 随操作系统分发，新能力无法自动下放到旧系统
OC 判断
SwiftUI 已经不是实验项目，但它的兼容成本仍像一个快速变化的框架。团队应按组件风险逐步采用，保留 UIKit/AppKit 逃生口，并把最低系统版本当成架构条件，而不是发布前才处理的限制。
为什么重要
- 对开发者：短代码不等于低维护，必须测试不同系统版本上的布局和状态行为。
- 对团队：技术选型应计算兼容层、回归测试和迁移成本，而不只比较首版开发速度。
- 对用户：旧设备上的功能缺失和行为差异，最终会变成体验不一致。
评论
围绕这篇文章补充信息、提出问题或分享观察。