StoreKit 测试的新功能

StoreKit 测试的新功能

发现可帮助您测试 App 内购买项目与订阅的最新工具。我们将向您介绍如何在 Xcode 中对 App Store Connect 的产品进行 StoreKit 测试，了解交易管理器的改进，并探索 Xcode Previews 中的 App 内购买流程。我们还将与您分享为沙盒环境设置 Apple ID 的最佳实践，说明如何为退款请求、价格上调同意状态、计费重试等创建测试。

资源
相关视频

WWDC23
WWDC22
- App 内购买的新功能
- SKAdNetwork 的新功能
WWDC21
- 管理服务器上的 app 内购买
- 认识 StoreKit 2
WWDC20
- 介绍 Xcode 中的 StoreKit 测试
下载

♪ ♪ Greg: 大家好我是Greg 欢迎使用 StoreKit 测试中的新功能在本次课程中 Peter 和我将重点强调一些很棒的新功能可用于 StoreKit 中的 App 内购买项目的测试我们先来看看使用 Xcode 14 精简你的 App 内购买项目测试的一些方法接下来我们来看一些全新的功能你可以利用这些功能在你的 App 内订阅项目实现中覆盖更多的角落案例最后 Peter 将展示沙盒测试环境新的加强功能我们将与 Food Truck 合作这是一款为销售甜甜圈的 Food Truck 运营商提供强大功能的 App 我已经加入了 StoreKit 以提供完整版的 Food Truck 销售历史记录功能以及订阅加强版的 Social Feed 服务在整个课程中我们将在 Xcode 中使用 StoreKit 来测试我们的 App 的 App 内购买项目功能回到 WWDC 2020 我们在 Xcode 中引入了 StoreKit 测试使你能够在 Xcode 中开始测试你的 App 内购买项目今年有了 Xcode 14 我们很高兴能够分享一些 StoreKit app 的测试生命周期的更新像之前一样你可以创建 Xcode 中的 StoreKit 配置文件并开始在无需在 App Store Connect 中设置 App 的情况下测试你的 App 内购买项目实现当你准备好配置你在 App Store Connect 中的 App 时我们向你推荐 Xcode 14 中的一项全新功能它可以让你使用与你已经在 Xcode 中利用 StoreKit 测试进入 App Store Connect 时一样的 App 内购买项目产品如果你已经有 App 在商店中你现在就可以在 Xcode 中使用 StoreKit 测试无需从头开始设置 StoreKit 配置文件这个方便的功能让你可以配置一次你的 App 内购买项目并在 Xcode 中本地使用相同的配置在你的单元测试中在沙盒环境中以及在 App Store 准备好发布时在 App Store Connect 中使用 Xcode 同步你的产品很容易首先在 App Store Connect 中配置你的产品例如这个 Social Feed+ 订阅然后你创建一个同步的 Xcode 中的配置文件这会将产品数据加载到 Xcode 里面如果你想做出改变例如更新美国英文标题你可以在 App Store Connect 中做出改变并再次在 Xcode 中同步你的配置你还可以将你已经同步的配置转换到一个本地的可编辑的文件中以进行即时更改转换同步配置到本地配置是一种单向操作要想再次同步你就需要创建一个新的配置文件我已经开始设置 Social Feed+ 的订阅组这是 Food Truck app 提供的加强版 Social Feed 服务让我们跳入 Xcode 看看在 Xcode 中使用 StoreKit 测试时如何使用这些产品我在我的 Mac 上打开了 Food Truck 项目首先我们将通过转到文件菜单来创建一个新的 StoreKit 配置文件制作一个新文件通过 StoreKit 过滤并单击下一步
在 Xcode 14 中当我们创建一个新的配置文件时我们得到这个复选框来利用 App Store Connect 中的 App 保持文件同步创建本地文件时要填写名称并取消选中该框设置同步时我们只需要选中该框并确认正确的组和 App 被选中如果需要我们可以选择不同的小组以及使用选择器菜单的 App 我们点击下一步并选择一个地方来保存我们的文件一旦我们保存了文件 App 内购买项目元数据便开始从 App Store Connect 同步在下载数据时我们可以继续开发我们的 App 并在活动栏中跟踪其进度同步完成后你会注意到这个文件看起来与典型的 StoreKit 配置文件有所不同那是因为同步的文件处于只读状态我们一眼便可以看到 Xcode 中所有的数据但要做出改变我们就必须打开 App Store Connect
在 Safari 中我有 Social Feed+ 月度产品让我们通过添加后缀来为这款产品更新英文标题帮助将产品与年度计划区分开来
现在更新完成让我们保存并返回 Xcode
要想让这个改变反映在我们的配置文件中我们只需要在左下角按下这个同步按钮即可
同步完成后我们可以看到 Xcode 中反映的变化
即使同步的文件是只读的我们也可以将数据复制到本地文件在 Xcode 中进行快速更改
除了从配置文件中复制项目之外我们还可以将整个同步文件转换到本地的可编辑文件我们需要做的就是打开我们同步的文件进入编辑器菜单然后点击 Convert to Local StoreKit Configuration
记住你无法撤消转换文件后的此项操作要想再次与 App 同步你就需要创建一个新的 StoreKit 配置文件我想使用 App Store Connect 来保持这个文件同步所以让我们取消这个警报现在我们已经同步了文件让我们配置我们的测试环境作为开始我们将打开方案编辑器
选择运行动作并选择选项
在选项中我们可以从选择器菜单中切换不同的 StoreKit 环境如果我们选择“无” 就会连接到沙盒如果我们选择 Food Truck 就会连接到 Xcode 环境根据我们当前的测试需求来切换环境就是这么简单现在两个环境都将使用完全相同的产品和订阅元数据让我们暂时选择我们的同步配置文档
我们现在已经在 Xcode 中设置了 StoreKit 所以让我们开始测试吧由于我们使用的是 SwiftUI app 我们可以在 Xcode 中预览我们的订阅商店
从 Xcode 14 开始 StoreKit 配置文件中的产品将直接加载到 SwiftUI 预览中这使得构建和测试漂亮的商店用户界面变得超级容易使用真正的 App 内购买项目数据让我们通过为我们的产品添加副标题来试着将一些细节添加到产品选项我们只需添加一个 Text 视图其中包含产品的本地化描述
利用我们在 App Store Connect 中设置的描述即可观看预览更新我认为现在看起来好多了
现在我们的 UI 状态良好让我们在 iPhone 上运行 App 并开始一些功能测试
在 Xcode 14 中 StoreKit Transaction Manager 中有一些强大的新工具随着我们的 App 运行我们可以通过按下调试栏中的购买图标来打开交易管理器
在右边有一个新的交易检查器这使我们能够可视化一笔交易后台的所有细节这个工具有助于理解 App 内交易项目的状态例如我们可以看到日期对 Social Feed+ 的订阅已过期以及即将到来的续订信息我们也可以为了产品订阅组或订阅报价跳转到配置文件我们只需要点击订阅组旁边的跳转按钮即可
在配置文件中我们直接来到了 Social Feed+
当我们查看更高级测试用例时这个检查器将在稍后的课程中帮到我们
我们现在也可以过滤我们的交易这对于浏览包含了所有这些 Social Feed+ 更新的交易列表来说真的很有用在我们的 App 中你会注意到我们可以访问年度销售历史记录功能
我们拥有所有这些订阅续订这使我们很难分辨哪个交易使我们有权使用该功能我们可以通过开始输入其 ID 来轻松地为产品找到交易
从自动完成菜单中选择产品 ID 过滤器
我们还可以在购买日期之前过滤因此我们可以专注于我们现在正在进行的购买
由于我们订阅的 Social Feed+已过期让我们进入 App 并再次订阅
现在我们已经确认了订阅我们可以看到新交易的出现
我们刚刚通过同步产品和订阅从 App Store Connect 中看到了一些在 Xcode 中加强 App 内购买项目测试的方法使用你的 Storekit 配置和 SwiftUI 预览并在 Transaction Manager 中利用新工具现在我们将继续通过在 Xcode 中使用一些新功能来测试 Food Truck 的 App 内购买项目功能以涵盖高级订阅案例首先我们来看一下测试退款请求这使人们能够为在 Food Truck 上购买的产品申请退款接下来我们将测试报价代码提供针对 Social Feed+ 订阅者的促销之后我们来看看如何在 Food Truck 的用户界面中处理涨价最后通过支持计费重试和宽限期减少 Social Feed+ 非自愿流失开始测试退款请求时我们将导航到我们的 App 中的这个支持视图这让我们可以选择最近的交易退款这种代码很简单我刚刚为我们的视图添加了一个 refundRequestSheet 视图修饰符当我们按下退款按钮时我们将把 isPresented Binding 翻转为真现在让我们看看它的实际效果
当 Binding 为真时退款请求会出现在我们的视图上方在 Xcode 环境中测试时我们选择的问题与 StoreKit API 中的 RevocationReason 是一一对应的让我们选择 “Developer Issue” 并按下 “Request Refund ”按钮
在 App Store 中退款请求需要一些时间来处理但是在使用 Xcode 或沙盒进行测试时退款请求会立即退还交易在交易管理器中关于这个更新的交易我们可以看看检查器看看我们刚刚选择的撤销原因和撤销日期
你还可以测试退款只需在交易管理器中点击一下退款按钮退款请求 API 帮助我们为使用 Food Truck 的人提供出色的客户支持现在我们了解了如何测试 Xcode 中的退款请求让我们看看你用 StoreKit 处理退款交易时可以使用的一些方法
当一笔交易退款后更新的交易值将从 Transaction.updates 序列发出我们可以使用revocationDate 和 revocationReason 属性来检测这些退款的交易通过在 Xcode 的退款申请表中选择相应的选项很容易测试两个撤销原因案例这就是你测试 Xcode 中的退款申请表的方式当使用 Xcode 环境或沙盒时这适用于 iOS 和 macOS 对于使用 Xcode 进行测试你需要你的 iPhone 或 iPad 运行 iOS 或 iPadOS 15.2 或更高版本要想在 Mac 上使用 Xcode 进行测试你需要 macOS 12.1 或更高版本现在让我们来看看测试订阅报价代码为此我们将使用我们本地的 StoreKit 配置文件要想为代码提供新的报价我们就要选择订阅然后在报价码表下按下 "+" 按钮然后我们可以配置我们的报价我们将这个命名为“免费月” 并免费提供一个月
就像在 App Store Connect 中一样我们选择那些符合条件的客户以及介绍性报价是否可以使用此报价兑换让我们暂时保留默认设置现在我们的代码已经配置好了我们按下“完成”按钮当然如果你正在同步使用 App Store Connect 那么你配置的报价将自动显示在这个表格中现在我们的报价已经配置好了我们导航到 App 的商店视图我已经在视图底部附近添加了这个按钮用于兑换订阅报价如果我们在 Xcode 中打开商店视图使用报价代码就和添加一个 offerCodeRedemption 修饰符一样轻松在我们看来当有人点击按钮时 isPresent Binding 就会翻转为真我们看看这是如何工作的
当我们按下按钮时兑换表出现在我们的 App 上方在 App Store 中人们可以输入在 App Store Connect 中生成的报价代码但在 Xcode 中的测试体验更加精简在我们的配置文件中我们有所有代码报价的列表按照它们解锁的订阅进行了分组为了兑换让我们点击我们刚刚创建的报价并按下兑换按钮付款单出现我们可以看到代码的报价将在现收现付介绍性报价之后开始
订阅后我们会看到一个确认屏幕我们现在可以关闭工作表并到 Social Feed+ 验证我们的 App 解锁访问
如果我们看这项新交易的检查器那么我们就可以看到介绍性报价目前已应用由于报价是现收现付续订部分显示我们会再续约两次介绍性报价在这之后我们刚刚兑换了免费月份代码然后标准订阅将无限期更新检查器使我们清楚地了解我们的订阅状态发生了什么即使是在复杂的场景中比如多个报价我们刚刚看了如何在我们的本地 StoreKit 配置中的代码配置报价以及如何在 iPhone 上测试兑换它们报价代码是提供灵活促销活动的好方法对于我们未来和现有的订阅者来说现在开始在 Food Truck 中使用报价代码比以往任何时候都容易现在让我们来看看如何使用 StoreKit 处理这些报价兑换代码后两个 Transaction.updates 和 Status.updates 序列将发出新值我们可以在交易价值上检查 offerType 属性查看是否有报价应用到当前交易我们刚刚查看了 offerType 值是否设置了介绍因为我们允许订阅者用代码报价兑换介绍性报价在更新信息值上我们可以检查 offerType 属性看看什么样的报价将在下一次更新中出现在我们刚刚看到的示例中我们可以期待初始值为介绍性报价因为我们使用了现收现付的报价两个订阅期后我们将看到值切换到代码因为我们有一个代码报价堆叠当 offerType 为代码时我们可以使用 offerID 属性来获取申请代码的参考名称这就是你在 Xcode 中测试报价代码的方式从 Xcode 13.3 开始你可以为代码配置报价并在 iPhone 和 iPad 上运行 iOS 15.4 或更高版本来测试它们现在我们已经验证了 Food Truck 中的代码报价的有效性让我们测试一下我们的 App 如何处理 Social Feed+ 的涨价在 Xcode 中测试涨价真的很简单首先我们将提高价格用于每月的 social feed 订阅
此步骤是可选的你可以保持价格不变并且模拟涨价回到交易管理器我们需要做的就是选择最新的订阅交易并在工具栏中按下 “Request Price Increase Consent”按钮
我们可以在交易管理器中看到我们的交易现在在 “Price Increase Pending”状态如果看一下设备我们就会注意到我们的 App 上方出现了一张工作表要求同意涨价此工作表将自行显示无需添加任何代码但我们利用了新的 Messages API 来自定义其行为
让我们看看我们是如何在代码中使用 Messages API 集成的
我们这里有一个循环迭代的消息序列如果我们收到消息比如涨价要确保我们没有呈现敏感视图如甜甜圈编辑器否则我们将使用 DisplayMessageAction 来显示消息如果出现甜甜圈编辑器我们将保留 Message 值并在甜甜圈编辑完成之后显示
让我们回到测试
在 App Store 中现有订阅者在不同的时间可能会收到多条涨价的消息直到他们决定取消或同意涨价在 Xcode 中我们可以完全控制这些消息什么时候来当我们每次在交易管理器中按下按钮时我们都会再次收到消息即使交易已经处于涨价状态现在我们可以测试我们的延迟逻辑是否确实有效所以我先打开甜甜圈编辑器
并发送一个再次打开工作表的消息
工作表还没有出现但是如果我们离开甜甜圈编辑器工作表会按预期显示当我们可以接受涨价或取消工作表中的订阅时用户事实上可能会通过外部资源来回应涨价比如电子邮件为了对此进行模拟我们可以在交易管理器中使用批准和拒绝按钮由于甜甜圈编辑体验非常好我将在交易管理器中按下同意按钮同意新价格在 Xcode 中使用 StoreKit 测试复杂的极端情况例如涨价会很顺利现在我们来看看如何模拟涨价让我们看看如何使用 StoreKit 在我们的 App 中处理涨价
在测试涨价状态时状态更新序列将发出每次状态变化的新值我们可以在我们的 App 中通过检查 priceIncreaseStatus RenewalInfo 值的属性检测到这些更新如果客户由于涨价而取消订阅我们就能够通过检查在 expireReason 属性中的 didNotConsentToPriceIncrease 来检测到这一点我们也可以围绕测试涨价来写单元测试首先禁用对话框可以让我们在 App 没有实际显示涨价 UI 的情况下允许我们测试购买订阅后我们可以使用 requestPriceIncreaseConsentForTransaction API 启动进程给 ID 传入最新的订阅交易要验证测试交易是否正在等待涨价我们将会检查 isPendingPriceIncreaseConsent 属性最后根据我们正在测试的内容我们可以调用 consentToPriceIncreaseForTransaction 或 declinePriceIncreaseForTransaction 来查看我们的 App 如何响应已完成的涨价案例这都是为了测试涨价在所有平台上涨价都可通过 Xcode 13.3 进行测试注意涨价消息只能在 iOS 15.4 或更高版本上测试最后我们来看看订阅计费重试和宽限期计费重试是一种尝试续订订阅时发生错误的状态如一张过期的信用卡在 App Store 中计费重试期间 App Store 将尝试修复问题并恢复订阅你可以选择启用宽限期这使人们可以在计费重试状态开始时在有限时间内继续使用他们的订阅让我演示一下在 Xcode 中进行测试时如何对此进行模拟要想在订阅续订上模拟计费问题我们可以打开正在测试的 StoreKit Configuration 上的“编辑器”菜单并启用 “Billing Retry on Renewal”
我希望 Food Truck 支持计费宽限期所以我们也在菜单中启用 “Billing Grace Period”
我们也会加快订阅速度所以我们可以观察状态如何变化
我们先订阅 Social Feed+
现在让我们等待续订的时机
交易到期时注意我们首先进入计费宽限期状态我们可以看看交易检查器并查看每个状态即将结束的时间
计费宽限期刚刚到期现在我们处于标准计费重试状态我们可以随时使用 “Resolve Issue For Transaction”按钮模拟修复计费错误让我们测试一下解决这个问题
现在问题解决了我们得到了一个新的交易
只要我们能启用 “Billing retry on renewal” 每笔新交易就都将继续进入计费重试所以我们想重复这个测试多少次都可以妥善地处理计费重试和宽限期是通过减少非自愿流失来留住订阅者的关键我们来看看用 Xcode 模拟这些状态有多简单现在就让我们看看如何使用 StoreKit 处理它们随着计费重试和宽限期状态发生变化状态更新序列将发出一个新值由于我们在 Food Truck 中提供了一个计费宽限期我们需要确保订阅者在宽限期内可以访问 Social Feed+ 使用 GracePeriodExpirationDate 更新信息上的属性我们可以看到订阅者的宽限期应该是多久要想检查计费重试我们只需要检查 isInBillingRetry 即可
我们也可以使用 Status 的 state 属性轻松地检测到这些状态中的任何一个如果我们看到一个客户处于这些状态中的任何一个那么我们就可以将他们引导至深层链接到 App Store 解决计费问题如果你正在使用任何当前授权的API 当它们处于宽限期内时你会收到为过期订阅准备的交易我们也可以通过设置 billingGracePeriodIsEnabled 和我们的 StoreKit 测试课程中的 shouldEnterBillingRetryOnRenewal 来控制计费重试和我们单元测试中的宽限期在我们的 App 注意到订阅进入计费重试后测试交易的 hasPurchaseIssue 属性将为真等各种状态更新以及按预期确定我们的 App 更新后我们可以使用解决交易问题的方法来模拟 App Store 恢复订阅计费重试和宽限期可在 Xcode 13.3 或更高版本或稍后在所有平台上测试在稍后的课程中 Peter 会进一步详细介绍如何在 iOS 和 iPadOS 16 的沙盒上测试这些状态
我们了解了从要求退款到处理计费重试和宽限期的高级测试用例关于如何使用新的 StoreKit API 支持其中一些用例的更多详细信息请查看 “What's new with in-app purchase.”
刚刚是对今年 Xcode 的 StoreKit 测试的新功能的一个快速概述但是我们并没有全面讲解这里有新的订阅续订率你可以测试 Xcode 中的 StoreKit 2 App 内管理项目订阅工作表也可以使用 StoreKitTest 为你的SKAdNetwork implementations 编写单元测试请查看 "What's new in SKAdNetwork” 以了解更多信息现在 Peter 将带你了解今年的沙盒测试环境中有哪些新的内容 Peter: 谢谢 Greg 大家好我是 Peter 我是一名 App Store 服务器工程师我们在 Xcode 中看到了 StoreKit 测试的新功能可以帮助你测试更复杂的 App 内购买项目实现我们一直在倾听你的反馈我们知道你们中的许多人依赖于 App Store 沙盒环境来测试你的 App 内购买项目和服务器实现我很高兴能分享一些我们在沙盒中所做的新的加强功能这样你就可以更轻松地测试你的 App 和在线测试环境中的服务器我们将推出加强功能创建 Sandbox Apple ID App Store 连接 API 和计费失败模拟要想使用沙盒环境我们首先需要在 App Store Connect 中设置一个 Sandbox Apple ID 你会注意到我们将沙盒测试人员列表移动到了用户和访问页面上的导航栏在这里我们可以用加号按钮创建一个新的测试器我们通过删除几个字段从新的测试仪窗口简化了创建过程我们现在只问最少的信息这样你就可以在没有不必要信息的情况下继续创建你的帐户你也可以用你的电子邮件地址中的 “plus symbol” 不需要为每个测试人员创建全新的电子邮件地址我们知道创建强密码可能很乏味而我们也让这变得更容易了我们还添加了在线建议有助于使你的密码更安全
我们希望精简 Apple ID 创建表格更好地进行密码复杂性提示帮助你在设置帐户时花费更少的时间并有更多时间开发你的 App App Store Connect 是你可以创建和管理 Sandbox Apple ID 并管理你的 App 内容和组织的中心位置过去几年里我们一直在按你的要求向沙盒添加功能比如更改沙盒帐户区域并清除购买历史记录在 App Store Connect 中或 Sandbox Manage Subscriptions 页面上的设备端有许多功能是可访问的今年晚些时候我们将把沙盒的几个功能加进 App Store Connect API 包括查询 Sandbox Apple ID 列表清除购买历史记录和设置中断购买状态利用你的沙盒帐户可以实现更快的测试并帮助你为常用的测试工具设置自动化客户端最后我很高兴地宣布支持沙盒中的计费失败模拟 2018 年我们宣布了自动续订订阅的 Billing Retry 和 Grace Period 以帮助你减少非自愿流失自 2019 年推出以来 Billing Grace Period 允许你恢复为你的客户提供有偿服务的 3亿天的记录这会为你的业务带来增量收入而你的客户在服务中不会遇到中断当你们中的许多人已经在处理生产中的计费失败案例时我们也想提供更多的沙盒测试场景这样你就可以在你的 App 先于 App Store 发布之前测试和处理计费失败你可以使用新的沙盒帐户设置页面以便为你的帐户启用计费失败模拟在你的 App 上下文中测试订阅失败的前景和背景并使用 verifyReceipt App Store 服务器 API 和沙盒中的 App Store 服务器通知 V2 验证订阅状态关于计费重试以及减少非自愿流失的更多信息我推荐 2018 年的 WWDC 课程 “Engineering Subscriptions” 今年我们在沙盒帐户设置中引入了一个开关用于模拟失败的 App 内购买项目尝试这也是沙盒订阅页的新主页启用计费失败模拟后前台 App 内购买项目将失效该行为与你的客户的付款方式被拒绝时的行为相匹配计费失败模拟还确保了自动续订订阅状态与那些生产中的计费失败相匹配这意味着你可以为你的那些有帐单问题的客户测试 App 内购买项目的消息传递这些订阅状态会通过 V2 通知体现在你的 App 内购买项目收据中让我们回顾一下订阅生命周期当你在沙盒中购买自动续订时你已经收到了 V2 通知比如 SUBSCRIBED 和 DID_RENEW 当你为带有活跃订阅的账户测试失败的 App 内购买项目尝试时下一次更新将进入计费重试状态你现在将在沙盒中收到结算重试的通知比如 DID_FAIL_TO_RENEW 如果你在我们停止尝试恢复你的订阅续订之前禁用计费失败模拟那么下一次续订尝试将会成功你会收到具有子类型 BILLING_RECOVERY 的 DID_RENEW 通知如果我们达到重试次数的限制而且计费失败模拟已启用那么订阅将会过期你会收到带有子类型 BILLING_RETRY 的 EXPIRED 如果你已经在生产中使用了宽限期和沙盒中的 V2 通知那么你预计可以收到带有子类型 GRACE_PERIOD 的 DID_FAIL_TO_RENEW 通知这是一个计费重试状态下的示例订阅带有宽限期如果计费失败模拟仍然在宽限期结束时启用那么你将收到带有子类型 GRACE_PERIOD 的 DID_FAIL_TO_RENEW 通知以及 GRACE_PERIOD_EXPIRED 使用 App Store 服务器 API 验证订阅信息时你可以通过解码 signedRenewalInfo 的有效载荷来验证订阅状态这里我们看到了 expirationIntent 而且计费重试字段已被填充使用处于计费重试状态的订阅收据调用 /verifyReceipt 时你会看到 is_in_billing_retry_period 标志设置了 1 此外在使用宽限期时你现在可以期望填充宽限期到期日期字段完成沙盒中的计费失败测试之后你可以在 Sandbox Account Settings 中禁用开关我们希望这种新的可测试性能帮助你为客户打造最好的可能体验今天我们讨论了几个你可以使用的新测试功能以简化测试你的 App 的 App 内购买项目功能通过在带有 Xcode 的 App Store Connect 中同步你的配置在本地测试或使用沙盒环境测试时你可以使用相同的 App 内购买项目配置报价代码以及 Xcode 中的退款测试等新功能将帮助你验证复杂的 StoreKit 实现而且订阅管理的可测试性将使你能够发展你的 App 以确保出色的客户体验即使他们的服务被中断说到计费失败影响订阅收据以及沙盒中的 App Store 服务器通知 V2 的细节我推荐你观看 WWDC 21 的课程 “Manage in-app purchases on your server” 还有若想了解 App Store 服务器 API 和 V2 通知的最新消息请查看 “What's new with in-app purchase” 我们期待听到你关于这些新功能的反馈感谢你的加入

