我的应用程序不会主动提示用户在 App Store 上对应用程序进行评分，它仅在应用程序设置中包含一个“评价此应用程序”页面。因此，用户可以手动访问该页面，并且只有在他点击 Do Rate 按钮后，他才会被重定向到 App Store。
当然，SKStore Review Controller 的 UI 比将用户重定向到 App Store 应用以留下评论要简单得多。所以我只是将对 App Store URL 的调用更改为对 [SKStore Review Controller requestReview] 的调用。
这在我的所有测试中都运行良好:每次我点击评论按钮时都会显示评分对话框。
但是我想知道这在实际调试环境之外会如何表现。根据 Apple 文档，[SKStore Review Controller requestReview] 限制为每年每个 App 3 次提示。
- 一旦达到此限制，应用程序将如何运行？按下审核按钮 (=
[SKStore Review Controller requestReview]) 会不会有任何效果，还是会有某种反馈？ - 我如何知道我是否仍可以使用
[SKStore Review Controller requestReview]或者我是否必须手动将用户发送到商店？ - 每年每个应用 3 次提示到底是什么意思？这真的是每个应用还是每个应用版本？
- 两次
[SKStore Review Controller requestReview]调用之间的间隔是否有限制？连续使用 3 天与每 4 个月使用一样合法吗？
最佳答案
免责声明
虽然我不能引用官方回应(我也不能保证这些发现会保持多久)，但我只是花了一些时间逆向工程逻辑，它看起来很简单。
请求审核:
当您请求审核时，StoreKit 会向 com.apple.itunesstored.xpc 发送一条消息，后者负责执行和跟踪限制。如果未达到请求限制，XPC 进程会跟踪请求并使用应用审查 token 进行响应。否则，它会返回 nil。
收到 XPC 响应后，StoreKit 检查 token 是否为 nil。如果它不是零，一个 SKStoreReviewViewController 被实例化并呈现在一个内部 UIWindow 中。否则，该请求将被静默忽略。没有回调或通知可以监听，虽然 XPC 处理程序中有一些代码用于记录错误，但我没有在 XPC 进程中看到任何错误来源。
验证限制
就限制背后的逻辑而言，它非常简单。必须满足两个条件:
无论应用版本如何，在过去 365 天内，用户收到的提示不得超过 3 次。
如果用户在之前的请求中对应用进行了评分，则不得提示用户，除非:
- 他们的最后一次评分是在超过 365 天前
- 并且应用程序版本已更改
虽然 Apple 建议在请求另一个提示之前等待几周的进一步参与，但目前没有逻辑可以阻止您在三分钟内提示用户三次。不过，这些提示将计入接下来 365 天内的所有三个提示。
tl;博士
StoreKit 会默默地忽略任何多余的请求，您无法确定何时会发生这种情况。
虽然您可以自己跟踪您的请求以了解何时需要重定向到 App Store 或请求审核，但 Apple 可能会随时更改逻辑。无法以编程方式查询您的限制。
每年三次提示是指过去 365 天内出现三次提示，无论应用版本如何。 (虽然更新应用会清除“不再提示”的要求。)
两次请求审核调用之间的间隔没有限制。
对于您的情况，我建议使用新的 App Store URL，将用户直接带到评论撰写屏幕。这将更加一致地工作，同时仍然遵循 HIG 准则(因为它是对按钮按下的响应)。
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.
关于ios - SKStore 评论 Controller : How are the limits handled?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45695887/