# Guideline 5.6.3：请求评分导致 App 被拒

> 首次启动或引导流程中请求评分会因 5.6.3 被拒。应在用户真正使用后用系统弹窗请求。

原始页面：[Guideline 5.6.3：请求评分导致 App 被拒](https://devoria.fr/zh-hans/blog/guideline-5-6-3-app-review-request-rejected)
作者：[Mehdi Azizi](https://devoria.fr/zh-hans/mehdi-azizi)
发布：2026-10-13
内容最后修订：2026-10-13


Apple 会拒绝过早请求评分的 App。**如果你的评分请求在首次启动或引导流程（onboarding）中弹出，就可能因 guideline 5.6.3 被拒。**请求应该在用户真正用过 App 之后出现，并且要用系统自带的弹窗。

我在 Solys 上就吃过这个拒审。Solys 是我做的一款小游戏闹钟。下面讲讲这条规则说了什么、Apple 推荐怎么做，以及我是怎么改的。

## Guideline 5.6.3 说了什么？

Guideline 5.6.3 属于「Developer Code of Conduct」，也就是 [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#5.6.3) 的 5.6 节。条文禁止操纵 App Store 用户看到的内容：排名、搜索、评论、指向你 App 的推荐。它没有提到引导流程。

可 Apple 拒我的评分请求时，引用的偏偏就是这一条。理由写在它的设计规范里：首次启动或引导流程中，用户还没来得及形成看法。

同一节的 5.6.1 规定了允许的方式：用 Apple 提供的 API 请求评分。自己做的评分弹窗不被接受，而且 guideline 3.2.2 禁止用评分来换取解锁某个功能。

## 什么时候请求评分

Apple 关于[评分和评论](https://developer.apple.com/design/human-interface-guidelines/ratings-and-reviews)的设计规范说得很清楚：只有在用户真正用过 App 之后才请求评分。

| 请求时机              | Apple 的立场 | 原因             |
| --------------------- | ------------ | ---------------- |
| 首次启动时            | 避免         | 还没有看法       |
| 引导流程中            | 避免         | 还没用过 App     |
| 任务进行到一半        | 避免         | 请求会打断操作   |
| 成功完成任务后        | 推荐         | 用户已经了解 App |
| 「给 App 评分」按钮上 | 可以，用链接 | 弹窗有时不出现   |
| 连续多次请求          | 避免         | 反复提醒让人厌烦 |

只有前两行让我被拒过，其余来自 Apple 的建议。两个有用的参考：Apple 建议两次请求之间至少隔一到两周；系统本身限制同一个 App 的弹窗在每 365 天内最多显示三次。所以你没法强制它弹出来。

## 我在 Solys 上遇到的 5.6.3 拒审

2026 年 8 月 30 日，Solys 的一次更新被拒。Apple 的消息引用了 5.6.3，说 App 在首次启动或引导流程中请求评分。审核用的是 iPad Air。

原因很简单。在欢迎流程里，「留下评价」页面排在第二位，紧跟在小游戏演示后面。用户只看过演示。

**修复方法**：把请求挪到流程更后面，而且只有用户刚赢下演示时才显示。跳过演示或输掉演示的人看不到任何请求。改好的版本随后通过了审核。

这算是我赌了一把：Apple 的消息说的是「不要在引导流程中」，没有任何余地。

**教训**：稳妥的做法是把请求移出引导流程。评分和权限一样，要等用户看到 App 能给他带来什么之后再请求。

## 用系统弹窗请求评分

在 Expo App 里，系统弹窗通过 [expo-store-review](https://docs.expo.dev/versions/latest/sdk/storereview/) 库调用：

```ts
import * as StoreReview from "expo-store-review";

export async function demanderUnAvis() {
  if (await StoreReview.isAvailableAsync()) {
    await StoreReview.requestReview();
  }
}
```

根据 Apple 关于[请求评分](https://developer.apple.com/documentation/storekit/requesting-app-store-reviews)的文档，有三点要知道：

- **弹窗显不显示由系统决定。**调用后可能什么都不出现。不要做任何依赖它出现的界面。
- **避免在用户操作（比如按钮）里触发它**，弹窗可能不会显示。如果要做「给 App 评分」按钮，改为打开你 App 的 App Store 页面，在地址末尾加上 `?action=write-review`。
- **选一个成功的时刻**：用户刚完成一系列操作的时候，而不是打开 App 时。

Apple 的示例代码还会延后调用：等用户多次完成某个操作，并且同一个 App 版本不会请求两次。具体次数由你决定。

## 提交前的检查清单

- 首次启动时不请求评分。
- 引导流程中不请求评分。
- 请求走系统弹窗，而不是自己做的带星星的页面。
- 设置里的「给 App 评分」按钮打开 App Store 页面，不调用系统弹窗。
- 请求出现在真实使用之后：完成一项任务、通过一关、多次打开。
- 欢迎流程也在 iPad 上测过：我有好几次拒审都是在 iPad 上发现的，而那些都是 iPhone App。

## 下次提交前避开 5.6.3 拒审

[Apple Review Kit](https://devoria.fr/zh-hans/kits/review-apple) 包含我的提交前检查清单、我修复过的 Apple 拒审案例，以及会检查你项目的 Claude Code skills。如果你的 App 刚被拒，想找人帮忙看看，[预约我一小时](https://devoria.fr/zh-hans/coaching)：我们视频连线，在你的屏幕上一起过一遍欢迎流程。完整流程见 [App 被 Apple 拒绝](https://devoria.fr/zh-hans/expertise/app-rejected-by-apple)页面，其他常见拒审原因见[为什么 Apple 拒绝你的 App](https://devoria.fr/zh-hans/blog/apple-app-rejection-reasons-real-cases)。

如果你在准备第一次上架，[做一下免费诊断](https://devoria.fr/zh-hans/diagnostic)：它会帮你理清步骤顺序，并把我的 Apple 防拒审清单发给你。

## 常见问题

### 可以在引导流程中请求评分吗？

Apple 在设计规范里不建议这样做，我也因此按 guideline 5.6.3 被拒过。用户还没用过 App，不可能有看法。把请求放在真实使用之后。

### 评分请求最多能显示几次？

系统限制同一个 App 的弹窗每 365 天最多显示三次。Apple 还建议两次请求之间至少隔一到两周，它的示例代码也不会对同一个 App 版本请求两次。

### 可以自己做评分弹窗吗？

不行。Guideline 5.6.1 要求使用 Apple 提供的 API，并排除了自制的评分弹窗。不过你可以提供一个「给 App 评分」按钮，打开你 App 的 App Store 页面。

### 5.6.3 被拒后需要重新打包 build 吗？

如果请求写在 build 的代码里（几乎总是如此），就需要。审核员首次启动时看到的是打包进去的代码，远程更新不够。挪动请求位置，重新打 build 再提交。

### 什么时候请求评分最合适？

在一次成功之后：完成一项任务、赢下一关、达成一个目标。Apple 推荐选一个不会打断任何操作、用户已经了解 App 的时刻。避开打开 App 时和操作进行中。


## 你的项目

[Apple Review Kit](https://devoria.fr/zh-hans/kits/review-apple)：我在用的 App Store 审核检查清单、我被 Apple 拒绝后的修改、给审核员的备注，以及两个审查你 App 的 Claude Code skills。29 €。

[iOS Kit](https://devoria.fr/zh-hans/kits/ios)：用 Claude Code 做你的 iPhone App：我自己 App 的起步代码、检查其工作的 skills，以及 Apple Review Kit、App Store Screenshots Kit 和 ASO Kit。129,99 €。