VStack(alignment: .leading) {
    Text(subscription.displayName)
        .font(.headline.weight(.semibold))
    Text(subscription.description)
}

11:18 - Refund view

struct RefundView: View {
    @State private var selectedTransactionID: UInt64?
    @State private var refundSheetIsPresented = false
    @Environment(\.dismiss) private var dismiss
    var body: some View {
        Button {
            refundSheetIsPresented = true
        } label: {
            Text("Request a refund")
                .bold()
                .padding(.vertical, 5)
                .frame(maxWidth: .infinity)
        }
        .buttonStyle(.borderedProminent)
        .padding([.horizontal, .bottom])
        .disabled(selectedTransactionID == nil)
        .refundRequestSheet(
            for: selectedTransactionID ?? 0,
            isPresented: $refundSheetIsPresented
        ) { result in
            if case .success(.success) = result {
                dismiss()
            }
        }
    }
}

12:33 - Refunds emit an updated value from the transaction updates sequence

for await update in Transaction.updates {
    let transaction = try update.payloadValue
  
    if let revocationDate = transaction.revocationDate,
  	   let revocationReason = transaction.revocationReason {
        print("\(transaction.productID) revoked on \(revocationDate)")
       
        switch revocationReason {
        case .developerIssue: <#Handle developer issue#>
        case .other: <#Handle other issue#>
        default: <#Handle unknown reason#>
        }
        
        <#Revoke access to the product#>
    }
    <#...#>
}

