iOS 審核被拒的 10 個真實案例：BotsUP 維運紀錄

我們實際踩過與在業界常見的 10 個 iOS 審核被拒案例。每個案例都對應到具體的 App Store Review Guideline 條目，附上拒信原文、修法與事前 checklist，幫你把被拒的機會壓到最低。

TL;DR

我們在水滴發票、間歇健走、OnReel、Agent2PDF 這些 App 的上架與維運過程裡，累積了各種被拒又重上的紀錄；被拒不是失敗，流程沒跑對才是。
最常踩的 3 條：Guideline 2.1（Crash / 走不完的 flow）、2.3（Metadata 與截圖不一致）、3.1.1（用非 IAP 賣數位內容）。
2024 年 Apple 強制 Privacy Manifest 後，5.1.1 相關被拒暴增；很多老 App 只是照舊 resubmit 就中鏢。
被拒通常 24–48 小時內可以修完重送，關鍵是回 App Review Notes 寫清楚做了什麼、把 Resolution Center 當客服對話在經營。
不要等被拒才準備授權文件、測試帳號、影片。這三樣是加速審核最有效的工具。

先講結論：10 個案例 at-a-glance

#	Guideline	典型情境	來源
1	2.1 App Completeness	提交版本 crash / flow 點不到	BotsUP 踩過
2	2.3 Accurate Metadata	Screenshot 含未上架功能 / App 外文字	間歇健走第一版
3	4.0 Minimum Functionality	單頁 + 一顆按鈕「太簡單」	業界常見
4	4.3 Design: Spam	多個高相似度白牌 App	業界常見
5	5.1.1 Privacy Manifest	缺 Privacy Manifest / reason code 錯	水滴發票維運踩過
6	5.1.1(v) Account Sign-In	有 Google/Facebook 但缺 Sign in with Apple	業界常見
7	3.1.1 In-App Purchase	在 App 內導到網頁買數位內容	OnReel 類型常見
8	2.5.1 Software Requirements	使用 private API / undocumented framework	業界常見
9	4.7 HTML5 Games, Bots, etc.	純 WebView 套殼 App	業界常見
10	1.1.6 Objectionable Content: Legal	涉政府 API / 法規，缺授權說明	水滴發票初次送審

案例 1 — Guideline 2.1：送出的版本自己 crash

情境：最常見、最尷尬。開發機跑得好好的，一上 TestFlight 給審核員點某個入口直接 crash；或是某個 flow 在特定 iOS 版本 / 舊機型走不完。

拒信常見措辭：

We found that your app crashed on iPhone running iOS 17.x, which is not in compliance with the App Store Review Guidelines. 我們發現你的 App 在某台 iPhone 執行 iOS 17.x 時 crash，不符合審核規範。

怎麼修：

打開 Xcode Organizer → Crashes 或 App Store Connect → TestFlight → Crashes，把 symbolicated stack trace 抓出來。
如果是偶發，安裝 Firebase Crashlytics / Sentry 到下一版，重送時在 Review Notes 補一句「已加上 crash reporting 並在此版本修復 X」。
找不到 repro？直接下載 Apple 附的 .crash 檔到 Xcode 裡對照 dSYM。

怎麼預防：

上架前 TestFlight 跑至少 48 小時，團隊至少 3–5 人在 2 種 iOS 版本、2 種機型（老 + 新）各走一次主要 flow。
在 App Review Notes 附測試帳號（含密碼）與一條「走完主 flow」的逐步說明。BotsUP 在水滴發票的 major release 每次都會附 3 組測試帳號，審核通過率肉眼可見上升。
離線 / 弱網 / 權限拒絕這三種狀態一定要測到。審核員很常把網路關掉試你的 App。

案例 2 — Guideline 2.3：Screenshot 含未上架功能或 App 外文字

情境：截圖放了實際包裡沒有的功能、或合成圖多了一段文案。Apple 對 metadata 與實際 App 的一致性非常嚴格。

拒信常見措辭：

We noticed that your app's screenshots include content that does not sufficiently reflect the app in use. 你的 App 截圖所呈現的內容，並未真實反映 App 實際使用情形。

BotsUP 踩過：間歇健走 第一次送審被退，就是截圖上我們加了一句 App 外的標語（像是宣傳詞「每天 30 分鐘」）。審核員判這一句 App 內找不到對應文字 → metadata 不一致。修法是全數重新截一組「把文字換成 App 內實際會出現的文案」。

怎麼修：

