WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
改进 App 和图书的 MDM 分配

改进 App 和图书的 MDM 分配

App StoreDistribution & MarketingBusiness & Education
观看原视频

改进 App 和图书的 MDM 分配

Highlight

新版 Apps and Books Management API 引入实时通知和异步处理，将 25 万次应用分配从最少 25,000 个请求减少到仅 10 个请求。单次请求最多可分配 25 个应用到 1,000 台设备，分配状态通过推送通知实时送达。

核心内容

管理企业或教育机构的应用分配一直是个规模化难题。一所学校有 10,000 名学生、每人一台设备，需要分配 25 个核心应用——总共 250,000 次分配。旧版 API 每次请求最多处理 10 台设备的单个应用分配，意味着至少需要 25,000 次 HTTP 请求。

WWDC2021 推出的新版 Apps and Books Management API 用两个核心改进解决了这个问题：实时通知消除了持续轮询的需求，异步处理让服务器端并行执行分配操作。同样的 250,000 次分配，现在只需 10 个请求。

详细内容

实时通知类型

新版 API 支持四种通知类型，需要在 client config 中按 sToken 分别订阅（01:20）：

Asset Management 通知

分配状态变更时触发，包括 associate（分配）、disassociate（解除分配）、revoke（撤销）事件（01:44）：

{
  "notification": {
    "assignments": [
      {
        "adamId": "408709785",
        "pricingParam": "STDQ",
        "serialNumber": "C02Y402HLCM6"
      }
    ],
    "eventId": "87cbc650-16cc-4f9e-a833-e622f377a9f7",
    "result": "SUCCESS",
    "type": "ASSOCIATE"
  },
  "notificationType": "ASSET_MANAGEMENT",
  "uId": "2049025000431439"
}

收到通知后即可向对应设备发送安装命令，无需等待批量操作全部完成。

Asset Count 通知

购买、转移或退款导致应用数量变化时触发（03:37）：

{
  "notification": {
    "adamId": "408709785",
    "countDelta": 50,
    "pricingParam": "STDQ"
  },
  "notificationType": "ASSET_COUNT",
  "uId": "2049025000431439"
}

countDelta 为正表示购买或转入，为负表示退款或转出。MDM 可以用这个增量直接更新本地计数，无需调用 sync endpoint。

User Management 通知

注册用户状态变更时触发，包括 create、update、retire 事件（05:34）：

{
  "notification": {
    "users": [
      {
        "clientUserId": "client-100",
        "idHash": "leSKk3IaE2vk2KLmv2k3/200D3=",
        "status": "Associated"
      }
    ],
    "eventId": "e0def1f8-9158-4343-9c52-8dd32da50b9b",
    "result": "SUCCESS",
    "type": "UPDATE"
  },
  "notificationType": "USER_MANAGEMENT"
}

User Associated 通知

用户接受邀请、将个人 Apple ID 关联到注册账户时触发（08:33）：

{
  "notification": {
    "associatedUsers": [
      {
        "clientUserId": "client-100",
        "idHash": "leSKk3IaE2vk2KLmv2k3/200D3=",
        "inviteCode": "f551b37da07146628e8dcbe0111f0364",
        "status": "Associated"
      }
    ]
  },
  "notificationType": "USER_ASSOCIATED"
}

通知订阅配置

在 client config 中配置通知接收（09:00）：

  • notificationAuthToken：共享密钥，Apple 在通知的 Authorization header 中使用
  • notificationUrl：接收通知的 HTTPS 端点

收到通知后返回 HTTP 200 表示成功投递。非 200 响应或超时时，Apple 会重试几次（best-effort）。如果长时间无法接收通知，需要针对可能过期的状态进行轮询同步。

异步处理

旧版 API 的所有操作都是同步的：发送请求后等待 Apple 完成分配再返回响应（10:07）。新版改为异步处理：

旧版流程：
请求 → Apple 同步执行分配 → 返回结果（单次最多 10 台设备 × 1 个应用）

新版流程：
请求 → Apple 立即返回 eventId → 后台异步处理 → 通过通知推送结果
（单次最多 1,000 台设备 × 25 个应用）

异步处理的优势（10:25）：

  • 服务器端强制并行，优化处理速度
  • 有序处理减少间歇性失败和重试
  • 大规模部署更可靠，教育机构的返校季部署更轻松

实际对比：250,000 次分配

以 10,000 用户 × 25 应用的场景为例（11:08）：

指标旧版 API新版 API
单次请求处理能力1 应用 × 10 设备25 应用 × 1,000 设备
最少请求数25,00010
响应方式同步等待立即返回 eventId
结果获取响应体中直接获取通知推送或查询 event status endpoint

请求格式变化

新版 API 使用 versioned URI 和正确的 HTTP 方法（04:34）。所有请求在 Authorization header 中以 Bearer token 格式携带 sToken：

Authorization: Bearer <sToken>

获取资产状态（GET 请求）：

GET /v1/assets?adamId=408709785&pricingParam=STDQ

响应包含分页信息和资产计数：

{
  "assets": [
    {
      "adamId": "408709785",
      "pricingParam": "STDQ",
      "assignedCount": 5000,
      "availableCount": 10000,
      "totalCount": 15000
    }
  ],
  "currentPageIndex": 0,
  "size": 1,
  "totalPages": 1
}

分配资产（POST 请求）：

// 请求
{
  "assets": [
    { "adamId": "361309726", "pricingParam": "STDQ" }
  ],
  "serialNumbers": [
    "serial-1", "serial-2", ..., "serial-1000"
  ]
}

// 响应
{
  "eventId": "92467a8e-8a50-4df9-9b30-f7ff4a99dea7",
  "tokenExpirationDate": "2021-07-06T14:12:10+0000"
}

有序处理

新版 API 保证同一 event 内的操作按提交顺序执行（13:49）。例如重新分配：先发送 disassociate 请求获得 eventId1，再发送 associate 请求获得 eventId2。Apple 保证 eventId1 的所有操作完成后才开始 eventId2 的操作。

Sync API 的版本标识

所有 sync API 响应包含 versionId（07:28），在底层数据发生写入时变更。遍历大量分页响应时，可以用 versionId 检测之前页面的数据是否已变化。

核心启发

  1. 立即迁移到新版 API：旧版 API 继续支持，但同一 sToken 混用新旧版本不受官方支持。新版 API 的异步处理和批量能力是未来的唯一方向。

  2. 部署通知接收端点：配置 notificationUrl 和 notificationAuthToken，订阅所有四种通知类型。这是消除轮询、实现实时状态同步的关键。

  3. 利用批量请求减少调用次数：单次请求最多 25 个应用 × 1,000 台设备。合理组织分配批次，将请求数压到最低。

  4. 用 eventId 跟踪异步操作：发送分配请求后记录返回的 eventId，后续通过通知或 event status endpoint 跟踪进度。收到成功通知后再向设备发送安装命令。

  5. 处理通知投递失败：Apple 的通知是 best-effort 投递。如果服务不可用导致通知丢失，针对可能过期的状态进行有针对性的轮询，而非全量同步。

关联 Session

评论

GitHub Issues · utterances