AI Skills
app-store-review

app-store-review

熱門

審查 App Store 送審準備度與拒絕風險，涵蓋現行審查指南、PrivacyInfo.xcprivacy 與必要原因 API、隱私標籤、ATT、StoreKit 付款、中繼資料、授權、Widget 與 Live Activities。適用於準備送審、回應拒絕、調和隱私證據，或區分上傳阻礙與清理事項。

927星標
46分支
更新於 2026/7/15
獲取技能源代碼

相關技能

mcp-builder6.9萬orch-pipeline24萬recsys-pipeline-architect24萬
SKILL.md
唯讀
名稱
app-store-review
描述

審查 App Store 送審準備度與拒絕風險，涵蓋現行審查指南、PrivacyInfo.xcprivacy 與必要原因 API、隱私標籤、ATT、StoreKit 付款、中繼資料、授權、Widget 與 Live Activities。適用於準備送審、回應拒絕、調和隱私證據，或區分上傳阻礙與清理事項。

App Store 審查準備

在送審前找出 App Store 拒絕風險。將政策、SDK、隱私、授權、付款與中繼資料檢查視為當前版本的證據，而非永久事實。

目錄

每次審計開始時，先取得最新的 App Review Guidelines、Upcoming Requirements、螢幕截圖規格、必要原因 API 文件，以及適用的商店/授權付款規則。在每個版本阻礙旁記錄檢查日期與來源。然後封存建置並驗證確切的送審版本，區分阻礙與清理事項，修正一類證據不符，並對重建的封存重新執行相同檢查。

對於關鍵字、螢幕截圖說明、產品頁面中繼資料或中繼資料拒絕風險的提示，請從合規角度回答，並明確將關鍵字研究、排名策略、轉換優化、螢幕截圖順序與 A/B 測試交由 app-store-optimization 處理。將 App Review 中繼資料指引限制在準確性、欄位限制、誤導內容風險與螢幕截圖合規。從 Current Release Requirements 載入日期格式、螢幕截圖與工具鏈事實。

對於完整的送審準備度審計，請將阻礙上傳/審查的問題與一般清理事項分開。交叉檢查隱私清單、App Store 隱私營養標籤、隱私政策、ATT 狀態、執行時期網路行為與 SDK 行為；宣告與實際行為必須一致。

阻礙送審檢查

在一般清理之前，將以下問題升級為阻礙：

  • 封存缺少當前 Xcode 或平台 SDK 上傳最低版本
  • 未解決的隱私證據不符；請根據 PrivacyInfo.xcprivacy 要求 進行調和
  • 付款路徑未通過 StoreKit 規則
  • 缺少 App Store Connect 當前規格所需的螢幕截圖組
  • 審查存取未通過下方指南 2.1 完整性證據

常見拒絕原因與避免方法

指南風險 版本證據
2.1 完整性 無佔位符、損壞/空白流程、無法存取的僅硬體功能，或沒有有效示範帳號與審查說明的登入閘道。
2.3 中繼資料 應用程式名稱、類別、說明、關鍵字與螢幕截圖準確代表送審的二進位檔與實際 UI。
4.2 最低功能 應用程式提供有意義的應用程式特定價值，而非簡陋網站或系統行為的瑣碎複製。
2.5.1 軟體要求 封存使用公開 API，且不下載在文件例外之外變更已審查功能的程式碼。

根據當前指南與確切封存驗證這些項目；不要從舊版檢查清單沿用版本或螢幕截圖要求。

PrivacyInfo.xcprivacy -- 隱私清單要求

當您的應用程式程式碼、可執行檔、動態函式庫或第三方 SDK 使用 Apple 的必要原因 API 類別，或宣告收集資料/追蹤行為時，需要隱私清單。

請參閱： references/privacy-manifest.md 了解完整結構、原因代碼與檢查清單。

摘要

  • 必要原因 API 類別包括檔案時間戳記、系統開機時間、磁碟空間、使用中的鍵盤與 UserDefaults；使用時每個都需要一個核准的原因代碼。
  • 在最終送審前，重新檢查 Apple 當前必要原因 API 文件，不要選擇廣泛、方便或自創的原因代碼。
  • 必要原因 API 宣告應屬於包含使用該 API 的程式碼的套件；每個包含清單相關程式碼的應用程式目標、可執行檔、動態函式庫、框架或 SDK 套件都需要相符的清單宣告。
  • 每個收集資料、使用必要原因 API、啟用資料收集/追蹤或聯絡追蹤網域的 SDK、可執行檔或動態函式庫，都需要在包含該程式碼的套件中進行清單關注；SDK 程式碼不能依賴主應用程式的清單來報告 SDK 自身的使用情況。
  • 清單宣告必須與 App Store 隱私營養標籤、SDK 行為以及應用程式的呈現功能相符。

資料使用、分享與隱私政策（指南 5.1.2）

  • 必須在 App Store Connect 中設定隱私政策 URL，並且在應用程式內可存取
  • 隱私政策必須準確描述您收集的資料、使用方式以及分享對象
  • App Store 隱私營養標籤必須與實際資料收集做法相符
  • 隱私標籤、隱私清單、SDK 揭露與執行時期行為應講述相同的故事

應用程式內購買與 StoreKit 規則（指南 3.1.1）