截圖不要加任何 App UI 之外的廣告文案；若要加，確保 App 實際畫面找得到同義敘述。
不要塞「即將上線」、「Beta 中」的 badge，審核員會判定是 misleading。
不要有其他 App 的 UI 或 logo（例如把 Line 分享截在背景）。

怎麼預防：

定一個規則：截圖只能從 TestFlight 包用 Simulator 或實機錄出來，不許在 Figma 後製加文字。
每次送審之前，照 Guideline 2.3 條列檢查一次：價格、功能、截圖、描述、關鍵字、支援網址。

案例 3 — Guideline 4.0：Minimum Functionality

情境：功能過於單薄，Apple 判定沒有實質價值。經典：「每日金句」、「單畫面計算機」、「只會顯示一張圖的 App」。

拒信常見措辭：

Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience. 你的 App 所提供的體驗過於有限，與直接用行動瀏覽器看網頁沒有本質差異。

怎麼修：

加上離線功能、本地資料、通知、Widget、Shortcuts 整合 — 任何「網頁做不到」的能力。
若定位是工具，把它做到「離線也可用」、「有本地資料庫」、「iOS 原生能力（Live Activity、Share Extension、Watch App）」其中至少 2 條。

怎麼預防：

在送審之前問自己：「如果我把這個功能做成網頁，使用者少掉哪些東西？」答不出來就不要送。
資訊型 App 一律再加至少一個互動功能（收藏、筆記、本地搜尋、分享到 iMessage）。

案例 4 — Guideline 4.3：Spam（白牌 App 農場）

情境：用同一份 codebase 幫多家客戶換 logo/顏色上架。Apple 很討厭這種「同一隻模板生 50 個 App」的行為。

拒信常見措辭：

We noticed that your app provides the same feature set as other apps submitted to the App Store; simply submitting many similar versions of the same app is considered spam. 我們注意到你的 App 功能與其他已送審的 App 雷同；大量送出相似版本會被視為垃圾 App。

怎麼修：

換一套開發者帳號（走客戶自家 Apple Developer Account，而不是用你公司帳號批量上架）。
每一隻 App 要有實質差異：不同的內容、不同的使用族群、獨立的資料後台。
若真的是「系列」，改用 content variant（同一隻 App 內切換模式）而非多隻獨立 App。

怎麼預防：

接多個同性質客戶（例如補習班、健身房）要上架時，不要用你家帳號代送，要 client 自己申請 Developer Program。
白牌合約一開始就寫明「App Store 送審由甲方（客戶）自備帳號並負責被拒風險」。

案例 5 — Guideline 5.1.1：Privacy Manifest 缺失或 reason code 錯誤

情境：2024 年 5 月起 Apple 強制要求 App 與第三方 SDK 都要附 PrivacyInfo.xcprivacy，宣告使用哪些 Required Reason API（UserDefaults、File timestamp、Disk space 等）並填正確的 reason code。

拒信常見措辭：

ITMS-91053: Missing API declaration. Your app's code references one or more APIs that require reasons, but the PrivacyInfo.xcprivacy file does not provide approved reasons. ITMS-91053：缺少 API 宣告。你的 App 使用了需要原因的 API，但 PrivacyInfo.xcprivacy 中沒有提供核可原因。

BotsUP 踩過：水滴發票 一次小改維運版本因為某第三方分析 SDK 沒跟上 Apple 的 Privacy Manifest 要求，整個包被退。修法是升級 SDK 到最新版、自家 App 的 PrivacyInfo.xcprivacy 補上 NSPrivacyAccessedAPICategoryUserDefaults 的 reason code CA92.1。

怎麼修：

用 Xcode 15+ 編譯時，Build Log 會列出哪些 API 觸發需要 declaration。對照 Apple 官方清單把 reason code 填進 Manifest。
第三方 SDK 過舊，升級到作者釋出的「Privacy Manifest ready」版本。找不到？換 SDK。

怎麼預防：

每季度檢查所有 SDK 版本與其 Privacy Manifest 支援狀況。
CI 加一條：build 完成後自動檢查 PrivacyInfo.xcprivacy 存在且包含你預期會使用到的 API category。

情境：App 提供 Google / Facebook / Line / Twitter 登入，但沒有放 Sign in with Apple。Apple 從 2020 起強制這條。

拒信常見措辭：

Your app uses a third-party login service, but does not offer Sign in with Apple as an equivalent option. 你的 App 使用第三方登入服務，但未提供 Sign in with Apple 作為對等選項。

怎麼修：

