App Store 的社交媒体勾选框，以及它的代价

App Store Connect API 里的两个布尔字段，扛起了 9 月开始生效的整套提交要求：socialMedia 与 socialMediaAgeRestricted。¹ 后者的代价是一项权限、一次 API 接入，以及应用内的一条行为分支。

Apple 在 2026 年 6 月 8 日公布了这项要求：“自 2026 年 9 月起，若要向 App Store 提交新版本或更新，或为在替代应用市场分发而申请公证，您必须声明您的 App 或游戏是否包含社交媒体能力。”² 7 月 9 日，Apple 上线了问卷改动，并补上一句话——正是这句话决定了 9 月之前这段时间该怎么用：“今天起，您就可以查看并回答这些问题。”³

要点速览

• 该声明已经在 App Store Connect 中上线，2026 年 9 月起变为强制。可用与必答之间的这段空档，是留给您做决定的，而不是留给您等截止日期的。²³
• Apple 确实定义了“社交媒体能力”，而且定义了四处，其中三处彼此对不上。6 月版把范围限定在“向众多用户可见地扩散内容”的信息流；7 月版则整句删掉了这个限定。²³⁴
• App Store Connect API 把答案暴露为两个可写布尔值，同时把 userGeneratedContent 和 messagingAndChat 保留为独立问题，各自对应不同的分级下限。社交媒体是一个新增维度，不是改个名字而已。¹⁴
• 想要不落进 13 岁以下的社交媒体分桶，需要同时满足三个条件，而不是一个。Apple 的新闻稿只点了 Declared Age Range API；App Store Connect 帮助文档还补了两条：13 岁以下用户完全无法访问，且“仅投放适龄的 UGC”。²⁴
• Declared Age Range API 只在 iOS、iPadOS、Mac Catalyst 和 macOS 上提供，别无其他。⁵ 而 tvOS、visionOS 或 watchOS 应用在 9 月同样要回答这个问题——可文档给出的那条豁免路径，在它们的平台上根本不存在。

本轮周期里唯一由日历触发的变更

我在这一轮周期里写过的其他破坏性变更，都要等您先动手。启动画面要求由针对 iOS 27.0 SDK 构建触发。@State 宏由在 Xcode 27 中打开工程触发。On Demand Resources 弃用触发的是一条编译器警告，您可以无限期无视。只要不碰工具链，这些都追不到您头上。

社交媒体声明却躲不掉，因为 Apple 把它绑在了一个月份上，绑在了一件您本来就要做的事上。一行 bug 修复走的提交管线，和一次功能发布走的是同一条；到了 9 月，这条管线就会开口发问。

适用范围很窄，值得逐字读清楚。要求覆盖的是“向 App Store 提交新版本或更新”以及“为在替代应用市场分发而申请公证”。² 7 月版把这一对表述重述为“向 App Store 提交新 App 或更新”和“为替代分发提交 App 进行公证”。³ 两份公告都没提 SDK 版本、部署目标或平台。已经上架的应用照常销售。这道关口，就设在下一次提交的门口。

答案的真正代价，是被归进一个家长可以设上限的分桶。Time Allowances 将于今年秋季随 Ask to Browse、Schedules 和重新设计的屏幕使用时间一同推出，让家长“以更灵活的方式管理孩子在各类 App 上花费的时间，包括娱乐、游戏和社交媒体”，并以按年龄定制的建议作为起点。¹⁶ 娱乐和游戏的归类，跟着您在 App Store Connect 里选的类别走。社交媒体的归类只跟着问卷答案走，“与在 App Store Connect 中所选类别无关”。² 一款带信息流的益智游戏，会落进家长最先掐时间的那一类，不管产品页上写的是什么。

Apple 定义了这个词，但定义在漂移

政策类问题最典型的翻车方式，是对着一个没有定义的词瞎猜。Apple 给出了定义，猜的空间因此变窄；但它给了四次，每次边界都不一样。

6 月版的表述是外延式的：“这包括通过社交信息流或类似发现机制，对用户生成内容进行再分发、放大或互动，并向众多用户可见地扩散内容的能力。”²

7 月版改成了定义式，而且更短：“社交媒体能力的定义是：通过社交信息流或类似发现机制，对用户生成内容进行再分发、放大或互动的能力。”³“向众多用户可见地扩散内容”这个限定语没了。

