现象
我们的App已经完成了NA部分的ATS适配。
网页端由于有使用到第三方的页面，所以开启了网页的豁免权限。
关于如何开启豁免及方法，可以参考喵神的Blog
最终，我们的适配参数为：
NSAllowsArbitraryLoads: YES
NSAllowsArbitraryLoadsInWebContent: YES
但是，在访问一些Https先行者的网站（如：移动营业厅）时，却出现了网页无法正常访问的情况。
且这种情况只出现在iOS 10.0(.x)，及10.1(.x)上，iOS 10.2上就没有问题。
分析
这种情况在做NA Https化的时候也遇到过，通常是和证书有关系。
于是做了以下实验：
- 用Chrome浏览器查看证书详情，发现使用的加密算法，浏览器输出加密算法比较旧。
- 通过NSCurl的检测也发现这个网址确实不符合ATS的要求。(NSCurl使用参考网址)
- 开启整个APP豁免ATS，这个页面是可以正常访问的。
说明虽然之前我们的App要求了网页的ATS豁免，但是在iOS 10.0(.x)，及10.1(.x)并未生效。
顺着这个思路，终于找到了苹果论坛的一个帖子，这是个系统bug……讨论得挺热烈的。
最后苹果工作人员给出建议：
The obvious workaround would be to continue to use NSAllowsArbitraryLoads until this problem is resolved.
You should also contact the site owner: the level of security for that site is way below what I would expect to see on the modern Internet.
如此，如果你的App用到了先驱网站又想想覆盖iOS 10.0/10.1的系统，只剩下NSAllowsArbitraryLoads一条路可走了。
然后记得用联通手机打电话给移动“你们的网站安全级别太低了，赶紧给上帝（laozi）升级！”
设想苹果推行ATS的未来
通过这个事件，苹果估计得更改一下他们推行ATS的计划了。
那么多做HTTPS的先驱，他们用的算法各异，只要我们的网页中有跳转到这些先驱网页的可能，就必须开启网页的豁免。如果开启这个就必须做NA的ATS化。
再加上iOS 10.0/10.1的这个bug，NSAllowsArbitraryLoadsInWebContent也用不得了，就剩下和iOS 9一样的NSAllowsArbitraryLoads设置为YES才能让iOS 10.0/10.1上可以正常访问先驱网页。
2016年末苹果说会推迟ATS强制执行的时间。
iOS 9发布后到iOS 10苹果想出了个新的Key解决ATS豁免问题。
现在新Key不能用了。看来这一推迟，怎么也得到下个大版本之后了。