管理服务器上的 app 内购买

您好 欢迎来到WWDC开发者大会 我是托蕾 非常高兴能跟您聊聊 我们为您的服务器准备的新功能 并针对运行高效服务器 追踪您所有App内购买项目的状态 提供一些操作指南 我们马上来看看吧 这是三个讲题系列的第二个部分 着重讨论App内购买项目 如果您还没观看过“见见StoreKit 2” 或“支持客户与处理退款” 我推荐您在本讲题结束后去看看 以得到更完整的信息 本场讲题重点放在服务器 以及如何建立服务器 以管理您的App内购买项目 讲题的一开始 我们先来谈谈 为何拥有服务器会很实用的一些原因 拥有服务器有好几个实用之处 以App内购买项目来说 大部分都跟追踪项目状态有关 当您拥有服务器 我们即可在您的 任一App内购买项目状态改变时 通过App Store服务器通知栏 实时推播给您 您可以利用服务器对接的API 随时呼叫我们以确认项目状态 拥有服务器让您可以随时验证 用户对于您的内容之存取权 即便该用户装置处于离线状态 或由App外进行状态更新 这样就能知道您的用户 是否在订阅到期后仍然续订 或是他们在您的游戏中所购买的钱币 是否已经完成退款 如果您已经拥有服务器 也许是为了上述几个理由 如果您尚未拥有服务器 但正考虑建立一个的话 这些理由也非常值得参考 因为服务器使您更好掌握您的项目 即使您已经有服务器 我们的故事仍始于iPhone、iPad 或其他有App内购买功能的装置 当您送出购买项目的信息至服务器 包含像是transactionId originalTransactionId以及收据 即可通过直接与我们的服务器通信 来从您的服务器追踪该交易 如今 这涉及了使用 像verifyReceipt这样的API 或是App Store服务器通知等软件框架 我们致力于让整合服务器 能够为您带来更多益处 这让我们进入了今天的主题 我将一一介绍我们这次服务器端 所有的更新 以及如何整合这些功能 来建立更好、更强大的服务器 首先 我将介绍用App Store收据 来验证存取 用App Store服务器API 来追踪项目状态 接着 我将深入说明 您可以如何用App Store服务器通知 被动追踪项目状态 我也会解释这对于管理“家人共享” 会有什么样的影响 和您可以在沙盒中测试服务器的方式

让我们从使用收据 验证状态开始 现在 我们的收据都是统一的 App收据格式 要取得JSON格式的收据 您必须在您的App中进行 终端装置收据验证 或者 既然我们正谈到服务器 您也可以呼叫我们的对接服务器 verifyReceipt端点 当您以对接服务器呼叫我们 您会得到这份已解码的收据 加上在latest_receipt_info区中的 任何新交易 在pending_renewal_info区的 下一次续订信息 以及latest_receipt 这个收据可能很庞大 且包含了您整个App的交易 无论是非消耗品、消耗品 订阅或手动续订 这提供您非常大量的信息 但我们不知道这样信息是否会太多 此外 有了StoreKit 2 我们推出新的通过JWS 又称JSON web signature的 签名交易形式 并安排在客户端 而且我们想在服务器上 提供相同的功能给您 我们为何决定推出签名交易？ 在Apple 我们重视安全性 使用JWS来签署这些交易 可以通过签署以及签名验证 来提升安全性 此外 这些交易的解码与验证很容易 以至于您可以在自己的服务器完成 无需呼叫我们 我们来看看这些签名交易 我们的签名交易包含三个字符串 分别以句点隔开 第一个字符串是一个 base64编码的JSON标头 再来是base64编码的JSON内容 后面接着签名 如果您用base64将标头解码 会得到我们使用的签名算法 以及一个x5C声明 这包含了您验证签名所需要的 证书链 我们稍后回来继续讨论签名验证 接着 如果您用base64将内容解码 将会看到收据JSON 意思是您要解码交易 只要用base64将内容解码即可 一个您就能在自己的服务器完成的 简易操作 我们来看一下解码后的交易 扫过一眼 您可能会发现 有些数据类型从刚才收据中的字符串 转换为更洽当的数据类型了 像是数字或布尔 也可以注意到日期被整理成一种格式 milliseconds since epoch时间戳 我们还增加了一些新的字段 我们加了一个叫type的字段 这个字段显示交易的内容类型 我们还加了appAccountToken字段 当您在买入时 在StoreKit 2中 将此数值提供给StoreKit 我们会将数值持久化至服务器 回传您的每一笔交易 我们不只回传到新的签名交易内 也会将每笔交易 回传到现存的统一化 App收据内 我接着想提到的这两个字段 不算新的字段 而是被重新命名了 我们将cancellation_date 以及cancellation_reason 重新命名为revocation_date 以及revocation_reason 使这两个字段的存在更明确表示 应该自撤销日期开始 撤销服务 最后这两个字段 也许看起来是新的 其实是刚才收据中一些信息的简化 我们将isTrialPeriod isIntroOfferPeriod promotionalOfferIdentifier 及offerCodeRefName 合并成offerType及offerIdentifier offerType显示您的客户在此周期 适用的优惠类型 1代表试销优惠 2代表订阅优惠 3代表代码优惠 若优惠类型为2或3 还会在offerIdentifier字段看到一个值 不是promotional_offer_id 就是offerCodeRefName 现在 我要讲讲签名的交易信息中 签名验证的部分 签名验证让您证实交易是来自Apple 而且值得信任 若您只想看到交易的内容 则不需要此步骤 不过要验证签名 您需要用签名的交易信息标头中 可使用的声明 使用alg声明得知 我们用的签名算法 并使用x5c声明数组中的证书链

