那个页面的问题其实不复杂，一个列表在 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 架构
  • 内置编译工具套装
  • 可以直接真机运行
  • 提供安装包构建能力

这里比较关键的是，它没有把“编辑”和“编译”拆成两个独立环境，代码修改之后，可以直接进入构建和设备验证流程，于需要频繁调试页面或者维护多个项目的人来说，这种设计会比较容易保持开发连续性。

工具的价值，不一定体现在功能数量上

很多时候，一个工具真正有用的地方，不是它多强，而是它是否减少了重复动作。例如少打开一个窗口、少切换一次环境、少执行一遍重复命令，这些细节单独看都不大，但它们会不断累积。

尤其是在一个页面需要反复调试的时候，开发者会越来越明显地感受到工具链本身对节奏的影响。