這篇接續正式三十天挑戰之後，紀錄《異世界救援》第一次送 iOS 審核的真實過程。
原本以為 Android 因為需要 12 個測試者連續測試 14 天會比較慢，沒想到 iOS 遇到全新審核問卷，反而也落入了等待的大坑。

一、凌晨送審，6 小時後「已被拒絕」

送審後不到一天就進入「審查中（In Review）」，但神奇的是，狀態在同一分鐘內從「審查中」瞬間變成「已拒絕（Rejected）」。

退件類別是：2.1.0 Performance: App Completeness

兩狀態的時間戳記在同一分鐘。看到這個時間差，我猜測這根本還沒進入「真人人工審查」階段，而是直接被 Apple 的自動化系統（Bot）篩檢退件。面對每日暴增的送審量，Apple 似乎在第一關就設了自動化攔截機制——只要是特定條件的新 App，就先秒退件並丟出這份問卷，等到開發者把影片與說明補齊後，才真正交給審查人員人工測試。

看到「App Completeness」，我的第一反應是：程式哪裡不完整？有重大 Bug 嗎？

打開信件才發現，標題寫著 Guideline 2.1 - Information Needed - New App Submission。信裡完全沒有指出任何具體畫面瑕疵，整封都是制式模板，要求我回答 6 個問題，並要求將回答同步貼進 App Store Connect 的「App 審查資訊」備註欄，供未來每次送審參考。

📋 Apple 要求回答的 6 個核心問題：

1. 實機螢幕錄影：使用最新版 OS，從點開 App 亮屏開始拍攝，呈現完整操作流程（含帳號註冊/登入、IAP 付費或用戶生成內容）。
2. 用途與目標族群：App 解決什麼問題、提供什麼核心價值，主要使用者是誰。
3. 設定與主要功能：如何設定、如何進入主功能，以及相關的測試帳密或示範檔案。
4. 外部服務清單：列出提供核心功能的第三方服務（如：資料庫、第三方登入、金流、AI API 等）。
5. 地區差異：不同地區的功能或內容是否有差異？或各地區皆一致？
6. 管制產業與第三方素材：是否涉及高度管制產業，或使用受保護的第三方素材（需檢附授權證明）。

原本以為是程式壞掉，結果收到的是一份必須補交的「新 App 詳細身分調查表」。

二、這是針對我，還是大家都會遇到？

收到退件的第一時間，我最想釐清的是：這是常態？還是特例？

我透過 Claude Code 搜尋了相同標題的案例，找到了幾個 GitHub Issue 與 Reddit 討論區：

• m96-chan/iOSSH Issue #48（2026-09-17）：第一次送審即被要求補交審查資訊。
• sharneng/spliit2go Issue #184（2026-10-05）：與我同一天，同樣遭遇補單要求。
• tesserix/mark8ly PR #931（2026-09-24）：將 Apple 要求的問卷內容整理成審查備註草稿。
• tesserix/mark8ly PR #944（2026-09-24）：整理審核用螢幕錄影的分鏡清單，相當具參考價值。
• Reddit 社群討論：早在幾個月前，開發者社群就開始陸續出現類似討論。

不過，這些都是開發者端經驗分享，Apple 官方並沒有公開正式文件說明這份問卷的觸發條件與適用範圍。

三、對照 Review Guidelines：2.1 真的有寫這些嗎？

既然題目是固定的，那能不能事先在審核指南裡看到並預防？

我重新對照了 Apple 的 App Review Guidelines（最後更新日期：2026 年 6 月 8 日）。

結論是：從 2.1 條文本身，完全看不出需要提交這 6 項資料。

• 2.1(a)：要求送審版本完整、經實機測試，並提供測試帳號。
• 2.1(b)：規範 App 內購買（IAP）。

信中的 2.1 Information Needed 更像是 Apple 用來歸類補件要求的「通用分類標籤」，這 6 題並非直接出自 2.1 的條文內容。