有了这两样 您就可以使用您喜欢的加密库 来为签名的交易信息进行签名验证 以上就是我们这次在 App Store Receipts的更新 现在也改称之为“签名交易”

让我们继续探讨如何以API确认状态 虽然您不需要像verifyReceipt 这样的API 来验证您签名交易的有效性 或是将交易解码 但我们仍希望建立能在您的服务器 协助您的API 因此我们要在今年的WWDC 推出App Store服务器API 一个全新的数据库 可以提供您一些 之前在您的服务器无法使用的新功能 而且能好好利用新的签名交易 这里要介绍两个全新API 订阅状态API 以及App内购买纪录API 首先来聊聊订阅状态API 订阅状态API 从您的App的originalTransactionId 所显示的信息 提供您自动续订的最新状态 有了这个API 您可以快速确认您的订阅者状态 您能快速得知他们的订阅 是活跃、过期、宽限期 或是其他状态 我们现在就来看看 API的请求很简单 只需要在URL 放入originalTransactionId 这个API的响应 包含了用户在您的App中 每一个订阅的状态 由subscriptionGroupIdentifier分组 每一个subscriptionGroupIdentifier 我们都提供一个近期交易列表 订阅分组中 每个 originalTransactionId都有一个入口 这个数组中的每个入口 都有一个status originalTransactionId signedTransactionInfo 以及一个signedRenewalInfo 同样以JWS格式签署 我们进一步看看status字段

status字段可以快速告诉我们 您的订阅状态 如此一来您就能得知 是否要为您的订阅户解锁服务 有五个可能的数值 1 代表订阅活跃 2 代表订阅过期 3 代表订阅在计费重试期 4 代表订阅在宽限期 以及 5 代表订阅因为取消 或其他事件 而被终止 这些status字段可以快速 提供您订阅的状态 想了解该状态的更多信息 您可以看看签名的交易信息的内容 以及签名的续订信息的内容 解码签名的续订信息的步骤 跟解码签名的交易信息一样 用base64将内容的部分解码