14:21 - Offer code view

struct SubscriptionPurchaseView: View {
    @State private var redeemSheetIsPresented = false
        
    var body: some View {
        Button("Redeem an offer") {
            redeemSheetIsPresented = true
        }
        .buttonStyle(.borderless)
        .frame(maxWidth: .infinity)
        .padding(.vertical)
        .offerCodeRedeemSheet(isPresented: $redeemSheetIsPresented)
    }

}

16:23 - Offer redemptions emit updated values from Transaction.updates and Product.SubscriptionInfo.Status.updates

for await verificationResult in Transaction.updates {
    guard case .verified(let transaction) = verificationResult else {
        <#Handle failed verification#>
    }
    <#Handle updated transaction#>
}

for await updatedStatus in Product.SubscriptionInfo.Status.updates {
    guard case .verified(let renewalInfo) = updatedStatus.renewalInfo else {
        <#Handle failed verification#>
    }
    <#Handle updated status#>
}

16:31 - Check the active offer on the transaction value

for await status in Product.SubscriptionInfo.Status.updates {
    let transaction = try status.transaction.payloadValue
    let renewalInfo = try status.renewalInfo.payloadValue
    
    if let currentOfferType = transaction.offerType {
        switch currentType {
        case .introductory: <#Handle introductory offer#>
        case .promotional:  <#Handle promotional offer#>
        case .code:         <#Handle offer for codes#>
        default:            <#Handle unknown offer type#>
        }
        self.hasCurrentOffer = true
    }

    <#...#>

}

