接手一个 iOS 项目的时候，开发机上的跑分和功能验证都过了，发出去用户就开始报问题——某个 iOS 15 的机型上布局错位、某一批 iPhone 上闪退、某个旧系统版本上功能点了没反应。这类问题很难在单一设备上复现，因为 iOS 的碎片化不像 Android 那么明显，但实际上不同系统版本、设备型号和硬件配置之间的差异一直在那。
兼容性问题的来源
系统版本层面，iOS 17 对隐私权限的收紧可能影响功能调用，iOS 16 前后的推送机制也不一样。设备型号的差异更隐蔽——刘海屏和灵动岛的状态栏高度不同，不带 LiDAR 的机型上依赖深度传感器的功能直接不可用。CPU 架构从 arm64 到 arm64e 的过渡期里，某些第三方库在特定机型上编译行为不一样。这些差异在单一设备上根本看不出来。
先用模拟器做快速筛查
兼容性验证的第一步不会直接上真机。Xcode Simulator 提供了一个快速筛选的手段，尤其是针对不同系统版本的 UI 适配。模拟器里可以同时开几个不同 iOS 版本的实例，快速过一遍核心功能页面的布局和交互流程。比如在 iOS 16 和 iOS 17 的两个模拟器上分别跑一遍登录注册流程，看看权限弹窗的表现是不是符合预期。这一步能筛掉大概百分之六七十的明显兼容性问题。
模拟器覆盖不到的方面是硬件相关功能——相机、传感器、真机特有的 API 行为。这些只能交给真机验证。
真机验证的覆盖策略
真机测试不可能买齐所有机型。覆盖策略是按设备特征分维度：不同系统版本（选最新的、次新的、两年以上的）、不同屏幕形态（刘海屏、灵动岛、带 Home 键的传统屏）、不同 CPU 架构（至少一台 arm64e）。
把一台设备连接到电脑之后，第一步是确认这台设备的完整硬件和系统信息。用 KeyMob 连接设备后打开设备信息面板，能直接看到系统版本、硬件型号、CPU 架构、销售地区、设备类型这些关键参数。比如在兼容性测试记录里列出每台测试设备的信息——iPhone 14 Pro Max 跑的是 iOS 17.5、arm64e 架构、销售地区是中国，这样后续排查问题的时候能快速定位到"这个 bug 只出现在 arm64e 设备上"还是"只出现在某个地区的固件版本上"。设备信息的完整采集是兼容性测试的基础，否则出了问题很难回推。
安装测试包也有一些值得注意的细节。KeyMob 支持直接从电脑安装 IPA 到设备上，不需要经过 Xcode 或 TestFlight。测试多个版本或功能分支的包时，直接在设备上安装、启动、看运行日志，比每次都走 Xcode 部署快很多。安装后还能查看 app 的 MinimumOSVersion、签名身份、entitlements 授权列表——排查"为什么这个包在老系统上装不上"的时候，问题经常出在最低系统版本设太高，或者某个 entitlement 只在特定系统版本上可用。
用 TestFlight 扩大覆盖
自己手头的设备再全也有限。TestFlight 是扩大覆盖面的一个常规手段——发布内测版本让真实用户在不同设备上跑。TestFlight 的优势不在于帮你找 bug，而在于它能覆盖到你自己没有的那些设备组合。一个有意思的做法是，在 TestFlight 的反馈收集中专门标注设备型号和系统版本，让用户提交问题时附带这两项信息。积累一段时间之后，可以看看哪些设备组合在 crash report 里反复出现，把那些缺失的设备补到本地验证的覆盖范围里。
云测平台作为补充
还有一些情况手头没有对应设备——用户用三年前的机型跑最新的 iOS，或者国内厂商的设备搭配特定运营商固件。这时可以用 Firebase Test Lab 或 AWS Device Farm，上传 IPA 后在远程真机上跑核心用例。技巧是不必跑完整自动化测试，手动指定几台目标设备跑安装和启动流程就够了——很多兼容性问题在安装或首页加载阶段就已经暴露了。
一个可落地的验证流程
结合前面的思路，一个最终的兼容性验证流程大概是这样：新版本提测后，先在 Xcode Simulator 上跑三个 iOS 版本的 UI 筛查，半天内能做完。然后用手头的真机，用 KeyMob 查看每台设备的完整信息并记录到测试台账，安装测试包后逐台跑核心功能，同时打开实时日志观察异常输出。这一步一般一到两天。之后发 TestFlight 内测版本，收集一到两周的用户反馈。如果有特定机型的兼容性问题被报上来，再通过云测平台定向验证和修复。