App / Flutter / Launch

2026 Flutter App 上架檢查表：被 Apple 退件 10 次後留下的發布關卡

PEAKSTW 是我實際開發、送審並營運的跨平台 App。十輪退件沒有換來「審查玄學」，反而讓我確定：多數延誤來自帳號、訂閱、審查存取與真機邊界沒有被放進同一個 release gate（發布關卡）。

2026 年 8 月 13 日 · 約 10 分鐘 · 可列印檢查表

送審前 15 分鐘：先跑這 14 項

• 送審 build 是最終版本，沒有 crash、placeholder（暫代內容）、測試網址或無法完成的功能。
• Apple：自 2026 年 4 月 28 日起，送到 App Store Connect 的 App 必須使用 Xcode 26 或更新版本與對應的 26 SDK 建置。
• Google Play：自 2026 年 8 月 31 日起，手機新 App 與更新必須 target Android 16（API level 36）或以上；Wear OS、Android Automotive、TV 與 XR 有不同門檻。
• 後端、第三方 API、圖片與登入服務在審查期間都能從公開網路使用。
• Review Notes（審查備註）寫出非直覺步驟；需要登入時附可長期使用的 demo account（示範帳號）或完整 demo mode（示範模式）。
• 商店文字、截圖、隱私權政策、支援網址與 App 內實際功能一致。
• App 會建立帳號時，App 內能找到「刪除帳號」，不是只有停用、登出或寄客服信。
• Google Play 的 Data safety（資料安全）表單填入可用的網頁刪除入口；即使 App 內已能完整刪除，仍要讓解除安裝後的使用者可從網頁提出要求。
• 若第三方／社群登入是主要登入方式，重新核對 Apple Guideline 4.8 的等價登入服務要求與例外。
• 訂閱商品在 App Store Connect／Play Console 已完整、可售，App 內能取得真實價格，不用寫死價格。
• 實際走完購買、恢復購買、取消、到期、退款／撤銷後收回權益，不只測「付款成功」。
• Apple Server Notifications V2 與 Google Real-time Developer Notifications（即時開發者通知）已接到 production（正式）後端，且真的送過官方測試事件。
• 至少在一台真實 iPhone 與一台真實 Android 裝置測過登入、權限拒絕、離線、背景切換與重新安裝。
• 保存送審證據包：commit、版本／build number、測試結果、螢幕錄影、審查帳號、後端狀態與 rollback（回復）方式。

一、帳號與隱私：最容易「功能正常，政策不過」

帳號刪除不是多放一個按鈕

Apple 的規則是：只要 App 支援建立帳號，就要讓使用者在 App 內發起刪除；只提供暫停或停用帳號不夠。Google Play 還要求在 Data safety 表單提供網頁資源，讓已解除安裝或無法進 App 的使用者也能要求刪除。

• 刪除入口放在直覺位置，例如帳號設定；必要的身分確認可以有，但不能故意增加阻力。
• 說清楚會刪除哪些資料、處理多久，以及因安全、反詐或法規必須保留什麼。
• 訂閱不會因刪帳自動取消時，在確認畫面清楚說明取消方式與後續計費。
• 使用 Sign in with Apple 時，把 token 撤銷也納入刪帳流程，不只刪自己的資料表。
• 隱私權政策同時放在商店 metadata（商店資料）與 App 內，內容涵蓋蒐集、分享、保存與刪除。

第三方登入要看「等價能力」，不是只看按鈕數量

Apple Guideline 4.8 對使用第三方或社群登入作為主要帳號驗證的 App，要求另一個符合資料最小化、可隱藏電子郵件、未經同意不做廣告追蹤的等價登入服務；規則也列出企業、教育、政府身分系統等例外。不要只看到「有 Google 登入」就機械式加按鈕，應先確認自己的情境是否落在規則或例外內。

二、訂閱與內購：測權益，不只測付款畫面

Apple 對數位內容與外部購買連結的規則已因 storefront（商店地區）與 entitlement（特別許可）而有差異，不能再用一句「所有數位內容只能 IAP」概括。最安全的做法，是在送審當天依目標地區核對 Guideline 3.1，而不是複製幾年前的文章。

Google Play 的 productId 陷阱

Google 現行模型允許同一個 subscription（訂閱商品）下面配置多個 base plan 與 offer。這代表月繳、年繳或優惠不一定各有獨立 productId；若你的前端或後端只用 productId 當唯一鍵，可能把不同價格方案覆蓋成同一筆。