App Store Connect 帮助文档给出的版本最长，保留了限定语，还加了示例：“通过社交信息流或类似发现机制，对用户生成内容进行再分发、放大或互动，并向众多用户可见地扩散内容。可能包括：用户通过社交信息流、社区、搜索或其他分享与发现工具进行转发、点赞、评论、回应，或使用户生成内容获得更高曝光。”⁴

四处里有三处要求“广泛可见的扩散”。有一处不要求——而对于一款贴着边界的应用，这个差别就决定了答案。我倾向于以帮助文档为准，因为问卷本身链接到它，而新闻稿会过时；不过这样读是我的推断，不是 Apple 的指示。“可能包括”同样值得留意：Apple 列的是示例而非封闭集合，所以哪怕一项能力跟列出的五个动词都不像，照样可能算数。

真正让边界清晰起来的，是这个描述符身边站着谁。Apple 单独定义了用户生成内容——“作为 App 预期用户体验组成部分的、用户所创作内容的广泛分发”；又单独定义了消息与聊天——用户“可通过 App 内的功能彼此直接沟通”。⁴ App Store Connect API 原封不动地保留了这种切分，把 userGeneratedContent、messagingAndChat 和 socialMedia 作为三个互相独立的布尔值。¹

分级上的分野同样锋利。用户生成内容和消息都出现在 Apple 的 4+ 定义里。社交媒体最低出现在 13+。⁴ 一款应用可以承载用户内容、允许用户互发消息，仍然评为 4+；一旦加上把同一批内容放大推给陌生人的信息流，下限直接跳高九岁。两个社交媒体描述符只存在于 OS 26 及更高版本的分级体系中，Apple 针对更早 OS 版本的表格里，任何分级下都没有社交媒体条目。⁴

这个字段今天就能填

三份 Apple 材料共同证实问卷改动已经上线——这才是整篇文章最有实操价值的一点。

Apple 7 月 9 日的公告称问卷“现已包含关于您 App 社交媒体能力的问题”，并邀请您立刻作答。³ App Store Connect API 把 socialMedia 记录为“表示该 App 是否包含社交媒体功能的布尔值”，把 socialMediaAgeRestricted 记录为“表示该 App 的社交媒体功能是否受年龄限制的布尔值”。¹ Apple 发布的 OpenAPI 规范中，两者均为可写、可为空的布尔字段。¹ 它们紧挨着 ageAssurance——那是 Apple 上一轮问卷改版加进来的字段，其定义里就点名了“declared age range API”作为一种合格机制。⁴¹⁵ 也就是说，采用豁免路径的同时，您也落进了那条定义的射程之内；在我看来，这是又一个需要回头复核的问题，而不是可以搁着不管的问题。

正在做提交自动化的人，现在就该把接口形状摸清楚：用 GET /v1/appInfos/{id}/ageRatingDeclaration 读取声明，用 PATCH /v1/ageRatingDeclarations/{id} 写入，两个布尔字段都可以传给 fields[ageRatingDeclarations] 参数。¹ 一条手工拼装年龄分级载荷的流水线，会一直跑得好好的——直到它突然不好使的那天。

有一项后果只在 7 月才浮出水面：“具备这些能力的 App，其 App Store 产品页上将显示新的社交媒体内容描述符。”³ 答“是”改变的不只是家长控制的分桶，还有您的商店页面。

所以，这周就打开问卷，看看 App Store Connect 算出来的分级是什么。这么做在提交之前不构成任何承诺，却能把一个截止日期，换成一个您已经做完的决定。

豁免有三个条件，不是一个

Apple 的新闻稿把 13 岁以下这条路径说得像是调一次 API 就完事：“如果您声明 App 或游戏包含社交媒体能力，但这些能力对 13 岁以下的任何人均已停用，则该 App 不会被纳入 13 岁以下用户的社交媒体 Time Allowance 类别……您还需要（至少）使用 Declared Age Range API 来核查用户的年龄区间。”²

App Store Connect 帮助文档把同一个描述符拆成了三项要求：“13 岁以下用户无法访问社交媒体能力。在启用社交媒体功能之前，至少会调用 Declared Age Range API 来核查用户的年龄区间。仅投放适龄的 UGC。”⁴