加上 Sign in with Apple，登入位階要跟其他選項同一列、字體大小不得刻意弱化。
後端要能處理 Apple 的 email relay（<hash>@privaterelay.appleid.com）並允許用戶日後解除綁定。

怎麼預防：

在 UI 設計階段就把 Sign in with Apple 畫進 mockup。改版時一起測「刪除帳號」流程，Guideline 5.1.1(v) 也規定了。

案例 7 — Guideline 3.1.1：用非 IAP 賣數位內容

情境：App 內「看更多內容請升級」的按鈕連到網頁付費（Stripe、綠界、街口），繞開 Apple 30% 抽成。這條被盯非常緊。

拒信常見措辭：

Your app, or its metadata, enables the purchase of content or services intended to be consumed within the app, by means other than in-app purchase. 你的 App（或 metadata）允許使用者以 IAP 以外的方式購買 App 內使用的內容或服務。

怎麼修：

數位內容（解鎖章節、訂閱看影片、AI 額度）一律走 StoreKit 的 IAP / Subscription。
若是「實體商品或服務」（例如叫車、訂餐、賣衣服）才能走外部金流 — 但介面不能有任何字樣誘導用戶去網頁購買數位內容。
有條件的例外：Reader apps、Apple 的 External Link Entitlement — 都需要額外申請，不要預設能用。

怎麼預防：

在架構階段就分清楚「這個付費是實體 or 數位」。OnReel 這種內容型 App（台灣原創短劇）就是典型必須走 IAP 訂閱、不能自建金流的情境。
做 Subscription 上架之前先把 Product ID、試用期、價格階層在 App Store Connect 建好並連到 Xcode build。

案例 8 — Guideline 2.5.1：Private API / Undocumented Framework

情境：App 呼叫了 Apple 未公開的 API（例如用 runtime 抓 _systemStatus、或從舊 Jailbreak SDK 留下的 symbol）。過去有些開發者為了抓電池、記憶體細節會這樣做。

拒信常見措辭：

Your app uses or references the following non-public APIs: _someInternalMethod. The use of non-public APIs is not permitted. 你的 App 使用或引用了以下非公開 API，這是不被允許的。

怎麼修：

自家 code 搜 underscore-prefixed selectors、dlsym、NSClassFromString("_Internal...") 這類痕跡。
第三方 SDK 的問題，直接聯絡作者或換掉。常見踩雷是很老的廣告 SDK 或舊版 push 服務。

怎麼預防：

CI 加一條 nm / strings 掃描，檢查 binary 是否包含已知 private selector 清單。
換 SDK 優先挑有持續更新、每年跟 Xcode 主線的。

案例 9 — Guideline 4.7：純 WebView 套殼 App

情境：客戶說「我官網都做好了，幫我包一個 App 就好」。結果整隻 App 打開就是一個 WKWebView 顯示 https://yoursite.com。Apple 判「不具原生價值」直接退。

拒信常見措辭：

Your app appears to primarily display content from a website / consists of a web view without providing additional native functionality. 你的 App 看起來只是主要呈現網站內容，或只是一個 WebView 而沒有其他原生功能。

怎麼修：

至少加入以下 2 條：原生登入（含 Sign in with Apple）、Push Notification、離線快取、Widget、Share Extension、Apple Pay、相機 / 掃碼、地圖。
首頁不能只是 WebView，至少要有一個原生首頁（包含原生元件、可運作的分頁結構）。

怎麼預防：

接案時先問：「這個需求是否其實用 PWA / 網頁書籤就夠了？」誠實講出可節省很多溝通。
若真的要 hybrid，把「原生功能清單」寫進報價單範圍，別讓客戶以為包一下就能上架。可延伸閱讀我們寫的 App 開發費用怎麼估。

案例 10 — Guideline 1.1.6：涉及政府 / 法規內容，缺授權說明

情境：App 整合到政府或公用系統（電子發票、健保、金融帳戶、車輛監理），審核員會質疑：你有權拿這些資料嗎？有立案嗎？

拒信常見措辭：

Your app includes content or features that require permission or authorization from a third party, but you have not provided documentation. 你的 App 包含需第三方授權的內容或功能，但你並未提供相關文件。

BotsUP 踩過：水滴發票 初次送審就遇到這條 — App 直接對接財政部電子發票整合服務平台。我們準備的文件包含：

財政部電子發票 API 的 App ID 授權信件 / 截圖。
矽基崛起有限公司的營業登記（業務項目含「資訊服務」）。
App Review Notes 裡用英文說明：「This app uses the official MOF e-Invoice Integration Service Platform API. Authorization ID: XXXX. See attached documentation.」