16:49 - Check the next pending offer on the renewal info value

for await status in Product.SubscriptionInfo.Status.updates {
    let transaction = try status.transaction.payloadValue
    let renewalInfo = try status.renewalInfo.payloadValue
    
    <#Check active current offer#>
    
    if let nextOfferType = renewalInfo.offerType {
        switch currentType {
        case .introductory: <#Handle introductory offer#>
        case .promotional: <#Handle promotional offer#>
        case .code:
            print("Customer has \(renewalInfo.offerID) queued")
            <#Handle offer for codes#>
        default: <#Handle unknown offer type#>
        }
        self.hasQueuedOffer = true
    }
    <#...#>
}

18:45 - Messages updates loop

private var pendingMessages: [Message] = []

private func updatesLoop() {
    for await message in Message.messages {
      if <#Check if sensitive view is presented#>,
         let display: DisplayMessageAction = <#Get display message action#> {
           try? display(message)
      }
      else {
        pendingMessages.append(message)
      }
    }
}

20:53 - Price increase changes emit an updated value from the status updates sequence

for await status in Product.SubscriptionInfo.Status.updates {
    let renewalInfo = try status.renewalInfo.payloadValue

    if renewalInfo.priceIncreaseStatus == .agreed {
        print("Customer consented to price increase")
        <#Handle consented to price increase#>
    }
    if renewalInfo.expirationReason == .didNotConsentToPriceIncrease {
        print("Customer did not consent to price increase")
        <#Handle expired due to not consenting to price increase#>
    }

    <#...#>

}

