# Guideline 4.2 最低功能要求：App 被拒怎麼辦

> Guideline 4.2：App 只做到網站能做的事，Apple 就會拒絕。把一個原生功能放在核心用途，並告訴審查人員在哪裡找到。

原始頁面：[Guideline 4.2 最低功能要求：App 被拒怎麼辦](https://devoria.fr/zh-hant/blog/guideline-4-2-minimum-functionality-app-rejected)
作者：[Mehdi Azizi](https://devoria.fr/zh-hant/mehdi-azizi)
發布日期：2026-10-19
內容最後修訂：2026-10-19


Guideline 4.2「Minimum Functionality」會拒絕那些跟網站比起來沒有多做什麼，或內容太少、讓人不會想留著的 App。**解法不是堆一堆原生功能，而是把一個原生功能放在核心用途裡，再告訴審查人員在哪裡找到它。** 修正幾乎都需要一個新的 build。

我自己有在上架 iOS App：Solys、TradaZen 和 Nolera 都在 App Store 上。這篇指南根據 Apple 的官方條文（2026 年 10 月 15 日查閱），以及開發者在 Apple 論壇上公開的 4.2 被拒案例。下面提到的被拒 App 都是範例。如果你想看所有被拒原因的總覽，請改讀[Apple 為什麼拒絕你的 App](https://devoria.fr/zh-hant/blog/apple-app-rejection-reasons-real-cases)。

## Guideline 4.2 說了什麼？

4.2 位在 [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#4.2) 第 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 指南](https://devoria.fr/zh-hant/blog/guideline-4-3-design-spam-rejected)，因為它和反垃圾規則是一起的。

## 最常見的兩種 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 論壇上的訊息](https://developer.apple.com/forums/thread/108931)有一句關鍵的話：「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.」這則[第二個訊息](https://developer.apple.com/forums/thread/115230)要求重新檢視概念，也承認沒有任何量化規則能定義什麼叫實用或有娛樂性。

> 在包起來的網站上加推播、定位和分享按鈕是不夠的：Apple 在自己的被拒訊息裡就這樣寫了。

## 四種典型的 4.2 被拒案例

以下四個案例是為了說明規則而設計的範例，不是真實的 App。

### 包起來的網站

範例：一間健身房把它的手機版網站放進 WebView，上面加一條原生分頁列。課表、預約和帳號都是網頁。審查人員看到的，就是 Safari 會顯示的東西。Apple 在它的 [App Review 頁面](https://developer.apple.com/distribute/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](https://devoria.fr/zh-hant/blog/ai-ios-app-pitfalls-checks) 裡有詳細說明。各種生成工具產出的格式（網頁應用或行動專案）比較，請看 [Lovable、Rork 還是 FlutterFlow](https://devoria.fr/zh-hant/blog/lovable-rork-flutterflow-mobile-app-comparison)。

### 等著內容進來的空殼

範例：沒有任何商品的交易平台、空的名錄、顯示「即將推出」的動態牆。審查人員打開的是一個沒東西可看的 App。這種情況也會碰到 2.1，它拒絕暫時性內容：請看 [Guideline 2.1 指南](https://devoria.fr/zh-hant/blog/app-store-guideline-2-1-rejection-fix)。等 App 有真實內容再送審，或提供一個已經填好資料的展示帳號。

## 我做的測試：「那 Safari 呢？」

送審前，我會問自己：網站能不能提供同樣的核心功能？如果可以，這個 App 就有 4.2 的風險。以下是我評估原生功能的表格。**一個功能有沒有用，看它是不是服務核心操作，而不是拿來裝飾。**

| 功能         | 算數的情況                 | 不夠的情況         |
| ------------ | -------------------------- | ------------------ |
| 推播通知     | 帶來使用者期待的資訊       | 只是轉發你的文章   |
| 離線         | 主要內容仍然可以使用       | 只顯示一個錯誤畫面 |
| 小工具       | 顯示屬於這個人的資料       | 顯示你的 logo      |
| 分享         | 可以把內容傳進你的 App     | 只是分享一個連結   |
| 相機、感測器 | 是核心操作的一部分         | 只是打開你的網站   |
| 本機資料     | App 會計算、整理、記住東西 | 所有東西都在網頁上 |

Apple 的建議也是同一個方向。[小工具](https://developer.apple.com/design/human-interface-guidelines/widgets)顯示即時、一眼就能看懂的內容。[通知](https://developer.apple.com/design/human-interface-guidelines/notifications)用簡短的文字帶來有用的資訊，不是用來催人去 App 裡做某件事。

## 我的 App 做到了網站做不到的事

我設計每個 App 時，都會圍繞一個瀏覽器裡不存在的核心功能，或一個讓人會回來的價值。

- **Solys** 是鬧鐘。鈴聲透過 iOS 26 的鬧鐘服務 AlarmKit 播放：它能穿過靜音模式，就像 Apple 的鬧鐘一樣。要關掉它，得先贏一個小遊戲，而你選的 App 在起床後會繼續暫停。沒有任何網頁能讓靜音中的 iPhone 響起來。
- **TradaZen** 是交易模擬器：在真實日期看真實圖表、做決定、K 線逐根揭曉、排名對戰、等級逐步提升。這裡撐起 App 的不是原生功能，而是 4.2 所說的持久娛樂價值。
- **Nolera** 是虛擬衣櫃：你拍下衣服，App 會自動去背、分類，然後每天早上推薦一套穿搭。相機是核心操作的一部分，不是附加功能。

**4.2 要的不是一張原生功能清單，而是一個讓人安裝 App、而不是打開網站的理由。**

## 一步步修正 4.2 被拒

1. **先判斷是哪一類。** 網頁瀏覽：是包起來的網站。內容或功能太少：是太單薄的 App。4.2.3：依賴另一個 App，或沒事先告知的下載。
2. **改產品，不是改說法。** 只辯解卻什麼都沒改的回覆，沒有理由能說服審查人員。把核心操作的畫面用原生重做，或補上缺少的深度。
3. **準備新的 build。** 問題出在 App 本身：遠端更新不夠。每次送審都要重新排隊，請看 [App Store 審核時間](https://devoria.fr/zh-hant/blog/app-store-review-time)。
4. **寫能引導審查人員的審查備註。** Apple 在它的[完整審查資訊](https://developer.apple.com/help/app-review/before-submitting-for-review/complete-review)頁面中，要求描述概念、功能和目標使用者。如果是更新：寫出改了什麼，以及在哪裡找到。
5. **只有審查人員漏看時才申訴。** 如果你的原生功能早就存在，只是沒被看到，就在 App Store Connect 回覆並附上一段短影片。向 App Review Board 申訴適用於 App 被誤解的時候，不是 App 內容太單薄的時候。

我會用的備註範本，用英文寫，請自行調整：

```text
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](https://devoria.fr/zh-hant/expertise/ios-app-mvp) 測試過了。

## 下次送審就通過 4.2

如果你的 App 剛因 4.2 被拒，[Apple Review Kit](https://devoria.fr/zh-hant/kits/review-apple) 能幫你找出被引用的條款和它的要求，並附上給審查人員的備註範本。如果你還在開發，[iOS Kit](https://devoria.fr/zh-hant/kits/ios) 的流程會在寫第一行程式碼前，先從核心功能出發。想要有人幫你看，[跟我預約一小時](https://devoria.fr/zh-hant/coaching)。完整流程在 [App 被 Apple 拒絕](https://devoria.fr/zh-hant/expertise/app-rejected-by-apple)頁面。

如果你正在準備第一次上架，[做一下免費診斷](https://devoria.fr/zh-hant/diagnostic)：它會幫你把步驟排好順序，並寄給你我的 Apple 防拒檢查清單。首頁會說明怎麼[開發手機 App](https://devoria.fr/zh-hant)，從一開始就為審查做好準備。

沒有人能保證 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。


## 你的專案

[Apple Review Kit](https://devoria.fr/zh-hant/kits/review-apple)：我使用的 App Store 審核檢查清單、我被 Apple 退件後的修正、給審核人員的備註，以及兩個審閱你 App 的 Claude Code skills。29 €。

[iOS Kit](https://devoria.fr/zh-hant/kits/ios)：用 Claude Code 打造你的 iPhone App：我的 App 所用的 Starter Code、檢查成果的 skills，以及 Apple Review Kit、App Store Screenshots Kit 與 ASO Kit。129.99 €。