App 上架完整檢查清單：送審前準備、退件原因與上線後節奏
App 開發完成、測試也過了，結果卡在上架這一關拖了好幾週——這在第一次做 App 的團隊身上非常常見。
原因不難理解：上架牽涉的不只是程式，還包括帳號、法律文件、行銷素材與商店規範，而這些工作分屬不同人負責，常常沒有人統籌。這篇把整個流程拆成「送審前、送審中、上線後」三段，讓你知道每一段該由誰準備什麼。
送審前：五件必須先備妥的事
一、開發者帳號
兩大商店都需要先有開發者帳號才能提交。這是最容易被低估的前置作業，因為它涉及身分驗證與文件審核，不是註冊完就能立刻使用。
要注意的重點：用公司名義申請、由公司統一保管帳號與憑證、指定不只一位可存取的人。帳號綁在某位員工的個人信箱上，是日後最常見的麻煩來源。至於費用、驗證文件與審核時間，各商店的規定會調整，一律以官方最新說明為準。
二、隱私政策與資料揭露
現在兩大商店都要求說明 App 蒐集哪些資料、用途是什麼、是否提供給第三方。這不只是放一個連結就好，商店頁面上通常要逐項勾選資料類別，而且必須和 App 實際行為一致。
實務上的做法是：先請開發團隊列出 App 實際會取得的資料項目與用途（包含第三方套件蒐集的部分），再據此撰寫隱私政策，最後對照填寫商店的揭露表單。順序反過來寫，很容易出現文件與實際不符。涉及個人資料的責任歸屬建議請律師確認，不要直接沿用網路上的範本。
三、權限申請要有理由
只申請真正需要的裝置權限。相機、定位、通訊錄、麥克風這類敏感權限，如果 App 裡找不到對應的功能，審核時會被質疑。同時要在使用者第一次被詢問時說明用途，不要在開啟 App 的瞬間一次要求一大串。
四、商店頁面素材
這一塊常被當成開發的附屬品，實際上它直接決定使用者要不要下載：
- App 名稱與副標：包含使用者真的會搜尋的字詞，但不要堆砌關鍵字
- 截圖：前兩張最重要，要能一眼看懂這個 App 解決什麼問題，建議加上簡短說明文字
- 描述文案：開頭幾行在未展開時就會顯示，重點放前面
- 圖示：小尺寸下仍要清楚辨識
- 年齡分級資訊：依實際內容誠實填寫
各商店對尺寸、數量與字數的規格會調整，製作前先查官方最新規範，避免重做。
五、測試範圍要涵蓋真實裝置
模擬器測起來正常，不代表實機沒問題。送審前至少要完成：不同螢幕尺寸與系統版本的顯示檢查、網路不穩或離線時的行為、首次安裝與從舊版更新兩種情境、以及登入、付款等關鍵流程的完整走查。
驗收該怎麼安排、由誰驗、什麼算通過，可以參考軟體驗收測試 UAT 指南的做法，把標準寫下來再開始測。
送審時：把審核人員當成第一個使用者
審核人員拿到的是一個陌生 App，如果他無法在幾分鐘內順利使用，退件機率就會上升。
提供可用的測試帳號。 如果 App 需要登入才能看到主要功能，務必附上有效的測試帳號與密碼，並確認在送審期間不會過期或被鎖定。這是最常見也最冤枉的退件原因。
寫清楚審核備註。 如果有需要特殊條件才能觸發的功能（例如需要實體設備配合、或限定地區才能使用），在備註欄說明，並提供操作步驟。
確認所有連結可用。 隱私政策、服務條款、客服聯絡方式的連結都要能正常開啟。
功能要和描述一致。 商店頁面寫了的功能就要做得到；還沒完成的功能不要先寫上去。
常見退件原因的幾種類型
與其背誦條文，不如理解平台在意什麼。常見退件大致落在這幾類：
| 類型 | 背後的邏輯 | 預防方式 |
|---|---|---|
| 資訊不完整 | 審核人員無法驗證 | 測試帳號、備註、連結全部先自檢 |
| 隱私揭露不符 | 使用者知情權 | 資料清單先由工程確認再寫文件 |
| 權限過度索取 | 最小必要原則 | 刪掉沒有對應功能的權限 |
| 內容與描述不符 | 避免誤導 | 文案以實際完成的功能為準 |
| 付費機制不合規 | 平台商業規則 | 規劃期就確認金流方式是否被允許 |
| 完成度不足 | 使用者體驗底線 | 不送測試性質、功能殘缺的版本 |
其中「付費機制」最需要提早釐清。數位內容、訂閱、實體商品、線下服務適用的規則不同，而規則會隨平台政策調整。這件事應該在需求階段就確認，因為它可能影響整個商業模式設計，不是上架前才處理的細節。App 專案的成本結構與這些前置工作的關係，可以對照App 開發費用完整指南一起看。
上線後：真正的工作才開始
版本節奏
建議把更新分成兩種：修正類遇到影響使用的錯誤就儘快發布；功能類配合開發節奏定期釋出。NETVANA 的開發流程以兩週為一個 Sprint、每個週期結束提供可操作的 Demo，上線後同樣可以沿用這個節奏安排更新批次。
另外要記得，作業系統每年改版，平台對開發工具與相容性的要求也會調整。長期不更新的 App 會逐漸出現異常，甚至不再符合上架條件。把版本維護排進年度預算，而不是當成臨時支出。
評論回覆
商店評論是公開的，新使用者會在下載前看到。回覆的原則和社群客服一致：先確認對方遇到的問題、說明已知狀況或修正時程、提供可以聯繫的管道，不要和使用者在公開版面爭辯。回覆的語氣與結構可以參考社群客服公開回覆指南。
要特別強調的是：不要購買評價、不要用人頭帳號洗好評、不要以獎品換取指定星數。這類操作違反平台規範，可能導致 App 被下架；在台灣，若涉及有償而未揭露的推薦，也可能踏入公平交易委員會《對於薦證廣告之規範說明》與 2023 年修正的《對於網路廣告案件之處理原則》所規範的範圍。正當做法是在使用者完成一次順利的體驗後，以不干擾的方式邀請評價——邀請時機與話術可以看如何請顧客留下評價。想同時規劃 App 的口碑佈局，可以看App 與手遊口碑行銷。
上線後要盯的數字
初期建議至少看四件事：安裝後的啟用比例、關鍵流程的完成情況、崩潰與錯誤回報、以及使用者評論中反覆出現的主題。這些訊號會告訴你下一版該修什麼，比內部討論更有依據。
一張可以直接用的檢查清單
送審前逐項確認：
- 開發者帳號由公司持有，憑證有備份，不只一人可存取
- 隱私政策已上線、連結可開、內容與實際蒐集項目一致
- 商店資料揭露表單填寫完成，含第三方套件蒐集的部分
- 僅申請有對應功能的權限，並有使用前說明
- 圖示、截圖、名稱、描述依官方最新規格製作完成
- 實機測試涵蓋多尺寸、多系統版本、離線情境、更新安裝
- 測試帳號可用且不會過期，審核備註寫清楚特殊條件
- 付費與訂閱機制已確認符合平台規則
- 客服聯絡管道與問題回報方式已就緒
- 版本更新與維護責任已納入合約與預算
上架流程本身不難，難在它橫跨開發、法務、行銷三個角色，任何一環沒人認領就會卡住。把上面的清單指派到人、寫上日期，多數延誤都能避免。
如果你的 App 正要進入上架階段，或還在規劃想先確認商業模式會不會撞到平台規則，與 NETVANA 討論你的 App 專案。NETVANA 採先諮詢再報價、沒有固定套餐，專案費用結清後原始碼與文件完整移交；各階段的交付內容可以看軟體開發流程。
延伸閱讀：想先估算預算與時程，看App 開發費用完整指南；不確定第一版該做多少功能，看MVP 最小可行產品開發指南；準備安排驗收，看軟體驗收測試 UAT 指南；送審被退件，是時程失控最常見的原因之一，可以看軟體專案為什麼延誤；選定原生 App 之後才會用到上架流程，可以看做 App 還是網頁版。
