背景
最近有一个产品需要在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 server running on the wider Internet, it is not necessary to update your server immediately. Your server will be accessible to IPv6-only devices via DNS64/NAT64.
由此，所以我上文说国内坊间的各类快餐文千万不要去看，更加不能照做。
开始实验
好，以上解决方案也给了，IPv6的简单技术解释也说了，这些基本和国内快餐文区别不大， 无非摆了一些或者很多 苹果啊、思科啊的巨头洋文出来看着有点吓人，似乎高大上，怎么知道是不是真的呢，或者说是切题的呢？所谓Computer Engineering么，直接拿家伙出来实验呗。
针对第三种模式： Translation， 也就是确实正确的苹果审核时的场合环境， 直接照开发者文档指导走通即可， 如果你的app已经可以走通，那么说明你的审核问题完全不在app中的网络通讯代码上。
环境搭建
这里我的实验内容是Dual Stack和Tunneling。这南墙我撞一下给大家看。由于我无法从ISP处拿到纯IPv6接入，所以用了一台有IPv4互联网接入的router通过H.E(著名运营商：飓风)的IPv6 Tunneling服务获得虚拟的IPv6接入。而后将一台iOS设备接入此路由器，那么从这台iOS设备的角度，似乎他以为自己获得了Dual Stack的环境。
实验内容
实验全程，我通过iOS 11自带的录屏记录了下来，毕竟看文字描述太累，流量不是问题就跳到下一小节看视频吧。
首先我让这台iOS设备只连接IPv6，关闭IPv4，也就是所谓的真正的IPv6 only internet network了。在此环境下，只有极其极其少数的精英级服务可以访问：Google, Facebook等。国内主流诸如微信完全没戏。所以苹果审核绝对不会在这样的环境去测试你的app，不然能符合要求的app可能就只有个位数了。题外话：我倒希望苹果真的那么极端激进，毕竟这才是推进整个世界革命的激进，而不是去掉个3.5mm耳机孔。
然后我打开iOS设备的IPv4，使之状态变成v4 v6双协议栈同时支持，这下自然网络就四通八达了。
实验视频
References:
本文参考以下文档，来源互联网，版权归各源所有，此为引用
- 苹果官方的关于提交审核需要支持IPv6网络的文档. 来源：Apple. Supporting IPv6-only Networks ↩
- 苹果开发者文档中关于NAT64环境的技术简单描述及如何简单搭建开发测试环境. 来源:Apple Supporting IPv6 DNS64/NAT64 Networks ↩
- 思科官网关于NAT64技术的白皮书. 来源： Cisco. NAT64 Technology: Connecting IPv6 and IPv4 Networks ↩
- IETF 官网的RFC 6052 文档：在IPv4/IPv6 地址转换中的IPv6 地址命名. 来源：IETF. IPv6 Addressing of IPv4/IPv6 Translators ↩
- 国内坊间误导文之一. 来源: CSDN. aliyun支持ipv6的配置-苹果审核被拒的的破解之道 ↩
