Offer subscriptions to groups and organizations
App Store & Distribution 进阶 7m

利用多席位订阅来拓展订阅用户群并触达新受众

Offer subscriptions to groups and organizations

2026年6月10日

在 Apple 官方观看视频

一句话判断

Apple 终于官方接管了 B2B 订阅的“席位分发”和“阶梯定价”，做团队协作或企业应用的开发者不用再自己手写那套反人类的 License 邀请系统了。

这场 Session 讲了什么

以前搞团队订阅，开发者得自己算阶梯价格，自己发邮件发邀请码，还得处理员工离职后的席位回收，简直是个无底洞。现在 Apple 直接在 StoreKit 2 里加了 Group Purchases（群组购买）和 Volume Purchasing（批量购买）。App Store Connect 里能直接配最多 5 个阶梯的 Volume Pricing（批量定价）。小团队在 App 里直接买多个席位，Apple 会帮你生成邀请链接并管理生命周期；大企业则通过 Apple Business Manager（ABM）走 MDM（移动设备管理）分发。

这对做 SaaS、协同工具、企业培训的开发者是史诗级利好。你只需要把精力放在产品上，把算账和发 License 的苦活累活扔给 App Store。那些还在用 StoreKit 1 硬扛 B2B 订阅的项目，现在有了最充分的理由去重构支付模块。

值得深挖的点

内置席位管理 vs 自定义 Server API 的取舍

Apple 这次最聪明的设计，是为 Group Purchases 提供了一套内置的席位管理系统。默认情况下，你只管发起购买请求，Apple 负责生成邀请链接、追踪成员接受状态，甚至处理取消订阅时的席位回收。这能直接干掉 80% 的自建后台需求，让独立开发者也能在一周内上线团队版。

但这套内置系统是个黑盒。如果你的应用有复杂的权限控制，比如管理员和普通成员看到的界面完全不同，或者需要和现有的企业 SSO（单点登录）打通，你就必须用全新的 App Store Server API 群组管理端点（Group management endpoints）。这里的 trade-off 很明显：用内置系统开发极快，但控制权弱；用自定义系统灵活，但得自己处理 App Store 状态同步的各种边缘 case。建议先用内置系统跑通 MVP，等客户提出复杂权限需求时，再切到自定义 Server API。

Volume Pricing（批量定价）的商业杠杆

App Store Connect 新增的 Volume Pricing 允许设置最多 5 个价格区间（Price bands），买得越多单价越低。这不仅仅是个定价功能，这是逼着 C 端应用向 B 端转型的催化剂。以前买 50 个席位和买 1 个席位单价一样，企业采购根本没动力去走繁琐的审批流。

现在有了阶梯折扣，配合 ABM 的批量采购流程，直接打通了企业集中采购的预算审批流。比如字幕里提到的例子，买 50 个席位能让平均成本降低 20%。对于开发者来说，这意味着你的客单价（ARPU）上限被彻底打开了。赶紧去算算你的边际成本，把那些原本只卖给个人的高级功能，打包成团队版扔进 ABM 里。

代码片段

1. 在 App 内发起多席位群组购买

场景：用户在小团队里当“队长”，在 App 内选择购买 5 个席位。

// 获取用户请求的席位数量
let requestedSeats = 5 
guard let product = try await Product.products(for: ["com.myapp.team.monthly"]).first else { return }

// 构建购买选项，传入席位数量
var options: Set<Product.PurchaseOption> = []
options.insert(.quantity(requestedSeats))

// 触发 StoreKit 2 购买流程
let result = try await product.purchase(options: options)

坑：StoreKit 2 的 .quantity 选项默认可能受限于 App Store Connect 的配置，确保你的订阅产品在后台已经开启了“向群组和组织销售”，否则传大于 1 的数量会报错。

2. 处理多席位交易结果

场景：购买成功后，解析 Transaction 获取实际购买的席位数量，并解锁对应功能。

switch result {
case .success(let verification):
    let transaction = try verification.payloadValue
    
    // 提取交易中的数量/席位信息
    let purchasedSeats = transaction.purchasedQuantity 
    print("成功购买 \(purchasedSeats) 个席位，准备生成邀请链接或同步服务端")
    
    // 通知 App Store 交易已完成
    await transaction.finish()
    
case .userCancelled:
    print("用户取消了购买")
// 处理其他错误...
}

坑：purchasedQuantity 拿到的是总席位数，不是新增席位数。如果是续费或升级场景，记得和之前的 Transaction 历史做对比，别给用户重复发邀请链接。

最佳实践

已有项目的迁移策略：最紧要的动作是把 StoreKit 1 升级到 StoreKit 2，这是支持多席位订阅的硬性前提。升级后，去 App Store Connect 检查你的自动续费订阅，大部分会默认开启 Group and Organization 销售。如果你的产品之前开了 Family Sharing（家人共享），这个选项会被默认 Opt-out（退出），你需要手动去后台重新勾选，理清家人共享和团队共享的业务边界。

新项目的采用建议：无脑使用 Apple 内置的席位管理系统。不要在第一天就试图自己写一套完整的 License 分发和校验逻辑。把 Apple 生成的邀请链接直接通过系统的 Share Sheet 分享出去，先验证“团队购买”这个动作能不能带来真实的转化率提升。

实战中容易踩的坑：批量购买（Volume Purchasing）走的是 Apple Business Manager 和 Apple School Manager，这部分购买流程完全在 App 外部发生，由企业的 IT 管理员通过 MDM 分发。你的 App 代码里不需要（也无法）处理批量购买的 UI，只需要确保后端能通过 App Store Server API 正确识别并放行这些通过 MDM 塞进来的席位。

还有什么值得关注

  • 教育专属套餐：你可以在 App Store Connect 里设置“仅在 Apple School Manager 提供”，从而为经过认证的教育机构创建专属的折扣套餐，不用担心被普通用户薅羊毛。
  • 静默安装订阅：通过批量购买和 MDM 分发，企业 IT 部门可以像静默安装 App 一样，直接把订阅席位推送到员工设备上，员工打开 App 就是已授权状态。
  • Server API 群组查询：新的 App Store Server API 端点不仅能查单个用户，还能直接拉取“某个用户所在的所有群组”以及“群组内的所有成员”，做协同功能时拿来做权限校验非常方便。
StoreKit 2 App Store Server API Volume Pricing B2B Subscriptions