# Guideline 5.6.3：要求評分害 App 被拒的原因

> 首次啟動或引導流程就要求評分會被拒。要等使用者真正用過 App，再用系統視窗詢問。

原始頁面：[Guideline 5.6.3：要求評分害 App 被拒的原因](https://devoria.fr/zh-hant/blog/guideline-5-6-3-app-review-request-rejection)
作者：[Mehdi Azizi](https://devoria.fr/zh-hant/mehdi-azizi)
發布日期：2026-10-13
內容最後修訂：2026-10-13


Apple 會拒絕太早要求評分的 App。**如果你的評分請求在首次啟動或引導流程（onboarding）中出現，就可能因 guideline 5.6.3 被拒。**請求必須在使用者真正用過 App 之後才出現，而且要透過系統視窗。

我在 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-hant/kits/review-apple) 收錄了我的送審前檢查清單、我修正過的 Apple 退件，以及會幫你檢查專案的 Claude Code skills。如果你的 App 剛被拒、想找人幫忙看，[預約一小時跟我談](https://devoria.fr/zh-hant/coaching)：我們透過視訊在你的螢幕上一起檢查歡迎流程。完整做法在 [App 被 Apple 拒絕](https://devoria.fr/zh-hant/expertise/app-rejected-by-apple)頁面，其他常見原因請看[Apple 為什麼拒絕 App](https://devoria.fr/zh-hant/blog/apple-app-rejection-reasons-real-cases)。

如果你正在準備第一次上架，[做免費診斷](https://devoria.fr/zh-hant/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-hant/kits/review-apple)：我使用的 App Store 審核檢查清單、我被 Apple 退件後的修正、給審核人員的備註，以及兩個審閱你 App 的 Claude Code skills。29 €。

[iOS Kit](https://devoria.fr/zh-hant/kits/ios)：用 Claude Code 打造你的 iPhone App：我的 App 所用的 Starter Code、檢查成果的 skills，以及 Apple Review Kit、App Store Screenshots Kit 與 ASO Kit。129.99 €。