補完這三樣再重送，一次通過。

怎麼修：

備好授權文件 PDF，在 Resolution Center 附上。
在 Review Notes 用英文一句話講清楚：是誰授權的、授權範圍、你的公司實體是誰。

怎麼預防：

只要 App 動到公部門或金融 API，送審前就主動在 Review Notes 附上授權說明，不要等被拒。
營業登記項目要涵蓋 App 做的事情（資訊服務業、電子資訊供應服務業等）。

通則防範：上架前 6 條 checklist

TestFlight 跑 48 小時以上，至少 3 人、2 種 iOS 版本、2 種機型實測主 flow。把 crash reporting 裝好。
Privacy Manifest 全量填好：自家 code 與所有第三方 SDK 都要有 PrivacyInfo.xcprivacy。每季檢查一次 SDK 版本。
Screenshot 上傳前對照 Guideline 2.3：不含 App 外文字、不含未上架功能、不含其他 App UI。
若有任何登入 / 付費 / 政府資料：Sign in with Apple 就位、IAP 就位、授權文件就位。
寫好 App Review Notes（這是最被忽略的殺手鐧）：測試帳號、特殊 flow 的逐步說明、任何需要授權的資料出處。用英文寫。
保留 Resolution Center 所有紀錄：每次被拒與回覆存檔成 PDF，下次改版可直接引用「此功能已於上一次 Review 通過」。

FAQ

Q：被拒後多快可以重新 submit？ 技術上沒有冷卻期，修完馬上就能重送。實務上我們會花 1–2 小時確認修法、寫好 Review Notes 再送，避免同一個問題被退第二次（會累積負面紀錄）。

Q：可以跟 Apple 吵回覆嗎？ 可以。Resolution Center 裡可以回覆文字、附截圖、附影片；也可以到 App Review Board 申訴（Guideline 的 1.0 Introduction 有連結）。態度要專業、具體講出 guideline 條號與你的反駁。我們在水滴發票曾經靠一次 App Review Board 申訴讓被拒的 metadata 重新通過。

Q：台灣帳號和美國帳號審核嚴謹度有差嗎？ 理論上審核 pool 是全球共享，但 in-market metadata 會用該市場的本地審核員。同一隻 App 在台灣市場用繁中送審與在美國市場用英文送審，被退的細節可能不一樣（截圖文案、授權文件）。

Q：被拒 3 次會被 Apple 黑名單嗎？ 單一版本連續被拒不會直接封號，但同一個 binary / 同一問題被退 2 次以上會進入加強檢查，審核時間延長、下一版也容易被挑毛病。每次被拒都要認真修，不要為了 rush deadline 亂 resubmit。

Q：Expedited Review 真的有用嗎？ 有用，但是只給緊急情況：重大 bug 導致 App 無法使用、安全性問題、配合新 iOS 發行、重大活動檔期。濫用會被 Apple 記一筆、日後申請通過率下降。我們一年用 1–2 次，通常 24 小時內就會被加速。

Q：重大節日（年底 / iOS 更新）提交會比較快嗎？ 反過來。12/20 – 01/03 Apple 會有部分審核暫停；iOS 主版本更新前後（通常 9 月）審核員忙到癱瘓、平均時間會拉長到 48–72 小時。有重要改版請避開這兩段。

參考資料

Apple, App Store Review Guidelines（官方條文）
Apple, Privacy Manifest Files
Apple, Describing Use of Required Reason API
Apple, Sign in with Apple
Apple Developer News, Upcoming third-party SDK requirements（2024 年 Privacy Manifest 強制公告）
Apple, App Review — Responding to your reviewer（Resolution Center 指引）

BotsUP 幫客戶處理過 App Store 下架危機 24 小時內重新上架。上架被卡或擔心會被卡？30 分鐘需求診斷先聊聊。

TL;DR

我們在水滴發票、間歇健走、OnReel、Agent2PDF 這些 App 的上架與維運過程裡，累積了各種被拒又重上的紀錄；被拒不是失敗，流程沒跑對才是。
最常踩的 3 條：Guideline 2.1（Crash / 走不完的 flow）、2.3（Metadata 與截圖不一致）、3.1.1（用非 IAP 賣數位內容）。
2024 年 Apple 強制 Privacy Manifest 後，5.1.1 相關被拒暴增；很多老 App 只是照舊 resubmit 就中鏢。
被拒通常 24–48 小時內可以修完重送，關鍵是回 App Review Notes 寫清楚做了什麼、把 Resolution Center 當客服對話在經營。
不要等被拒才準備授權文件、測試帳號、影片。這三樣是加速審核最有效的工具。