數位商品、功能、訂閱、虛擬貨幣、廣告移除與數位小費通常需要 IAP，除非當前指南例外、商店規則或核准的授權適用。實體商品與現實服務使用其一般付款流程。購買前，顯示價格、持續時間、續約/試用條款、計費頻率與取消條款；驗證產品分類、恢復、授權驗證、延遲/中斷購買與 Ask to Buy。載入 storekit 進行實作，並在標記路徑合規前重新檢查當前區域/外部連結規則。

HIG 遵循檢查清單

從 review-checklists.md 載入導覽、模態、Widget、系統功能、啟動畫面與空狀態的完整 HIG 檢查。

App 追蹤透明度（ATT）

何時需要 ATT

如果您的應用程式在其他公司的應用程式或網站間追蹤使用者，您必須：

  1. 在任何跨應用程式或跨網站追蹤發生之前（包括具追蹤能力的 SDK 行為），透過 ATTrackingManager.requestTrackingAuthorization 請求權限
  2. 尊重使用者的選擇 -- 如果使用者拒絕權限，則停用跨應用程式與跨網站追蹤
  3. 不要將應用程式功能限制在追蹤同意之後（「接受追蹤否則無法使用此應用程式」會被拒絕）
  4. 在 NSUserTrackingUsageDescription 中提供明確的目的字串，說明追蹤的用途

何時不需要 ATT

如果您不在應用程式或網站間追蹤使用者，請勿顯示 ATT 提示。Apple 會拒絕不必要的 ATT 提示。

ATT 實作

import AppTrackingTransparency

@MainActor
func requestTrackingPermission() async {
    let status = await ATTrackingManager.requestTrackingAuthorization()
    switch status {
    case .authorized:
        // 啟用追蹤，初始化含追蹤的廣告 SDK
        break
    case .denied, .restricted:
        // 使用非個人化廣告，並停用跨應用程式/跨網站追蹤
        break
    case .notDetermined:
        // 請求後不應發生，優雅處理
        break
    @unknown default:
        break
    }
}

時機： 在應用程式啟動且使用者了解為何請求追蹤後，再請求 ATT 權限。請勿在首次啟動時立即顯示提示，或與其他系統權限提示堆疊。

歐盟數位市場法（DMA）考量

替代發行、瀏覽器引擎、公證與外部付款路徑是區域與授權特定的。重新檢查當前商店規則，並將不支援的路徑視為阻礙。

授權與能力

每個授權都需要一個啟用的功能、適用的特定使用說明，以及相符的封存行為。使用 Entitlements and Usage Descriptions 中的表格與有效的屬性列表範例。

送審流程

送審前步驟

  1. 在 Xcode 中封存。 Product > Archive（需要 Distribution 簽署身分）。確認封存在 Release 組態下乾淨建置，零警告。
  2. 上傳至 App Store Connect。 使用 Organizer 視窗（Distribute App > App Store Connect）或 xcodebuild -exportArchive。透過 altool 或 Transporter 自動上傳也可行。
  3. TestFlight 內部測試。 建置在處理後幾分鐘內即可供內部測試人員（您的團隊）使用。在至少兩種裝置尺寸上走過每個畫面與流程。
  4. TestFlight 外部測試。 外部群組在首次外部發行前需要 Beta App Review。在完整送審前使用此功能與真實使用者驗證。
  5. 提交至 App Review。 在 App Store Connect 中，選擇建置，填寫所有中繼資料欄位，附加螢幕截圖，然後按一下 Submit for Review。審查時間不定；為拒絕、申訴與中繼資料修正預留緩衝。

加速審查請求

僅在 Apple 文件記載的關鍵或時間敏感情況下，使用 App Store Connect 的 Contact Us 表單，以簡潔的事實理由請求加速審查。

階段性發行

使用 Phased Release Schedule 了解推出百分比與 App Store Connect 控制項。

中繼資料最佳做法

保持名稱、副標題、關鍵字、螢幕截圖與預覽準確反映送審的二進位檔與實際 UI。不要使用價格、競爭對手術語或誤導性聲明。套用 Metadata Compliance Checklist 中的欄位限制與媒體規則，並將研究、排名、轉換、螢幕截圖順序與 A/B 測試交由 app-store-optimization 處理。

申訴流程

在 App Store Connect 的 Resolution Center 中回覆，附上簡潔的證據鏈：

  • [ ] 將拒絕對應到引用的指南與確切的送審行為。
  • [ ] 如果已修正，指出精確的變更並重新送審；如果爭議，說明送審如何滿足每個相關要求。
  • [ ] 附上重現合規所需的證據，例如有效的示範帳號憑證、螢幕截圖或重點影片逐步解說。
  • [ ] 如果交流仍未解決，透過 Resolution Center 或 App Store Contact 表單（App Review > Appeal）請求 App Review Board 升級，包含完整的送審歷史與支援證據。

委員會的決定對該送審為最終決定；修改應用程式並重新送審仍可行。

常見錯誤

  1. 模糊的使用說明。 指出使用資料的特定功能。
  2. 將程式碼品質視為審查合規。 並行與交易正確性不能取代隱私、付款、中繼資料與授權證據。

審查檢查清單

每次送審前快速檢查（完整版本在 references/review-checklists.md）：

參考資料