Apple 文档出了什么问题的一个具体例子
Apple 面向 macOS 和 iOS API 的官方文档被广泛批评为浅薄、不完整且难以浏览，尤其是像 SwiftUI 这样的新框架。开发者表示，哪怕只是做基础任务也会浪费数小时，于是转而依赖 LLM、第三方博客以及归档的“老 Apple”文档，这些旧文档曾经要详尽得多；也有人认为，这种情况源于 Apple 每年一轮的发布节奏、内部保密文化以及对技术写作的低优先级。另一些人则反驳说，只要理解面向对象模式并仔细阅读，这些 API 其实是能用的，但普遍担忧是，糟糕的文档正在损害生产力，并把开发者推向 AI 辅助工具和文档更好的替代平台。
将 LLM 作为 Apple 文档的替代方案
- 许多评论者表示，ChatGPT 以及类似工具如今成了他们学习 Apple API 的主要方式，尤其是 SwiftUI、macOS 和 iOS 框架。
- LLM 受到称赞，因为它们能快速找出模式、边缘情况技巧，以及 Apple 文档未提供的缺失示例。
- 也有人指出，对于受保护的内部代码库存在局限性，因为安全原因无法将代码粘贴到 LLM 中；面向企业的工具被提及为一种潜在解决方案。
Apple 文档的现状
- 普遍被认为内容稀少、缺少示例，并且经常遗漏关键行为细节（例如网络请求头、UIPickerView 的行为、table/stack 视图）。
- 文档经常把重要知识转移到 WWDC 视频中，很多人认为这不是一种可接受的参考形式，尤其是随着旧视频逐渐消失。
- 有人说 SwiftUI 的文档和教程按 Apple 的标准来说“很棒”，但对于非理想路径的使用场景仍然不完整。
历史上的衰退及原因（如线程中所讨论）
- 几位评论者回忆，早期的 Objective-C / Cocoa 文档以及 “Inside Macintosh” 时代的资料堪称典范，具备深入的概念解释和示例。
- 线程中将这种退化归因于：每年一次的操作系统发布节奏、Swift/Objective-C 双轨并行、缺乏专职技术文档写作者，以及管理层未将文档质量列为优先事项。
- 其他人则认为扩大文档团队并不容易：优秀的文档写作者必须是强开发者，难以招聘，而且往往得不到重视、薪酬也偏低。
API 设计、OOP 与可发现性
- 有人抱怨 “不必要地过度复杂” 的 OOP 设计和深层继承（例如 NSOpenPanel 继承自 NSSavePanel、UIKit 组件），这使得如果不沿着类层次结构追查，行为就不直观。
- 也有人认为这是用户的问题：任何使用 OO 框架的人都应该预期要通过 IDE 和父类来导航继承关系。
- 还有人反驳说，好的文档应该把继承行为显式展示出来，提供示例并讲解概念，而不是假设读者已经具备平台知识。
文档与 LLM 的未来
- 一派认为，传统的、全面的人工编写参考文档仍然必不可少（并以 Go 的标准库作为正面范例）。
- 另一派预测，文档将转向教程和可供 LLM 使用的注释，由 LLM 直接生成答案，而不是由人类撰写穷尽式参考文档。
- 也有人担心，随着 LLM “足够好用”，投入高质量官方文档的动力会进一步减弱。
平台对比与退出决策
- 有些人认为 Apple 仍然比 Windows 或 Android 更好；也有人说，糟糕的文档和复杂的 API 让他们完全放弃了原生 Apple 开发。
- Flutter 的文档被拿来作为一个有力反例，其跨平台 API 更清晰，参考资料也更好。