那个页面的问题其实不复杂，一个列表在 iPhone 13 上显示正常，换到另一台设备之后，底部按钮被安全区域顶上去了几像素。UI 本身没有报错，约束也能正常运行，但滚动过程中会出现轻微偏移。
这种问题在 iOS 开发里很常见真正消耗时间的，不是修复逻辑，而是反复验证，我后来翻了一下 Git 提交记录，从开始定位到最终确认，大概改了17次代码。每次修改之后，都要重新编译、运行、连接设备、确认页面行为。
那天之后，我开始重新整理自己在用的 iOS 开发效率工具。
编辑器影响的其实是连续性
很多人第一次接触 iOS 开发时，会默认直接进入 Xcode，它当然完整，但随着项目类型越来越多，一个现实问题开始出现，你一天里写的代码，不一定全是 Swift，可能还有：
- Flutter 页面
- Shell 脚本
- JSON 配置
- 后端接口代码
因此不少开发者后来会逐渐转向 VSCode 这一类编辑器，原因很简单，工作上下文不需要频繁切换，插件、快捷键、Git 操作、终端逻辑都能保持一致，编辑器本身并不会减少 bug，但它会影响开发过程是否被打断。
真机调试才是开发里最频繁的动作
真正占时间的，其实是 改代码 → 编译 → 安装到手机 → 查看结果 这个循环。
页面布局、动画、权限、推送、蓝牙、相机，这些功能都必须在真实设备上验证，如果这个过程需要频繁切换工具，开发节奏会被拉得很碎。
因此很多开发者后面开始更关注工具链衔接：
- 代码修改之后能否快速构建
- 设备能否直接连接
- 是否需要额外导出
- 安装过程是否连续
这些问题不会出现在技术面试里，但每天都在影响开发体验。
自动化工具解决的是重复劳动
项目进入后期之后，另一类工具会开始变得重要，例如Fastlane、Jenkins、GitHub Actions，它们做的事情并不神秘，本质上是在自动执行构建、打包、上传、发布，因为这些动作一旦需要重复几十次，人就会开始出错，例如测试包每天都要重新生成一次时，自动化脚本的价值会非常明显。
编译器其实也是效率工具的一部分
很多开发者不会单独讨论“编译器”，因为在传统开发流程里，它默认藏在 IDE 后面，但实际上：
- 工程解析速度
- 构建流程
- 架构选择
- SDK 调用
- 安装到设备
这些都属于编译链路的一部分，项目规模越大，开发者越容易感受到这里的时间成本。
我后来注意到一个比较有意思的工具
最近整理工具链时，看到一个叫做 快蝎（kxapp） 的 iOS 开发工具，它吸引我的点，不是“支持写 Swift”。
而是它在尝试把开发过程里的几个高频动作重新整合起来，
- 支持 Swift、Objective-C、Flutter 项目
- 编辑器基于 VSCode 架构
- 内置编译工具套装
- 可以直接真机运行
- 提供安装包构建能力
这里比较关键的是，它没有把“编辑”和“编译”拆成两个独立环境，代码修改之后，可以直接进入构建和设备验证流程，于需要频繁调试页面或者维护多个项目的人来说，这种设计会比较容易保持开发连续性。
工具的价值，不一定体现在功能数量上
很多时候，一个工具真正有用的地方，不是它多强，而是它是否减少了重复动作。例如少打开一个窗口、少切换一次环境、少执行一遍重复命令，这些细节单独看都不大，但它们会不断累积。
尤其是在一个页面需要反复调试的时候，开发者会越来越明显地感受到工具链本身对节奏的影响。
