Kyle Hughes 上周在 Mastodon 上发表了一篇简短的帖子：
在工作中，我正在一个小团队里开发一款新的 iOS 应用，与此同时，一个小型 Android 团队也在做同样的事情。由于 Kotlin、Compose 和 Cursor 的使用效率极高，我们被甩在身后，速度快得令人难以置信。他们能够使用最新功能支持到 Android 10（2019 年）的所有版本；而我们的目标是 iOS 16（2022 年），因此不得不做出巨大的牺牲（例如 Observable、泛型中的参数包）。Swift 6 简直就是法学硕士的笑柄。这几乎是站不住脚的。
2010 年代的情况并非如此。我参与过的各种规模的团队开发的每个 iOS 应用的质量和实现速度都绝对胜过 Android。[…] 在计算机历史上，从来没有哪个时期比现在更糟糕，需要对语言和框架进行根本性的、彻底的变革。
问题并不一定是 Swift 语言设计所固有的（但是，与几位专业编写 Swift 的朋友交谈后，我认为这可能是其中的一部分原因），而是在 Swift 的整个发展过程中，Apple 在每个主要新版本中都引入了彻底的改变。Swift 是在 2014 年 WWDC 上推出的（又是这个），去年 Apple 推出了 Swift 6。对于一种编程语言来说，十年内发生了这么多次重大版本变化。过去十年，Apple 的做法有优点也有缺点。但现在有一个新的、主要的缺点：因为 Swift 6 去年才首次亮相，所以没有大量的 Swift 6 代码供 LLM 进行训练，所以他们在生成 Swift 6 代码方面不如用其他语言生成代码，也不如为 React 等其他编程框架生成代码那么好。
Swift 6 中的新功能是更好的，但一位朋友向我描述它们时说“我认为 Swift 6 变化很小，但这小小的改变却有着巨大的影响。类似于从MRR 到 ARC 的转变。”这是对 2011 年 Objective-C 内存管理从手动保留/释放（MRR）到自动引用计数（ARC）的变化的引用。ARC 问世后，没有人愿意使用手动保留/释放编写新代码（这既乏味又经常导致内存泄漏错误）。但如果 LLM 在 2011 年就已经存在，他们就只能生成 MRR Objective-C 代码，因为这是他们所训练的所有 2011 年之前的代码所使用的。
我确信苹果公司所有应该关注这个问题的人都在关注这个问题。问题是，他们下周会公布解决方案吗？这整个领域——语言、框架和 LLM 时代的工具——是我下周参加 WWDC 时最关心的问题。