新創行動 App 檢查清單:從 MVP 到 App Store 審核通過的 34 個項目 (2026)
Apple 的 App Store 審查準則 5.1.1(v) 搞砸過的新創上架日,比我們歷來出過的任何 bug 都多。少了一個帳號刪除按鈕,在 demo day 前一晚提交出去,整條時程就往後滑一週。這份新創行動 App 檢查清單之所以存在,是因為這個錯誤完全可以避免,卻幾乎沒有人把肇事的準則條號寫下來。
重點整理:
- Apple 會因為缺少帳號刪除流程和隱私政策連結而拒絕 App:準則 5.1.1 和 1.5 寫得清清楚楚。
- Google Play 要求 App 內和公開網頁都要有帳號刪除路徑,並在 2024 年 5 月 31 日延期期限過後開始執法。
- iOS 和 Android 的提交檢查清單並不相同;把它們當成同一張清單處理,是上架前最後一刻延誤的頭號原因。
寫程式之前
在設計任何一個畫面之前,有三件事必須先定案:你的 MVP 到底是什麼、你需不需要隱私政策(需要),以及 GDPR 或土耳其的 KVKK 是否適用於你的使用者。跳過這個階段,就是為什麼創辦人總在打算提交的那一週,才手忙腳亂地補寫法律頁面。
一句話說完,MVP 就是能夠用真實使用者驗證你核心假設的最小產品版本。它不是你完整願景的精簡版。如果你對範圍還很模糊,在寫下第一行程式之前先妥善界定你的開發範圍,能讓你不必在開發途中砍功能,而是在動工之前就取捨好。
Apple 自己的準則對隱私政策要求說得很直白:準則 5.1.1(i) 規定 App「必須在 App Store Connect 中繼資料中包含其隱私政策的連結」,許多情況下還必須在 App 內提供。這不是建議,缺了,提交就會被擋下。
- 用一句話定義你的 MVP 範圍
- 確認你需要隱私政策(幾乎一定需要)
- 準備好支援 URL(Apple 準則 1.5 要求)
- 如果有歐盟或土耳其使用者,檢查 GDPR/KVKK 適用性
- 決定原生或跨平台技術架構
MVP 開發週
MVP 開發週要決定的是什麼真的會上線、什麼會被砍掉,而誠實的答案是:被砍的比創辦人以為的多。分析與崩潰回報要在開發期間就接上,不是上線之後。上線後才補裝,等於丟掉你驗證第一個假設正需要的那批資料。
我們從 v1 範圍裡實際砍掉的,大部分時候,就是所有跟「這次要驗證的那一件事」無關的東西。推播通知、社交登入、有六個開關的設定畫面,全都可以等。創辦人會抗拒,這可以理解;感覺像在推出一個沒做完的東西。它本來就沒做完。這就是重點。
正如一位上線過好幾款 App 的創辦人在一篇 dev.to 檢查清單文章裡說的,早期略過意見回饋機制是他「每次都後悔」的錯誤。現在就把它接進去,不要等到第一則評論出現才補。如果你想加快範圍界定本身的討論,在開發開始之前先看看用 AI 加快範圍界定值得一讀。
- 在第一個 TestFlight/內部版本之前埋好分析
- 接上崩潰回報(Sentry 或 Firebase Crashlytics)
- 在 App 內建一個意見回饋機制
- 砍掉所有與你正在驗證的核心無關的功能
- 寫出第一個版本字串(見下方版本控制)
提交前那一週
這是每一份競品檢查清單都完全跳過的階段,也是最容易避免的延誤發生的地方。App 的語意版本控制遵循 MAJOR.MINOR.BUILD 格式(1.0.0,然後修補是 1.0.1,功能更新是 1.1.0)。現在就選定一個規則,因為不一致的版本號碼會同時搞混應用程式商店和你自己的團隊。
分階段發布會先把更新推送給一小部分使用者(通常是 1%,然後 10%,然後 50%),之後才推到所有人。我們審過的三份競品檢查清單中只有一份提到它,而且還只是一筆帶過。如果有崩潰漏網,分階段發布能把影響範圍限制住,而不是一次打中 100% 的使用者。
我們在放行客戶提交案之前會問的問題很簡單:關鍵路徑現在、此時、在真機上跑得通嗎?不是模擬器。無崩潰率可以接受嗎?商店頁面的素材真的是最終版,不是佔位符嗎?
- 確認你的版本號碼遵循一致的規則
- 再從頭到尾測試一次關鍵路徑
- 如果商店支援,準備好分階段發布的百分比
- 提交前確認無崩潰率可以接受
- 截圖並備妥所有商店頁面素材
提交日:iOS 與 Android
iOS 和 Android 的提交會因為不同的原因失敗,而把它們當成同一張檢查清單處理,是我們見過的最大宗上架前延誤原因。Apple 的 App Store 審查準則和 Google Play 的開發者政策各自列出具體、可逐項檢查的要求,而多數創辦人都是在收到拒絕信之後才知道它們存在。
在我們自己的提交案裡,最常絆倒第一次上架的創辦人的兩件事,是帳號刪除要求和連不上的支援 URL。如果你在提交前發現,兩者都是一行就能修好的問題。如果沒發現,兩者都會自動被拒。
Apple 的 App Store 審查準則寫得很具體:準則 5.1.1(v) 要求支援帳號建立的 App 也必須提供 App 內帳號刪除,準則 1.6 涵蓋資料安全揭露,準則 1.5 要求可正常運作的支援 URL。在 Android 方面,Google Play 的開發者政策要求帳號刪除請求同時要有 App 內路徑和一個公開網頁 URL。Google 在 2023 年 4 月宣布這項要求,為資料安全表單的資料刪除問題設定 2023 年 12 月 7 日的期限,並允許延期到 2024 年 5 月 31 日,之後不合規的 App 將面臨執法。這不是某種對小型 App 既往不咎的舊規定;它現在仍然適用。
兩套提交流程在機制上也有分歧,不只是紙面上。在 iOS,你透過 Xcode 或 Transporter 上傳建置版本,App Store Connect 會處理它(從幾分鐘到一小時以上都有可能),接著你可以把它送到 TestFlight 給內部和外部測試者,或直接提交 App 審查。TestFlight 不是可有可無的雜事:它是 Apple 預期你用來攔下審查人員會拿來拒絕你的那些 bug 的方式。在 Android,Google Play Console 用軌道運作,而不是單一提交,依序經過內部測試,然後封閉或開放測試,再到正式版,每一軌都有自己的受眾和自己的晉級步驟。分階段發布只會在你要更新一個既有的正式版時才出現。正如 Google 自己的發布文件所說,「如果你推出的是第一個版本,就不會看到選擇發布百分比的選項」,所以不要把你生平第一次上架規劃成百分比爬坡,那是之後的事。
真正擋住多數首次提交的,是文件,不是程式碼。Apple 針對一份明列的常用第三方 SDK(廣告聯播網、分析、崩潰回報工具)要求 privacy manifest,而它自己的指南對誰要負責說得很直白:根據 Apple 的第三方 SDK 要求頁面,「當你的 App 使用第三方 SDK 時,你要為該 SDK 包含在你 App 內的所有程式碼負責,並且需要了解它的資料收集與使用做法。」漏掉一個列管 SDK 的 manifest,你的建置版本就過不了 App Store Connect。Google Play 對應的文件關卡是資料安全表單,而且除了純內部測試版本之外,每一軌上的每個 App 都必填:根據 Google Play 的資料安全文件,「所有在 Google Play 上發布 App 的開發者都必須完成資料安全表單,包括封閉、開放或正式版測試軌上的 App。」填錯了,Google 也講得很明白:一旦你宣告的行為和 App 實際行為之間出現落差,它「可能會採取適當行動,包括執法行動」。
還有第三種失敗模式跟政策條文完全無關:審查人員根本沒辦法測試你的 App。Apple 的準則 2.1 直接寫明:「如果你的 App 包含登入,請附上示範帳號資訊(並且把你的後端服務打開!)。」沒有可運作的示範帳密、審查期間後端沒上線、支援 URL 連不上,無論你的帳號刪除流程多合規,都會被打回。如果你的 App 有任何部分藏在付費牆或登入門檻後面,寫一份給審查人員的說明,講清楚要怎麼進去。這是兩分鐘就能完成的步驟,第一次上架的創辦人卻一直跳過它。
還有一個只屬於 Android 的關卡也該放在同一個討論裡:目標 API 等級。Android 自己的開發者文件指出,「新的 App 和 App 更新必須以」目前要求的 Android API 等級「為目標,才能提交到 Google Play」,而且「過時的 App 無法被執行較新 Android 版本的裝置上的新使用者取得。」它跟帳號刪除或資料安全毫無關係,但它照樣擋住提交,而且這類要求每年都會變,所以建置發布版本之前先查一下目前的數字。
| 要求 | iOS (App Store) | Android (Google Play) |
|---|---|---|
| 帳號刪除 | 需要 App 內路徑(準則 5.1.1(v)) | 需要 App 內路徑和公開網頁 URL(2024 年 5 月 31 日後執法) |
| 隱私政策 | 需要,並附上連結(準則 5.1.1(i)) | 需要,在資料安全表單中附上連結 |
| 支援聯絡方式 | 需要支援 URL(準則 1.5) | 需要支援電子郵件/URL |
| 資料揭露 | 資料安全區段(準則 1.6) | 資料安全表單(必填) |
| 分階段發布 | 可用分階段發布,須手動啟用 | 可用分階段發布,須手動啟用 |
| 審查時程 | 以我們的提交案來看通常一兩天,被標記時較久 | 通常比 Apple 快,但有波動 |
這個搜尋詞下排名最前面的檢查清單,沒有一份引用過任何一個 App Store 準則條號。我們有,因為靠猜來合規,就是上架時程一次延誤一週的原因。如果你正在建立更完整的資料處理姿態,上架前的資料處理檢查清單涵蓋了這裡不重複的安全面。
iOS 提交檢查清單:
- 隱私政策 URL 已上線且可存取
- App 內帳號刪除路徑已上線(準則 5.1.1(v))
- 支援 URL 已上線(準則 1.5)
- 資料安全揭露已完成(準則 1.6)
- 公開提交前 TestFlight 版本已通過核准
Android 提交檢查清單:
- Play Console 中的資料安全表單已完成
- App 內帳號刪除路徑已上線
- 帳號刪除請求的公開網頁 URL 已上線(Google Play 要求)
- 已設定分階段發布百分比
- 目標 API 等級符合目前 Play 的要求
上架日
上架日是你的 App 真正對真實使用者開放的那一天,它不同於提交(提交可能早幾天甚至幾週),也不同於第一週(第一週是善後)。分階段發布監控在第一天的作用,是告訴你該繼續擴大,還是按下暫停。
前 24 小時,每小時看一次你的 App Store Connect 或 Play Console 儀表板,不是每天。如果無崩潰率掉了,你要在一小時內知道,不是隔天早上又有一百個使用者撞上同一個 bug 才知道。備好一個可回退的版本。我們用在 AI 功能上的加固、穩定、部署紀律,在這裡同樣直接適用。
- 前 24 小時每小時監控無崩潰率
- 支援管道有人值守、隨時就緒
- 確認分階段發布照計畫擴大
- 備好一個回退版本,以防重大 bug
上架後的第一週
上架後的第一週,是大部分實際工作發生的地方,儘管幾乎沒有人為它做計畫。每日崩潰報告檢視和回覆第一批商店評論,比你在上架當天做的任何事都重要。
「上架本身沒有你以為的那麼重要。重要的是接下來幾週你做什麼,」一位創辦人在他自己的上架後檢查清單裡寫道。這就是第一週的誠實版本:快速修補、親自回覆,然後在真正的使用者替你測試之前,先確認你的資料刪除流程真的跑得通。如果你現在開始想知道這一切建置和維護要花多少錢,上架後維護與更新的預算規劃是它的配套文章。這篇講的是準備就緒;那篇講的是帳單。
- 第一週每天檢視崩潰報告
- 親自回覆你的前 10 則商店評論
- 重大 bug 在 48 小時內分類並修補
- 確認你的資料刪除請求流程真的從頭到尾跑得通
- 定下對照原始 MVP 假設檢查分析資料的節奏
Techsy 的做法
我們對每一個客戶建置案的提交前審查都用同一套方式:在放行提交之前,我們會問,關鍵路徑在真機上跑得通嗎、無崩潰率撐得住嗎、以及每一個準則要求的流程(帳號刪除、隱私政策、支援 URL)是否真的能運作,而不只是在 mockup 裡存在。清單很短,但決定一個 App 能不能第一次就通過審查的,就是這張清單。
如果你寧可讓走過這些準則的人來處理你的提交,我們的行動 App 開發流程就是圍繞這個提交前審查步驟打造的。它不是取代你自己該做的功課,而是在你做完功課之後,我們接手做的事。
常見問題
什麼是 MVP?為什麼它對上架檢查清單很重要?
MVP 是能夠用真實使用者驗證一個核心假設的最小產品版本。它在這裡之所以重要,是因為這張檢查清單上的每一個項目都會隨範圍放大,MVP 收得越緊,提交時可能出錯的東西就越少,第一週要埋監測、要監控、要修補的功能也越少。
App 為什麼會被 App Store 拒絕?
最常見、也最可以預防的原因是:缺少隱私政策連結(準則 5.1.1(i))、沒有 App 內帳號刪除(準則 5.1.1(v)),以及連不上的支援 URL(準則 1.5)。這些都不需要工程功夫來修,它們是檢查清單項目,不是 bug。
如果我的 App 沒有加入帳號刪除選項,會怎樣?
在 iOS,如果你的 App 支援帳號建立,準則 5.1.1(v) 讓這件事成為自動拒絕的理由。在 Android,Google Play 要求 App 內和公開網頁兩條刪除路徑,不合規的 App 在 2024 年 5 月 31 日延期期限過後面臨執法,漏掉它會在兩個平台上擋住提交。
新創的行動 App 需要隱私政策嗎?
需要,幾乎一定需要。Apple 在準則 5.1.1(i) 下要求附上隱私政策連結,Google Play 則要求在資料安全表單內提供。只要你收集任何使用者資料,哪怕只是註冊用的電子郵件,你就需要在提交之前備好一份。
提交到 App Store 和 Google Play 有什麼差別?
Apple 的審查以準則條文(5.1.1、1.5、1.6)和真人審查員為核心;Google Play 則倚重資料安全表單和自動化檢查。帳號刪除要求精神相似,但機制不同;見上方的對照表。
應用程式商店審查實際上要多久?
兩家商店都沒有公布保證時程,所以你讀到的任何數字都只能當成粗略預期,不是承諾。在我們自己的客戶提交案中,Apple 的核准通常在一兩天內送達,任何碰到帳號刪除或資料揭露的案子則較久。Google Play 通常比較快。無論如何,排上架日時都要留出餘裕。
什麼是分階段發布?我該用嗎?
分階段發布會先把更新推送給一小部分使用者,然後逐步擴大,而不是一次推到 100%。只要商店支援就該用;它能限制在你暫停並修復之前,有多少使用者撞上 bug。
提交 App 一定需要支援 URL 嗎?
需要。Apple 的準則 1.5 要求提交時附上一個可運作的支援 URL,Google Play 同樣預期有支援聯絡方式。這裡放一個死連結或沒人看的信箱,是一個簡單、完全可以避免的被拒原因。
App 上架後第一週該監控什麼?
每天看崩潰報告、你的前十則商店評論,以及你的資料刪除請求流程是否真的從頭到尾跑得通。這也是你開始拿真實使用資料,對照你的 MVP 當初要驗證的假設的時點。
GDPR 或 KVKK 跟小型新創的 App 有關嗎?
如果你在歐盟有使用者,無論你的公司多小,GDPR 都適用。如果你在土耳其有使用者,KVKK 同樣適用。兩部法律都沒有小型新創豁免,所以要在範圍界定階段就檢查適用性,而不是等你有真實使用者資料要保護之後。
關於作者
Mert Batur 是 Techsy.io 的共同創辦人,團隊為 B2B 客戶推出 AI 代理、自動化系統和語音/SDR 流程。他寫的是 Techsy 團隊在生產環境實際使用的 LLM 工具架構。在 LinkedIn 上連結。
結論
一份新創行動 App 檢查清單,只有在具體到今天就能執行的程度,才配存在:用一句話定義你的 MVP、在開發之前埋好分析、在提交前一週檢視你的版本規則,以及把 iOS 和 Android 檢查清單拆開,而不是當成同一張清單。光是帳號刪除和隱私政策這兩項,就占了我們見過的大部分可避免拒絕。
把檢查清單印出來,一個階段一個階段走完,而且不要跳過上架後的第一週,那是每一份競品檢查清單都漏掉的部分,也是真正決定你的上架能不能站穩的部分。如果你想在送出提交之前多一雙眼睛幫你看過,取得免費諮詢 →