• 用 productId 加上 basePlan／offer 身分映射顯示方案與權益，不假設 productId 單獨就能辨識價格。
• 每次顯示購買選項前取得目前 eligible offers（符合資格的優惠）；Google 不建議快取可能過期的 ProductDetails。
• 升級、降級、月轉年時，畫面清楚顯示目前方案、目標方案與生效時間。
• 伺服器權益以商店可驗證狀態為準，通知可觸發同步，但不是唯一真相來源。

Server notification 要測到「事件被正確處理」

Apple 已把 App Store Server Notifications V1 標成 deprecated（已棄用），新整合應使用 V2。官方 Server API 能發送 TEST 通知並查詢結果；驗收不能停在「URL 已填好」，還要確認伺服器驗證簽章、更新對的使用者、重送不會重複發權益，失敗時能追查。

三、審查存取：不要讓 reviewer 猜你的產品

Apple 的送審前清單要求 metadata 完整、聯絡資訊有效、後端服務在線；有帳號功能時，應提供有效 demo account 或完整 demo mode。實務上，審查者進不去核心流程，通常不會替你排查原因。

• 審查帳號不綁開發者手機、不依賴短效 OTP（一次性密碼），也不會在審查期間自動失效。
• 預先放入能展示核心價值的資料；空白首頁不是一個好 demo。
• 需要特定地點、硬體、權限或時間才能觸發時，附短片與逐步路徑。
• 內購不容易找到時，在 Review Notes 說明入口與商品用途；不要藏著等 reviewer 自己發現。
• 每個連結由無登入、無公司 VPN 的乾淨網路重新打開一次。

四、真機與邊界：模擬器不會替你經歷現實

• 全新安裝與舊版升級各跑一次；資料 migration（遷移）失敗時不應卡在啟動畫面。
• 把網路關掉、切到背景、重開 App，再恢復連線，確認不會重複送出操作。
• 拒絕定位、相機、通知或照片權限，核心 App 仍能合理降級並解釋如何恢復。
• 系統字體放大、深色模式、較小螢幕與鍵盤彈出時，主要按鈕仍看得到且能按。
• 登出、刪帳、退款或訂閱失效後，快取資料與付費功能同步收回。
• 從商店測試軌實際下載，而不是只安裝本機 debug build。

五、Google 新個人帳號：12 人、14 天有適用條件

Google Play 的封閉測試門檻不是所有帳號都相同。官方目前寫的是：2023 年 11 月 13 日後建立的新個人開發者帳號，要先讓至少 12 位測試者連續 14 天保持 opted-in（加入測試），再申請 production access（正式版權限），並回答測試、回饋與上線準備問題。

• 先確認帳號類型與建立日期，別把條件錯套到組織或舊帳號。
• 把測試者招募、加入日期與回饋集中記錄；中途退出可能讓連續天數重新計算。
• 不要只湊人數：讓測試者實際走核心流程、回報裝置與問題，申請時如實描述修正。
• internal testing（內部測試）雖非此門檻的必要條件，仍適合先快速驗證 build 與商店安裝。

六、把「送出」改成可稽核的 release gate

十輪退件真正教我的，是每修一個問題就重新送審，會讓下一個舊問題在下一輪才浮出來。現在我會把同類風險一次掃完，並留下可重現證據。

• 版本證據：Git commit、版號、build number、簽章與送審 binary（安裝檔）一致。
• 政策證據：送審當天重讀適用條款，記下版本／更新日期與自己採用的解法。
• 行為證據：測試案例、真機型號、螢幕錄影、後端事件與失敗情境結果。
• 營運證據：正式 API、通知端點、隱私／刪帳網頁與客服入口在公開網路可用。
• 回復證據：出事時能關閉哪個 feature flag（功能開關）、回到哪個 build，以及不會遺失哪些資料。

這份清單不能保證什麼

它不能保證一次通過，也不能取代 App Review Guidelines、Play policy（Google Play 政策）或法律顧問。App 類型、地區、資料種類、醫療／金融等受管制領域，都可能有額外要求。能保證的只有一件事：當審查結果回來，你知道自己送了哪個版本、驗過什麼、哪個假設錯了，不必從聊天紀錄裡拼湊現場。

若你想看這份清單從哪裡來，可以讀PEAKSTW 被 Apple 退件 10 次的完整上架記。

不想手動刪掉不適用項目，可直接使用免費的2026 App 上架清單產生器，依平台、首次上架／更新、帳號與訂閱條件產生可勾選、列印及下載的 Markdown 清單。