第一次送 app 上 App Store，最怕的不是寫不完，是送出去之後被拒，而你看不懂它在講什麼。
這篇不是把 App Store Review Guidelines 抄一遍。是我自己的 app 實際被拒的兩個原因、每一個的真正根因，以及之後我固定會檢查的六件事。
被拒的那一次，同時中了兩條
2026 年 9 月，收藏庫第二個 build 送審被拒。回信裡有兩條獨立的理由——不是一條，是兩條同時成立。兩條都跟程式寫得好不好無關。
第一條：Guideline 2.1(a) — 打開就閃退
審查員打開 app，直接崩潰。
根因是這樣的：那次出 release build 的時候，漏帶了一個編譯參數。這個參數負責把 Google 登入的 client id 傳進去；漏了它，那段程式在 release 模式下拿不到值，一開機就崩。
而在我自己機器上跑 debug 版，一切正常——因為 debug 版走的是另一條設定路徑。
教訓不是「要測試」，是「要測你真正送出去的那一個檔案」。debug 版開得，跟你上傳的那個 build 開得，是兩件事。
第二條：Guideline 4.1(a) — 截圖裡有個名人的名字
這一條我完全沒想過。
上架截圖裡面，有一條示範用的收藏，標題是一首很有名的歌。Apple 判定這是未經授權利用第三方知名度。
我當時的盲點是：以為審查看的是 app 本身。但截圖和示範資料都算 metadata，一樣要過審。你在截圖裡放什麼，等於你在商店頁面上聲稱了什麼。
名人、藝人、KOL 的名字或樣貌；知名歌曲、電影、劇集的標題；其他 app 的品牌 logo 當成內容。平台名稱本身沒問題——如果你的 app 真的支援那個來源。
修法沒有捷徑：開一台全新、什麼資料都沒有的模擬器，逐條放回自己的示範內容，重新拍一次。
附帶好處是截圖乾淨了很多。之前那批混著測試殘留，有個叫 ADB_EDIT_Ricky 的測試人物在裡面——就算 Apple 不拒，那張也不該出街。
之後我固定檢查的六件事
- 截圖裡有沒有任何不屬於你的東西 名人、歌名、劇名、其他 app 的 logo。放大逐張看一次，當自己是審查員。
- 示範資料有沒有測試殘留 名字叫 test、asdf、或某個同事名字的假資料。最好的做法是用全新模擬器重拍。
- 你上傳的那個 build 真的開得 不是 debug 版開得就算。release 版本自己裝一次、開一次。
- 版本號有沒有 bump 忘了 bump，上傳會直接被擋，但錯誤訊息未必講得清楚。
- 新功能有沒有漏填必填欄位 加了新權限、新的 App 內購買、新的資料類型，通常都會多出必填欄位。送出前那一版審查草稿會逐層揭示，要逐層看完。
- 按了「提交」之後，回頭確認狀態真的變了 這條我吃過虧：按完就當送了，等了兩天，才發現狀態根本沒動。「按過掣」不等於「已送出」。去查一次狀態，或用 API 確認。
被拒之後，不要立刻重送
被拒之後有一個順序問題容易踩：如果上一次的 review submission 還卡在未解決狀態，你直接再送，會拿到一個看起來像「暫時性問題、稍後再試」的錯誤。
那個訊息是誤導的。它不會自己好。要先把上一次的項目標記為已解決，才開得了新的提交。
順帶一提：App Store Connect 有不少錯誤訊息都寫成「請稍後再試」，但實際上是狀態限制，重試一百次都不會成功。撞到這種訊息，先查是不是狀態問題，不要真的去等。
最後一件事
兩次理由，一次是漏了參數，一次是截圖裡有個名字。兩次都不是「程式寫得不夠好」。
第一次送審的人通常把力氣全放在功能上，然後在這些周邊的地方翻車。上面六件事花不到半小時，但省的是一輪三到七天的來回。