第三句是没人引用的那句。“仅投放适龄的 UGC”是一项内容审核义务：没有配套 API，没有公布阈值，也没有任何您能跑的测试。适龄是什么、投放机制是什么，Apple 都没定义。一个团队接了年龄门槛、却仍把同一套未经筛选的信息流推给 12 岁的孩子，按帮助文档自己的文字，三个条件里只满足了一个。

还要注意豁免买不到什么。Apple 那句话后半段就写着，这类应用“对 13 岁及以上用户仍将留在社交媒体类别中”。² 豁免只覆盖 13 岁以下用户，所以一个 14 岁的孩子，照样撞上家长给社交媒体设的那个上限。

分级表里有一处矛盾，我没能解开。Apple 的新闻稿说，选了受限选项后，分级仍由您“在年龄分级问卷中的总体作答”决定，“可能得出低于 13+ 的分级”。² 可 Apple 的全球表格把“社交媒体”和“对 13 岁以下用户停用社交媒体”两项都列在能力项下的 13+，各地区表格也把两者一并放在澳大利亚的 16+、巴西的 A16、韩国的 15+ 和越南的 16+。⁴ 按其他每一行的读法——描述符设定一个下限——受限选项看起来同样是 13+ 的下限。Apple 没做任何调和，我也不打算猜计算器实现的是哪份文档。去线上问卷里选中这个选项，读出算出来的分级，然后相信计算器，别信那两份文档。

顺着勾选框一路查到应用内部

假设您走豁免这条路。您在 Xcode 中为 target 启用 Declared Age Range 能力，这会加上 com.apple.developer.declared-age-range 权限：“表示您的 App 是否可以请求某人年龄区间的布尔值。”⁶ 然后带上您关心的阈值去调 API——在 SwiftUI 中，它以一个环境操作的形式出现：⁵

Apple 给这个操作附了一条使用位置规则：应“响应用户交互”调用，而 Apple 自家的示例代码就把调用放在按钮后面。⁵ 该请求可能弹出系统面板，所以从 .task 或 onAppear 里触发，等于朝一个什么都还没要求的人脸上甩一个权限弹窗。改成挂在进入受限界面的那次点按上。

import SwiftUI
import DeclaredAgeRange

@available(iOS 26.0, *)
struct SocialFeedGate: View {
    @Environment(\.requestAgeRange) private var requestAgeRange
    @State private var feedEnabled = false
    @State private var checking = false

    var body: some View {
        if feedEnabled {
            FeedView()
        } else {
            Button("Open community feed") {
                checking = true
                Task {
                    feedEnabled = await resolveGate()
                    checking = false
                }
            }
            .disabled(checking)
        }
    }

    private func resolveGate() async -> Bool {
        guard let response = try? await requestAgeRange(ageGates: 13) else {
            return false          // AgeRangeService.Error: your default, not Apple's
        }
        guard case let .sharing(ageRange) = response else {
            return false          // .declinedSharing
        }
        guard let lowerBound = ageRange.lowerBound else {
            return false          // nil lower bound means below your lowest gate
        }
        return lowerBound >= 13
    }
}

这段代码里有四个细节，决定了这道门槛守不守得住。

您最多只有三个门槛。 两个重载都停在三个阈值：SwiftUI 操作是 callAsFunction(ageGates threshold1: Int, _ threshold2: Int? = nil, _ threshold3: Int? = nil)，UIKit 方法只多一个展示锚点。⁷ 四个分桶就是天花板。为 Apple 的规则留 13、为澳大利亚法律留 16，还什么都没设计，四个里就已经用掉三个。

下界为 nil 是答案，不是错误。 AgeRange.lowerBound 和 upperBound 都是 Int?，Apple 对 nil 的说明毫不含糊：“当该值为 nil 时，表示此人的年龄区间低于您指定的最低年龄，即未达到您的最低年龄要求。”⁸ 乐观地解包，恰好会在这道门槛本要保护的那批人身上把逻辑反转过来。