先講結論：10 個案例 at-a-glance

#	Guideline	典型情境	來源
1	2.1 App Completeness	提交版本 crash / flow 點不到	BotsUP 踩過
2	2.3 Accurate Metadata	Screenshot 含未上架功能 / App 外文字	間歇健走第一版
3	4.0 Minimum Functionality	單頁 + 一顆按鈕「太簡單」	業界常見
4	4.3 Design: Spam	多個高相似度白牌 App	業界常見
5	5.1.1 Privacy Manifest	缺 Privacy Manifest / reason code 錯	水滴發票維運踩過
6	5.1.1(v) Account Sign-In	有 Google/Facebook 但缺 Sign in with Apple	業界常見
7	3.1.1 In-App Purchase	在 App 內導到網頁買數位內容	OnReel 類型常見
8	2.5.1 Software Requirements	使用 private API / undocumented framework	業界常見
9	4.7 HTML5 Games, Bots, etc.	純 WebView 套殼 App	業界常見
10	1.1.6 Objectionable Content: Legal	涉政府 API / 法規，缺授權說明	水滴發票初次送審

案例 1 — Guideline 2.1：送出的版本自己 crash

情境：最常見、最尷尬。開發機跑得好好的，一上 TestFlight 給審核員點某個入口直接 crash；或是某個 flow 在特定 iOS 版本 / 舊機型走不完。

拒信常見措辭：

We found that your app crashed on iPhone running iOS 17.x, which is not in compliance with the App Store Review Guidelines. 我們發現你的 App 在某台 iPhone 執行 iOS 17.x 時 crash，不符合審核規範。

怎麼修：

打開 Xcode Organizer → Crashes 或 App Store Connect → TestFlight → Crashes，把 symbolicated stack trace 抓出來。
如果是偶發，安裝 Firebase Crashlytics / Sentry 到下一版，重送時在 Review Notes 補一句「已加上 crash reporting 並在此版本修復 X」。
找不到 repro？直接下載 Apple 附的 .crash 檔到 Xcode 裡對照 dSYM。

怎麼預防：

上架前 TestFlight 跑至少 48 小時，團隊至少 3–5 人在 2 種 iOS 版本、2 種機型（老 + 新）各走一次主要 flow。
在 App Review Notes 附測試帳號（含密碼）與一條「走完主 flow」的逐步說明。BotsUP 在水滴發票的 major release 每次都會附 3 組測試帳號，審核通過率肉眼可見上升。
離線 / 弱網 / 權限拒絕這三種狀態一定要測到。審核員很常把網路關掉試你的 App。

案例 2 — Guideline 2.3：Screenshot 含未上架功能或 App 外文字

情境：截圖放了實際包裡沒有的功能、或合成圖多了一段文案。Apple 對 metadata 與實際 App 的一致性非常嚴格。

拒信常見措辭：

We noticed that your app's screenshots include content that does not sufficiently reflect the app in use. 你的 App 截圖所呈現的內容，並未真實反映 App 實際使用情形。

怎麼修：

截圖不要加任何 App UI 之外的廣告文案；若要加，確保 App 實際畫面找得到同義敘述。
不要塞「即將上線」、「Beta 中」的 badge，審核員會判定是 misleading。
不要有其他 App 的 UI 或 logo（例如把 Line 分享截在背景）。

怎麼預防：

定一個規則：截圖只能從 TestFlight 包用 Simulator 或實機錄出來，不許在 Figma 後製加文字。
每次送審之前，照 Guideline 2.3 條列檢查一次：價格、功能、截圖、描述、關鍵字、支援網址。

案例 3 — Guideline 4.0：Minimum Functionality

情境：功能過於單薄，Apple 判定沒有實質價值。經典：「每日金句」、「單畫面計算機」、「只會顯示一張圖的 App」。

拒信常見措辭：

Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience. 你的 App 所提供的體驗過於有限，與直接用行動瀏覽器看網頁沒有本質差異。

怎麼修：

加上離線功能、本地資料、通知、Widget、Shortcuts 整合 — 任何「網頁做不到」的能力。
若定位是工具，把它做到「離線也可用」、「有本地資料庫」、「iOS 原生能力（Live Activity、Share Extension、Watch App）」其中至少 2 條。

怎麼預防：

