评分与评论
关于评分与评论，相信不仅仅是开发者，甚至任何一个 iPhone 用户都不陌生。
因为很多 App 在使用的过程中都会弹出评分与评论的弹窗。这一点无可厚非，因为评分和评论在 App Store 的 App 详情页直接显示出来，运用得当可以有效提升 ASO。
姑且不说评分和评论对 ASO(App Store Optimization) 的影响至关重要（一个 5 星好评，评论内容捎带各种关键词的话），单说用户搜索一个类别之后面对着一堆搜索结果要接着筛选。换做是我，我也会先看看星级，再看看评论内容，之后甄别一下到底用哪个 App。
相信这也是很多公司的市场推广给开发加需求，要求弹出弹窗引导用户去 App Store 给予评分和评论的原因之一。
iOS 10.3 之前的评分与评论
在 iOS 10.3 之前，评分与评论需要跳转到 App Store。通常都是弹出一个提示框引导用户跳转 App Store 给予好评，如果差评则引导用户反馈问题提交到自己的后台。
这种通常就是使用 deep-links 跳转到 App Store，体验很差。一般用户都会毫不犹豫的选择 “不再提示”、“残忍拒绝” 等等。因为操作成本确实太高，要从 App 跳转到 App Store，严重中断了用户的使用，如果用户很久没登陆过 App Store 还会要求用户重新登录 Apple ID 之后才可以给 App 评分。说不定还有少数本来想给好评的用户一顿操作之后来一个 One Star。
iOS 10.3 关于评分与评论的更新
首先 iOS 10.3 提供了 API 去调用请求用户评分与评论的弹窗，这个 API 是在 <StoreKit/StoreKit.h> 库中，开发者需要引入这个库：
然后我们可以在需要请求评分与评论弹窗的地方：
#import <StoreKit/StoreKit.h>
// 请求评论
[SKStoreReviewController requestReview];
这样就可以实现应用内请求用户评分啦，还是挺简单的哈~
那么我们来看一下 官方文档 关于这个 API 的介绍：
Tells StoreKit to ask the user to rate or review your app, if appropriate.
告诉 StoreKit，如果合适，请让用户对您的应用进行评估或审核。
请注意这个 如果合适，文档中
Although you should call this method when it makes sense in the user experience flow of your app, the actual display of a rating/review request view is governed by App Store policy. Because this method may or may not present an alert, it's not appropriate to call it in response to a button tap or other user action.
虽然您在应用程序的用户体验流程中有意义时应该调用此方法，但评分/评论请求视图的实际显示受 App Store 策略的约束。由于此方法可能显示或不显示弹窗，因此它不适合响应于按钮轻击或其他用户操作。
换句话说官方不建议开发者在点击按钮或者其他显式操作的响应中去调用该 API，因为 API 可能弹出也可能不弹出请求评分/评论的弹窗。我们应该把 API 的调用放在某个隐式的契机，后面我们再去说明什么契机去隐式调用 API（挖坑）。
那么请注意 "Request view is governed by App Store policy" 请求弹窗的弹出是受 App Store 策略决定的，网上一挫一簸箕的文章都写到了 iOS 10.3 这种 App 内评分/评价的弹窗一年只能弹出三次，但是无一例外我都没在其文中找到出处。这种在二手资料（非贬义）Get 到的来历不明（这里贬义）的知识实在是煎熬着宝宝的内心。所以我翻到了相关的 App Store 找到了 出处。
方便各位读者老爷找，直接上图：
对了，从上图也可以看到官方给的建议 Don't use buttons or other controls to request feedback.
产品思维，什么契机去隐式的调用 iOS 10.3 新 API
这个其实可以在 Human Interface Guidelines iOS 中找到很多建议：
- 仅在用户展示与您的应用程序的互动后才能要求评级
- 不要中断用户，特别是当他们执行时间敏感或压力很大的任务时
- 不要像瘟疫
- 不要使用按钮和其他控件来请求
这几条官方的建议真的超级好，放开来讲：
- 仅在用户展示与您的应用程序的互动后才能要求评级。可以理解为不要在用户还不熟悉你的 App 时就急着请求评分。
- 不要中断用户，特别是当他们执行时间敏感或压力很大的任务时。例如一个购物 App 在用户正在下单的过程中弹出一个请求评分，那我觉得 One Star 给的一点都不冤。
- 不要像瘟疫。这是个比喻，意思为不要频繁请求评分，烦不胜烦！
- 不要使用按钮和其他控件来请求。这个说过了，因为这个 API 的响应机制受限于 App Store 策略，不收我们把控，谁都不希望点击按钮/控件之后无响应出现，搞得用户莫名其妙！
针对上面的 4 点建议，我相信很容易设计出科学而又符合官方建议的需求，所以建议各位 PM 们多多阅读 Human Interface Guidelines iOS 不要拍脑袋出需求！开发们也可以把这个转给你们公司的产品看，我觉得一个靠谱的产品至少需要把官方的这些建议都看一看，不要总是仿竞品丢需求~
那么我们之前的评分引导弹窗去掉了，这个又受限制于 App Store 的一年三次，如果我们推出的 App 在某个版本已经比较成熟且有把握抓到好评的时候怎么办呢？别急，之前的 deep-links 还没封~ 我的意思不是要你在版本中改回去之前的 low 弹窗，且看开发者文档中的建议：
When you call this method in your shipping app and a rating/review request view is displayed, the system handles the entire process for you. In addition, you can continue to include a persistent link in the settings or configuration screens of your app that deep-links to your App Store product page. To automatically open a page on which users can write a review in the App Store, append the query parameter action=write-review to your product URL.
官方建议你可以在 “设置” 页面中放一个入口用 deep-links 来直接跳 App Store 给 App 打分。所以，我们是不是可以在设置页面加一个类似 “好评鼓励” 的按钮来做入口呢？
