先贴原文地址:https://forums.developer.apple.com/thread/48979#146140
原文:
eskimoAug 2, 2016 4:17 AM(in response to RLKingSoftware)
First up, there have been no changes to the technical behaviour of ATS (other than the addition of NSAllowsArbitraryLoadsInWebContent and NSRequiresCertificateTransparency). From a technical perspective, ATS exceptions in the newly seeded OS releases work the same way as they do in the current OS release.
What has changed is that App Review will require “reasonable justification” for most ATS exceptions. The goal here is to flush out those folks who, when ATS was first released, simply turned it off globally and moved on. That will no longer be allowed.
The impact of this will depend on the circumstances of your app. I don’t work for App Review, so I can’t give definitive answers as to what constitutes a “reasonable justification” in their minds. However, I can recommend that you do the following:
watch the WWDC session where we announced this change (WWDC 2016 Session 706 What’s New in Security) so that you can get a feel for the rationale behind it
carefully audit your app’s use of HTTP and HTTPS
construct a minimal ATS exception dictionary
if you have ATS exceptions, keep notes about your analysis so that you can refer back to them when you need to submit your justification to App Review
Finally, if there are places where ATS has limitations that cause you to specify wider exceptions than one might reasonably expect, file an enhancement request against ATS for more appropriate exceptions. Make sure to note the bug number to use in your justification. And I’d appreciate you posting your bug number here, just for the record.
[I’ve removed the following example because we introduced NSAllowsLocalNetworking in iOS 10.0b4, partly based on the feedback we got from developers like you. Thanks everyone! OTOH, the general advice from the previous paragraph still stands.]
For example, right now ATS has very poor support for dealing with accessories on the local Wi-Fi. An app that needs to deal with such an accessory may well need to set NSAllowsArbitraryLoads. In that case, it would be wise to file a bug that describes your app’s requirements and requests better support from ATS, and use that bug number as part of your justification.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = "eskimo" + "1" + "@apple.com"
谷歌直翻译文:
首先，ATS的技术行为没有改变（除了添加NSAllowsArbitraryLoadsInWebContent和NSRequiresCertificateTransparency）。从技术角度来看，新种植的OS版本中的ATS异常的工作方式与当前操作系统版本中的相同。
改变的是，应用程序审查对大多数ATS异常需要“合理的理由”。这里的目标是清除那些谁，当ATS首次发布时，只是把它全球关闭，继续前进。这将不再允许。
这将取决于您的应用程序的情况。我不为App Review工作，所以我不能给出确定的答案，什么构成一个“合理的理由”在他们的头脑。但是，我建议您执行以下操作：
观看我们宣布此更改的WWDC会议（WWDC 2016会议706安全性的新增功能），以便您可以了解其背后的理由
仔细审核您的应用程序的HTTP和HTTPS的使用
构造最小ATS异常字典
如果您有ATS异常，请记录您的分析，以便您可以在需要向App Review提交您的理由时参考它们
最后，如果有某些地方ATS有限制，导致您指定比合理期望的更宽的例外，请针对ATS提出增强请求以获得更合适的例外。确保记下在您的理由中使用的错误号。我很感谢你在这里发布你的bug号码，只是为了纪录。
[我删除了以下示例，因为我们在iOS 10.0b4中引入了NSAllowsLocalNetworking，部分基于我们从像您这样的开发人员那里获得的反馈。感谢大家！ OTOH，上一段的一般建议仍然存在。]
例如，现在ATS对于处理本地Wi-Fi上的附件的支持非常差。需要处理这样的附件的应用程序可能需要设置NSAllowsArbitraryLoads。在这种情况下，明智的做法是提交一个描述应用程序需求的错误，并请求ATS提供更好的支持，并使用该错误编号作为您的理由的一部分。
分享和享受
- -
Quinn“爱斯基摩！
苹果开发人员关系，开发人员技术支持，核心操作系统/硬件
let myEmail =“eskimo”+“1”+“@ apple.com”