拒绝是一条真实分支，而 Apple 没说该怎么处理。 AgeRangeService.Response 有 .sharing(range:) 和 .declinedSharing 两个 case。⁹ 在某些受监管地区，“系统会自动提供此人的年龄区间”，用户“无法拒绝共享”；在非监管地区，“如果此人拒绝，您会收到 declinedSharing 响应”。¹⁰ 一次拒绝，和一位重视隐私的成年人在信号上完全无从区分：当成 13 岁以下处理，就挡住了成年人；当成成年人处理，就打开了您承诺要关上的门。默认怎么选，Apple 留给了您。我会选择失败即关闭，并在界面里把这一点讲明白。

您设的门槛只是建议。 系统“可能根据此人所在位置和适用法规，返回覆盖您所指定年龄门槛的年龄区间”；当当地法规要求特定门槛时，“返回的年龄区间反映的是法规要求，而非您设定的门槛边界”。⁷ 假定返回边界与请求一致的代码，最先在监管最严的司法辖区出问题。

还有一项行为必须写进设计里，我估计它会带来一批客服工单。Apple 会缓存答案：“当某人的年龄跨入新的区间时（例如年满 13 岁），API 仍会返回此前的区间，直到其最初声明的周年日为止。”¹⁰ 一个周一满 13 岁的孩子，可能接下来好几个月都被读作 13 岁以下。补救办法是一条只能由用户自己走完的设置路径：设置 → 本人姓名 → 个人信息 → App 年龄区间。¹⁰ 任何以 13 岁为门槛的应用，都得把这段说明放进自己的 UI 里，否则没人找得到。

还有两个较小的细节在设计阶段就要考虑。isEligibleForAgeFeatures 报告的是此人是否处于要求年龄核验的地区；而在 macOS 上它“返回 false，因为系统不要求对该用户或设备进行年龄核验”，所以 Mac 应用直接调 requestAgeRange 即可。¹¹ 另外，用于报告年龄如何被确定的 AgeRangeDeclaration 已经变过一轮：26.2 中的六个细分 case（分别对应本人与监护人的支付、政府身份证件等方式），到 26.5 被合并成单一的 confirmed。¹² 现在再想问某个用户是通过哪种方式核验的，当前 API 已经不告诉您了。

再往下是平台门槛——这一点只有可用性元数据写着，没有任何叙述性文档提过。Declared Age Range 公布的可用性是 iOS 26.0、iPadOS 26.0、Mac Catalyst 26.0 和 macOS 26.0，再无其他：没有 tvOS 行，没有 visionOS 行，没有 watchOS 行。⁵ Time Allowances 落在同一批平台上，“iOS 27、iPadOS 27 和 macOS 27 或更高版本”，而声明要求完全没有平台限定语。²³ 于是，一款带社交信息流的 tvOS 或 visionOS 应用 9 月照样要作答，却无法满足豁免的文档最低要求——因为它点名的那套 API 在那里并不存在。把这个错位读作疏漏而非有意豁免，是我的推断；Apple 两边都没有发文说明。

我自己的八个应用会怎么声明

在写别人的代码之前，我先把这份调查做在了自己身上：八个 Xcode 工程，491 个 Swift 文件。¹³ 没有任何一个包含 CKShare、UICloudSharingController、共享或公共 CloudKit 数据库、GameKit，或任何 Declared Age Range 符号。这批应用里，没有一个会把内容从一个人搬到另一个人那里。四个工程完全不存在任何需要警惕的界面。另外四个的确有些界面会让谨慎的人犹豫一下，它们分成三类，值得摊开来讲讲推理过程。

Get Bananas 有一份共享购物清单，而“共享”比听上去要窄得多。 应用把一个 JSON 文档写进 iCloud ubiquity 容器，再在 iPhone、Apple Watch 和 Mac 上读回来，com.apple.developer.icloud-services 设为 CloudDocuments，整个工程里没有任何 CloudKit 共享。¹³ 清单是在同一个人的多台设备之间共享，不是在人与人之间共享；既没有再分发，也没有第二个用户可供扩散。哪天我为家庭协作加上 CKShare，答案就会翻转；即便如此，它翻向的也是用户生成内容而非社交媒体，因为一份两人共用的购物清单既没有信息流，也没有发现界面。真正值得盯的那条线在更远处：共享清单，加上公开的模板画廊，再加上点赞——那就是一个绕了几步路的信息流。