21:19 - Unit testing price increases

let session: SKTestSession = try SKTestSession(configurationFileNamed: "<#Configuration name#>")
session.disableDialogs = true

<#Purchase a subscription#>

var transaction: SKTestTransaction! = session.allTransactions().first
session.requestPriceIncreaseConsentForTransaction(identifier: transaction.identifier)

transaction = session.allTransactions().first
XCTAssertTrue(transaction.isPendingPriceIncreaseConsent)

<#Assert app updates for pending price increase#>

// Write a test case for consenting and cancelling due to price increase:

session.consentToPriceIncreaseForTransaction(identifier: transaction.identifier)

// OR

session.declinePriceIncreaseForTransaction(identifier: transaction.identifier)
session.expireSubscription(productIdentifier: "<#Product ID#>")

<#Assert app updates for finished price increase#>

24:57 - Billing retry and grace period status changes emit an updated value from the status updates sequence

for await status in Product.SubscriptionInfo.Status.updates {
    let renewalInfo = try status.renewalInfo.payloadValue

    if let gracePeriodExpirationDate = renewalInfo.gracePeriodExpirationDate,
       gracePeriodExpirationDate < .now {
        print("In grace period until \(gracePeriodExpirationDate)”)
        <#Allow access to subscription#>
    }
    else if renewalInfo.isInBillingRetry {
        <#Handle billing retry#>
    }

    <#...#>

}

25:27 - Using the state property of a status value to check for billing retry states

struct SubscriptionStatusView: View {
    let currentSubscription: Product
    let status: Product.SubscriptionInfo.Status
    @Environment(\.openURL) var openURL
    var body: some View {
        Section("Your Subscription") {
            <#...#>
            if status.state == .inBillingRetryPeriod || status.state == .inGracePeriod {
                VStack {
                    Text("""
                    There was a problem renewing your subscription. Open the App Store to
                    update your payment information.
                    """)
                    Button("Open the App Store") {
                        openURL(URL(string: "https://apps.apple.com/account/billing")!)
                    }
                }
            }
        }
    }
}

25:41 - Current entitlement APIs will account for grace period

for await entitlement in Transaction.currentEntitlements {
    <#Grant access to product#>
}

25:50 - Unit testing billing retry and grace period

let session: SKTestSession = try SKTestSession(configurationFileNamed: "<#Configuration name#>")
session.billingGracePeriodIsEnabled = true
session.shouldEnterBillingRetryOnRenewal = true

<#Purchase a subscription#>

wait(for: [<#XCTExpectation#>], timeout: 60)

let transaction: SKTestTransaction! = session.allTransactions().first
XCTAssertTrue(transaction.hasPurchaseIssue)

<#Assert app still allows access to subscription due to grace period#>

wait(for: [<#XCTExpectation#>], timeout: 60)

<#Assert app detects billing retry and no longer allows access to subscription#>

session.resolveIssueForTransaction(identifier: transaction.identifier)

<#Assert app allows access to subscription#>

正在查找特定内容？在上方输入一个主题，就能直接跳转到相应的精彩内容。

提交你查询的内容时出现错误。请检查互联网连接，然后再试一次。

资源

相关视频

WWDC23

WWDC22

WWDC21

WWDC20