Apple 于 2026 年 10 月 16 日公布 App Review Guidelines 修订;结论是:不用因更新就盲目改版,先核对创意素材是否准确、适龄且没有无法证明的主张,再确认实际功能对用户和审核人员清晰可见。指南新增 2.3.14 创意素材条款,并以 2.5.19 进一步说明隐藏、休眠或未说明功能的既有规则。(Apple Developer 更新说明)
谁该看:即将提交新 App 或版本更新的个人开发者,应核对应用表现与商店素材是否一致。
使用远程配置、功能开关或分阶段上线功能的小团队,应确认审核人员能理解并访问相关功能。负责商店页面素材的开发者,则要分清创意素材、截图和预览视频的用途。
最后更新于 2026 年 10 月 21 日,规则依据 Apple Developer 于 2026 年 10 月 16 日发布的修订说明,以及当前指南和 App Store Connect 文档。
先按风险拆解 2026 年指南更新
Apple 的更新说明将 2.3.14 标为新条款;2.5.19 则是对长期规则的进一步说明,原先相关要求归在 2.3.1。这个变化不等于所有 App 都必须立刻改代码:是否要调整,取决于实际提交版本中有哪些素材、功能和审核人员可见的路径。
| 核验对象 | Apple 明文要求 | 送审前优先动作 |
|---|---|---|
| 2.3.14 创意素材 | 素材应与 App 内容、功能或品牌有关,符合元数据要求,并适合所有受众;不得含误导性他 App 引用、无法核实的产品主张或具体、折扣价格信息。 | 按投放位置和语言版本逐张检查素材,删去无法在当前 App 中证实的承诺。 |
| 2.5.19 功能 | App 不应包含隐藏、休眠或未说明的功能;功能应让用户和 App Review 清楚理解。 | 检查正式包中的功能和入口,并准备可供审核人员使用的访问路径。 |
| 2.3.1 说明 | 新功能、功能变化应在 App Store Connect 的审核说明中具体描述,并可供审核。 | 把“本次更新优化体验”改成具体变更、入口位置和验证步骤。 |
注意,表格中的“优先动作”是基于规则制定的自查方法,不是 Apple 对每个个案的预判。是否违反规则、如何处理,仍以 Apple 对实际提交内容的审核为准。
先核对创意素材与截图、预览的职责
App Store 创意素材审核不是把所有页面图片都当成同一类内容。Apple 将创意素材定位为突出 App 内容、功能或品牌的资产,可用于产品页页眉、搜索结果等位置;截图则应展示 App 正在使用,预览视频也有自身的呈现要求。先确认资产类型,再套用对应规则,避免拿宣传横幅标准去判断应用内截图。(Apple App Review Guidelines)
| 资产类型 | 主要用途 | 自查重点 |
|---|---|---|
| 创意素材 | 强调 App 的内容、功能或品牌,可用于商店内的特定展示位置。 | 是否与实际 App 有关;是否适龄;是否有误导性引用、无法验证的主张或具体、折扣价格。 |
| 应用截图 | 展示 App 在设备上的实际使用情形。 | 界面和当前提交版本是否一致;是否主要展示实际功能,而非只放标题图或启动页。 |
| 预览视频 | 让用户了解 App 的界面和操作体验。 | 视频是否使用 App 本身的屏幕画面;旁白、文字说明是否准确,不掩盖实际功能。 |
检查素材时,可把每条文案拆成“主张—证据—对应功能”三列。比如“支持离线同步”就要能指向提交版本里的同步行为、适用条件和限制;如果功能仅在某地区、某账号类型或某订阅状态下可用,素材与商店描述就不能让普通用户误以为人人都能使用。
创意素材中容易漏掉的,不只是截图画面,还包括其他 App 的名称或标识、价格和折扣标签,以及“保证”“即时”“完全准确”一类难以验证的绝对承诺。把审核范围扩展到不同语言的商店素材、产品页页眉和搜索展示资产,不要只看默认语言版本。App Store Connect 提供资产管理和预览相关操作,可参考 Apple 的 App Store 资产管理说明。截图则应按 Apple 的截图指南展示实际使用,而预览视频须遵守 App 预览规格说明。
⚠️ 注意:某张图“看起来像截图”并不能决定它属于哪种资产。先对照 App Store Connect 中的资产位置和用途,再检查内容;别把同一张宣传图复制到不同展示位后,就认为所有位置都自动合规。
再检查远程配置是否让功能变得不可见
远程配置、功能开关或分阶段开放,不应仅凭技术实现方式就被判定为隐藏功能。真正需要核实的是:正式包里是否已经包含用户看不到、审核人员也无法发现或访问的功能;功能何时启用;商店描述是否已经对外承诺;审核说明能否解释入口、条件和测试方式。Apple 当前条文要求功能对用户和 App Review 清晰,并禁止隐藏、休眠或未说明功能,但并未在这段文字中把所有功能开关一概定义为违规。
| 情况 | 风险判断 | 送审前处理 |
|---|---|---|
| 开关只控制已公开功能的展示时机,审核账号可访问,说明也与实际一致 | 不能只因存在开关就断言违规;仍须核对具体体验是否透明。 | 在审核说明中交代入口、启用条件和测试账号设置。 |
| 功能已在商店页面宣传,但审核账号或审核路径看不到 | 可能导致承诺与可验证体验不一致。 | 提供可复现的审核访问路径,或修正素材与描述,确保不超出当前可用功能。 |
| 正式包包含未说明的功能,计划审核后再远程开启 | 与隐藏、未说明功能相关的风险较高。 | 重新评估是否应随本次版本提交;不可仅靠审核说明掩盖实际不可见的功能。 |
| 功能按地区、账号权限或逐步发布开放 | 条件本身不自动等于违规,但可能让审核人员无法判断功能边界。 | 说明地区、账号条件和审核环境,并确保提供的测试路径能验证所申报功能。 |
重点是把“正常分阶段开放”和“刻意让审核看不到功能”分开。前者要有真实、清楚的开放条件和稳定的审核访问方法;后者若让提交版本的功能表现与审核后实际提供的体验发生重大差异,就需要先处理可见性和披露问题,而不是假设审核人员会自行猜到开关逻辑。
对照商店承诺,排除审核人员无法验证的落差
商店描述、创意素材、截图、预览视频和当前提交版本,实际上构成一条用户预期链。任何一个环节提到的功能,都应能在本次提交版本中得到印证;若功能有门槛、尚未向所有用户开放或只在特定情形出现,就把条件讲清楚,而不是用模糊文案让用户或审核人员自行推测。Apple 的元数据规则也要求商店信息准确反映 App 的核心体验,并随版本保持更新。
App Store 隐藏功能审核的实操排查,可以从一张“承诺到入口”映射表开始:
- 冻结提交版本信息。记录准备提交的版本号、构建产物和后端配置快照,避免自查期间配置变化,导致审核环境与开发者核对结果不一致。
- 收集全部对外承诺。整理产品页描述、创意素材、截图、预览、更新说明,以及 App 内引导文案。
- 逐项映射到实际路径。为每个功能写明入口、账号权限、地区限制、订阅要求和依赖服务;标出仅靠远程开关才出现的功能。
- 用审核条件复现。从全新安装和审核测试账号开始,按说明进入关键流程,确认不会因为缺少验证码、过期账号、停用服务或配置不一致而卡住。
- 修复落差并留下记录。区分需要改素材、改描述、补审核说明和调整构建的事项;不要把所有问题都归结为“重新截图”。
- 提交前复核最终版本。确保上传的构建、商店素材和审核说明对应同一个版本状态;若构建或配置改变,应重新走相关核验。
可以使用下面的记录模板,让团队成员针对同一事实核验,而不是只留一句“已检查”:
版本 / 构建标识:
素材位置与语言:
对外功能主张:
App 内入口与复现步骤:
远程配置 / 账号 / 地区条件:
审核账号或演示模式:
核验结果:
待修正项目:
如果宣称功能无法稳定复现,先不要依赖口头解释。确认是测试账号、服务状态、账号权限还是配置开关导致差异,再决定修复、补充说明或调整本次提交范围。
在 App Store Connect 送审前写清楚审核路径
App Store Connect 送审时,审核说明不应只是版本摘要。Apple 的文档建议提供 App 概念、功能、目标用户,以及更新内容和新功能位置;需要登录的 App 还应提供可用的演示账号。审核说明中的信息应帮助审核人员发现并验证不明显的功能,而不是替代 App 本身的清晰呈现。(Apple 关于完整审核信息的说明)
说明一个不明显功能时,至少写清:
- 功能是什么:用用户能理解的名称描述,不只写内部代号或开关名。
- 从哪里进入:按实际界面顺序列出入口;若需要演示账号,注明账号类型和登录方式。
- 在什么条件下出现:说明地区、权限、订阅、远程配置或设备条件。
- 如何验证:写明审核人员完成哪些操作后,应看到什么结果;如果有不能通过普通账号复现的情况,解释原因并提供可行路径。
- 本次变更是什么:明确本次新增、修改或移除的内容,避免笼统写“体验优化”。
示例结构可写成:“本次新增 X 功能。审核账号登录后,进入 A 页面并选择 B,即可查看;该功能仅对 C 类型账号开放。当前提交版本已启用该功能,相关服务可供审核访问。”其中每项必须按实际情况填写,不能为了显得完整而虚构账号或功能状态。
如功能需要特定后端服务,提交期间应确认其保持可用;需要账号、验证码或特殊访问步骤时,应提前写入资料。版本信息和审核说明字段可对照 App Store Connect 版本信息参考逐项核验。
用三类风险表做最终自查记录
将审核风险分成素材、功能和审核说明三类,能避免素材问题修了,却漏掉 App 内功能不可见;也能避免把单纯的说明不足误当成必须改代码。每项记录对应的材料、核验结论和下一步动作,必要时再判断要不要替换素材或重新构建。
| 风险类别 | 发现问题时的典型信号 | 修正方向 |
|---|---|---|
| 素材本身 | 展示内容与 App 无关;提到无法证明的能力;出现具体或折扣价格;不同语言版本的承诺不一致。 | 更换相关素材或调整文案,并重新预览实际展示位置。 |
| App 内功能 | 页面描述的功能找不到;开关开启后出现未披露能力;审核账号无法进入主要流程。 | 修正实际功能、访问条件或提交范围,并验证当前构建。 |
| 审核说明 | 只写通用更新说明;关键流程依赖账号、地区或远程配置,却未交代。 | 补充功能入口、条件、账号与验证步骤,并确保描述匹配实际环境。 |
准备送审前,可以再做一次简短的 App Review Guidelines 2026 自查:素材是否真实适龄;商店每一项主张是否对应当前版本;正式包内的功能能否被用户和审核人员理解;不明显流程是否有可用说明;提交构建是否与核验结果一致。规则层面的依据应以 Apple 当前发布的指南和 2026 年 10 月 16 日更新说明为准。
如果自查后仍有不确定项,应根据具体条文和实际提交内容谨慎处理;指南并不意味着某个个案一定会被拒,也不能据此承诺一定通过。收到审核反馈后,再对照其指出的素材、功能或说明问题逐项回应,不要把未被指出的推测当成既定拒审理由。
完成素材、功能和审核说明的核验后,若团队还需要稳定的 macOS 环境来生成并复核 iOS 构建,可以先查看 ViewMini 的远程 Mac 环境,再按项目实际情况评估。与临时借用设备相比,自购 Mac 会占用一次性硬件预算、需要自行维护;Windows 或 Linux 环境无法直接替代 macOS 上的 Xcode 构建链;团队成员各自本地打包,也可能带来工具链和构建环境不一致的问题。若正在比较具体的托管方案,可查看 ViewMini 的 Mac mini 环境页面,并按项目的访问与构建需求确认是否适用。远程 Mac 适合需要临时或持续使用 macOS、又不想立即购置硬件的团队,但它只提供构建与复核环境,不会替代合规自查,也不保证审核通过。
送审前,先在独享云端 Mac 验证构建
使用 ViewMini 独享物理云端 Mac,核验构建环境与版本配置,减少环境差异带来的排查成本。
