Appium在iOS14.4真机上运行WKWebView场景XCUITest需要特殊配置吗？

第一优先级（90%概率命中）：真机包签名权限配置错配 #

模拟器环境下系统默认放开所有调试相关的沙盒权限，所以同一份代码打出来的模拟器包、真机包，webview的可调试属性根本不在同一规则下，这是当前场景下最容易踩的坑：

• iOS真机系统默认拦截外部进程对第三方App的WKWebView的读取权限，只有当安装包的 entitlements 配置里开启 com.apple.security.get-task-allow 权限时，WDA、ios-web-driver-proxy 才能枚举到应用内的webview上下文。日常打正式包、AdHoc分发包时，这个权限会被签名流程自动关闭——这个权限关闭完全不影响App正常运行，但会直接切断所有调试工具对webview的访问通道。
• 验证方法：直接用Debug模式重新打包App，配套的描述文件显式开启get-task-allow权限，生成.ipa安装到真机上跑测试。如果打完包之后能正常识别webview，即可100%定位为该问题。
• 之前测试Safari远程调试正常的结果无参考价值：Safari是系统自带应用，永久开放调试权限，和第三方App的沙盒规则没有任何可比性。

第二优先级（7%概率命中）：Appium1.20.2版本的固定逻辑bug #

这个版本的真机适配存在已知缺陷，正好对应用户之前调整超时完全没有效果的现象：

• 版本内置的 webviewConnectTimeout 参数，逻辑上只会等待WDA自身的启动完成，根本不会延长对App内WKWebView调试端口的等待时长。真机环境下WKWebView的调试端口注册速度比模拟器慢得多，哪怕把超时值拉到2分钟，WDA刚启动完成就立刻扫描端口时，webview的调试接口还没完成注册，自然返回空的上下文列表。
• 临时解决逻辑：调用 getContexts() 之前增加固定等待，等App完全加载、webview内容渲染完成后再执行枚举操作，不需要特意把全局超时拉到很长。
• 额外踩坑点：这个版本在真机上如果不给 webviewDebuggerProxyPort 配置固定端口，系统会随机给iwdp分配端口，哪怕webview的调试权限全开，也会因为端口匹配不上扫不到组件，编写capabilities时必须给这个参数指定一个固定的空闲端口值。

第三优先级（3%概率命中）：易遗漏的配置细节 #

• 检查WKWebView本身的可调试开关：iOS14之后，第三方App的WKWebView默认关闭 isInspectable 属性。模拟器环境下Xcode的Debug配置会自动把这个属性打开，但Release模式的真机包不会默认开启。验证方法：在真机上打开应用的webview页面，长按内容区，如果弹不出来“检查元素”的选项，说明代码里没手动将webview的isInspectable设为true，哪怕签名权限全对，系统也不会把webview暴露给调试工具。
• 手动排查iwdp的扫描能力：把真机的27753服务端口映射到本地，直接读取本地的webview调试列表。如果读出来是空列表，就说明前述的签名权限、isInspectable配置存在问题；如果能正常读到webview列表，就说明是Appium和iwdp之间的端口匹配错了，和webview本身的权限无关。

内容的提问来源于stack exchange，提问作者Patrick Ramser