您还可以用同样的方式 利用标头 验证签名的续订信息的签名 解码后 您会看到类似这样的东西 续订信息包含的字段 跟目前我们在verifyReceipt的 pending_renewal_info区 提供的字段相同 加上一些更新 例如 只使用一种日期格式 以及将一些字段改为布尔或数字 也会把我们的新字段 offerType及offerIdentifier 加进签名的续订信息 这样您就能知道客户是否打算 在下一次续约时使用优惠 除了订阅状态API 我们还想提供您一个可以将全部交易 跟您的App建立关联 且类似我们目前在verifyReceipt的 latest_receipt_info区所提供的作法 因此 我们还加入一个 App内购买纪录API App内购买纪录API 提供您的App所有交易历史 就如同您目前在verifyReceipt的 latest_receipt_info区接收的那样 关键的差异在于每一笔交易 会用新的签名的交易信息格式 且为了控制您从App Store 收到的响应大小 API会被分页 初始请求 跟订阅状态API一样 相当简单 只需要您提供originalTransactionId 我们就能处理您的请求 在响应中您会收到App元数据 像是您App的Apple ID及Bundle ID 还有用新的签名的交易信息格式 呈现您App前20笔最新交易的数组 您每一次的请求 我们将回传20个签名的交易信息 如果您还有更多交易 请看响应中 hasMore及revision的值 如果您的App中还有更多交易 hasMore的值就会是true 以当前的例子来说 再次送出请求 将revision令牌作为查询参数传出 来得到下20笔交易 重复此步骤直到hasMore为false 我们换个话题 来聊聊 所有App Store服务器API 将如何保持一致性 它们都会有JWT 全名JSON Web Token的验证 它们支持我们新的签名交易 且使用JSON请求响应格式 最棒的是 它们都是从您在请求中 提供的originalTransactionId得来的 无需在请求中提供收据和共享密钥 现在 我想说明JWT验证 我们所有新的App Store服务器API 将会使用JSON Web Token的验证 又称JWT 我们的选择是为了 在我们和您的服务器间提升安全性 要生成JWT 您需要自App Store Connect 下载一个私钥 此过程会自动地 将公钥登录在我们的服务器 接着在呼叫我们的服务器前 您必须用ES256算法签署令牌 要在App Store Connect生成您的私钥 请至Users and Access页面 并拜访密钥标签 选择App内购买密钥 接着您就会看到像这样的页面 加入一个密钥并为它命名 将密钥存在安全的地方 因为只能下载一次 接着记录密钥ID 现在 来看看JWT实际上看起来如何 一个JWT有三个部分 一个标头、一个内容、一个签名 标头中 您应放入您的私钥ID 以及用来签名的算法 我们需要一个 有SHA256哈希或ES256的 椭圆曲线签章 您还要放入令牌类型 在这个例子中 只会是JWT 内容应该放入您的发行者ID 您可以在App Store Connect 取得此数值 您也需要以seconds since epoch放入 令牌发行及失效的时间 这两个时间相差 应不大于一小时 放入对象 在此只会是appstoreconnect-v1