三个应用会弹出分享面板，而分享面板不是社交功能。 Get Bananas、Water 和 ResumeGeni 的 iOS 应用各自封装了 UIActivityViewController，把用户自己的内容交给用户选择的任意应用。¹³ 内容离开后去了信息或邮件，再也不会回到我的应用所控制的任何界面；而 Apple 的定义关键在于“通过社交信息流或类似发现机制”进行再分发——系统分享面板不是这种东西。⁴ 这条推理覆盖了 App Store 上很大一片：导出不等于发布。

Watch Connectivity 看着像消息，其实不是。 Get Bananas 和 Reps 都用了 WCSession，它在同一个人配对的手机和手表之间搬运数据；而 Apple 的消息与聊天描述符要求“用户可以彼此直接沟通”。⁴¹³ 这里两端坐的是同一个用户。

这个“零命中”的结论可以推广，这才是值得借鉴的部分。这批应用无一例外，都是为创作者本人存储内容，再把内容给同一个人看。而问卷问的完全是另一回事：您的应用会不会拿一个人的内容，通过某种会扩散的机制推到别人面前。追踪器、计时器和学习工具答“否”，靠的是架构，而不是对政策条文的解读。真正需要斟酌的，是那些存在“用户能看见彼此作品”的界面的应用。

部署目标是另一个要优先核对的数字。七个含 iOS target 的工程里有六个已在 iOS 26.0 或更高；Ace Citizenship 的部分 target 仍声明 17.0 和 17.5。¹³ 低于 26.0 的一律无法调用该 API，也就没有豁免可言，只剩直白声明这一个准确答案。

同一份调查里也暴露了平台缺口，而且比版本缺口波及更广。八个工程中有四个在 SUPPORTED_PLATFORMS 里声明了 xros xrsimulator：Reps、Return、Water 和 Yawara。Reps 还加了 appletvos appletvsimulator，并单独发布一个 watchos watchsimulator target；Return 和 Banana List 也带 watchOS target。¹³ 而 Declared Age Range 公布的可用性只有 iOS 26.0、iPadOS 26.0、Mac Catalyst 26.0 和 macOS 26.0，tvOS、visionOS、watchOS 一行都没有。⁵ 这些 target 每一个都欠着 9 月那份声明，而在其中任何一个上答“是”，都会让豁免变得遥不可及——因为豁免所依赖的那套 API 根本不在那里发布。

关于方法有一处提醒，因为我第一遍就搞错了。XROS_DEPLOYMENT_TARGET 会出现在压根没有 visionOS 目标的工程里，因为 Xcode 无论如何都会把这个设置写进配置。ResumeGeni 带着 XROS_DEPLOYMENT_TARGET = 26.2，实际只构建 iphoneos iphonesimulator。¹³ 请读 SUPPORTED_PLATFORMS，别读部署目标那几个键，否则您会把应用根本不发布的平台也算进去。

答案不再是技术问题的那条界

Apple 给 Declared Age Range 文档附了一段值得读两遍的免责声明：这些数据“基于最终用户或其父母、监护人所声明的信息”，并且“确保遵守可能适用于您 App 的相关法律或法规，完全是您自己的责任”。¹⁴

这句话画出了本文停笔的位置。Apple 的问卷产出的是一个分级和一个 Time Allowance 分桶，而不是任何意义上的合规。自 2025 年 12 月 10 日起，澳大利亚法律已要求特定社交媒体平台阻止 16 岁以下人士持有账户，而 Apple 针对该法律的指引，把 Declared Age Range API 列为五种工具之一。¹⁵ 问卷和法条彼此重叠却对不齐：一个问 13 岁，一个问 16 岁，而您手上只有三个门槛要覆盖两者。

您的应用在某部法律下算不算社交媒体平台，那是该司法辖区律师的问题。它在 Apple 的问卷下有没有社交媒体能力，则是您自己的问题——今天就能对着 Apple 已公布的定义答出来。

常见问题

社交媒体这个问题现在已经能在 App Store Connect 里填了吗？

