测试同事反馈说，应用第一次安装后没有弹出推送授权窗口。我一开始以为是接口时序问题，后来才发现，问题只会在真实设备上出现。
模拟器里一切正常。也是那次排查过程中，我重新整理了一遍现在常见的 iPhone 真机调试方法，因为很多 iOS 功能，本来就只能在设备上验证，比如推送通知、蓝牙、相机、Face ID、后台定位、Apple 登录这些功能

这些行为涉及系统权限和真实硬件，模拟器并不能完全覆盖。

Xcode 直连调试：目前最常见的一种方式

大多数 iOS 开发者接触的第一种真机调试方式，就是 Xcode。

连接 iPhone 之后选择设备 -> 点击 Run、IDE -> 自动构建并安装应用

调试过程中还能直接查看 控制台日志、崩溃信息、内存占用、网络请求，这种方式的优势是完整。

工程管理、编译、调试都在同一个环境里完成，不过当项目越来越复杂之后，有些团队会开始把开发流程拆开。

使用 TestFlight 做真实环境验证

有些问题并不适合通过开发包调试，例如 审核环境差异、Release 配置行为、真实用户权限流程，这时候很多团队会通过 TestFlight 分发测试版本，流程大概是 构建 IPA → 上传 App Store Connect → TestFlight 安装

这种方式更接近正式环境，但缺点也很明显，每次修改之后都需要重新构建和上传，如果只是调试 UI 或接口，整个反馈流程会比较长。

无线调试：减少设备连接动作

后来 Apple 增加了无线调试，设备首次连接之后，可以通过局域网继续调试，对于频繁测试页面布局或者动画的人来说，这种方式会减少很多插拔数据线的动作，不过它仍然依赖完整 IDE，构建和安装流程并没有改变。

使用日志工具辅助真机问题排查

有些问题不会直接导致崩溃，例如某个接口字段为空、后台状态切换异常、权限状态不一致，这时候很多开发者会额外使用：

Charles

用于 抓包、查看请求、分析接口响应

Console.app

用于 查看设备系统日志、分析运行状态

这些工具不会直接运行应用，但会帮助定位真机行为。

Flutter 与混合项目里的调试方式

跨平台项目出现之后，真机调试流程也发生了一些变化。

例如 Flutter 项目会使用"flutter run"直接安装并运行到设备，热重载会缩短页面验证时间，但当项目同时包含 Flutter、Swift、Objective-C之后，开发流程会开始变得复杂，有些修改仍然需要重新进入 iOS 构建流程。

开始重新整合真机调试流程的工具

最近几年开始出现一些新的 iOS 开发工具，不再把“编辑”“编译”“真机运行”完全拆开，最近看到一个快蝎（kxapp）。它比较特别的一点在于真机调试能力直接放在 IDE 内部目前支持 Swift 项目、Objective-C 项目、Flutter 项目

代码修改之后，可以直接 构建、安装到 iPhone、真机运行，编辑器基于 VSCode 架构，同时内置了自己的 iOS 编译工具套装，对于需要频繁修改 UI、调试交互或者验证权限行为的人来说，这种方式会减少开发过程中的工具切换。

真机调试的问题就是反馈速度

不同工具都在解决这个问题，有人会选择 Xcode 直连调试、TestFlight 验证真实环境、Flutter 热重载，也有人开始尝试整合型工作流。