Review readiness
目的
一次提交即通過。大多數拒絕的原因並非應用程式的點子，而是審查者無法登入、無法購買、看到佔位符，或發現後設資料與應用程式之間的矛盾。
前置條件
- 要提交的確切版本已在 TestFlight 或 Play 測試軌道上。
subscriptions-and-payments檢查點已通過（真實購買在兩個平台都已解鎖進階功能）。privacy-and-declarations已完成；listing-and-aso驗證器無錯誤；螢幕截圖已上傳。
像零知識審查者一樣思考
假設審查者在您未測試過的裝置上安裝乾淨的版本（iPhone 專用應用程式可能在 iPad 的相容模式下被審查），使用全新的商店帳號，且時間有限。他們會閱讀您的備註，嘗試登入，尋找購買功能，並將螢幕截圖與應用程式進行比較。一次拒絕可能結合多層次原因：帳號狀態、後端行為和後設資料。
流程
1. 示範帳號
- 憑證應放入 App Store Connect › App Review Information（「需要登入」）和 Play › App content › App access。絕不能放在儲存庫中。
- 帳號使用電子郵件 + 密碼登入。 如果您的正常登入方式是電子郵件一次性代碼或魔法連結，審查者無法接收。請為審查用的電子郵件地址添加密碼路徑（伺服器端允許清單）或固定測試代碼（僅對該地址有效）。
- 充滿資料：個人資料完整、幾天歷史記錄、每個主要畫面都有內容。空的帳號會隱藏功能，並引發「我們無法找到功能 X」的疑慮。
- 已解鎖進階功能：透過伺服器端手動賦予權限（審查期間不過期），以便審查者無需購買即可看到付費功能。
- 另外，確保新使用者能夠到達付費牆，並使用審查者的沙盒帳號購買（他們也會測試購買流程）。
- 審查進行期間，不要變更、刪除或重新初始化此帳號。
2. 購買（2.1(b) 和 3.1.x）
- 首次版本的訂閱項目需附加在 App Store Connect 的版本中（「App 內購買項目與訂閱項目」區段），並提供審查螢幕截圖和備註。在較新的 App Store Connect 介面中，版本頁面上可能沒有該區段：請開啟訂閱群組和每個訂閱項目，使用「加入以供審查 → 草稿提交」。草稿中必須包含版本、群組和每個訂閱項目，然後再點擊「提交以供審查」。
- 每個訂閱項目都需要至少一個顯示名稱 + 說明在地化內容和一個審查螢幕截圖；沒有這些，「加入以供審查」操作會失敗（「您必須加入至少一個訂閱項目在地化內容 / 審查資訊螢幕截圖」）。
- 審查螢幕截圖必須顯示真實的付費牆，包含真實價格和正確的商店用語。如果是透過小工具或 UI 測試產生的，請強制使用 iOS 平台（否則會顯示「Google Play」），並提供真實的商店價格；「價格不可用」的狀態是不可接受的。
- App Store 版本字串必須與版本的市場版本號（
CFBundleShortVersionString）相同。名稱為1.0的版本無法提供上傳為1.0.0的版本；版本區塊只會顯示「上傳您的版本」，沒有「加入版本」的按鈕。請重新命名版本以使其相符。 - 在 TestFlight 上使用全新的沙盒 Apple 帳號（未連結至您的任何應用程式帳號）：產品能載入、購買可運作、恢復購買可運作。
- 付費牆錯誤狀態應顯示重試，絕不能顯示已停用的「即將推出」。
- 如果應用程式中無法存取某個 App 內購買項目（例如僅限於某個地區），請在審查備註中解釋原因。
- 必須提供恢復購買、條款與隱私權連結以及管理訂閱連結。
3. 裝置與版本
- 冷啟動時無網路、網路緩慢以及切換飛航模式：不應崩潰，也不應出現無限載入轉圈。
- iPad：即使是 iPhone 專用應用程式，在 iPad 的相容模式下也可執行，並可能在那裡被審查。請在 iPad 模擬器上執行完整流程：登入（包括使用 Apple 帳號登入）、付費牆滾動、購買頁面、表單上的鍵盤、權限提示、旋轉。如果 HealthKit 或其他 API 在此處不可用，請顯示禮貌訊息，不要崩潰。
- 最小支援的手機和最大文字大小：付費牆或同意畫面上的按鈕不應被截斷。
- 釋出版本，而非除錯版本：無除錯橫幅、無測試選單、分析/錯誤回報應使用正式環境設定。
- 在實體裝置上，使用您要提交的確切版本，走完整個帳號生命週期：安裝、註冊、主要功能、沙盒購買、帳號刪除，以及刪除後應用程式顯示的內容。
4. 內容與後設資料
- 搜尋應用程式的字串和清單是否有：
TODO、lorem、coming soon、beta、test、[PRICE]、佔位圖像。這些都不應出現。 - iOS 版本和後設資料不得包含 Android / Google Play 用語；Play 版本不得包含僅限 Apple 的用語（2.3.10）。包括應用程式內字串，如「在 App Store 或 Google Play 取消」— 請在執行階段選擇平台的文字。
- 每張螢幕截圖都應與目前的使用者介面相符；描述中的每個數字都應與應用程式相符。
- 隱私權政策、條款、支援和帳號刪除的 URL 無需登入即可載入，提及應用程式名稱，並與隱私權表單一致。
- 年齡分級應與條款一致。
5. 後端
- 後端正在執行，且處於不會在審查期間達到限制的方案（免費方案若暫停或限制流量，會導致拒絕）。
- 審查期間不要部署會造成破壞性變更的內容。對於正在審查的版本，API 應保持向後相容。
- 應設定警示（
post-launch-ops），以便在審查期間發生中斷時能立即察覺。
6. 審查備註
填寫 templates/review-notes.md。保持事實性：功能的位置、如何登入、如何測試購買、AI 和健康資料如何處理、帳號刪除在哪裡進行。
Apple 可能以**準則 2.1「需要資訊」**回應，而不是直接審查。在一個觀察到的案例中，它要求了以下六項；在首次提交時就主動回答這些問題，可以避免一來一回的溝通：
- 在最新作業系統的實體裝置上進行螢幕錄製，從應用程式啟動開始，顯示典型流程：註冊、登入、帳號刪除、任何使用者產生的內容及檢舉/封鎖功能，以及存取付費內容。使用提交的版本進行錄製；將檔案附加在提交訊息的回覆中（或提供連結），並在備註中提及。刪除部分絕不要使用示範審查帳號：請在錄製中建立一個全新帳號。
- 應用程式的目的和目標受眾：它解決的問題及其價值。
- 主要功能的設定和存取說明，包括示範憑證和選單路徑。
- 核心功能背後的所有外部服務：驗證/資料庫、支付（StoreKit 及任何包裝層）、AI 提供者、資料來源（例如地圖 API）、電子郵件、健康框架。
- 區域差異，或說明功能在所有地區皆相同。
- 對於受監管領域或第三方受保護內容：提供文件或說明不適用（例如「一般健康用途，非醫療裝置」）。
7. 執行/不執行報告
填寫 templates/go-no-go-report.md，為每一行提供證據（螢幕截圖、版本號碼、命令輸出）。任何一個阻塞行的否都意味著不能提交。
8. 提交（核准）
要求帳號持有者提供明確核准，並附上報告。在 iOS 上選擇手動釋出，以便核准後不會立即發布。在 Play 上，正式環境存取權限（新的個人帳號）需要先完成 14 天的封閉測試和正式環境存取權限申請。
被拒絕後
請參閱 references/rejection-playbook.md：閱讀確切的準則，重現問題，修復根本原因（通常不止一個層面），在 Resolution Center 中具體回覆，重新提交；僅在審查者誤讀了您可以證明的事實時才提出上訴。
需要人類核准的決策點
提交、選擇釋出方式、回覆拒絕（語氣和承諾）、提出上訴、為審查帳號授予進階功能權限。
驗證
執行/不執行報告完整且附有證據，並且由未參與建置功能的人員在乾淨的裝置上走過審查備註並成功。
常見陷阱
- 示範帳號依賴於審查者無法讀取的電子郵件代碼。
- 示範帳號為空、已凍結或被清理作業刪除。
- 產品處於「遺漏後設資料」狀態（無審查螢幕截圖），因此在審查中永遠無法載入。
- 將版本從審查中移除（「開發者拒絕」）也會從草稿中移除訂閱項目；在重新提交前，需重新加入群組和每個訂閱項目，否則版本會獨自提交。
- 當版本處於「等待審查」狀態時，產品頁面素材會被鎖定（例如較新的標頭素材）。請在提交前新增所有內容；否則您必須將版本從審查中移除、編輯並重新提交（您會失去在佇列中的位置）。
- Apple 自己的「加入以供審查」檢查通過，並不表示選擇性素材已設定：空的標頭素材是被允許的，請在提交前決定好。
- 審查者全新的 Apple 帳號與您的恢復/轉移規則衝突，導致購買「失敗」。
- 後端使用一個在閒置後會暫停或限制審查者速率的方案。
- 版本中任何地方出現「coming soon」。
- 應用程式內文字提及另一個商店。
- 審查備註僅說明示範登入（無錄製、目的、服務或區域資訊）。