十年的 iOS 开发，数千次崩溃，以及一个令人不安的事实：Xcode 的糟糕程度，恰好是苹果愿意容忍的程度。
如果你做 iOS 开发者超过，比方说，五分钟，你可能就经历过以下情景：
-
你打开 Xcode。
-
你按下 <math xmlns="http://www.w3.org/1998/Math/MathML"> ⌘B \text{⌘B} </math>⌘B（构建/编译）。
-
发生了点什么。但不是你预期的那个东西。
- 构建挂起了。
- 索引器卡死了。
- 模拟器毅然决然地说：今天不是我工作的日子（即模拟器出故障或运行缓慢）。
然后，在库比蒂诺的某个角落，有人耸了耸肩，表示无所谓。
欢迎来到 Xcode 的世界 ：这是一款没人爱，人人忍，却被全球最有价值公司保护着的唯一一款 IDE（集成开发环境）。
但我今天不是来单纯发牢骚的。我搞 iOS 应用已经十多年了，从 Xcode 4 熬到了 16。经历了 Swift 的普及、Storyboards、SwiftUI、并发编程等等，所有的一切。
经过这几年的心力交瘁，我得出了一个残酷的结论：
Xcode 不是"意外变差的"。它目前的平庸程度，恰恰是苹果允许它达到的程度。
日常 Xcode 体验：一份痛苦清单
咱们说实话：Xcode 不只是有 Bug，它是以一种我们非常熟悉 的方式持续地不可预测。
一个典型的 Xcode 日常是这样的：
- 刚加了一个新文件， "Indexing..." 就卡住了 5 分钟。
- 在一个大文件里输入 <math xmlns="http://www.w3.org/1998/Math/MathML"> . \text{.} </math>. 的时候，自动补全直接冻结。
- SwiftUI 预览可能工作了一次，然后就消失了，只留下 "Some previews failed."
- 构建（Build）成功了。App 没启动。模拟器崩了。Xcode 在撒谎。
- 断点（Breakpoints） ...自己消失了。
- 你叹了口气。打开活动监视器，把那个索引进程杀掉。
你甚至已经不再惊讶了。而这才是更大的问题。
很多开发者已经停止质疑了。我们默默地接受了这种平庸。
Xcode 是如何变成一个瓶颈的
Xcode 一开始没这么烂。当然，它一直有点笨重------但至少还能应付。
然后一切都变了。
1. Swift 登场了
Swift 让 Xcode 的复杂性呈指数级增长。它是一个强大的语言，但编译器也非常重。
再加上 Swift 每年都在变，Xcode 就必须疲于应付：
- 旧的 Swift 项目
- 正在过渡中的项目
- 使用最新特性的新代码库
这可不是正常的 IDE 应该有的工作量。
2. SwiftUI 登场了
SwiftUI 预览本应实时显示 UI 变化。但它们经常：
- 冻住
- 悄无声息地失败
- 像个挖矿程序一样耗干你的笔记本电池
开发者已经学会了不信任预览。如果一个开发工具教会你不要相信它显示的内容------那就有大问题了。
3. 年度操作系统更新周期
苹果每年都会发布新的 iOS、macOS、watchOS、tvOS，现在还有 visionOS。Xcode 必须全部支持。
每一年，都得来一遍。
那什么事情从来没有发生过呢？
"我们停下来，重构一下，花三年时间把工具链做得坚如磐石吧。"
结果就是：每年六月都有新东西。新的 Bug。新的临时解决方案。但 Xcode 还是那个 Xcode。
为什么苹果就是不修复它？
简单的答案：他们没必要。
苹果垄断了整个生态
如果你想做 iOS App，你就得用 Xcode。就这么简单。
没有竞争。没有替代品。除非能帮到设备销售，否则苹果没有动力去投资提升开发者的幸福感。
这就是为什么你会看到：
- <math xmlns="http://www.w3.org/1998/Math/MathML"> CI/CD \text{CI/CD} </math>CI/CD 流水线在底层也必须使用 Xcode
- IDE 工作流程被绑定在专有的代码签名过程上
- 一群沮丧的开发者社区，却仍然在不断地交付应用
开发者的痛苦不是 <math xmlns="http://www.w3.org/1998/Math/MathML"> KPI \text{KPI} </math>KPI
苹果在乎的是：
- iPhone 销量
- 生态系统锁定
- 服务收入
- App Store 收入
- WWDC 制造的热度
这个清单里，根本没有这条：
"这个季度 Xcode 导致开发者浪费了 300 小时在构建失败上吗？"
如果它不影响收入或公众形象------那就不是优先事项。
<math xmlns="http://www.w3.org/1998/Math/MathML"> WWDC \text{WWDC} </math>WWDC 文化：炫酷 > 稳定
苹果的文化是宣布"下一步是什么"。新的 <math xmlns="http://www.w3.org/1998/Math/MathML"> API \text{API} </math>API。新的功能。新的框架。
没有人会站在台上说：
"Xcode 现在速度提升了 50%，崩溃减少了 60%。"
这不带感。这在推特上火不起来。
"Vision Pro 新 <math xmlns="http://www.w3.org/1998/Math/MathML"> API \text{API} </math>API" 才能火。
平庸的隐性成本
Xcode 最糟糕的部分不是崩溃。而是我们已经把这种感受常态化了：
"做 iOS 开发，就是这样的。"
我们学会了：
- 像条件反射一样删除 <math xmlns="http://www.w3.org/1998/Math/MathML"> DerivedData \text{DerivedData} </math>DerivedData 文件夹
- 避免某些重构，因为索引器可能会挂掉
- 禁用预览，改用 <math xmlns="http://www.w3.org/1998/Math/MathML"> print \text{print} </math>print 语句来调试
- 接受模拟器崩溃是工作的一部分
这会以一种看不见的方式拖慢团队进度。
- 它破坏了心流状态。
- 它消耗了认知能量。
- 它给新开发者灌输了错误观念：现代开发流程就该是这个样子。
而且它悄悄地赶走了人才。一些非常牛的工程师------尤其是做后端的人------试了一下 iOS，体验了一下 Xcode，然后就再也没回来了。
一个"不平庸"的 Xcode 应该是什么样的
让我们幻想一下。
一个很棒的 Xcode 应该：
- 启动很快。而不是"卡顿 40 秒来重建模块"。
- 提供值得信任的预览，即使失败也能体面地给出提示。
- 给出人能看懂的构建错误，而不是用另一种语言抛出编译器崩溃。
- 允许你直观地调试异步代码。
- 让你可靠地进行内部整理：重构、依赖升级和诊断。
如果苹果愿意把它当作一款产品来重新构想，而不仅仅是作为一个依赖工具，它可能会是世界上最好的 <math xmlns="http://www.w3.org/1998/Math/MathML"> IDE \text{IDE} </math>IDE。
但这需要高层把这件事列为优先事项。
那么，我们能做什么？
我们没有万亿美元的预算。但作为开发者，我们手上有两个筹码：
1. 要求苹果负责
不是通过空洞的愤怒，而是通过清晰的沟通：
- 提交详细的反馈。
- 公开谈论真实的用户体验问题。
- 别再美化开发者体验了。
沉默对任何人都没有好处。
2. 呼吁更好的开发者文化
让我们停止说：
"唉，Xcode 就那样。"
让我们开始说：
"这坏了。而且这不应该是常态。"
最后的想法
Xcode 不是我们的私人仇敌。它是系统性选择的结果------一个刚好能用来发布 iOS 应用的工具。
但我们值得拥有更好的。
我们为苹果带来了世界上最具创新性的应用。
我们在他们的平台上建立了数十亿美元的业务。
我们学习了 Swift、SwiftUI、Async/Await、Combine、Concurrency。
我们遵守了所有模式。学会了所有规则。买了所有 Mac。
难道我们要求 Xcode 能正常工作，过分吗？
不用花哨。不用神奇。只要可靠就行。
在苹果把 Xcode 当作一款值得完善的产品之前，我们得到的就会是现在这个样子：
一个打磨得无比精美的硬件生态系统......运行在一个开发者们多希望自己能修复的，摇摇晃晃的软件地基之上。
欢迎关注我的公众号：OpenFlutter