能。Apple 2026 年 7 月 9 日的公告写明，问卷“现已包含关于您 App 社交媒体能力的问题”，而且“今天起，您就可以查看并回答这些问题”。³ App Store Connect API 从另一侧独立佐证了这一点：socialMedia 和 socialMediaAgeRestricted 被记录为 AgeRatingDeclaration 资源的属性，且都可通过 PATCH /v1/ageRatingDeclarations/{id} 写入。¹ 现在作答不构成任何承诺：答案在您提交时才生效，而 2026 年 9 月是“不带这些答案就无法提交”的起点。²

Apple 定义“社交媒体能力”了吗？

定义了，一共四处，但有两种不同的范围。App Store Connect 帮助文档给出的版本最完整，要求“通过社交信息流或类似发现机制，对用户生成内容进行再分发、放大或互动，并向众多用户可见地扩散内容”，随后列出转发、点赞、评论、回应和提升曝光作为示例。⁴ 6 月版带着同样的范围限定语；7 月版把它删了。²³ 由于这些示例是举例而非穷举，最终仍需您自己给应用定性——而我会对着帮助文档来定。

我的应用有用户生成内容，这就自动算社交媒体吗？

不算。Apple 把两者保留为独立问题，定义不同，分级后果也不同。用户生成内容指“作为 App 预期用户体验组成部分的、用户所创作内容的广泛分发”，出现在 Apple 的 4+ 定义中。⁴ 社交媒体则要求通过信息流或同类发现界面进行再分发、放大或互动，最低出现在 13+。⁴ API 用互相独立的 userGeneratedContent 和 socialMedia 布尔值原样映射了这种切分。¹ 而一款用户创作的内容只有自己能看见的应用，两者都不算。

13 岁以下这个选项到底要求我做出什么东西？

三件事，而且只有第二件跟 API 有关。App Store Connect 帮助文档要求：13 岁以下用户无法访问社交媒体能力；“在启用社交媒体功能之前，至少会调用 Declared Age Range API 来核查用户的年龄区间”；以及“仅投放适龄的 UGC”。⁴ 也就是说，您要加上 com.apple.developer.declared-age-range 权限，在任何社交界面出现之前带上包含 13 的门槛调用 requestAgeRange，针对响应做分支处理（包括 Apple 未作规定的拒绝分支），此外还要单独保证投放给未成年人的内容适龄。⁵⁶ 该 API 最多只给三个门槛，并会缓存某人的年龄区间直到其声明的周年日，所以一个刚满 13 岁的用户，在自己去改设置之前会一直被读作更小。⁷¹⁰

关键要点

对 iOS 开发者： - 这周就去答问卷，别拖到 9 月。字段已上线，答案只在提交时才生效，而读出算出来的分级，正好能了结两份公告都没说清的那个 13+ 问题。³⁴ - 如果您走 13 岁以下豁免，预算要按三个条件来做，而不是一次 API 调用；拒绝分支更要刻意写清楚。.declinedSharing 和一位在意隐私的成年人看起来一模一样，而该往哪边失败，Apple 没给任何指引。⁴⁹

对 tvOS、visionOS 或 watchOS 团队： - 先查可用性，再做规划。Declared Age Range 只公布了 iOS、iPadOS、Mac Catalyst 和 macOS 四行，别无其他；也就是说，豁免的文档最低要求在您的平台上无从满足，而 9 月的声明要求照样落在您的提交头上。²⁵ - 同一道缺口也会以另一种方式卡住任何低于 iOS 26.0 的 target：没有 API，就没有豁免，直白声明是唯一准确的答案。⁵

对发布负责人： - 把日期本身当成触发条件——这一点与本轮周期的其他变更都不同。启动画面键和 @State 宏由您掌控的 SDK 和工具链触发；9 月触发的，是一次您本来就要做的提交。² - 让答案经过产品页的负责人过一遍。声明具备社交媒体能力，会给您的 App Store 商店页加上一个社交媒体内容描述符——这项后果 Apple 直到 7 月才披露。³

27 这轮周期一直在按“由什么触发”给自己的变更分类：一项构建设置、一条工具链、一个编译器警告，现在又多了一本日历。同一轮周期里牙口最软、身后迁移量却最大的那项弃用，见On Demand Resources 与 Background Assets 的代价。整个系列的入口是 Apple 生态系统系列。

参考资料