如果你的品牌把 Live Activities 当成又一个广告位来用,iOS 27 就是终结这种做法的版本。在 2026 年 6 月的审核指南更新中,苹果把 Live Activities 纳入了其反垃圾信息条款:不得用它向用户”发送垃圾信息、钓鱼信息或未经请求的消息”。这个原本悄悄变成锁屏营销阵地的功能,现在审核人员可以据此拒绝上架,也可以直接下架应用。
这一点值得仔细读,因为合规的 Live Activity 和违规行为之间的界线,并不在于功能本身,而在于用户是否主动要求了你展示给他的内容。本文将说明这条规则到底禁止什么、合法用例和滥用行为的分界线在哪里、如何在规则范围内配置 Live Activities,以及如何自查已经上线的推送活动。对于用 FCM/APNs 触达海外用户的出海团队来说,App Store 审核规则和国内应用商店的规则并不相通——iOS 端的这条新规只按苹果自己的标准执行,与其他任何本地法规无关。Pushwoosh 是一个客户互动平台,凡是配置或自查涉及到你在我们平台上设置的内容,本文会直接指出对应位置。
本文是 iOS 27 完整更新解读 系列的一部分。文案规则还有一个合规姊妹篇:AI 层如何重写你的推送通知文案。
这条规则到底说了什么
这条规则是 App Store Review Guideline 4.5.3,它并不是新规则。它一直禁止使用苹果服务向用户”发送垃圾信息、钓鱼信息或未经请求的消息”,并明确点名了 Game Center 和推送通知。2026 年 6 月 8 日的更新(与 WWDC 同期)所做的,是把 Live Activities 也明确点名加入了这份名单。也就是说,这个界面现在被明确纳入了一条本来就很有约束力的反垃圾信息规则。指南上一个不起眼的修改,对所有把这个渠道用于营销的团队来说都是重大后果。
真正提高风险的是这条规则和什么一起发布。在同一批更新中,苹果扩大了整体的垃圾信息规则的适用范围,使其可以下架已经在架的应用,而不只是拒绝新提交的版本。所以 Live Activities 这一条不再只是提交审核时的一道关卡。一个今天仍在投放促销性 Live Activities 的应用,随时可能因此被标记——不是等到下一次发版,而是在当前已上线的版本上就可能发生。苹果没有公布任何过渡期,而从历史经验看,苹果通常会在发布新指南后的 1 到 3 个月内开始严格执行。这个倒计时从 6 月就已经开始。
合规红线在哪里
Live Activity 的设计初衷,是在锁屏和动态岛上追踪一个真实、正在进行的事件:一份正在送往你家门口的外卖订单、一次正在临近的行程、一个不断刷新的比分、一次登机流程。这个事件是用户自己发起的,Live Activity 只是实时反映它的状态。这就是全部合法用例,而且是一个真正好的用例。
刚接触这个话题?看看 iPhone 上的 Live Activities 到底是什么,以及它们在锁屏和动态岛上的表现。
违规行为是用同一个界面,去推送用户并未主动发起的内容。一个用户从未订阅过的促销倒计时。一个被钉在锁屏上的”限时秒杀” Live Activity。一次伪装成活动的召回提醒。这些都没有在追踪一个由用户发起的事件。它们每一个,都是披着 Live Activity 外衣的未经请求的消息——而这正是 4.5.3 现在明确点名的行为。
判断标准很简单:这个 Activity 反映的,是用户正在主动等待的东西,还是你想让他看到的东西?前者是 Live Activity,后者是促销信息,而促销信息应该属于专门为促销设计、发给已经同意接收的用户的渠道。
| 用例 | 是否合规 | 原因 |
|---|---|---|
| 订单和配送追踪 | 合规 | 用户已下单;Activity 追踪的是真实状态 |
| 行程或骑手在途 | 合规 | 用户已预订;实时位置正是重点所在 |
| 用户关注比赛的实时比分 | 合规 | 用户主动选择关注;比分是真实进行中的事件 |
| 用户未订阅的促销倒计时 | 违规 | 未经请求;背后没有用户发起的事件 |
| 以 Activity 形式钉在锁屏的限时秒杀/促销 | 违规 | 把 Activity 界面当广告位使用的营销信息 |
| 伪装成 Activity 的召回提醒 | 违规 | "事件"是为了博取关注而人为制造的 |
如何在规则范围内使用 Live Activities
合规不等于回避这个渠道,而是把它用在设计初衷上,把营销内容导向专门为营销设计的渠道。
把每一个 Live Activity 都锚定在一个用户发起的事件上。如果确实有用户在等待的真实事件,就去追踪它。订单状态、配送进度、实时比分、预订进度——这正是这个界面存在的意义,用户也乐于在这里看到它们。Pushwoosh 的 Live Activities 配置,正是围绕在整个生命周期内更新这类实时事件而设计的,从开始到最终状态。
把促销意图挡在 Activity 之外。如果你想让用户知道一个促销活动,应该用推送通知或面向已订阅用户的应用内消息,而不是钉在锁屏上的 Activity。一旦 Activity 的作用从告知变成了打广告,你就已经踩进了 4.5.3 的范围。
用推送来更新 Activity,而不是用它来替换成一条广告。Live Activities 是通过推送远程更新的:推送携带事件的新状态,Activity 负责展示它。这和利用 Activity 的更新通道去插入一条用户从未要求过的消息,是完全不同的两件事。
值得一读的实现机制:如何组合使用推送和 Live Activities。
自查已经上线的推送活动
因为这条规则可以追溯到已经在架的应用,当务之急不是你的下一个活动,而是现在正在运行的那些。逐一检查所有跑在 Live Activities 界面上的内容,诚实地给每一个分类。
对每一个正在运行的 Live Activity 问自己 3 个问题。用户是否发起了背后这个基础事件?这个 Activity 是否随事件结束而结束,还是一直滞留在界面上占位?如果去掉品牌元素和行动号召按钮,是否还剩下一个真实的、被追踪的事件?任何一项没通过的,都应该在审核人员替你做决定之前就下架。
要特别留意那些标着 Activity 之名、实际上是排期营销节点、限时优惠或召回活动的内容。这些做法一直都是对这个功能的过度延伸使用。而现在,它们成了一条被明确点名的违规行为,后果也不再只是版本被拒——赌上的是一个已经在产生收入的应用的生存资格。
用正确的方式在 Pushwoosh 中配置 Live Activities
Pushwoosh 支持 Live Activities,用途正是苹果所设想的那样:通过推送更新追踪真实的、由用户发起的事件,从下单到配送再到最终状态。而当你确实有促销内容要传达时,同一个平台也为你提供推送、应用内消息、邮件和短信,让你在专为此设计的渠道中,向已同意接收的用户传达它。锁屏上合规,其他所有渠道上依然有效。Pushwoosh 已通过 SOC 2 Type I 和 ISO 27001:2022 认证,符合 GDPR 要求,数据中心位于欧盟和美国——这也为出海团队处理 Live Activity 更新中的用户数据提供了合规基础。