加载失败
这条帖子讨论的是 Swift language support 扩展从官方 VS Code marketplace 转到 Open VSX Registry（面向 VS Code forks 的开源扩展仓库）后，Cursor（基于 VS Code 的 AI 编辑器）等工具终于可以直接安装。背景是 Microsoft 之前限制 forks 访问官方 marketplace，所以用户只能手动下载 .vsix 侧载，社区把这次变化看作安装体验的修复，而不是 Swift 本身第一次可用。评论进一步把话题分成两层：纯 Swift 代码编辑相对容易，而 iOS/SwiftUI 开发会牵涉 Xcode（Apple 的 IDE）、xcodebuild、预览和苹果工具链，因此常靠 LSP、xcode-build-server、sweetpad、sourcekit-bazel-bsp 之类桥接方案。与此同时，很多人怀念 JetBrains 的 AppCode（面向 Apple 开发的 IDE），认为它的消失让 Swift/iOS 开发体验明显变差。
这次变化最直接的好处，是 Swift 扩展终于能通过 Open VSX Registry（面向 VS Code forks 的开源扩展仓库）正常安装到 Cursor（基于 VS Code 的 AI 编辑器）等编辑器里。有人指出，之前因为 Microsoft 禁止 forks 访问官方 marketplace，用户只能手动下载 .vsix 再侧载，流程很别扭。评论因此认为标题有点夸张：Swift 一直能用，真正变化的是安装和分发方式变顺了。
不少评论把焦点放在“Swift 支持”到底覆盖到哪一层：大多数人认为这只是纯 Swift 语言开发，不等于完整 iOS 开发。有人提到可以通过 LSP（Language Server Protocol）接入非官方方案，例如在 Bazel iOS 项目里用 sourcekit-bazel-bsp，或者用 xcode-build-server 解析 xcodebuild 日志，把构建信息转成 LSP 供编辑器使用。也有人已经用 sweetpad 之类工具给 VS Code 补 iOS 工作流，说明真正缺的往往是 SwiftUI 预览、语言检查、工程索引等一整套集成，而不只是高亮和补全。
另一条很强的情绪线，是对 AppCode 退出后的遗憾。有人说 JetBrains 失去 AppCode 是继续写 Swift 的巨大打击，因为 Xcode 的体验、键盘快捷键和工作流都不如自己习惯的 JetBrains IDEs。也有人直接希望 iOS 开发能进一步开放，好让 AppCode 重新回来，核心诉求其实是找回熟悉、顺手的开发环境。
有评论提出一个更极端的愿望：希望有一个开源的 Swift IDE，能够在运行时自我修改，而不必重启。发言者把这种能力类比到 Oberon 系统里的可组合式 IDE 文化，显然追求的是“工具本身也是可编程对象”。回应则认为这个要求非常小众，基本只能自己动手做一个，现成方案几乎不可能满足。
讨论中还短暂转向了平台是否一定要绑定官方 IDE 的问题。有人拿 Android Studio 作类比，认为 Android app 开发也离不开官方工具；但反驳很快指出，Android 的 build tools 实际上是开放且跨平台的，真正问题未必是构建系统，而是某些 IDE 集成体验。这个插曲把 Swift 话题扩展成了更普遍的争论：开发者想要的是 IDE 自由，还是平台专属的一体化体验。
Open VSX Registry: 面向 VS Code forks 的开源扩展仓库，用来分发和安装扩展。
.vsix: VS Code 扩展包文件格式，常用于手动安装扩展。
LSP: Language Server Protocol，编辑器通过它获得补全、跳转、诊断等语言智能。
SwiftUI: Apple 的声明式 UI 框架，通常和 Xcode 的工程构建、预览能力深度绑定。
xcodebuild: Xcode 的命令行构建工具，常被脚本和外部工具用来提取编译信息。
AppCode: JetBrains 曾经面向 Apple 开发的 IDE，常被拿来和 Xcode 对比，也已停止更新。