URL Scheme的配置和使用都十分简单。本篇不再赘述。
一、获取其他应用URL Scheme
获取其他App的URL Scheme 往往用于检测安装和吊起，获取也很容易，有安装包的话显示包内容(没有通过这个获取，也可以拿到系统应用的Scheme)，搜索Info.plist 文件，很可能会找到很多个文件。逐个打开，找有URL type 的那个，展开后URL Schemes中的任何一个都可以用于判断是否安装了该app。如图：
这里有个几个小技巧：
1.大厂的app一般都比较复杂，在配置这些功能的时候都会加到这个文件中，所以只用找比较大/长的该同名文件即可。
2.实在找不到，可以直接试试这些app的名称的全小写字母，比如Facebook就试试facebook，中文的就试试拼音的小写全拼，比如微信就试试wexin。大厂的app往往都会有一个这样的scheme。
3.有很多URL Scheme的时候要选那些看起来不会变的（结合第二点）。如图：
第二个红框中的更符合不会变的特点。
二、canOpenURL使用误区：白名单最多50个（LSApplicationQueriesSchemes中添加50个）
笔者在搜索资料的时候发现很多帖子都有LSApplicationQueriesSchemes最多只能添加50个的说法。查询文档后确认是错误的，并没有这样的限制。
看文档上的精确描述（文档地址）：
红框中文字的意思是，如果App是用iOS9.0之前构建的版本（原文是连接），但是运行在9.0及之后的版本中，调用方法canOpenURL只能在前50次获取到正确的值。超出次数则都会返回NO，直到重新安装或者更新本应用才会重置次数。
说以说只要是9.0之后构建的应用调用canOpenURL并没有任何次数限制，白名单也没有个数限制。
三、URL Scheme 的其他作用：数据分析
由于白名单没有个数限制，一些定向检测和统计用户安装的App便可以进行用户画像和数据分析。
比如，检测到如果只有女性才会用的App就可以精准分析性别。再比如一组App都装了的话就可以精准分析用户年龄、消费习惯等。结合这些可以在自己的App中给用户精准投放广告、限制用户行为等。
很明显，这也算侵犯了用户隐私。而且对于用户来说这样的检测也不会有任何权限提示，应该算是“合法”漏洞了。（也看到有资料说如果添加的过多 app store 审核时候可能会觉得你滥用了这个机制，从而不让你的 APP 审核通过，有待核实）
四、调用报错
调用canOpenURL时控制台打印"OSStatus error -10814"， 这往往是因为打开的scheme写的不对。
有时也有系统误报的情况，即如果确认写的没有问题那么就忽视这个错误。
