背景 最近有一个产品需要在Apple AppStore 上架，算是所谓首审(initial review)。一直听说上架过程中有很多麻烦事，也确实看到过很多国内外开发者鲜活的被拒实例，各种吐槽审核机制的严格。由于苹果app审核流程这种「宗教和神」（可能言之有过）一般的存在，同时也衍生出了很多所谓中介帮快速过审的服务（类似黄牛代拍沪牌）。 这次主要谈一下审核过程中的遇到的一个问题，以下是苹果审核团队就此问题的邮件回复原文： We discovered one or more bugs in your app when reviewed on iPad/iPhone running iOS 11.2.2 on Wi-Fi connected to an IPv6 network. 大意就是在IPv6网络下，审核的人发现会出现问题。同时还可以获取到其文中所指的问题的体现截图，从截图看，确实是当时有需要联网获取的内容无法获取（或者还未获取到）导致的无法显示。 解决方案 如果你也收到了类似问题反馈，并且通过搜索引擎找到的本文，想要快捷的答案和解决方案而并没有太多耐心看完下文的话，那么我先在这里表述这个问题的正确解决方案： 根据文后参考文档中第一1、第二2篇检查自己的app实现，确定没有使用IPv4的IP显式建立IPv4的TCP,UDP socket的情况。因为在NAT64环境下，操作系统会将你的目标IPv4地址如 114.114.114.114 转换为 64:ff9b::114.114.114.114 发送到macOS模拟的节点，你写死了他就不干，具体有空请研读文后参考文档中的思科白皮书3和RFC文档4。另外检查通讯实现或者所用的第三方通讯库确实是使用了苹果推荐的高层级API：NSURLSession和CFNetwork中的API。最后使用第二篇中提及的IPv6 NAT64搭建方法搞一套测试环境确认app可用。 需要尝试从美国访问你的服务所在网络，测试可达性和性能如何。 千万不要听信国内很多坊间破解文去搭建真的IPv6 only的互联网服务5，你可能可以花费一些时间和费用搞出让纯IPv6环境用户也可以访问的服务，但是这并不是目前苹果要审核的内容，目前（2018年1月）苹果绝不会通过纯IPv6的互联网出口去测试访问你的服务并且要求可达。 以上是你真正需要去做的内容。 苹果提及的IPv6到底是怎么回事 IPv6网络从2011年、2012年那会儿谈及IPv4地址耗尽的事时开始就一直在大肆宣传要迭代转变，但是实际商用层面的转变速度非常慢，国外的很多ISP和IDC虽然在Infrastructure层面脚步更快一些，但是路离铺到用户家门口还会有一长段时间。根据思科的白皮书，目前我们可以接触到IPv6环境的方式大概有3种类型： Dual stack这种方式下你的接入商给了你同时支持IPv4和IPv6协议栈的网络， 针对有IPv6支持的服务，可以走v6，针对大部分还只支持v4的服务依旧走v4的协议。这种类型目前的普及率还很低，在国外部分ISP接入下已经实现，国内有些大学提供的互联网接入也是这样的。注意：此模式并非苹果测试审核环境的要求 Tunneling除了以上的第一种是纯ISP接入给用户时就提供有IPv6支持外，这里的Tunneling和下面的Translation都不需要ISP支持。从图示可以简单理解为即使ISP提供给你的是v4的接入，但是只要有其他第三方tunneling服务提供商给你提供4转6(6in4)的隧道服务，那么我们可以通过在即有的v4协议栈下模拟出v6的高层级协议栈（道理和VPN一样)。由此，如果提供此服务的那一头所连接的是整个实际互联网的IPv6世界的话，相当于让只有IPv4接入的你进入了纯IPv6的互联网（虽然那边目前犹如北极南极般荒凉）。注意：此模式并非苹果测试审核的要求，但是有些国内坊间误导文就让你一步步干这事 Translation这种模式也就是苹果在其开发者文档中提及的让你用macOS系统可以自己简单搭建一套纯IPv6的内网环境。你的macOS电脑作为NAT64地址转换和路由角色，一头（通常用有线）连接IPv4可以通向整个IPv4的互联网， 一头（通常用WIFI开hotspot）所谓的纯IPv6内网连测试iOS设备。既然如此，其实苹果的审核测试项也就是让通讯数据在iOS设备到macOS电脑这段跑在IPv6协议栈上而已，通过macOS的NAT64后一直到真正的服务所在设备该还是IPv4的大环境下还就是如此。事实上苹果的官文中也就这点特意很明确的表达过了： If you have a… Continue reading 苹果iOS app审核经验谈——IPv6