luda 对于iOS APP，当功能涉及到推送通知、访问照片或调用相机、获取地理位置等等时，都需要向用户申请授权。申请会发生在app运行的过程中，而不是像Android那样在安装的时候就莫名其妙的问用户是否同意app调用某些系统功能。不过如今Android也在向iOS的方式靠拢。
对于产品方而言，这里最大的问题在于，iOS只给你一次机会去征询授权 – 一旦那些缺乏耐心和理性的用户(多数用户)出于无论什么原因而拒绝授权，其结果就是要么无法使用关键功能，要么需要退出app去到系统的Settings里面重新设置授权然后再回到app。所以，怎样尽可能确保用户在初次使用产品时一次性通过授权？这是一个既有挑战性，同时又有点意思的话题。
我们归纳了市面上常见的五种模式，供大家根据自己产品的实际情况进行参考。
一、直接问，然后祈祷
很多app会在初次使用的过程中直接弹框索取权限。确实是最简单的实现方式，但被拒的可能性也最大(除了那些足够大牌到用户没理由不信任的产品)，用户如果决定重新授权，必须完整执行前面提到的设置流程，因为这个弹框是唯一一次决定的机会。
有些功能相对复杂的app更是会在初次加载的时候就执行一系列的授权申请，先是要求调用相机，然后问是否允许获取地理位置，最后还要让你授权接收消息通知。某些时候，这种简单粗暴的方式也确实可用，比如前面提到的，用户已经足够了解和信任这款产品的情况下。但对于多数产品，你不能做这样的假设，即便对于那些大牌，说到底也无法100%确保用户不会看走眼或习惯性的点击拒绝。
二、诱导用户
从本质上讲仍然是“直接问”的模式，但这类app会在询问时通过一些小技巧变着法的诱导用户点击“允许”。实现成本不会比第一种高出很多，但获取授权的几率会增大。
三、问两次，让用户有所准备
你也可以使用变通的方式在某种程度上突破“只能问一次”的局限，譬如在真正的系统对话框出现之前展示一个定制化的“假”的对话框。
如上图所示，左屏当中的对话框完全是定制化的UI元素，用户点击OK之后才会出现真正的iOS授权申请。这种方式有两点好处：
1.如果用户在“假”的申请中拒绝授权，那么你不会浪费掉唯一的那次“真”的系统授权机会，只需要关闭对话框即可。
2.当用户将来再次需要用到相关功能时，你仍然可以通过这种方式征询授权。
“假”的对话框在形式上可以自由发挥，譬如加入更多教学内容或引导元素。
两次提问的情境是可以根据实际情况进行控制的，例如Shazam这样，将第一次机会放在进入实际app之前，与引导页当中的内容整合起来。
四、等用户用到相关功能时再问
另一种更加情境化的常见模式就是等到用户实际用到与系统权限相关的功能时再征询授权，例如当用户点击“当前位置”按钮时，询问是否允许使用当前地理位置，或是当用户进入拍照界面时，询问是否允许调用系统相机。
这种模式的优点很明显，就是用户在实际功能情境中会对将要发生的事情更具预期，所以通过授权的可能性就更高。