AI 代寫 App 讓 iOS 審查變慢

Apple 說，約 90% 的 App 提交會在 48 小時內通過。聽起來很快。可是，現在有些開發者等了好幾天，甚至幾週。

原因很直白。AI 工具把做 App 的門檻壓低了。像 OpenAI、Anthropic、Replit，都能把自然語言變成程式碼。結果就是，送審量先爆了，審查隊列也跟著卡住。

講白了，現在不是只比誰會寫程式。是比誰能先通過 Apple 的審查。這件事對台灣獨立開發者，真的很有感。

為什麼 App Store 變得更擠

先看一個數字。Apple 說，90% 的 App 會在 48 小時內處理完。這代表大多數案子還算快。可是，只要有一小撮案子拖很久，開發者就會覺得整個流程在卡。

問題出在 AI 生成 App 的成本太低。以前你要做一個能跑的 iPhone App，得先會 Swift、UI、API 串接，還要處理錯誤。現在很多人只要丟提示詞，就能生出一個像樣的原型。能上架的東西變多，送審自然也變多。

外媒 ExtremeTech 引述 Business Insider 的說法，iOS 新 App 發布量，已經跑到大約 4 年來最快的速度。這不是小波動。這是整個供給端變厚了。

• Apple 說 90% 的 App 會在 48 小時內審完。
• 有些開發者回報，等待時間是幾天到幾週。
• Business Insider 指出，新 iOS 發布量達 4 年高點。
• AI 工具可用自然語言快速產出可運作的 App。

這種情況下，審查系統就會很痛苦。因為它不只是在看功能。它還要判斷是不是垃圾 App，是不是誤導使用者，是不是有安全風險。當送審量一口氣變大，人工審查就會先被拖慢。

我覺得這裡有個很現實的問題。很多 vibe-coded App 看起來像成品，實際上只是半成品。這種東西一多，真正要上架的正經 App 也會被掃到。

Apple 的審查壓力從哪來

Apple 的審查機制，本來就是混合模式。先靠自動化檢查，再靠人工判斷。這套流程在送審量穩定時，還算順。可是一旦 AI 工具把產量拉高，瓶頸就會浮出來。

Apple 沒有公開完整的延遲分布。外界只能看到平均值。問題是，平均值對單一開發者沒什麼幫助。你如果剛好卡在那 10%，就只能等。

Tim Cook 在 2016 年股東會說過一句話：

“Our goal is to give users a great experience and to help developers succeed.” — Tim Cook, Apple shareholder meeting, 2016

Apple 也碰到另一個麻煩。它曾經擋下某些 vibe-coding 工具的更新，理由是那些工具會下載或執行不符合規則的程式碼。Apple 的說法很清楚：它是在套用既有規則，不是在針對 AI 本身開刀。

這點很重要。因為它告訴開發者，風險不在 AI 這個標籤。風險在行為。像是動態載入程式碼、偷偷改功能、或在審查後才換內容，這些都很危險。

說真的，Apple 不是討厭 AI。它討厭的是不透明。你如果把 App 做得像黑箱，審查就會對你更不客氣。

數字一比，差距就很明顯

Apple 說 48 小時內可處理 90% 的提交。這個數字看起來漂亮。可是，對開發者來說，真正重要的是尾端延遲。因為產品發版、活動上線、訂閱續費，常常都卡在那幾天。

這也解釋了為什麼 AI 時代更需要自動化初篩。人工審查很貴，也很慢。當提交量變大，最先吃不消的，就是人力。自動化可以先擋掉明顯的垃圾、重複包、壞掉的 binary，讓審查員把時間留給真的需要判斷的案子。

如果把 iOS 和其他平台放一起看，差異也很明顯。iPhone 的分發高度集中。你要上架，幾乎只能走 Apple 這條路。這讓審查變成一個單點瓶頸。Android 雖然也有商店審核，但分發路徑比較多，壓力分散一些。

• Apple App Store Review Guidelines 是送審的基本規則。
• App Store 是 iPhone 主流分發入口。
• Android 也在加強開發者驗證與帳號控管。
• r/iOSProgramming 常有人分享審查時間與退件原因。
• Business Insider 曾報導 iOS 新發布量上升。

競品比較也很有意思。像 Apple 的優勢，是控制力強。壞處也一樣明顯。只要審查慢，所有人一起慢。這跟網路服務不同。你不能自己改 DNS 就繞過去。

我會直接說，這是平台治理的老問題。只是 AI 把問題放大了。以前一週進來一批 App，現在可能一天就湧進很多個半成品。審查員再強，也不是機器。

這波其實不是 Apple 才有的事

很多人以為，這只是 App Store 的麻煩。其實不是。這是整個軟體供應鏈的變化。AI 讓原型、測試版、甚至可上架版本的產出速度都變快了。結果就是，平台端要重新想怎麼過濾品質。

以前做 App，成本高，數量自然少。現在做 App 的門檻低，數量就會暴增。這個邏輯很簡單。你只要看 GitHub、各種 no-code 工具、還有 LLM coding assistant 的普及速度，就知道這波不會停。

但平台不會因為你用 AI 就放水。反而更可能收緊。因為 AI 產物太容易長得像真的。外觀像真的，不代表安全。功能像真的，也不代表合規。

對台灣開發者來說，這件事很現實。你可能在公司裡做的是內部工具，或是接案做 MVP。可是一旦要上架到 iOS，就得接受 Apple 的節奏。你的程式碼寫得再快，審查還是照它的表走。

所以，現在最實際的策略不是求快上。是先把風險收乾淨。不要用奇怪的動態載入。不要在送審後偷偷換功能。不要讓 metadata 跟實際內容對不上。

開發者現在該怎麼做

如果你正在做 AI 輔助的 iPhone App，我會建議你把審查時間抓寬一點。不要只看 Apple 的平均值。你要按最差情況排程。活動上線前，至少預留幾天緩衝。

另外，App 架構要盡量單純。binary 自包含最好。遠端下發程式碼這種玩法，現在很容易踩線。你如果真的需要後端控制，請把邏輯放在 API 層，不要碰審查最敏感的區域。

還有一點很重要。AI 幫你寫 code，不代表你就可以少做 QA。很多 vibe-coded App 的問題，不是功能不夠，而是邏輯太鬆。登入、付款、權限、隱私權說明，這些地方最容易出事。

我的判斷很直接。接下來 App Store 的爭點，不會是 AI 能不能寫 App。會是 Apple 怎麼證明一個 App 值得審、該不該放行、要不要更快處理正經更新。對開發者來說，現在最重要的問題是：你的 App 能不能在更嚴的隊列裡活下來？

如果答案不確定，那就別把上架時間押得太緊。先把產品做實，再來跟審查制度硬碰硬，通常比較不會翻車。