[IND] 5 分鐘閱讀OraCore 編輯部

Apple 擋下 iPhone 上的 vibe coding App

Apple 以 App Store 規則擋下會下載或執行生成程式碼的 vibe coding App,Replit、Anything 都受影響,焦點在安全與審核邊界。

分享 LinkedIn
Apple 擋下 iPhone 上的 vibe coding App

Apple 正在阻擋會下載或執行生成程式碼的 iPhone vibe coding App,爭點集中在 App Store 規則 2.5.2。

這件事不是單純的審核爭議。它直接碰到 AI 寫程式的商業模式。講白了,誰能把 AI 變成可用的軟體,誰就更容易收錢。

Apple 這次卡住的,不是聊天機器人。它卡的是能產生程式、預覽程式,甚至執行程式的工具。對開發者來說,這很像把刀磨好,卻不准切菜。

項目內容
規則App Store Guideline 2.5.2
Anything 的審核狀態先通過,4 月初又被移除,之後再被拒
報導日期2026 年 5 月 5 日

Apple 為什麼要擋

訂閱 AI 趨勢週報

每週精選模型發布、工具應用與深度分析,直送信箱。不定期,不騷擾。

不會寄垃圾信,隨時可取消。

Apple 的理由其實很直白。它不想讓 App 在審核後,再去下載或執行會改變行為的程式碼。這在一般軟體世界很合理,因為它能減少惡意程式混進來。

Apple 擋下 iPhone 上的 vibe coding App

問題是,vibe coding App 本來就靠這個吃飯。它們不是單純輸出文字。它們會生程式、跑預覽、再讓使用者即時調整。

對 Apple 來說,這就踩到審核制度的核心。因為一旦 App 能在上架後改變核心功能,審核就不再像以前那麼好控管。

我覺得 Apple 的立場不意外。iPhone 一直是高度封閉的平台。它要的是一致性,不是開發者想怎麼玩就怎麼玩。

  • 規則 2.5.2 直接碰到程式碼下載與執行。
  • vibe coding 的核心功能就是動態生成與預覽。
  • Apple 想把風險擋在裝置外面。
  • 審核制度一旦鬆動,邊界就會變得很模糊。

Replit 和 Anything 為什麼最慘

這波最常被拿來舉例的,是 ReplitAnything。Replit 說,Apple 擋下了它的更新。Anything 則更慘,因為它先被核准,後來又被移除,接著再被拒。

Anything 的共同創辦人 Dhruv Amin 在 Financial Times 的說法很直接。他說公司一直處在「不明朗」狀態。這句話很有感,因為審核標準如果一直飄,開發團隊根本很難排程。

“Either they should stop enforcing the rules in this weird way, or they should update the guideline to let this use case emerge.” — Dhruv Amin, Anything 共同創辦人

這句話其實把問題講穿了。Apple 不是只說不行。它是一下放行,一下又收回。開發者最怕的就是這種來回。

Anything 的案例尤其刺眼。它在 4 月初曾經上架,結果一天內就被移除。Apple 的理由是它違反了不能下載程式碼的規則。後來團隊拿掉預覽功能,卻又被以「功能太少」拒絕。

  • Replit 說自己對拒絕更新感到失望。
  • Anything 經歷了通過、移除、再拒絕。
  • Apple 對外沒有公開回應這次反覆。
  • 開發者最怕的不是拒絕,是標準不穩。

這對 AI 寫程式生意有多傷

這件事不只是 App Store 規則問題。它直接影響 AI 寫程式的變現路徑。因為能把 AI 變成可操作的開發工具,才有機會讓付費意願真的出來。

Apple 擋下 iPhone 上的 vibe coding App

如果手機上不能跑預覽,產品體驗就會差一截。你可以想像一下,工具幫你生出一段程式,卻不能直接看結果。那種感覺很像買了電鑽,卻只能看說明書。

但 Apple 也不是完全沒道理。AI 生成的程式碼可能有 bug,也可能有安全漏洞。更麻煩的是,惡意內容可以混在看起來正常的功能裡。

所以這場拉扯很現實。新創想要的是新分類。Apple 想要的是舊規則先別破。

如果你是做產品的人,這裡有幾個重點:

  • 能否在手機上預覽,會直接影響產品價值。
  • 不能執行程式碼的工具,通常只能做到半套。
  • Apple 把安全放在功能彈性前面。
  • 越依賴即時預覽的產品,越容易被卡。

跟其他 AI 開發工具比,差在哪

把這件事放到整個市場看,就很清楚了。桌面版 AI 開發工具通常比較自由。手機端就沒那麼好過,因為 App Store 的限制更硬。

Cursor 這類工具,主戰場還是在桌面。它們還沒把 iPhone App 當成核心入口,某種程度也反映了這個限制。

桌面和手機的差別,不只是螢幕大小。是權限、審核、執行環境,全部都不同。這會直接決定產品能做到哪一步。

下面這個比較最有感:

  • 桌面工具通常能更快迭代。
  • iPhone App 要過 Apple 審核。
  • 會執行程式碼的功能最容易被盯上。
  • 安全優先的政策,會壓縮功能空間。

說真的,這也不是第一次看到平台跟新工具打架。只是這次打的是 AI 寫程式,大家才會特別有感。因為這不是小功能,是整個產品核心。

這背後其實是平台控制權

Apple 長期都在管 App 能做什麼。它不是單純賣手機。它是在管整個生態系的入口。誰能上架、誰能更新、誰能跑什麼,都是它的權力範圍。

這種做法有代價,也有好處。好處是安全與一致性。代價是創新速度常常被拖慢。尤其是像 vibe coding 這種還在摸索的新類別,最容易撞牆。

從產業角度看,這場爭議也在測試一件事:AI 生成內容到底算不算「新程式碼分發方式」。如果算,那很多舊規則都得重寫。

我自己的判斷很簡單。Apple 短期內不太可能全面放寬。比較可能的路,是做更細的例外條款,或要求把執行放到雲端,而不是放在裝置本機。

如果這條路走不通,iPhone 上的 AI 寫程式工具,可能會先變成編輯器、提示器、或協作介面。真正跑程式的部分,還是會留在桌機或伺服器端。

結尾:開發者接下來該看什麼

接下來最值得觀察的,不是 Apple 會不會道歉。那太天真了。真正重要的是,它會不會調整 2.5.2 的解釋方式。

如果你在做 AI 開發工具,現在就該先想好備案。把預覽搬到雲端、把執行拆出去、把 iPhone 端改成輕量控制台,這些都比硬碰硬更實際。

我會繼續盯兩件事。第一,Apple 會不會放出更明確的審核說明。第二,這類 App 會不會開始把手機端功能縮到只剩編輯與協作。這兩個答案,會直接決定 iPhone 上的 vibe coding 到底能走多遠。