有一次只是改一个接口字段，我却在几个工具之间来回切换了快半小时，代码是在 VSCode 里改的。
因为项目里除了 Swift，还有 Flutter 模块和一些脚本文件。改完之后切回 Xcode 编译，测试包又交给自动化脚本处理，最后上传还得再打开另一个工具。
那天我突然意识到一件事很多开发者其实已经不再完全依赖 Xcode 了，准确一点说，不是“不用 Xcode”，而是开发流程正在被拆开。编辑器、编译器、构建工具和上传工具，开始分别承担不同职责。
很多人真正想替代的，其实不是 Xcode 本身
讨论Xcode 替代方案时，其实要知道开发者到底想替代什么？因为 Xcode 实际上包含很多部分、代码编辑、工程管理、编译构建、模拟器、真机调试、Archive、签名与发布，有些人想替代的是编辑体验，有些人想减少完整 IDE 的依赖，也有人只是想把不同技术栈放进统一工作流，因此现在的“替代方案”，很多并不是完全替代，而是在拆分其中某几个环节。
VSCode：最常见的一种替代
现在越来越多 iOS 开发者会用 VSCode 写代码。原因是很多项目已经不只是原生 Swift，还有Flutter、Node 服务、Shell 脚本、JSON 配置、Web 前端都可能在同一个仓库里。
如果所有内容都在一个编辑器中处理，开发上下文会更连续，Swift 插件、Git 插件以及 AI 辅助工具，也让 VSCode 在 iOS 项目中的使用频率越来越高，不过它更多是在替代“编辑器”这一层，真正涉及编译和运行时，很多项目仍然会回到 Xcode 工具链。
AppCode：JetBrains 风格的另一种路线
AppCode 曾经在大型 Objective-C 项目里很受欢迎，它提供更强的代码分析、更完整的重构能力、更好的大型工程导航，对于维护历史项目的人来说，这类 IDE 的体验会比较明显，不过它依然依赖 Xcode 的底层工具链，因此更像是“另一套开发界面”。
Flutter生态里的另一种工作流
跨平台项目越来越多之后，很多开发者其实已经在间接减少对 Xcode 的依赖。
例如Flutter UI 在 Android Studio 或 VSCode 中开发
Dart 调试在 Flutter 工具链里完成
只有最终构建时才进入 Xcode
这种方式下，Xcode 像一个构建节点，而不是整个开发中心。
自动化工具也在拆分 Xcode 的职责
以前很多事情只能在 IDE 里完成。
现在越来越多动作已经被脚本化：
Fastlane
负责自动构建、自动上传、自动发布 TestFlight，比如fastlane beta执行之后，可以直接完成一整套发布流程
GitHub Actions / Jenkins
进一步把编译、测试、构建放进自动化流水线，这意味着开发者不一定需要手动打开 IDE 完成所有事情。
开始重新整合工具链的新方案
当开发流程越来越碎之后，最近几年开始出现一些新的方向，不是继续拆工具，而是重新整合。比如快蝎（kxapp），，它和前面这些工具的思路不太一样，VSCode 更偏编辑器，Fastlane 偏自动化，AppCode 偏代码工程能力，而快蝎是在尝试把编辑、编译、真机运行、构建重新放回同一个环境里。
目前它支持wift 项目、Objective-C 项目、Flutter 项目，编辑器基于 VSCode 架构，同时内置了自己的 iOS 编译工具套装，代码修改之后，可以直接 构建应用、安装到设备、生成安装包，这种方式更像是在减少开发过程中不同工具之间的跳转。
现在再看Xcode 替代方案这个问题，会发现不是哪个软件能完全替代 Xcode，而是开发流程是否还需要把所有动作都集中在一个 IDE 中，有些团队会继续以 Xcode 为核心，也有人开始 VSCode 写代码、Fastlane 自动化、独立工具处理构建
或者直接使用整合型方案，不同项目会形成不同工作流。