在送審之前問自己：「如果我把這個功能做成網頁，使用者少掉哪些東西？」答不出來就不要送。
資訊型 App 一律再加至少一個互動功能（收藏、筆記、本地搜尋、分享到 iMessage）。

案例 4 — Guideline 4.3：Spam（白牌 App 農場）

情境：用同一份 codebase 幫多家客戶換 logo/顏色上架。Apple 很討厭這種「同一隻模板生 50 個 App」的行為。

拒信常見措辭：

We noticed that your app provides the same feature set as other apps submitted to the App Store; simply submitting many similar versions of the same app is considered spam. 我們注意到你的 App 功能與其他已送審的 App 雷同；大量送出相似版本會被視為垃圾 App。

怎麼修：

換一套開發者帳號（走客戶自家 Apple Developer Account，而不是用你公司帳號批量上架）。
每一隻 App 要有實質差異：不同的內容、不同的使用族群、獨立的資料後台。
若真的是「系列」，改用 content variant（同一隻 App 內切換模式）而非多隻獨立 App。

怎麼預防：

接多個同性質客戶（例如補習班、健身房）要上架時，不要用你家帳號代送，要 client 自己申請 Developer Program。
白牌合約一開始就寫明「App Store 送審由甲方（客戶）自備帳號並負責被拒風險」。

案例 5 — Guideline 5.1.1：Privacy Manifest 缺失或 reason code 錯誤

拒信常見措辭：

ITMS-91053: Missing API declaration. Your app's code references one or more APIs that require reasons, but the PrivacyInfo.xcprivacy file does not provide approved reasons. ITMS-91053：缺少 API 宣告。你的 App 使用了需要原因的 API，但 PrivacyInfo.xcprivacy 中沒有提供核可原因。

怎麼修：

用 Xcode 15+ 編譯時，Build Log 會列出哪些 API 觸發需要 declaration。對照 Apple 官方清單把 reason code 填進 Manifest。
第三方 SDK 過舊，升級到作者釋出的「Privacy Manifest ready」版本。找不到？換 SDK。

怎麼預防：

每季度檢查所有 SDK 版本與其 Privacy Manifest 支援狀況。
CI 加一條：build 完成後自動檢查 PrivacyInfo.xcprivacy 存在且包含你預期會使用到的 API category。

情境：App 提供 Google / Facebook / Line / Twitter 登入，但沒有放 Sign in with Apple。Apple 從 2020 起強制這條。

拒信常見措辭：

Your app uses a third-party login service, but does not offer Sign in with Apple as an equivalent option. 你的 App 使用第三方登入服務，但未提供 Sign in with Apple 作為對等選項。

怎麼修：

加上 Sign in with Apple，登入位階要跟其他選項同一列、字體大小不得刻意弱化。
後端要能處理 Apple 的 email relay（<hash>@privaterelay.appleid.com）並允許用戶日後解除綁定。

怎麼預防：

在 UI 設計階段就把 Sign in with Apple 畫進 mockup。改版時一起測「刪除帳號」流程，Guideline 5.1.1(v) 也規定了。

案例 7 — Guideline 3.1.1：用非 IAP 賣數位內容

情境：App 內「看更多內容請升級」的按鈕連到網頁付費（Stripe、綠界、街口），繞開 Apple 30% 抽成。這條被盯非常緊。

拒信常見措辭：

Your app, or its metadata, enables the purchase of content or services intended to be consumed within the app, by means other than in-app purchase. 你的 App（或 metadata）允許使用者以 IAP 以外的方式購買 App 內使用的內容或服務。

怎麼修：

數位內容（解鎖章節、訂閱看影片、AI 額度）一律走 StoreKit 的 IAP / Subscription。
若是「實體商品或服務」（例如叫車、訂餐、賣衣服）才能走外部金流 — 但介面不能有任何字樣誘導用戶去網頁購買數位內容。
有條件的例外：Reader apps、Apple 的 External Link Entitlement — 都需要額外申請，不要預設能用。

怎麼預防：

在架構階段就分清楚「這個付費是實體 or 數位」。OnReel 這種內容型 App（台灣原創短劇）就是典型必須走 IAP 訂閱、不能自建金流的情境。
做 Subscription 上架之前先把 Product ID、試用期、價格階層在 App Store Connect 建好並連到 Xcode build。

案例 8 — Guideline 2.5.1：Private API / Undocumented Framework

拒信常見措辭：

Your app uses or references the following non-public APIs: _someInternalMethod. The use of non-public APIs is not permitted. 你的 App 使用或引用了以下非公開 API，這是不被允許的。

