iOS 9 适配系列－快速获取URL Scheme的改变

Quick Take on iOS 9 URL Scheme Changes

[UPDATE #2: I have independent confirmation from several sources that these limitations are meant to only apply to “canOpenURL” and it is a bug that they are also effecting “openURL”. There are still implications, and many apps will need some updates, but that’s not so dramatic a change.]

[更新＃2：我从几个来源独立确认这些限制是为了只适用于“canOpenURL”，它是一个错误，它们也影响“的OpenURL”。还有影响，很多应用程序都需要一些更新，但事实并非如此戏剧性的变化。]

[更新：我越觉得这件事，得到的人在Twitter上的反馈，我越觉得上“的OpenURL”这些限制是一个错误。它会打破太多的东西（如登录流程为Facebook/ Dropbox的）。仍然有从独自canOpenURL的变化，但可以克服那些显著副作用。]

在会话703，“隐私与您的应用程序”，在WWDC2015（视频），苹果讨论了变化影响的URL方案在iOS9 URL通过我的一些应用程序的广泛使用，所以这引起了我的兴趣。这篇文章是我所理解的变化及其影响的快速摘要。其中的一些可能最终被证明是错误或iOS的9的最终发布前更改，但我想我会得到讨论继续下去。

What are URL schemes?

我不会试图去定义URL，但我只想说的网址导航是在互联网上的重要组成部分。你可能很熟悉网页的网址，如“http://apple.com”。一个URL的第一部分，该部分冒号前，是URL方案。该方案用于识别理解的URL所要求的服务的类型，和大多数操作系统具有一个机构，用于应用程序注册它们能够与某些URL方案开口网址。常见的例子是网络浏览器注册，打开“http”和“https”开头的URL方案，使网络链接将在浏览器中打开。

IOS拥有自己的登记的URL方案以及系统。一些URL方案，如“http”和“电子邮件地址”是由苹果保留指向自己的Safari浏览器和邮件应用程序，但是从App Store安装的应用程序可以注册以处理其他任意URL方案。像这样的自定义URL方案被用于各种目的而使用的许多应用程序。一个常见的用途是为一个特定内容内的应用程序深层链接- 看作是一个“开放的应用程序”，从一个网页链接。

因为对于应用彼此iOS上进行通信的有限可用信道，网址已用于曝光的应用程序之间的功能良好。 iOS的自动化社区已经建立在URL方案之上的功能了大量让应用程序提供服务，数据转发给其他应用程序，或者干脆启动其他应用程序。如果使用草稿，发射中心临，工作流和其他许多应用程序，你正在使用和受益于iOS上的URL方案。

What is Apple Changing?

关于修订iOS中9 URL方案的关键位是隐私和您的应用程序会话，开始在周围的标题为“应用程序检测”下的9分钟大关。

有可应用在iOS被实现2的URL相关的方法：canOpenURL和的OpenURL。这些都不是新的方法和本身不改变的方法。正如你可能期望从名字，“canOpenURL”返回一个肯定或检查是否有安装知道如何处理一个给定的URL中的设备上的任何应用程序后，没有回答。 “OpenURL”用于实际发射的网址，这将典型地离开该应用和其他应用中打开该URL。

直到iOS的9，应用软件已经能够调用任意URL的这些方法。开始在iOS9，应用程序将不得不宣布他们将什么样的URL方案希望能够检查和开放的应用程序的配置文件，因为它被提交给苹果公司。这基本上是只能被改变或添加到提交的更新，苹果白名单。看来，某些共同的网址通过系统的应用程序来处理象“http”，“https”开头，也不需要明确列入白名单。

我已经测试了这些限制在Xcode7与最初的iOS9测试版发布前，结果如下：

1.如果你调用一个URL，它是不在你的白名单中的“canOpenURL”的方法，它将返回“NO”，即使是安装一个应用程序，已注册来处理此方案。 一个“这个程序是不允许查询计划XXX”系统日志条目将出现。

2.如果你调用一个URL，它不是在你的白名单中“的OpenURL”的方法，它会悄悄地失败。 一个“这个程序是不允许查询计划XXX”系统日志条目将出现。

这是不是从会议明确，如果这些限制适用于“的OpenURL”的号召，但在实际的测试看来，他们这样做。这是可能的（我希望）这是一个错误。

每在会议的讨论，这些限制将被追溯执行的内置应用程序和系统，这将建立到iOS9之前提交到店它是多达50个URL方案自己的白名单允许根据实际调用的应用程序通过应用程序进行。这次会议没有明确的限制，以URL方案，可以在应用程序自身的白名单中的号码，但我要承担50，或其他一些合理的限制将被强制执行- 可能通过一个验证器提交的应用程序给苹果商店的时候。

在实践中，这意味着URL是现的东西只能被用于检查和开小许多已知以外的应用程序。例如，谷歌的方法所使用的X-回调，基于URL的URL回调打造“返回”按钮，返回到来自Chrome和地图他们的iOS版本的其他应用程序仍然可以继续自己的家庭的应用程序之间的工作，他们将有可能白名单，但将无法继续使用由拟作出的“后退”按钮会出现在Chrome浏览器等任意应用程序。


这也几乎杀死任何形式的发射器的应用程序，并阻止来自其他应用程序访问服务，链接URL回调和其他复杂的自动化任务，如草稿和工作流应用程序。

Why is Apple Making this Change?

苹果公司正在做出这种 改变是出于保护隐私。


虽然任何应用程序可以注册任意URL方案并没有保证，因为该系统从canOpenURL调用，实际上安装了特定的应用程序返回“YES”，注册独特的URL方案已成为事实上的方法来检查，如果某个应用程序安装在系统上 - 通过扫描与canOpenURL“已知”的URL方案列表，某些应用程序（如Twitter的）已经被滥用了这个漏洞扫描您的系统中安装的应用程序和使用这些信息的任何邪恶的原因 - 可能涉及广告。

苹果一直在增加更多的安全和可靠的方式做的事情可能与网址（扩展，应用程序链接等），许多（但不是全部）。长期这些都是重要的变化，因为这是真的，还有影响到无节制地使用的URL可能被利用。

Possible Alternatives

可能的备选方案

我同意与苹果关于“canOpenURL”滥用的担忧，但如果目前的实现是他们预期的解决方案，我认为这是太严重，会造成太大的破坏和不好的用户体验对于许多用户。

我希望（如上所述），这些变化只是为了适用于“canOpenURL”的方法，而且它是一个错误，他们也限制了“的OpenURL”呼叫的功能。我已经提出了雷达报告这是一个错误，如果你是一个开发人员，并同意我的判断，请考虑复制它（rdar：//21320635| openradar）。

即使是这样的话，能力的丧失称之为“canOpenURL”上任意的URL将限制有关URL的许多自动化应用的用户体验，因为一个应用程序具有无法检测的URL是否可以成功地被打开和将不得不依赖在系统上报告错误。它可能也有可能以使其能够继续发挥作用用于在节流方式的应用程序，将只允许一定数量“canOpenURL”的在一定时间内呼叫 - 从而阻碍它的用处进行扫描。


我还没有完全想出来这种变化所带来的后果，并且它的公共昨天 - 但我希望得到一些想法出来迅速展开讨论，并希望苹果在听，并愿意作出这样的保护用户良好的妥协，允许iOS系统继续作为强大和灵活越好。