📊 審核題目與官方指南對照表：

這就是我標題寫「規則之外」的原因：我收到了一份制式補件問卷，但這份問卷的要求卻無法在公開指南中找到直接對應的清單。

四、為什麼是 2026 年？背後的時代背景

這個系列文在記錄 Vibe Coding 的實作過程。查到這裡，又繞回了 AI 開發工具。

根據 TheNextWeb 的報導，因為 Vibe Coding（AI 輔助寫程式）的爆發，帶動 App Store 每日送審量激增了 84%，Apple 也因此開始嚴格加強審查機制。

當大量的 App 湧入，審核人員需要極快速地理解每一個 App 的真正用途與運作機制。要求開發者直接提供一長串問卷與一段實機操作錄影，確實是讓審核人員省時、快速進入狀況的最快手段。

（備註：此為根據市場趨勢與社群現狀推測，Apple 官方未證實該問卷與 Vibe Coding 有直接關聯。）

五、 App Store Connect 介面踩坑紀錄

除了問卷之外，這次還遇到了兩個跟程式碼無關的 UI/UX 小坑：

坑 1：附件不接受大寫副檔名（.MP4）

iPhone 側錄後經由 AirDrop 傳到 Mac 的影片檔名通常是 .MP4。上傳到 App Store Connect 時系統會跳錯表示「不支援此檔案格式」。

• 解法：手動把副檔名改為小寫 .mp4 即可順利上傳。

坑 2：備註欄「看得到文字」，不代表「有存進去」

重新提交後我回頭檢查，發現「審查備註欄」居然是一片空白！明明剛才已經貼貼上了，但剩餘字數仍顯示 4,000，表示剛才根本沒存成功。

• 解法：重新貼上內容後，務必手動點選「儲存」，確認剩餘字數變成（例如）745 且儲存按鈕變灰，才算是真正寫入資料庫！

💡 小提醒：框裡看得到文字，絕對不代表系統已經幫你儲存好了。

六、補件之後：等待的原則與心態建立

資料補齊並重新提交後，狀態回到「等待審查（Waiting for Review）」。

翻閱 Apple Developer Forums 後發現，補件後的等待時間極度隨機：有人等了 15 天，有人等了超過 25 天。 updated 版本通常幾小時或一兩天就好，但全新 App 的第一版審核通常需要漫長的耐心。

幸好這不是有嚴格時限的 App，即使審核稍微卡住、慢慢等其實也沒關係。不過，為了避免自己在漫長的等待與焦慮中亂了陣腳，我還是給自己定了三條心態原則：

1. 不要因為等得久就隨便撤回重送
   撤回後重新提交會導致排隊順序重新計算。除非發現了重大瑕疵必須更換 Build，否則絕不輕易撤回。
2. 設定合理詢問點（兩～三週）
   如果卡在等待審查超過 2~3 週完全沒有動靜，才透過 App Store Connect 的「聯絡我們」進行詢問。
3. 絕不濫用「加急審核（Expedited Review）」
   加急審核主要是針對已上架 App 出現緊急致命 Bug 等特殊情況。正如官方指南所提醒：若濫用加急機制，未來可能直接被取消申請資格。第一次上架等得久並不符合加急條件。

補充：換 Build 重新送審的注意事項

後來為了修正戰敗畫面的瑕疵，我不得不取消舊提交並更換新的 Build。

結果發現：Apple 原本的提問、以及我在舊提交對話框中的回覆與錄影，都會留在已移除的舊提交紀錄裡；新提交的訊息串會變成全新的空頁面！

幸好「審查備註欄」的內容是跟著 App 版本走，沒有遺失，錄影也有另外附在備註欄連結中。

結語

到底事先把這 6 題資料填寫在備註欄，能不能讓下一款 App 順利避開「補件問卷」直接通關？

目前沒有標準答案。等下一次送審新 App 時，答案自然揭曉！