怎麼修：

自家 code 搜 underscore-prefixed selectors、dlsym、NSClassFromString("_Internal...") 這類痕跡。
第三方 SDK 的問題，直接聯絡作者或換掉。常見踩雷是很老的廣告 SDK 或舊版 push 服務。

怎麼預防：

CI 加一條 nm / strings 掃描，檢查 binary 是否包含已知 private selector 清單。
換 SDK 優先挑有持續更新、每年跟 Xcode 主線的。

案例 9 — Guideline 4.7：純 WebView 套殼 App

拒信常見措辭：

Your app appears to primarily display content from a website / consists of a web view without providing additional native functionality. 你的 App 看起來只是主要呈現網站內容，或只是一個 WebView 而沒有其他原生功能。

怎麼修：

至少加入以下 2 條：原生登入（含 Sign in with Apple）、Push Notification、離線快取、Widget、Share Extension、Apple Pay、相機 / 掃碼、地圖。
首頁不能只是 WebView，至少要有一個原生首頁（包含原生元件、可運作的分頁結構）。

怎麼預防：

接案時先問：「這個需求是否其實用 PWA / 網頁書籤就夠了？」誠實講出可節省很多溝通。
若真的要 hybrid，把「原生功能清單」寫進報價單範圍，別讓客戶以為包一下就能上架。可延伸閱讀我們寫的 App 開發費用怎麼估。

案例 10 — Guideline 1.1.6：涉及政府 / 法規內容，缺授權說明

情境：App 整合到政府或公用系統（電子發票、健保、金融帳戶、車輛監理），審核員會質疑：你有權拿這些資料嗎？有立案嗎？

拒信常見措辭：

Your app includes content or features that require permission or authorization from a third party, but you have not provided documentation. 你的 App 包含需第三方授權的內容或功能，但你並未提供相關文件。

BotsUP 踩過：水滴發票 初次送審就遇到這條 — App 直接對接財政部電子發票整合服務平台。我們準備的文件包含：

財政部電子發票 API 的 App ID 授權信件 / 截圖。
矽基崛起有限公司的營業登記（業務項目含「資訊服務」）。
App Review Notes 裡用英文說明：「This app uses the official MOF e-Invoice Integration Service Platform API. Authorization ID: XXXX. See attached documentation.」

補完這三樣再重送，一次通過。

怎麼修：

備好授權文件 PDF，在 Resolution Center 附上。
在 Review Notes 用英文一句話講清楚：是誰授權的、授權範圍、你的公司實體是誰。

怎麼預防：

只要 App 動到公部門或金融 API，送審前就主動在 Review Notes 附上授權說明，不要等被拒。
營業登記項目要涵蓋 App 做的事情（資訊服務業、電子資訊供應服務業等）。

通則防範：上架前 6 條 checklist

TestFlight 跑 48 小時以上，至少 3 人、2 種 iOS 版本、2 種機型實測主 flow。把 crash reporting 裝好。
Privacy Manifest 全量填好：自家 code 與所有第三方 SDK 都要有 PrivacyInfo.xcprivacy。每季檢查一次 SDK 版本。
Screenshot 上傳前對照 Guideline 2.3：不含 App 外文字、不含未上架功能、不含其他 App UI。
若有任何登入 / 付費 / 政府資料：Sign in with Apple 就位、IAP 就位、授權文件就位。
寫好 App Review Notes（這是最被忽略的殺手鐧）：測試帳號、特殊 flow 的逐步說明、任何需要授權的資料出處。用英文寫。
保留 Resolution Center 所有紀錄：每次被拒與回覆存檔成 PDF，下次改版可直接引用「此功能已於上一次 Review 通過」。

FAQ

參考資料

Apple, App Store Review Guidelines（官方條文）
Apple, Privacy Manifest Files
Apple, Describing Use of Required Reason API
Apple, Sign in with Apple
Apple Developer News, Upcoming third-party SDK requirements（2024 年 Privacy Manifest 強制公告）
Apple, App Review — Responding to your reviewer（Resolution Center 指引）

BotsUP 幫客戶處理過 App Store 下架危機 24 小時內重新上架。上架被卡或擔心會被卡？30 分鐘需求診斷先聊聊。

iOS 審核被拒的 10 個真實案例：BotsUP 維運紀錄

TL;DR

先講結論：10 個案例 at-a-glance

案例 1 — Guideline 2.1：送出的版本自己 crash