还要生成一个nonce 也就是一次性独特字符串 最后 要放入您的App的 Bundle ID 有了以上这些信息后 要进行此令牌的签名 您必须使用ES256算法 或是SHA256哈希的椭圆曲线签章 在继续说下去前 来回顾一下 App Store服务器API的重点 第一 我们将“判断状态” 与“查看交易纪录”分开 因为这是两个不同的功能 第二 这些API的请求 只需要originalTransactionId 也就是说 您可以从您的App 或从我们服务器的响应 取得您收到的签名交易 存放您感兴趣的字段 包括originalTransactionId 然后删掉签名的交易信息 无需像我们以前引导您处理收据那样 要将签名交易存放起来 以上是您如何使用 新的App Store服务器API 来确认客户状态 现在 来说说我们如何让 App Store服务器通知栏保持一致性 以及如何使用通知栏来追踪状态 先快速复习一下 App Store服务器通知栏 关于App Store服务器通知栏 我们已经讨论了好几年 所以现在来看看它们的实用之处 有了App Store服务器通知栏 您可以在您任一交易状态更新时 直接从App Store 获得通知 当您收到通知时 客户不需要从他们的手机启动App 您就能立即将您这边的状态更新 有了App Store服务器通知栏 您也无需呼叫我们来得知状态了 我们会在状态一有更新时通知您 这是您服务器可以好好利用的 最强大的工具之一了 我们今年的目标 就是利用我们新的 操作友善的签名交易功能 让App Store服务器API 变得比以前还要更强 此外 我们会更新通知栏 以确保一个用户的行动 只会送出一个通知 我们会上传内容 然后整个内容都会用 提升安全性的JWS来签名 我们让您在您准备好时 再选择使用第二版的通知栏 并且会在一段时间内 持续传送现存通知 这是第一版通知栏目前提供的通知 共有11种类型 从“首次订阅”到“撤销订阅” 全部通包 而第二版的通知栏 我们舍弃其中四种通知类型 “首次订阅”、“手动续订成功” “取消订阅”以及 “订阅项目新价格请求同意” 不过我们增加了五种新类型 “已订阅”、“使用优惠” “订阅过期” “宽限期过期”以及“新价格” 除了新的通知类型 我们还加入一个 叫“子状态”的新字段 这会帮助您将比较总体性的通知类型 集中到某个具体的用户行动 目前“子状态”适用于 第二版通知栏中的其中六项 “已订阅”、“已更新续订状态” “已更新续订偏好” “使用优惠”、“订阅过期” 以及“新价格” 来看看“子状态”在通知类型的 几个应用范例 首先 我想说明“已订阅”通知 以及它的“子状态” 当用户首次订阅 您会收到“已订阅” 且子状态为“取消订阅”的通知 当用户再次订阅相同的项目编号 或不同的项目编号 您会收到“已订阅” 且子状态为“再次订阅”的通知 前提是该订阅 隶属于同一个订阅分组 我们的其中一个新通知类型 是第一版App Store服务器通知栏 所没有的通知类型 也就是“使用优惠”通知 来看看这个例子 每当用户使用一个促销优惠时 您就会收到“使用优惠”通知 如果用户在首次订阅时使用优惠 您就会收到“使用优惠” 且子状态为“首次订阅”的通知 如果用户于同一个闲置订阅 重新订阅时使用了优惠 您就会收到“使用优惠” 且子状态为“再次订阅”的通知 如果用户使用优惠 来升级它们活跃中的订阅 您就会收到“使用优惠” 且子状态为“升级”的通知 如果用户使用优惠 来降级它们活跃中的订阅 您就会收到“使用优惠” 且子状态为“降级”的通知 此外 如果用户在同一时间 先取消活跃中的订阅 再用优惠重新订阅 您就会收到“使用优惠” 且子状态为“开启自动续订”的通知 现在来看看“订阅过期” 有了新的“订阅过期”通知类型 您将用户关闭自动续订功能后 会在订阅过期时 收到“订阅过期”通知 且子状态为“自愿” 如果订阅过期是因为 在计费重试期结束时仍未成功付费 您将收到“订阅过期” 且子状态为“重新计费”的通知 此外 如果订阅过期是因为 用户并未同意新价格 您将收到“订阅过期” 且子状态为“新价格”的通知 总和第二版通知栏的类型 加上它们适用的“子状态” 我们现在纳入了超过20种 用户的生命周期常用事件 光是查看通知类型就足以大致得知 您的购买状态有哪些更新 但如果您想深入细节 通过查看“子状态” 可以提供您更具体的状态 现在来看看新的内容 我们总是在第二版通知栏 放入同一组字段 无论通知类型为何 通知类型、子类型 通知版本 如果您已订阅第二版通知栏 通知版本会是2 通知适用的环境 一些元数据像是Bundle ID App Apple ID以及Bundle的版本 signedTransactionInfo格式的 App内近期交易更新 以及签名续订信息格式的 App内近期续订信息 这些改变会让通知更容易被分析 且因为用了我们新的签名交易 使用上应该会更加容易上手 而且信息只包含 有更新状态的App内购买 如我先前提到的 整个内容会被签署 以提升我们通知栏的 安全性与信任度 刚才看到的内容为了方便阅读 尚未签名 但签名会跟我们用JWT 进行交易及续订信息签名的 作法相似 我们想让您在准备好时 再选择使用第二版的通知栏 因此 我们在App Store Connect的 通知栏URL增加了一个选项 让您可以选择 您的App Store服务器通知栏版本 想进行这个动作 请至您App的页面 然后滚动至新的 App Store服务器通知栏区 如果您选择生产服务器URL 您现在就能选择第一版 或第二版的 App Store服务器通知栏 今年晚些的时候 当这些更新启动 您就能选择使用 第二版的 App Store服务器通知栏 现在 我要分享一些情境范例 用我们新的App Store服务器通知栏 让我们从首次订阅说起 您App中如果有首次订阅消费 您会收到一个签名的交易信息 作为购买的结果 您可以选择在您的App上验证 并将originalTransactionId 及其他相关字段 传送至您的服务器 或是将signedTransactionInfo 传送至您的服务器进行验证 并选择该次要存放在数据库的字段 几乎同时 您将会收到 一个“已订阅” 且子状态为“首次订阅”的通知 既然现在通知中的签名交易信息 已经包含App账户令牌 您可以立即将此通知 跟您的App内购用户链接起来 即使您的服务器与您的App在订阅后 通讯丢失 也仍然可以进行连结 不需要呼叫我们的服务器 就能验证签名的交易信息 您可以随时呼叫我们的服务器 无论是想确认状态 或App内购买纪录的API 只要传送originalTransactionId即可 以上就是购买订阅的内容 我们接着来谈续订 现在我们来到订阅的期限 如果此订阅成功续订 您会收到“已续订”通知类型 您可以查看内容中的 签名交易信息及签名续订信息 来验证您订阅的下一次续订日期 以及您客户下一次续订的 续订偏好 作为故障转移机制 您也可以安排一个作业计划 在续订时间到时调用 我们的订阅状态API 来确认您订阅的状态 再次重申 您不用呼叫我们 来验证您在通知中收到的交易 当然 自动续订不见得会照着计划走 尤其牵涉到付费时 因此我要说明宽限期与计费重试 假设您的订阅 并未如预期续订 发生此状况时 我们会用“续订已失败”通知您 如果您有启用宽限期 而在宽限期满后 仍未成功续订 我们会用“宽限期过期”通知您 如此一来您就知道 您的用户已进入计费重试期 如果在计费重试期间 仍未恢复订阅 我们将传送“订阅过期” 且子状态为“计费重试”的通知给您 若我们在宽限期或计费重试期 恢复付款 我们会传送“已恢复”通知给您 无论续订的结果为何 我们都会用第二版通知栏通知您 并包含签名交易信息及签名续订信息 您可以在此过程中随时调用 订阅状态或购买纪录的API 来再次确认您的订阅状态 当然 我们知道订阅 不是用户在您的App唯一的消费 所以换个话题来谈谈 首次购买消耗品会有哪些状况 在您的App首次购买消耗品时 在消费后 您会收到一个签名交易信息 您可以选择在您的App中验证交易 并将originalTransactionId 及其他相关字段传送至您的服务器 或将签名交易信息传到您的服务器 进行验证 并选择该次要存放在您数据库的字段 永远将originalTransactionId记录起来 因为之后可能还要用到 以消耗品及其他消费类型 像是非消耗品或手动订阅来说 消费的生命周期不会有太多变化 除非用户要求退费 我现在就来说说这个状况 假设您的用户对他们购买的消耗品 提出退费要求 我们将在签名交易信息中 传送“退款”通知给您 包含退款日期及退款原因 您就会知道要在退款日期后 终止消耗品使用许可 如果您随时想知道 您消耗品购买的状态 您可以调用App内购买纪录API 然后在响应中查看 已取消的消耗品也都会被纳入 因此当交易状态改变时 您就会知道 现在我想说说故障情况 有时候 即使尽最大的努力 您的服务器仍然可能发生中断 现在我来说明您可以怎么协助 您的服务器从故障恢复 当您的服务器遇到故障情形 导致您错过App Store服务器通知 您会想知道这期间有哪些变动 App内购买纪录API此时就是 您的解决方案 只要为每一个用户调用API 提供您App上的 任何originalTransactionId 您就会得到 您App的近期交易纪录 如此一来 您就能更新在您的服务器上了 接着 您可以调用订阅状态API 取得您每一个订阅的 近期订阅状态 现在我要分享最后一个案例 将签名交易迁移到您的服务器 这非常重要 尤其当您会在更新App前 先更新您的服务器 或是当您还在从较旧版本的App中 接收统一化App收据 将签名交易迁移至您的服务器很简单 因为只需要originalTransactionId 您就能轻易将您服务器接收到的 统一化App收据 从您的App转换到JWS收据 如此一来您的服务器就能跟我们的 App Store服务器API 以及App Store服务器通知栏兼容了 进行此动作 要先用统一化App收据 调用verifyReceipt 接着从响应中取出所有的 独特originalTransactionId 调用App内购买纪录API 取得其中一个originalTransactionId 来从签名交易中 取得您App的历史纪录 然后调用订阅状态API 取得订阅originalTransactionId 来为您所有的客户订阅 取得签名交易以及签名续订信息 从签名交易中的内容 写下任何相关的数据 至此您就准备好 可以继续使用这些API 也可以从第二版的 App Store服务器通知栏接收信息了 现在我已经介绍完我们 App Store服务器通知栏所有的更新 以及您如何使用通知栏 确认客户状态的方法

