Guideline 4.2 最低功能要求:App 被拒怎麼辦
作者:Mehdi Azizi
發布於 ,9 分鐘
Guideline 4.2:App 只做到網站能做的事,Apple 就會拒絕。把一個原生功能放在核心用途,並告訴審查人員在哪裡找到。
Guideline 4.2「Minimum Functionality」會拒絕那些跟網站比起來沒有多做什麼,或內容太少、讓人不會想留著的 App。解法不是堆一堆原生功能,而是把一個原生功能放在核心用途裡,再告訴審查人員在哪裡找到它。 修正幾乎都需要一個新的 build。
我自己有在上架 iOS App:Solys、TradaZen 和 Nolera 都在 App Store 上。這篇指南根據 Apple 的官方條文(2026 年 10 月 15 日查閱),以及開發者在 Apple 論壇上公開的 4.2 被拒案例。下面提到的被拒 App 都是範例。如果你想看所有被拒原因的總覽,請改讀Apple 為什麼拒絕你的 App。
Guideline 4.2 說了什麼?
4.2 位在 App Review Guidelines 第 4 節「Design」。第一句就定下標準:「Your app should include features, content, and UI that elevate it beyond a repackaged website.」換句話說,你的 App 要提供功能、內容和介面,讓它比一個重新包裝過的網站更有價值。
條文還補了兩個概念。一個不夠實用、不夠獨特,或不夠「app-like」的 App,不屬於 App Store。而一個既沒有持久娛樂價值、也沒有足夠實用性的 App,可能會被拒。所以 4.2 看兩件事:跟網頁的差異,以及價值的多寡。
被拒訊息可能引用的子條款
| 子條款 | Apple 要求什麼 | 典型的被拒情況 |
|---|---|---|
| 4.2 | 超越一個網站 | 網站直接顯示在 WebView 裡 |
| 4.2.1 | 真正的擴增實境體驗 | 在 AR 畫面裡放一個 3D 模型 |
| 4.2.2 | 不只是行銷或連結 | 形象 App、內容聚合器、連結集 |
| 4.2.3 | 能獨立運作、下載資訊清楚 | 必須搭配另一個 App 才能用 |
| 4.2.6 | 不能是用商業範本做出來的 App | 外包廠商送審的範本 App |
補充三點。4.2.2 對型錄網開一面:「Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.」所以商品型錄可以過,廣告傳單不行。
4.2.3 有兩款。第 (i) 款要求 App 能獨立運作,不必安裝另一個 App。第 (ii) 款要求,如果 App 首次啟動時要下載資源,必須先告知下載大小並取得同意。
4.2.6 談商業範本和 App 生成服務,詳細內容在 Guideline 4.3 指南,因為它和反垃圾規則是一起的。
最常見的兩種 4.2 被拒訊息
Apple 的訊息開頭是標題「Guideline 4.2 - Design - Minimum Functionality」。接下來會說明審查人員看到的是哪一種問題。以下是開發者在 Apple 論壇公開的兩種寫法。它們是幾年前的:確切文字可能變了,但這兩大類沒變。
App 看起來像網站。「Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience.」這則發布在 Apple 論壇上的訊息有一句關鍵的話:「Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store.」
App 內容太單薄。「We found that the usefulness of your app is limited by the minimal amount of content or features it includes.」這則第二個訊息要求重新檢視概念,也承認沒有任何量化規則能定義什麼叫實用或有娛樂性。
在包起來的網站上加推播、定位和分享按鈕是不夠的:Apple 在自己的被拒訊息裡就這樣寫了。
四種典型的 4.2 被拒案例
以下四個案例是為了說明規則而設計的範例,不是真實的 App。
包起來的網站
範例:一間健身房把它的手機版網站放進 WebView,上面加一條原生分頁列。課表、預約和帳號都是網頁。審查人員看到的,就是 Safari 會顯示的東西。Apple 在它的 App Review 頁面上說過:放在 iOS App 裡的網站、沒有針對 iOS 調整的網頁內容,或有限的網頁互動,都不算高品質的 App。
我會怎麼做:把核心操作的畫面用原生重做,這裡就是課表和預約。然後加上網站做不到的事:上課前提醒、沒網路也能看課表、用小工具顯示下一堂課。
太簡單的 App
範例:一個每天顯示一句名言的 App,除此之外什麼都沒有。十秒就逛完了。4.2 提到「lasting entertainment value or adequate utility」:持久的價值,或足夠的實用性。要修正,就替核心操作加深度,而不是在旁邊加畫面。 這裡可以加:歷史紀錄、收藏、在你選的時間提醒、主畫面小工具。
AI 生成、沒有任何原生功能的 App
範例:一個文字輸入框、一個按鈕、一段以純文字顯示的 AI 回覆。Apple 不評判你用什麼工具,而是看審查人員螢幕上出現什麼。如果整個體驗放在一個網頁裡就能做到,4.2 很可能就會找上你。
AI 擅長什麼、會漏掉什麼,我在用 AI 做 App 裡有詳細說明。各種生成工具產出的格式(網頁應用或行動專案)比較,請看 Lovable、Rork 還是 FlutterFlow。
等著內容進來的空殼
範例:沒有任何商品的交易平台、空的名錄、顯示「即將推出」的動態牆。審查人員打開的是一個沒東西可看的 App。這種情況也會碰到 2.1,它拒絕暫時性內容:請看 Guideline 2.1 指南。等 App 有真實內容再送審,或提供一個已經填好資料的展示帳號。
我做的測試:「那 Safari 呢?」
送審前,我會問自己:網站能不能提供同樣的核心功能?如果可以,這個 App 就有 4.2 的風險。以下是我評估原生功能的表格。一個功能有沒有用,看它是不是服務核心操作,而不是拿來裝飾。
| 功能 | 算數的情況 | 不夠的情況 |
|---|---|---|
| 推播通知 | 帶來使用者期待的資訊 | 只是轉發你的文章 |
| 離線 | 主要內容仍然可以使用 | 只顯示一個錯誤畫面 |
| 小工具 | 顯示屬於這個人的資料 | 顯示你的 logo |
| 分享 | 可以把內容傳進你的 App | 只是分享一個連結 |
| 相機、感測器 | 是核心操作的一部分 | 只是打開你的網站 |
| 本機資料 | App 會計算、整理、記住東西 | 所有東西都在網頁上 |
Apple 的建議也是同一個方向。小工具顯示即時、一眼就能看懂的內容。通知用簡短的文字帶來有用的資訊,不是用來催人去 App 裡做某件事。
我的 App 做到了網站做不到的事
我設計每個 App 時,都會圍繞一個瀏覽器裡不存在的核心功能,或一個讓人會回來的價值。
- Solys 是鬧鐘。鈴聲透過 iOS 26 的鬧鐘服務 AlarmKit 播放:它能穿過靜音模式,就像 Apple 的鬧鐘一樣。要關掉它,得先贏一個小遊戲,而你選的 App 在起床後會繼續暫停。沒有任何網頁能讓靜音中的 iPhone 響起來。
- TradaZen 是交易模擬器:在真實日期看真實圖表、做決定、K 線逐根揭曉、排名對戰、等級逐步提升。這裡撐起 App 的不是原生功能,而是 4.2 所說的持久娛樂價值。
- Nolera 是虛擬衣櫃:你拍下衣服,App 會自動去背、分類,然後每天早上推薦一套穿搭。相機是核心操作的一部分,不是附加功能。
4.2 要的不是一張原生功能清單,而是一個讓人安裝 App、而不是打開網站的理由。
一步步修正 4.2 被拒
- 先判斷是哪一類。 網頁瀏覽:是包起來的網站。內容或功能太少:是太單薄的 App。4.2.3:依賴另一個 App,或沒事先告知的下載。
- 改產品,不是改說法。 只辯解卻什麼都沒改的回覆,沒有理由能說服審查人員。把核心操作的畫面用原生重做,或補上缺少的深度。
- 準備新的 build。 問題出在 App 本身:遠端更新不夠。每次送審都要重新排隊,請看 App Store 審核時間。
- 寫能引導審查人員的審查備註。 Apple 在它的完整審查資訊頁面中,要求描述概念、功能和目標使用者。如果是更新:寫出改了什麼,以及在哪裡找到。
- 只有審查人員漏看時才申訴。 如果你的原生功能早就存在,只是沒被看到,就在 App Store Connect 回覆並附上一段短影片。向 App Review Board 申訴適用於 App 被誤解的時候,不是 App 內容太單薄的時候。
我會用的備註範本,用英文寫,請自行調整:
Hello App Review team,
Thank you for your feedback regarding Guideline 4.2.
What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].
How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].
Best regards,
[Your name]
只寫送審 build 裡真的有的東西。宣稱有、卻找不到的功能,會讓你再被拒一次,而這次是依據 2.1。
送審前的 4.2 檢查清單
- 你能用一句話說出你的 App 做到了什麼網站做不到的事。
- 核心操作的畫面是原生的,不是網頁。
- 每個原生功能都服務核心操作,審查人員兩分鐘內就會碰到。
- App 從第一次啟動就有真實內容,或有一個填好資料的展示帳號。
- App 能獨立運作,不必安裝其他 App。
- 首次啟動時的大型下載會告知大小並徵求同意。
- 審查備註寫清楚概念、目標使用者和每個功能的位置。
- 如果你的點子接近邊界,你在寫程式前就用範圍明確的 iOS App MVP 測試過了。
下次送審就通過 4.2
如果你的 App 剛因 4.2 被拒,Apple Review Kit 能幫你找出被引用的條款和它的要求,並附上給審查人員的備註範本。如果你還在開發,iOS Kit 的流程會在寫第一行程式碼前,先從核心功能出發。想要有人幫你看,跟我預約一小時。完整流程在 App 被 Apple 拒絕頁面。
如果你正在準備第一次上架,做一下免費診斷:它會幫你把步驟排好順序,並寄給你我的 Apple 防拒檢查清單。首頁會說明怎麼開發手機 App,從一開始就為審查做好準備。
沒有人能保證 Apple 會接受你的 App。但我可以幫你給它一個存在於 App Store 的理由。
常見問題
「Guideline 4.2 - Design - Minimum Functionality」是什麼意思?
這是因功能過少而被拒的標題。Apple 認為你的 App 太像網站,或內容、功能太少。同一個標題也可能指向子條款:「Guideline 4.2.2」針對形象 App 或連結清單,4.2.3 針對依賴另一個 App 的 App。
用 WebView 做的 App 一定會被拒嗎?
不會。這條規則針對的是被塞進 App 的網站,不是技術本身。審查人員看的是主要體驗:如果主要畫面是跟 Safari 做一樣事情的網頁,風險就很高。在瀏覽器裡打開的說明頁面不是重點。
加上推播通知就能通過 4.2 嗎?
不能。Apple 在論壇公開的一則被拒訊息裡寫道,通知、定位和分享都不足以讓體驗夠豐富。通知要服務核心功能才算數,例如鬧鐘,或使用者自己設定的提醒。
Guideline 4.2 和 4.3 有什麼不同?
4.2 單獨評估你的 App:跟網站比起來,它提供的夠不夠?4.3 則拿它跟其他 App 比:它是不是複製品、變體,或是在飽和類別裡又多一個?同一個 App 可能兩個都中,但修正方式不一樣。
4.2 被拒後需要新的 build 嗎?
幾乎都需要,因為問題出在 App 本身。唯一的例外:審查人員沒找到一個早就存在的功能。這時就在 App Store Connect 回覆,附上清楚的備註和一段短影片,不必更換 build。