案例 2 — Guideline 2.3：Screenshot 含未上架功能或 App 外文字

案例 3 — Guideline 4.0：Minimum Functionality

案例 4 — Guideline 4.3：Spam（白牌 App 農場）

案例 5 — Guideline 5.1.1：Privacy Manifest 缺失或 reason code 錯誤

案例 7 — Guideline 3.1.1：用非 IAP 賣數位內容

案例 8 — Guideline 2.5.1：Private API / Undocumented Framework

案例 9 — Guideline 4.7：純 WebView 套殼 App

案例 10 — Guideline 1.1.6：涉及政府 / 法規內容，缺授權說明

通則防範：上架前 6 條 checklist

FAQ

延伸閱讀

參考資料

延伸閱讀

App 開發外包費用怎麼估？2026 台灣行情完整解

選技術夥伴 vs 選外包：5 年差在哪（給中小企業老闆）

軟體外包合約怎麼談：避免報價翻倍的 5 個條款

iOS 審核被拒的 10 個真實案例：BotsUP 維運紀錄

TL;DR

先講結論：10 個案例 at-a-glance

案例 1 — Guideline 2.1：送出的版本自己 crash

案例 2 — Guideline 2.3：Screenshot 含未上架功能或 App 外文字

案例 3 — Guideline 4.0：Minimum Functionality

案例 4 — Guideline 4.3：Spam（白牌 App 農場）

案例 5 — Guideline 5.1.1：Privacy Manifest 缺失或 reason code 錯誤

案例 7 — Guideline 3.1.1：用非 IAP 賣數位內容

案例 8 — Guideline 2.5.1：Private API / Undocumented Framework

案例 9 — Guideline 4.7：純 WebView 套殼 App

案例 10 — Guideline 1.1.6：涉及政府 / 法規內容，缺授權說明

通則防範：上架前 6 條 checklist

FAQ

延伸閱讀

參考資料

延伸閱讀

App 開發外包費用怎麼估？2026 台灣行情完整解

選技術夥伴 vs 選外包：5 年差在哪（給中小企業老闆）

軟體外包合約怎麼談：避免報價翻倍的 5 個條款

TL;DR

先講結論：10 個案例 at-a-glance

案例 1 — Guideline 2.1：送出的版本自己 crash

案例 2 — Guideline 2.3：Screenshot 含未上架功能或 App 外文字

案例 3 — Guideline 4.0：Minimum Functionality

案例 4 — Guideline 4.3：Spam（白牌 App 農場）

案例 5 — Guideline 5.1.1：Privacy Manifest 缺失或 reason code 錯誤

案例 6 — Guideline 5.1.1(v)：有第三方登入就必須同時提供 Sign in with Apple

案例 7 — Guideline 3.1.1：用非 IAP 賣數位內容

案例 8 — Guideline 2.5.1：Private API / Undocumented Framework

案例 9 — Guideline 4.7：純 WebView 套殼 App

案例 10 — Guideline 1.1.6：涉及政府 / 法規內容，缺授權說明

通則防範：上架前 6 條 checklist

FAQ

延伸閱讀

參考資料

延伸閱讀

App 開發外包費用怎麼估？2026 台灣行情完整解

選技術夥伴 vs 選外包：5 年差在哪（給中小企業老闆）

軟體外包合約怎麼談：避免報價翻倍的 5 個條款

TL;DR

先講結論：10 個案例 at-a-glance

案例 1 — Guideline 2.1：送出的版本自己 crash

案例 2 — Guideline 2.3：Screenshot 含未上架功能或 App 外文字

案例 3 — Guideline 4.0：Minimum Functionality

案例 4 — Guideline 4.3：Spam（白牌 App 農場）

案例 5 — Guideline 5.1.1：Privacy Manifest 缺失或 reason code 錯誤

案例 6 — Guideline 5.1.1(v)：有第三方登入就必須同時提供 Sign in with Apple

案例 7 — Guideline 3.1.1：用非 IAP 賣數位內容

案例 8 — Guideline 2.5.1：Private API / Undocumented Framework

案例 9 — Guideline 4.7：純 WebView 套殼 App

案例 10 — Guideline 1.1.6：涉及政府 / 法規內容，缺授權說明

通則防範：上架前 6 條 checklist

FAQ

延伸閱讀

參考資料

延伸閱讀

App 開發外包費用怎麼估？2026 台灣行情完整解

選技術夥伴 vs 選外包：5 年差在哪（給中小企業老闆）

軟體外包合約怎麼談：避免報價翻倍的 5 個條款