现在我想说说我们如何让您 从您的服务器管理 App内购“家人共享”变得更容易 如果您有在App Store Connect的 App内购买开启“家人共享” App内购“家人共享”目前支持 自动续订及非消耗品购买 现在 我们提供一个叫 inAppOwnershipType的字段 来表示一笔交易来自于 家人共享或是购买 而且我们为家庭成员 支持一个通知栏的子组 “撤销”、“已恢复” 及“续订失败” App内购买所有权类型字段 以及现存支持的通知类型 在新的签名交易以及 第二版App Store服务器通知栏中 仍然会保留 不过 今年稍晚 我们将在 App Store服务器通知栏的功能上 为家庭成员增加更多支持 以第一版通知栏来说 我们将加入 “已更新续订状态” “已更新续订偏好” “已续订”及“手动续订成功” 至于第二版通知栏 我们将为 家庭成员增加更多的支持功能 除了“已更新续订状态” “已更新续订偏好” 及“已续订” 我们还支持“已订阅” “订阅过期” “宽限期过期”及“使用优惠” 给购买者及家庭成员 这会让您通过App Store服务通知栏 追踪所有用户状态 包括购买者跟家庭成员 比以前还要更容易 有了今年这些针对家庭成员 通知栏的更新 “家人共享”原有的功能 加上这些更新 应该会让App内购买中 管理“家人共享”更加简单 我要再介绍一个更新作为总结 在沙盒测试您的服务器 我们想让您对您的App 及您的服务器有信心 因此我们想让您在正式运行前 在沙盒先整合我们新的 App Store服务器API以及 App Store服务器通知栏 以我们今天有讨论到的 App Store服务器API 来说 这意味着App Store服务器API 可以在沙盒完整地测试 而且从即刻开始！ 这包含了订阅状态API 及App内购买纪录API 除此之外 我们还在沙盒 加入了几个新功能 今年稍晚 您就可以 在App Store Connect加入 沙盒专属的通知URL 有了这个新增 您就可以将 您的正式运行 与沙盒通知栏完全地分开 而且您还能选择 您沙盒通知栏的版本 所以您可以在正式运行之前 先在沙盒测试第二版通知栏 去年 我们带来一些关于沙盒 令人兴奋的改良 像是重新设定试用资格 以及提供沙盒一个“管理订阅页面” 我们希望持续让沙盒测试变得更容易 并已在今年加入一些改良了 这些改良有 清除沙盒Apple ID的购买纪录 改变沙盒账户区域 及调整沙盒的续订频率 此外 作为安全性改良 当我们侦测到用户 不再是TestFlight使用者时 我们将针对TestFlight收据 从verifyReceipt回传一个错误 这些新的沙盒改良将适用于 App Store Connect的沙盒测试页面 要清除购买纪录 请选编辑 选取测试项目 接着选取清除购买历史 当您确认清除测试项目的购买历史 此动作就无法复原了 所以请记得您选择清除的测试项目 清除购买纪录 是一个强大的功能 让您可以无需建立新账户 便能重复购买同一项目 并且让您拥有干净又空白的收据 来进行测试 要改变账户区域 或调整续订频率 请回到测试页面 并选取一个测试列

