5

我的 App 不会主动提示用户在 App Store 上给应用评分，它只是在应用设置中包含一个“给这个应用评分”页面。因此，用户可以手动访问该页面，并且只有在他点击一个Do Rate按钮后，他才会被重定向到 App Store。

当然，用户界面SKStore​Review​Controller比将用户重定向到 App Store 应用程序以留下评论要直接得多。所以我简单地将对 App Store URL 的调用更改为对[SKStore​Review​Controller requestReview].

这在我所有的测试中都很好用：每次点击查看按钮时都会显示评级对话框。

但是我想知道这在实际调试环境之外会如何表现。根据 Apple 文档，每个 App 每年[SKStore​Review​Controller requestReview]限制为3 个提示。

  • 达到此限制后，应用程序将如何运行？按下查看按钮 (= [SKStore​Review​Controller requestReview]) 会没有效果还是会有某种反馈？
  • 我如何知道我是否可以使用[SKStore​Review​Controller requestReview]或是否必须手动将用户发送到商店？
  • 每个应用程序每年 3 个提示到底是什么意思？这真的是每个应用程序还是每个应用程序版本？
  • [SKStore​Review​Controller requestReview]两次通话之间的间隔是否有任何限制？连续三天使用它和每四个月使用它一样合法吗？
4

1 回答 1

8

免责声明

虽然我不能引用官方的回应（而且我不能保证这些发现会保持多久），但我只是花了一些时间对逻辑进行逆向工程，它似乎很简单。

要求审查：

com.apple.itunesstored.xpc当您请求审查时，StoreKit 会向负责执行和跟踪限制的发送消息。如果未达到请求限制，XPC 进程会跟踪请求并使用应用审查令牌进行响应。否则，它以 nil 响应。

收到 XPC 响应后，StoreKit 检查令牌是否为 nil。如果它不是 nil，SKStoreReviewViewController则实例化 an 并在 internal 中呈现UIWindow。否则，该请求将被静默忽略。没有可以监听的回调或通知，虽然 XPC 处理程序中有一些代码用于记录错误，但我没有在 XPC 进程中看到任何错误来源。

验证限制

至于限制背后的逻辑，这很简单。有两个条件必须满足：

  1. 在过去 365 天内，用户的提示次数不得超过 3 次，无论应用版本如何。

  2. 如果用户在之前的请求中对应用进行了评分，则不得提示用户，除非：

    • 他们的最后评分是 365 天前
    • AND 应用程序版本已更改

尽管 Apple 建议在请求另一个提示之前等待几周的进一步参与，但目前，没有任何逻辑可以阻止您在三分钟内提示用户三次。不过，这些提示将在接下来的 365 天内计入您的所有三个提示。

tl;博士

  • StoreKit 会默默地忽略任何多余的请求，您无法确定何时会发生这种情况。

  • 尽管您可以自己跟踪您的请求以了解何时需要重定向到 App Store 和请求审查，但 Apple 可能会随时更改逻辑。无法以编程方式查询您的限制。

  • 每年 3 次提示是指过去 365 天内的 3 次提示，与应用版本无关。（虽然更新应用程序会清除“不再提示”的要求。）

  • 两次请求审查调用之间的时间间隔没有限制。

对于您的情况，我建议使用新的 App Store URL，它将用户直接带到评论撰写屏幕。这将更一致地工作，同时仍然遵循 HIG 指南（因为它是对按钮按下的响应）。

要自动打开用户可以在 App Store 中撰写评论的页面，请将查询参数 action=write-review 附加到您的产品 URL。

于 2017-11-20T08:18:40.723 回答