大多数浏览器和
Developer App 均支持流媒体播放。
-
认识 StoreKit 2
StoreKit 2 为 app 内购买和自动续订提供强大的 Swift 原生 API。学习如何轻松实施 app 内购买和订阅,发现检索产品信息、处理交易、决定产品权利和客户状态的 API,以及 Xcode 中的综合测试支持。
资源
- App Store Server API
- App Store Server Notifications
- Human Interface Guidelines: In-app purchase
- Implementing a store in your app using the StoreKit API
- In-app purchase overview
- Introducing StoreKit 2
- JWS documentation (RFC 7515)
- Learn more about designing subscriptions
- StoreKit
相关视频
WWDC23
WWDC22
WWDC21
WWDC20
WWDC19
-
下载
♪播放重低音音乐♪ ♪ 嗨 欢迎来到WWDC21 我是罗斯勒博 我是StoreKit团队的工程师 今天 我们要为各位介绍StoreKit 这是三段影片的其中一段 协助你实作客户端程序代码 架构一个支持App内购买的服务器 还有如何协助客户以及处理退款 这里要介绍的是“遇见StoreKit 2” 你可以在WWDC21 找到其它两段影片 这段影片会把焦点放在客户端的功能 以及实现 让我们开始吧 自StoreKit在iOS 3上市以来 为你及你的事业带来了很大的商机 今日 在四个Apple平台都能找到它 它支持了各种项目 从游戏到新的App 从独立创作到全球畅销作品 这些来年 我们介绍过几项重要功能 例如提供程序代码、家人共享 以及在Xcode上测试StoreKit 但今年 我们决定回到最开始 今天 我很兴奋地向大家介绍 StoreKit 2! StoreKit 2是个全新的 现代化且灵活的Swift APIs 能支持跨平台的App内购买 包括iOS、macOS、tvOS 以及watchOS 我们以一个以Swift优先的 思考模式来架构StoreKit 我们运用了一些最新的语言功能 例如使用async/await模式的 Swift并行处理 创造简单但很有用的API 我们也针对App内购买 交易机制做了大幅更新 让它们更方便使用 同时提供更多的信息 以及更高的安全性 我们还针对订阅功能 增加了效用强大的API 让你针对如何提高业绩 获得更深入的启发 StoreKit 2 API位于现行的StoreKit 同样的架构内 把重点放在主要的App内购买功能 而不是取代每一个API 新的StoreKit 2 API包含五个主要领域 产品、购买、交易信息 交易历史、以及订阅状态 今天 针对这五个领域 我都会做概略介绍 我同事雅各布将会带你认识如何将 相对应的StoreKit 2 API 应用在真的程序代码上 首先 我们从StoreKit的基础开始 产品及购买 StoreKit 2 的产品架构是你熟悉的 StoreKit产品对象的加强版 首先 我们增加了额外的资料 例如产品类型 也扩展了订阅信息 在StoreKit 2 使用上更为便利 例如找出客户是否负担得起 你提供的上市价 我们也让StoreKit 2的产品功能 能够与新增的功能正向兼容 我们用一种环绕式的做法达成 称为BackingValue 让你能够通过直接下标产品 撷取存在于产品上的数据 这就表示 未来当我们在 产品上增加数据时 你永远都能在StoreKit 2上 取得这些资料 即使SDKs及所使用的装置 其操作系统上的是 旧版本的StoreKit 2 这就表示你可以使用最新的功能 提供新的服务 给更广大的客层 在StoreKit 2 你通过调用 产品类型上的静态函数请求产品 这需要App Store上的元数据 与现有的SKProductsRequest相同 但多亏了新的Swift 并行处理async/await 模式 StoreKit 2的产品请求 只需要一行程序代码 同样的 在StoreKit 2购买一项产品时 也是一项仅需一行就能完成的工作 购买 现在成了产品类型的实例方法 也就是你刚刚撷取的产品 可以直接对它们调用购买 因为购买方式也是使用async/await 你可以在你的内嵌程序代码上 得到你的购买结果 但我们知道每笔交易不见得相同 如果你想要调整超出初始设定的 购买行为 StoreKit 2 有提供 购买方式选项 购买方式选项是一个项目 描述了该次购买的单一属性 你可以将购买方式选项结合成一组 将这个组合变成购买方式选项的一种 StoreKit 2提供的购买方式选择包括 数量以及优惠方案 而且在StoreKit 2 我们还新增了一个选项 称为App账号令牌 App账号令牌可以让你追踪 你App的使用者账号 从开始到完成一笔交易 你生成的是一个不透明令牌 你可以连接到你App拥有的账号 App账号令牌相当容易生成 因为它唯一的要求是与 UUID格式吻合 你替该笔购买送出一个App账号令牌 做为一个购买方式选项 这个令牌会回到该笔购买的 交易信息里 App账号令牌会永远存在于 交易信息里 甚至可以跨越不同装置 如果你的App支持它所属的账号系统 它能协助你追踪每个App内账号 产生了哪些购买 不管是使用哪一个Apple ID或装置 来购买都可以 我们介绍了如何从App Store 取得商品 以及发起一笔购买 那么当购买完成时会发生什么事? 跟你所想的一样 StoreKit会回传一笔成功的交易给你 连同加密过的签名信息 听起来很熟悉 对吧? StoreKit 2为App内购买带来了 史上最大的更新 首先 StoreKit 2将能为 每一笔交易提供个别的签名对象 此外 自StoreKit 2开始 App内购买交易信息将会以 一个非常普通、操作便利的JSON 格式呈现 我们了解取得加密签名资料 是StoreKit购买一个很重要的部分 我们现在可以使用一个 跨平台的共同标准 称为JWS 此外 所有存在于该 签名对象的所有信息 将能够从原生的StoreKit API取得 你便能够在你的App程序代码上 轻松地使用这笔数据 事实上 我们将展示给你看有多容易 雅各布将在影片中使用真的 程序代码向各位展示这些API 嗨 我是雅各布 我是StoreKit团队的一名工程师 我今天很兴奋地将为各位展示 在你的App上启动以及使用StoreKit 2 是件多么轻松的事 在屏幕右边 有一个我正在构建的 App 叫Pocket Cars 你可以在这个影片的资源区 下载本App的样本程序代码 然后继续看影片 这个App有两个主要画面 一个画面是我收集的车子 另一个是我的商店 我们来到商店的画面 目前我的商店空无一物 因为我没有待售的商品 我将要开始加入我的商品 为了加快速度 我将使用由Xcode测试的StoreKit 这能够让我在尚未于 App Store Connect 定义我的产品之前 就能构建及测试我的商店 在我的Xcode项目 我已经建立好StoreKit 的配置文件 定义了我想出售的商品 这与我在StoreKit使用的配置文件 是同一个 我不需要改变或是转移任何东西 这里 我同时有个plist文件 包含了我所有产品的标识符 它以资源文件的形式内建在我App 所以我在执行期可以使用它 为了在我的商店展示这些商品 首先 我需要提出产品请求 我会使用一组我希望被展示出来的 产品标识符 在StoreKit 2 我仅需 调用产品架构的静态方法 我从App Store收到产品后 我想用类型来区分产品 使用StoreKit 2将可以轻松完成 因为这个产品类型提供的类型属性 跟在App Store服务器上 所定义的相同 在我的App 我出售的产品 有三种类型 燃料、车辆、以及导航软件包 燃料是一种消耗品 一旦我使用了 它变消失了 所以我会将所有消耗品都放在 燃料数组 车辆属于非消耗品 一旦我买了一辆车 我永远都能持有它 所以我将所有非消耗品 放在车辆数组 导航软件包是一个订阅性的产品 共有三种等级 我的客户能够一次订阅一种等级 他们将定期付费 而且当他们想要调整服务等级时 他们能随时升级或是降级 App Store针对每一种等级的服务 将会回传一个产品 所以我会将所有的自动续订 放在订阅数组 我还想将我的产品 依照不同类型依价格排序 从最低价排到最高价 来执行一下我的App 看看我目前的成果如何
现在我想移到我的商店 哗! 之前 我的商店空无一物 而现在看起来相当不错 我的产品都被展示出来了 我仅需要使用一行程序代码 就能够从App Store请求我App的商品 仅仅基于我收到的元数据 我能够分类及排序这些产品 使得构建我商店的UI变得相当容易 现在我的商品看起来很棒 但是当我点击购买钮时 什么事都没发生 这是因为我商店的购买方式选项 没有起作用 它应该要能够借着StoreKit启动购买 我们只需要调用产品的 购买方法 如同罗斯提到的 StoreKit 2 是从无到有构建出来的 使用新的Swift并行处理功能 这让我App的购买程序代码 以及处理这笔购买的程序代码 处于同样的脉络 这样我的程序代码便能够轻易被阅读 当一笔购买完成时 一笔购买的结果会被回传 这笔购买结果让我知道 该笔购买是否成功 还是它停在其它非错误的阶段 例如使用者取消购买 或是该笔购买需要 银行给予额外确认 或是需要父母的核可 为了处理每个不同的状况 我只需要去到那个阶段 如果购买结果是在成功这个阶段 我同时会得到一个验证结果 一个验证结果包含两种状况 验证过、以及尚未验证过 在StoreKit 2 交易类型 包含了JWS有效载荷 代表了签名过的交易 每一次我的App从StoreKit 2收到交易 这笔交易会经过一个验证流程 来确认有效载荷是否 由App Store签名 之后才进到这个装置上的我的App 你没有听错 StoreKit 2帮你完成了验证 当然 要如何处理验证结果 完全可以按照我的营业需求 由我决定该怎么做 针对我的App 我想确认 我从StoreKit 收到的这笔交易是 经过验证的 在我的商店 我将建立一个 checkVerified方法 能够被用在任何一个验证结果 假如这个结果尚未完成验证 我会丢出我自己的 failedVerification 错误信息 提醒我App的其它区域 如果结果已完成验证 我会把交易打开 回传给它的调用者 现在我可以在购买结果 使用checkVerified方法 最后 带着经验证过的交易 我将内容传送给使用者 使用者收到内容之后 我必须确认我告诉StoreKit 将交易结束 接着我必须回传 让我的UI 能够同步更新 我的App有一个我自行维护的 账号数据库 我希望这笔StoreKit的购买纪录 能够与我App上的 用户信息同步 当它取得App Store的签名交易时 我永远能够从我的App上 取得这个信息 我能用我的已登入账号令牌化版本 创建一个 appAccountToken购买方式选项 来达到这个目的 将这个选项传到购买方式 好的 我的购买方式实作就完成了 再来执行一下我的App
现在我们回到了我的商店 我感到相当新奇 我要来购买一台摩托车 因为我一直想要一台 这是StoreKit提供的付款单 显出这笔购买已经成功建立 我将点击确认这笔购买 StoreKit 接着会显示出一个警示 显示出这笔购买已成功 在我解除这个警示之后 我的购买钮会变成一个绿色的剔号 表示我的App相信这笔交易 我的摩托车已被寄送 还有一个重要事项要请大家注意 如同我先前说过的 有时候客人的账号必须经过 一些额外的验证 或是需要家长的核准 之后购买才会完成 遇到这些状况 我从product.purchase收到的购买结果 会处在待处理阶段 这表示在客户完成 账号验证、或是他们的家长 给予核准之后 我的App需将UI更新 反映出 购买已完成 为了监听这些交易更新状况 我必须反复查询交易类型的 静态属性
这个属性是一个无限异步序列 这表示当资料从StoreKit传来时 它会不断地反复查询交易更新 至到我选择取消或是将回路打断 我在这里建立一个中断连结工作 之后会回传一个我能使用的 任务处置柄 当商店解除分配时 明确地将我的更新监听器取消 如同所有我从StoreKit 2 接收到的交易一样 在将内容传送给使用者之前 我想要确认 验证结果是否已经被验证过 我可以使用先前定义好的 checkVerified方法 如同购买响应一般 一旦我收到验证过的交易时 我必须将内容传给使用者 当然 我必须结束我的交易 很重要的一点是 在我的app上市时 我即刻就开启更新监听器 我就不会错失任何一笔 在我的商店开张时 我即刻就要执行这项功能 差不多与我的App上市的时间相同 为了测试我的更新监听器 我要在我的Xcode测试环境上 启用询问购买 来模拟待处理阶段的购买响应 为了完成这项工作 我选择我的 StoreKit配置文件 在编辑菜单上 选择启用询问购买 再一次执行我的App进行一笔购买
这一次 在确认付款单后 我看到StoreKit出现一个新警示 显示我需要询问核准 才能完成我的购买 我点击询问 购买回应回传至我的App 的待交易阶段 为了核准这笔购买 我在Xcode的 交易管理员打开StoreKit测试 点击右上方的核准钮
太好了 我核准了这笔交易的那一刻 我的更新监听器便收到了验证结果 UI 立刻更新 将核准过的购买 显示出来 现在我可以坐上全新的标准五人座 到处遨游 你现在知道了这些作业有多么容易 包括请求产品 进行一项购买 对不同的购买结果进行响应 验证一笔交易是否属实 以及从App Store接受 待处理交易的更新状况 这些都能通过StoreKit 2达成 接下来将由罗斯向大家介绍 如何使用你的用户交易历史 以及订阅状态 哗 亲眼看到这些新的API起作用 真令人感到兴奋 还有自动验证 所有的需求都被满足了! 那是什么? 你很喜欢密码学 你仍然想要靠自己验证数据? 没有问题 StoreKit 2的自动验证 提供了高强度的安全性 但这并不表示它要完全取代 你自己的验证程序 一直以来 安全性涵盖了 强度、时间、以及复杂度 我稍候将会为大家介绍验证 首先 如果你跟我一样对于 StoreKit 2的交易感到很兴奋 你听到这个将会很开心 我们将提供很多新方式让你操作 交易流程 我们新增了一组API 让你能够查询使用者 交易历史中的已完成交易 在StoreKit 2 你能够取得 所有用户的历史交易 通过一个API调用即可完成 你也能够取得某项产品的最新交易 所以 如果你想看看最新的 订阅更新 也办得到 我们都知道 你需要知道的第一件事 是用户目前付费使用的产品为何 我们将那些信息撷取出来 放进一个称为当前权限的单函数 当前权限包含了该用户交易历史上 所有非消耗品 以及所有目前仍有效的 订阅交易 这样 你便备齐了所有信息 来解锁使用者在你的App所付费过的 所有商品 因为这里只有使用者 目前能够使用的产品 所有被驳回的交易 不会出现在这里 消耗品也不会出现 因为他们不是永远存在这类 交易历史上的项目 现在你一定想着“我等不及了” “我何时可以开始在我的App 调用这些资料?” 在StoreKit 2 用户完成的每一笔交易 只要你提出要求 你就可以在你的 App取得 也就是说 当用户在一个新装置 下载了你的App 你就会知道 他们可以取得的产品有哪些 在他们第一次打开你的App的时候 你就会知道 此外 交易历史会在用户的 所有装置上自动更新 当你的用户使用某一个装置 完成一笔购买 有下载你App的其它装置 都能够看到这笔交易 事实上 如果你的App正被启用 当一笔购买在另一台装置上完成时 装置会收到这笔新交易的提醒 雅各布提到要特别注意 在你启用App的当下就要开启监听 这里又再度证明了这个重要性 这表示 当你的App被重新下载、或是下载到 另一个新的装置上时 用户不需要恢复完成的交易 所有内容都能够自动通过 StoreKit取得 并且同步更新 但是大家使用Apple装置的方式 有几百万种 而且在几百万个不同的地方 在极罕见的情况下 一位使用者 认为他有笔交易没被App看到 此时 你能够使用App Store sync API 它能够将StoreKit 2上所有的交易 立即进行同步更新 这取代了 restoreCompletedTransactions API 而且你应该让你App的UI 有这个功能 让用户启动同步功能 然而 多亏了StoreKit 2的自动更新 使用者需要 自行启用同步 是非常罕见的 大部分的状况下都可以执行 自动同步 如果一位使用者必须自行启动 同步功能 他们需要先进行账号验证 为了这个目的 你必须使用这个API来响应 使用者输入的内容 最后 所有使用StoreKit 2 API 所完成的交易 都能在原始的StoreKit API取得 反之亦然 如果你的App上原本就有交易纪录 一旦你开始使用StoreKit 2 API 你就能在上面见到这些信息 使用原始StoreKit API完成的新购买 通过StoreKit 2 API 立刻就会出现在StoreKit 2上 在StoreKit 2完成的购买 在统一的收据信息更新之后 便会出现在上面 除了交易历史之外 StoreKit 2也增加了让你取得 详细信息的方式 有关用户订阅状态的信息 订阅状态共有三个部分 首先是最新的交易 这使得你很方便就能取得 该笔订阅的 最新交易纪录 这与我们先前介绍过的 调用最新交易所得到的结果相同 第二部分是更新状态 这个列表将告诉你 该笔订阅的最新状态 如果你想知道订阅 目前的状态如何 只需要参阅这个值 它会告诉你是否为订阅中 过期、处于宽限期、或是其它状态 我们设计成你只需要到一个地方查看 这样的话 App的逻辑便可轻松 用在这个值上 订阅状态的最后一个部分是更新信息 在这里你可以找到使用者 详细的订阅信息 它包含了各式各样的信息 在事务信息里是找不到的 因为在这里的信息无需交易 也可以被改变 举个例子 在更新信息里 你可以找到自动更新状态 你便可以知道使用者是否有开启 该笔订阅的自动更新 你甚至看得到 有设定自动更新的产品ID 如果一位使用者最近调降了订阅 服务等级 你在这里便看得见 你或许可以借着这个机会提供他 有吸引力的优惠方案 让他愿意 留在较高的等级 如果订阅已经过期 你可以在更新信息上得知过期的原因 完整的更新信息包含所有的数据 此外 尚有另一项重要功能 没错 你们这些密码学爱好者 更新信息是用JWS签名 跟交易信息一样 更新信息也是解锁服务 重要的内容之一 亦有助于制定营销决策 我们可以免除你的担忧 这个信息是直接从Apple取得 而且经过验证 现在来回答 正浮现在你脑海里的问题 是的 StoreKit 2 会将你的更新信息 自动更新 最后一个关于订阅状态API 你该知道的事 它们会将状态数组回传 这是因为 某些状况下 针对同一个产品 用户会有 好几种订阅服务 举个例子 用户订阅你的产品之后 也从家人共享 取得了订阅服务 此时你该查看数组 他们能够享受的最高服务等级为何 现在我请雅各布展示给各位看看 如何使用你的App程序代码 操作交易历史及订阅状态API 谢谢 罗斯 我们回到我正在开发的App 更新之后 便可使用罗斯 刚刚提到的最新的交易历史 以及订阅状态API 你可以看到我之前买的摩托车 没有绿色的剔号 我离开商店页面之后 再回来 这辆标准的五人座也没有绿色剔号 这么一来 使用者就无法辨识 已经买了什么产品 StoreKit 2可以轻松解决这个问题 任何时候 我的App都可以 查询StoreKit 找出已购买过的产品 所以我能够让我App的UI永远保持 在最更新的状态 在我的Store.swift文件上 isPurchased方法目前回传的结果 是错误 只需一个简单的步骤就能解决 调用Transaction.latest(for:) 接着输入我的产品标识符 以取得最新的交易 这个StoreKit方法回传了另一个 验证结果 通知我交易已经通过 StoreKit 2的验证确认 我将使用我之前编写的 checkVerified方法 确认这笔交易已经过验证之后 再打开它 接着 我查看revocationDate equals nil 来确认我的App没有传出 退款完成的交易内容 还有 当我的客户在订阅期间 升等了服务内容 订阅会将isUpgraded旗标会设定为真 我想要确认我的App传送出去的 是我客户所订阅最高等级的服务内容 因此isPurchased方法应该忽略 所有升等的交易 针对一个订阅产品 交易类型提供的仅有部分信息 除了交易日期之外 以及订阅到期日之外 我也想知道下一次的更新日期 以及是否我的客户已关闭自动更新 订阅服务 或是他们下一次的更新期间 是否会改变所订阅的服务等级 为了取得这些信息 StoreKit 2提供了一个订阅状态API 在我的SubscriptionsView.swift文件 这个updateSubscriptionStatus方法 负责从StoreKit 取得订阅状态 并将之展示给使用者 因为我所有的订阅产品 属于同一种类别 我能使用其中一个 就能取得该组别的目前状态 我将从我的商店选择 第一笔的订阅产品 一旦我有了一项产品 我便能从订阅取得状态属性 就是这么容易 如同罗斯提到的 有可能使用者 自己付费购买他们的订阅产品 但同时也通过家人分享 获得了订阅产品 所以状态属性会回传一个数组 包含了每个订阅产品的所有状态 现在 他们经由分享获得了一个 标准等级的产品 而自行购买的是专家等级 我希望确保我的使用者能够取得 他们权限范围内最高等级的服务 所以我会循环访问每一个状态 接着 我要确认状态 是否过期或是被驳回 我想要忽略这些状态 不将这些信息展示给用户 而其它状态 我将会取得更新信息 并确保有经由 我商店的checkVerified方法完成验证 一旦我确认了renewalInfo已经过验证 我将会把服务等级与 之前的商品比对 这个方法能够取得 所对应商品的订阅状态 然后它会与先前所有的产品 进行比对 如果它是较高的等级 我们 将这笔新的订阅 设定成highestStatus以及highestProduct 一旦我确认完所有的状态 且找出了最高的服务等级 我将替我的画面设定状态 以及目前订阅 我们来构建跟执行吧
来到我的商店画面 我先前购买的产品 有了绿色剔号 表示我已经拥有了这些产品 我不需要再购买一次 我们来看看如果我购买 一项我的订阅产品 会发生什么事
在我确认购买之后 我的商店立刻会出现状态 我能让我的使用者知道他们 所订阅的产品 以及产品何时进行更新 全部都是使用内建于 StoreKit 2的API即可完成 那么 我的汽车画面又是如何呢? 它必须列出所有我购买过的产品 但目前空无一物 为了让它出现数据 我可以 循环访问我所有的产品 然后取得每一项产品最新的交易 检查交易的到期日 以及检视它是否已被退款 但这工作量听起来很大 幸好 我能够使用 StoreKit 2的强大功能 以及一个新的、操作简易的API 来取得所有用户的已验证交易 称之为currentEntitlements 来到我的汽车画面 我用这个方法 加载我的画面 重新整理 我购买过的产品 与更新交易相同 我重复查询当前权限 但与更新交易不同的是 当前权限的异步序列是有限的 所以它不会永远等着for循环 在使用者每完成一笔订阅时 会传送一个新的权限 针对每一笔权限 我都要确认验证结果 就跟我其它交易一样 一旦我知道他们已经过验证 我会通过切换权限的productType属性 将它们分配到不同的数组 跟我处理我原始的产品请求一样 当前权限只会将 非消耗品及自动更新的产品回传 我可以忽略其它的产品类型 以完成我的切换语句 让我Swift编译程序感到很开心 一旦我有了交易 我必须让交易对应到的产品 显示在我的UI上 针对非消耗性产品的交易 我会检索汽车产品数组 找寻与该笔交易相符的产品标识符 同样地 我会检索订阅产品数组 找出与自动更新交易相符的产品 再执行一次之后 来看一下我的UI
现在 当我进入我的汽车画面时 我就能看见所有购买过的商品了 我所有的车辆分类在画面上方 订阅产品则在下方 我的App现在有了功能完整的商店 而且它看起来真棒 这就是你能够如何使用交易历史 以及订阅状态API 针对在你的App上 该让使用者 见到哪一种UI 协助你做出明智的决定 接着再由罗斯向大家更进一步介绍 JWS对象 雅各布 再次谢谢你为大家 带来这么精采的介绍 你能够清楚见到这个新的交易 以及订阅API真的是相当好用 现在 我们已经见到了两种 StoreKit 2使用JWS寻求安全性的做法 我答应过你会深入介绍JWS 以及你如何自行验证 JWS由三个部分组成 第一个是标头 包含了该对象的元数据 这包含了重要信息 例如哪一种算法被用在签名 以及去哪里找寻 用来验证签名的证书 StoreKit 2目前使用ECDSA算法 有CryptoKit的Swift可支持这个算法 针对证书 StoreKit 2使用x5c标头 这表示整个证书炼 都被包含在JWS资料 也就是说不需要使用到网络 就能验证JWS签名 JWS的第二个部分就是有效载荷 这里便是主要信息 例如交易ID 产品ID、购买日期…等等 一旦你验证了签名 你可以到这里查看有关交易 以及订阅你想知道的一切数据 JWS数据的最后一个部分 是签名本身 这是同时使用标头 及有效载荷取得的资料 验证JWS签名 这个部分有详细的文件说明 如果你有兴趣编写你自己的实作 我建议你真接了解原始来源 我在与这个章节相关的资源区 放置了一个连结 一旦你从JWS数据验证了签名 还有一些事情需要完成 以确保这份已签名的信息 对你的App 及目前的装置是有效的 首先 你要确认 签名信息有效载荷上的bundle ID 与你App上的bundle ID相符 这样做能提高安全性 你将你App的bundle ID 内建于App的某处 而不是依赖调用API 然后使用这个值与有效载荷的 bundle ID互相比对 你最后一件该做的事 是进行装置验证检查 这样能确保这笔签名信息 实际上是 针对它目前所处的装置而生成的 使用StoreKit 2 API AppStore.deviceVerificationID 检索目前装置的验证标识符 接着 将这个签名资料上的 装置验证nonce 附加你刚刚从StoreKit 取得的设备验证标识符 把这个值进行SHA384哈希之后 将结果 与从签名信息取得的装置验证 输入格互相比对 如果它们互相吻合 就表示 这笔签名信息 是针对这个装置而生成 那么你的签名信息验证就完成了 最后一个需要注意的是 这些新的JWS对象 只能使用于App内购买 所以如果你需要验证App收据 你必须使用现有的API 用它完成验证 当然 针对这些新的JWS对象 我们有提供App Store服务器API 所以你可以直接在你的服务器上 检索及验证它们 那么 希望你也跟我们同样地 为StoreKit 2的各项功能感到很兴奋 StoreKit 2让App内购买的功能更强大 通过新的API能提供你更多信息 而且更易于操作 这包含了每一笔交易新增的 以JSON为基础的对象 以及能提供以你的原生程序代码显示的 交易细节及历史交易信息的API 再加上新增的订阅状态API StoreKit 2为你的App内购买 解锁了一连串的可能性 想要更进一步了解App内购买 我建议你观看其它影片 以了解服务器编码以及客户支持 雅各布跟我都很兴奋 有这个机会向你们介绍StoreKit 2 谢谢你参加WWDC21 ♪
-
-
正在查找特定内容?在上方输入一个主题,就能直接跳转到相应的精彩内容。
提交你查询的内容时出现错误。请检查互联网连接,然后再试一次。