在测试设定中 您会看到改变App Store区域 以及调整续订频率的新选项

您可以选取想要的区域 来改变测试的账户区域 如此一来 只要用一个测试账户 即可在沙盒测试175个店面 我们最后一个沙盒新功能 就是在沙盒调整续订频率 要进行此动作 请自下拉菜单 选择您希望的续订频率 现在 沙盒内的一个月相当于五分钟 我们将提供您的测试页面的 调整续订频率更多选项 调整续订频率 可以给您更多时间去为订阅做 像是取消、升级 或是降级等动作 且让您可以快速将续订时程加速 模拟长期用户 以上就是今年所有沙盒的更新 希望您会喜欢使用这些 新的功能进行测试 我们今天说明了很多新的信息 现在 我希望您能好好探索 上述所有的东西 希望您能花点时间来更新 您的App及服务器 以套用我们新的JWS收据 好好利用我们新的 App Store服务器API 尤其是在现正开放的沙盒中 而且如果您还没的话 请登录App Store通知栏 然后准备迎接今年稍晚将推出的 第二版通知栏 我们也将在今年稍晚推出 新的沙盒改良 利用这些改良来提升 您的沙盒测试体验 最后 请去看看今年此系列的 另外两个介绍 “见见StoreKit 2” 与“支持客户与处理退款” 想知道更多 App Store服务器通知栏的背景 以及设定方式 请收看WWDC 2020的 “App内购更新” 以及“App内购及使用服务器 对接通知栏” 介绍影片 我们的收据、API与通知栏 会是您用来从您的服务器 管理App内购买的三个强大工具 利用这些优势 您可以使您的 服务器与App前所未有的强大 请好好利用我们今天介绍到的 所有新功能 我们期待您之后的回馈 非常感谢您今天的聆听 请继续享受WWDC的其他内容 [轻快音乐]