Guideline 4.2 被拒怎么办:最低功能
作者:Mehdi Azizi
发布于 ,9分钟
Guideline 4.2:App 只相当于一个网站就会被拒。把一个原生功能放在核心用法里,并告诉审核员在哪里找到它。
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 | 外包服务商提交的模板 |
补充三点。4.2.2 对目录类 App 有例外:「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 开发 App 里详细讲了 AI 擅长什么、会漏掉什么。各个生成工具产出的格式(Web 应用还是移动项目)在 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:你拍下衣服,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 论坛上公开的一条被拒消息里,Apple 写道:通知、定位和分享不足以让体验足够丰富。通知只有在服务于核心功能时才有意义,比如闹钟或用户自己设置的提醒。
Guideline 4.2 和 4.3 有什么区别?
4.2 单独评判你的 App:相比一个网站,它提供的东西够不够?4.3 把它和其他 App 比较:它是不是复制品、变体,或是一个饱和品类里的又一个 App?同一个 App 可能同时中招,但两者的修复方式不同。
4.2 被拒后需要提交新 build 吗?
几乎总是需要,因为问题出在 App 本身。唯一的例外是:审核员没找到一个本来就有的功能。这种情况下,在 App Store Connect 里回复,附上清楚的备注和一段短视频,不用改 build。