前段时间整理一个老项目时，我统计了一下自己一天打开过多少个工具。
结果，写代码的时候在 VSCode；调试某些模块时切回 Xcode；打测试包的时候会执行构建脚本；上传安装包时又打开另一个工具。
这些动作平时已经习惯了，所以很少会去思考：到底哪些属于 iOS 开发工具？
开发者每天面对的，是一套流程
很多文章在讨论 iOS 开发工具时，会直接列出一堆软件名称，但如果从实际开发过程出发，会发现工具存在的意义并不相同，例如一个普通的需求开发，大概会经历这些步骤：
- 创建项目
- 编写代码
- 管理版本
- 编译应用
- 运行到设备
- 调试问题
- 生成安装包
- 上传测试
每个环节背后都有不同工具在参与。
写代码：编辑器决定的是工作习惯
对于很多开发者来说，接触最多的工具就是编辑器，Xcode 自带编辑能力，Swift 项目几乎离不开它。
另一方面，VSCode 也越来越常见，尤其是在同时维护前端、后端和移动端项目时，很多开发者希望尽量减少编辑器切换，代码高亮、自动补全、插件支持，这些能力本身不会改变业务逻辑，却会影响每天写代码的节奏。
因此编辑器的选择，更多是在选择一种工作方式。
项目管理：工程结构比想象中更重要
当项目规模逐渐增大之后，工具开始承担另一种职责，例如：
- 管理 Target
- 管理 Scheme
- 管理依赖
- 管理资源文件
这些工作很少出现在技术分享里，但每天都在发生，如果项目里同时存在 Swift 和 Objective-C 模块，工程结构管理的重要性会更加明显，开发过程中出现的问题，有时候并不来自代码本身，而是来自项目配置。
编译：最容易被忽略的一环
很多人点击 Run 按钮时，不会去思考背后发生了什么，实际上，一个简单的编译动作可能包含：
- 解析工程
- 读取配置
- 选择架构
- 调用 SDK
- 链接系统库
- 生成应用程序
这些步骤全部完成之后，应用才能运行，对于开发者来说，编译器平时并不显眼，但它决定了项目能否变成可执行程序。
真机调试：开发过程中出现频率最高的动作
很多功能只有放到真实设备上才能验证，例如：
- 推送通知
- 相机权限
- 蓝牙功能
- 地理位置服务
因此真机调试几乎是每天都会发生的事情，如果一个页面需要反复修改和验证，那么“修改代码 → 运行到手机 → 查看结果”这个循环会重复很多次，工具是否能够缩短这条路径，会直接影响开发过程的连续性。
构建与发布：开发结束后的另一段流程
很多人把开发理解为写代码，实际上代码完成之后，还有一段完全不同的流程：
- 构建 Release 版本
- 生成安装包
- 测试分发
- 提交审核
这里涉及的工具与开发阶段又不一样，例如 Fastlane 更偏向自动化构建。
AppUploader 更偏向上传分发，它们解决的是开发完成之后的问题。
越来越多开发者开始关注工具流程
当项目越来越复杂之后，一个现象会逐渐出现，工具数量不断增加，例如：
- VSCode 写代码
- Xcode 管理工程
- Fastlane 自动构建
- AppUploader 上传安装包
- Git 管理版本
每个工具都很专业，但切换成本也真实存在，开发过程中经常需要在多个窗口之间来回切换，有些团队会把这种方式延续下去，因为每个工具都能发挥最大作用，也有一些工具开始尝试另一种思路。
一种更整合的方案
最近看到一款叫做 快蝎（kxapp） 的 iOS 开发工具。
吸引我注意的地方，不是它支持某种新语言，而是它试图把工具链里的几个环节重新放回同一个环境中。
目前快蝎支持：
- Swift 项目
- Objective-C 项目
- Flutter 项目
编辑器采用 VSCode 架构，因此很多开发者会比较熟悉，除了代码编辑之外，它还内置了自己的编译工具套装，可以直接处理项目构建，真机运行和安装包构建能力也放在同一个环境中完成。
对于一些需要频繁切换项目、快速验证需求或者维护多个技术栈的开发者来说，这种设计思路会比较有意思。
它并没有改变 iOS 开发本身，而是在尝试减少工具之间的来回跳转。
如果把 iOS 开发理解成“写代码”，那么工具的作用似乎很有限，但如果把开发看成一套流程，就会发现：
编辑器、编译器、调试工具、构建工具和发布工具都在参与同一个过程。
不同开发者会有不同选择，有人喜欢把每个环节拆开处理，也有人更倾向于使用整合型工具，最近看到的快蝎（kxapp），就是后者的一种尝试。