WWDC22 - In App Purchase 更新总结
作者:iHTCboy
前言
WWDC21 是历年来 In App Purchase(IAP,内购内购买)最大的变化,分别推出了 StoreKit 2、App Store Server API、App Store Server Notifications V2 三大特性,去年我们也编写了 《苹果iOS内购三步曲:App内退款、历史订单查询、绑定用户防掉单!--- WWDC21》 文章,所以我们本文不会再深入提及去年的更新,大家如果不太熟悉,可以先温习一下。本文将对今年 WWDC22 带来的变化,从整体的视角一起回顾。
以下是编者对 In App Purchase 这几年重要的更新或调整的梳理:
说到内购,环绕着的新闻,总起到一些波澜,从 2021 年苹果推出 App Store 小型企业计划,降低 15% 的佣金,大家的讨论一直源源不断,对于小型企业和开发者,确实是明显感受到 15% 带来的回报!本文不去讨论合理性,App Store 从 2008 年推出就是一个创举,它改变了世界对 App 的认识。我们本文更多的是讨论如果利用这些变化,为用户提供更好的服务或体验!
本文主要从四方面进行探讨:
StoreKit 2
App Store Server API
App Store Server Notifications V2
App Store Connect
StoreKit 2
StoreKit 2 和 Original StoreKit,应该怎么选择?苹果在选择文档在给出了答案:
StoreKit 2: 一个基于 Swift 的 API,以 JSON Web Signature (JWS) 格式提供 Apple 签名交易验证,从 iOS 15、macOS 12、tvOS 15 和 watchOS 8 开始提供。
Original API for In-App Purchase: 一个使用 App Store 收据提供交易信息的 API,从 iOS 3、macOS 10.7、tvOS 9 和 watchOS 6.2 开始提供。
去年的文章,我们提到以下功能必须依赖 Original StoreKit API:
为批量购买计划(VPP,Volume Purchase Program)提供支持。有关更多信息,请参阅 设备管理。
提供应用预订(app pre-orders)。有关更多信息,请参阅 应用预订。
您的 App 从收费更改为免费 App,反之亦然。
推广应用内购买。有关更多信息,请参阅 推广应用程序内购买。
对现有和历史遗留的旧 App 使用 v1 API。
因此,今年的 StoreKit 2,苹果提供新的字段 preorderDate 和 originalPurchaseDate 来获取 App 预订时间和购买时间,但是只支持 iOS 16+。
所以,目前 iOS 16 和 StoreKit 2 不能解决的问题:
为批量购买计划(VPP,Volume Purchase Program)提供支持。有关更多信息,请参阅 设备管理。
推广应用内购买。有关更多信息,请参阅 推广应用程序内购买。
对现有和历史遗留的旧 App 使用 Original StoreKit API。
2022 年,如何选择 Original StoreKit 还是 StoreKit 2
对于支持低于 iOS 15 以下 app 依然需要使用 Original StoreKit,直到只支持 iOS 15+,并且支持迁移到 StoreKit 2。对于目前开发者来说,使用 StoreKit 2 的成本主要是兼容的系统版本,还有一方面是服务端的兼容,最后是 app 如果有 IAP 服务,那一定是核心业务,不容许一点点的错误!这导致了大多数 app 还处于围观 StoreKit 2 的状态。对于只支持 iOS 15+ 或者独立开发者,建议可以尝试使用 StoreKit 2,如果有异常时,降级到 Original StoreKit 就可以。总之,最后等时间给我们答案吧。
App Transaction(App 交易)
StoreKit 2 增加了 App Transaction 结构体,用于代替 Original StoreKit 的 receipt 内容,具体直接查看接口文档:
App Transaction
从以上接口可以获取 App 预订时间 preorderDate 和购买时间 originalPurchaseDate 等。另外,验证用户当前使用的 app 是否正品购买以防止欺诈的作用。
购买您的 app 的签名信息
使用 JWS 签名
替换 Original StoreKit 的 receipt(票据)
StoreKit 提供验证方法
开发者可以执行自己的验证(或处理)
验证 App Transaction 的方法:
最后说明一下,App Transaction 的内容,首次启动时,StoreKit 会自动获取更新并保持最新状态。当您的 app 无法通过 shared
属性获得 App Transaction 时(包括返回 Verification.unverified(::) 或抛出异常错误),可以使用 refresh() 刷新 App 交易内容,但是刷新时,系统会弹窗提示用户可能需要重新授权认证 Apple ID 账号,所以建议是提供用户操作的按钮,由用户主动发起调用。
New properties(新特性)
StoreKit 2 带来了新的四个字段:
价格地区
交易的服务器环境
最近的订阅开始日期
哨兵值(占位符值)
Price locale
新增 priceFormatStyle 和 subscriptionPeriodFormatStyle 字段。一般情况下,苹果建议尽可能使用 displayPrice 字段表示格式。例如从 price 属性获取两个品项的价格,例如 2 products for $(
price * 2)
。
Server environment
在 iOS 16+ 使用 environment 结构体,在 iOS 15 使用 environmentStringRepresentation 字段。
获取到的字段值:
Recent subscription start date
recentSubscriptionStartDate 表示自动续期订阅购买中订阅的最早开始日期,忽略了超过 60 天的所有续费失败的订阅。
需要注意的是,不要使用 recentSubscriptionStart 字段日期来计算付费服务天数,以前,自动续期订阅的净收入结构和 App Store 上的其他商业模式不同,用户订阅累积满一年后,开发者的 收入将增加到订阅价格的 85%。所以,开发者不能依据这个字段来判断用户订阅是否满一年。另外,如果开发者当前注册了 App Store Small Business Program,符合条件的情况下,无论订阅是否已累积满一年,其实在每个结算周期收到订阅价格的 85%。
Sentinel values
另外,在不支持的系统和环境中,就会使用 Sentinel values
哨兵值(占位符值),例如 Price local 下使用 Locale(identifier: "xx\_XX")
,而 Recent subscription start date 使用 Date.distantPast
等。这是为什么呢?
因为以上的字段,其它在 Xcode13 和 iOS 15 是不存在的!苹果利用 Xcode 14 提供了对 iOS 15, iPadOS 15, macOS 12, Mac Catalyst 15, watchOS 9, tvOS 15 等的支持。原理是通过 Xcode 14 编译 app 时,会带上这些字段在 app 包体中,低系统的用户更新包含这些字段的版本时,就能使用。(具体是怎么编译和实现,有懂的朋友欢迎留言交流,小编暂时还没有找到相关文档。)
另外,JWS Transaction 的 Payload 内也新增 environment、recentSubscriptionStartDate 相关字段,下文会提到。
SwiftUI API
针对 SwiftUI 增加了优惠代码兑换接口和应用内评分接口。
StoreKit messages
StoreKit Message API 只支持 iOS 16+,用于开发者在 app 中接收和显示 App Store 消息处理。举例来说,自动续期订阅的费用涨价时,如果需要用户确认同意涨价,就需要弹窗给用于确认:
具体的 StoreKit messages 交互流程图:
获取 App Store messages 消息,使用 SwiftUI 实现的代码示例:
然后显示 App Store messages 消息,需要通过 SwiftUI 环境变量 displayStoreKitMessage
来解析和显示,使用 SwiftUI 实现的代码示例:
applicationUsername 和 appAccountToken
applicationUsername 是 Original StoreKit 创建苹果订单时,由开发者赋值的一个字段,原本这个字段是传入用户 UID 的 Hash 值,作用是给苹果验证应用购买以防止欺诈,比如代充和黑产恶意充值等。
而 appAccountToken 是去年 WWDC21 推出 StoreKit 2 的一个字段,用于开发者将苹果交易与自己服务上的用户关联的 UUID 格式的字段。
而现在,苹果打通了 applicationUsername 和 appAccountToken,当用 Original StoreKit 创建订单时,applicationUsername 字段赋值使用 UUID 格式内容时,则可以在服务端通知或者解析 receipt 票据时,可以获取这个 UUID 值,也就是订单可以关联确认。
我们回顾一下,我们为什么需要使用 applicationUsername
?我们是希望每个交易 transaction 可以关联用户订单号,对于订阅类型和非消耗类型品项,关联用户 UID 就能满足需求,但是对于非消耗型品项,其实,需要关联用户 UID 还有订单号 OrderID,因为非消耗型品项可以重复购买并且没有 UID 的强关联。举例来说,游戏里的用户账号可能不止一个,或者一个账号下的游戏角色,通常不止有一个角色,所以购买非消耗型品项时,开发者希望关联的是当前用户 UID 和此角色 RoleID 生成的开发者订单号 OrderID,但此时,UUID 格式并不能满足开发者自定义的需求!
所以,applicationUsername 和 appAccountToken 的透传值,对开发者有一定的关联作用,但其实还不完美。
External Purchase(外部购买,第三方支付)
符合条件的 app 可以包含一个链接,引导使用该 app 的用户访问网站进行外部购买。要包含该链接,请完成此授权的请求。有关符合条件的 app 和请求此授权的更多信息,请参阅:
具体的细节这里不说,就重点说说代码。首先,需要更新 app 的 Info.plist 文件,添加权限:
com.apple.developer.storekit.external-purchase :表示您的 app 是否可以提供外部购买。
com.apple.developer.storekit.external-purchase-link :表示您的 app 是否可以包含一个链接,引导用户访问网站进行外部购买。
SKExternalPurchase :表示您的 app 可以提供外部购买的国家或地区。
SKExternalPurchaseLink :表示您的 app 可以提供外部购买的国家或地区和对应的用户访问网站进行外部购买的链接。
配置示例:
然后就是接口调用,在 iOS 或 iPadOS 15.4 或更高版本,使用 StoreKit External Purchase API:
如图所示,按照苹果的规范,使用外部购买必须要的步骤:
检查当前设备允许付款
对于运行 iOS 和 iPadOS 15.4 或更高版本的设备,使用 StoreKit ExternalPurchase API
对于低于 iOS 和 iPadOS 15.4 系统,使用上图的 UI 设计和文本内容提示用户
在 iOS 和 iPadOS 15.4 运行的代码示例:
注意事项:
获取苹果许可权限后,您才可以在 app 中包含第三方支付系统
只有用户点击
I Understand
(我明白)后,才能跳转到第三方支付系统不包含任何隐藏、休眠或苹果未允许的支付功能或行为
只能在苹果允许的国家或地区的 App Store 商店使用第三方支付系统
External Link Account(访问外部网站的链接)
阅读器 App 是指将提供以下一种或多种数字内容类型作为其主要功能的 App:杂志、报纸、图书、音频、音乐或视频。
通过阅读器 App,用户可以登录他们在 App 之外创建的帐户,从而可以在用户的 Apple 设备上阅览和畅读先前购买的媒体内容或内容订阅。开发者可以提供指向 app 网站的链接,以便用户在 app 网站上创建和管理帐户。有关符合条件的 app 和请求此授权的更多信息,请参阅:
同理,首先,需要更新 app 的 Info.plist 文件,添加权限:
com.apple.developer.storekit.external-link.account :表示您的 app 是否可以链接到外部网站进行帐户创建或管理。
SKExternalLinkAccount :表示您的 app 可以提供外部创建或管理帐户的国家或地区,和对应的用户访问创建或管理帐户网站的链接。
然后就是接口调用,在 iOS 或 iPadOS 16 或更高版本,使用 StoreKit External Link Account API:
如图所示,按照苹果的规范,使用外部购买必须要的步骤:
检查当前设备允许付款
对于运行 iOS 和 iPadOS 16 或更高版本的设备,使用 StoreKit ExternalPurchase API
对于低于 iOS 和 iPadOS 16 系统,使用上图的 UI 设计和文本内容提示用户,并且必须是使用默认浏览器中打开一个新窗口,而不能使用 App 的 WebView 打开
在 iOS 和 iPadOS 15.4 运行的代码示例:
注意事项:
获取苹果许可权限后,您才可以在 app 中包含链接到外部网站进行帐户创建或管理
只有用户点击
Continue
(继续)后,才能跳转到外部网站进行帐户创建或管理跳转到外部网站,不能有没有任何重定向、中间链接或着陆页面
不得在 URL 中传递附加参数,以便保护用户 (例如用户的隐私)
App Store Server API
App Store Server API
是苹果去年 WWDC21 推出的 ,详细可以参考我们之前的文章《WWDC21 - App Store Server API 实践总结》。
今年 WWDC22 苹果新增了三个新接口,并且对部分接口增加了过滤功能,这里我们列了一个表格:
Filter and Sort(过滤和排序)
其中只有 Get Transaction History 接口提供了过滤和排序的功能:
目前支持的查询参数列表:
查询示例:
productId
、productType
和 subscriptionGroupIdentifier
查询参数可以同时指定多个值。例如,要按 NON_CONSUMABLE(非消耗型) 和 AUTO_RENEWABLE(自动续期产品类型)字符来筛选交易历史记录,请求中包含以下内容:
其实更优雅的方式可能是 App Store Connect API 的形式:&filter[appStoreVersions.appStoreState]=READY_FOR_SALE,PREORDER_READY_FOR_SALE,READY_FOR_REVIEW
。
最后,交易历史记录接口返回结果只支持以下情况:
自动续期订阅
非续订订阅
非消耗型应用内购买项目
消耗型应用内购买项目:如果交易被退款、撤销或 app 尚未完成交易处理等。
特别注意:消耗型应用内购买项目如果调用了 finishTransaction(_:),则不会在出现在舞台的交易历史列表中,所以,消耗型应用内购买项目不能使用这个接口作为校验接口!!!
New Notification API(新的通知接口)
测试 App Store 服务器通知
Request a Test Notification 让 App Store 服务器通知向开发者服务器发送测试通知。
接口响应的 testNotificationToken
字段是 App Store 服务器通知发送到开发者服务器的通知测试的测试通知令牌,每次请求获取的唯一标识 Token,这个 Token 用于下面的接口参数。
获取 App Store 服务器通知的测试结果
Get Test Notification Status,获取发送到开发者服务器的 App Store 服务器测试通知的检查状态。
根据 Request a Test Notification 接口获取到的 testNotificationToken
请求测试结果:
返回的响应有两个参数:
firstSendAttemptResult
:表示 App Store 服务器尝试向开发者服务器发送 TEST 通知的结果,如果不是SUCCESS
,则如上图会返回原因,如果TIMED_OUT
表示超时,SSL_ISSUE
表示开发者服务器的 SSL 证书有问题。根据这个字段就能测试和检查 App Store 服务器和开发者服务器之前的连通性。signedPayload
:JWS 格式的签名有效负载,包含 App Store 服务器发送到您的服务器的 TEST 通知。
具体的 signedPayload
解码后的格式内容如下示例:
获取 App Store 服务器通知的历史通知
Get Notification History,获取 App Store 服务器尝试发送到开发者服务器的通知列表。
此接口的目的是,因为 App Store 服务器通知是苹果推送的通知,开发者是被动接收,总会因为各种情况(服务器宕机,运营商链路或云服务提供商故障等)导致无法按时接收到 App Store 服务器通知。所以,可以通过这个接口查询 App Store 服务器通知的历史记录:
只支持 App Store 服务器通知 V2 版本的响应(即 JWS 格式)
最多可以查询 6 个月以内的历史列表(180 天内)
可以过滤通知类型、通知子类型或用户
开发者服务器宕机后可使用接口主动获取通知记录,直到开发者服务器可接收 App Store 服务器通知为止
查询接口的示例:
接口每次最多返回 20 条通知历史记录,所以响应会返回一个 paginationToken
字段,用来查询更多分页的通知结果。paginationToken 获取下一组最多 20 条通知历史记录,所有有更多历史记录的响应都包含 paginationToken 字段。
New properties(新特性)
除了 StoreKit 2 增加了 environment
、recentSubscriptionStartDate
字段,App Store Server API 的 JWS 格式的签名交易也包含。
JWS transaction info Decoded Payload:
JWS renewal info Decoded Payload:
详细说明可以查看官方文档:environment 和 recentSubscriptionStartDate,这里不在复述。
App Store Server Notifications V2
同理 App Store Server Notifications 也有新增相应的 environment 和 recentSubscriptionStartDate 字段。
从这个图片可以看出,App Store Server API 是 App Store 服务器和开发者服务器之前,相互可以响应的流程。而 App Store Server Notifications V1 和 V2 通知,是 App Store 服务器主动通知开发者服务器,开发者服务器不能主动请求,所以导致了一些场景的缺陷。
App Store 服务器通知宕机
服务器宕机是很常见的问题,但是宕机后,开发者就无法接收 App Store 服务器的通知。
所以,App Store Server Notifications V2 通知在首次尝试通知后没有收到来自开发者服务器的响应时会进行重试:
App Store Server Notifications V1:重试三次;在上次尝试后 6、24 和 48 小时。
App Store Server Notifications V2:重试五次;在上次尝试后 1、12、24、48 和 72 小时。
重试成功后,开发者服务器接收到的通知,可以并不再是顺序显示:
所以,开发者需要通过 signedDate
字段,确保通知的顺序逻辑正确,也就是说通知的结果状态以最新的 signedDate 时间来准,来更新用户能享受的服务。而重试的通知可能会出现重复的通知响应,所以开发者可以通过 notificationUUID
字段去重通知。
留住订阅者
用户需要不断从订阅中获得价值,才会持续地订阅您的 App。定期更新您的 App,提供新内容和增强功能,以鼓励订阅者继续订阅。
App Store Server Notifications V2 提供了更多的通知类型,达到 28 个,未来还会增加更多。
这里一个用户订阅过程的可能会发生的通知:
从这个图中,开发者可以思考到什么?
Subscription loyalty(订阅忠诚度)
从苹果的 自动续期订阅 文档可以获取这样的思考:
通过使用 获取所有订阅状态 接口和 获取交易历史记录 接口,可确定用户的订阅状态并查看交易历史记录,帮助您识别并执行以下操作:
自愿流失。使用 获取所有订阅状态 接口确定订阅者是不是已关闭特定订阅的自动续订。您还可以使用 App Store 服务器通知来获取有关用户状态变化的实时更新以及与其 App 内购买项目相关的关键事件,例如退款通知。使用这一信息来采取相应的行动,例如,您可以提供促销优惠以鼓励他们继续订阅,建议更符合他们需求的备用等级,或者在订阅到期后锁定相关订阅内容的访问权限。请务必向用户告知您所做的任何更改,以及他们是否需要完成任何操作,还有重新订阅的方式。
非自愿流失。当订阅者遇到账单问题 (如信用卡过期问题) 时,就会发生非自愿流失。选择接收服务器通知以了解何时由于账单问题而导致订阅续订失败,或使用 获取所有订阅状态 接口确定订阅是不是由于账单问题而处于计费重试状态。根据上述信息采取相应措施,例如,您可以在 App 中显示信息或发送电子邮件,提醒订阅者更新他们之前登记的付款方式,并提供其 App Store 帐户中“付款信息”区域的链接。一旦问题得到解决,您就可以恢复服务。Apple 将在 60 天内尝试收取付款。如果订阅在 60 天内续订,则付费服务的天数从续订日期开始继续累积。
为避免由于账单问题而导致服务中断,请在 App Store Connect 中启用账单宽限期。Apple 将尝试解决账单问题,并在订阅者保留订阅访问权限的同时恢复订阅。如果订阅在这个期限内恢复,则付费服务天数的计数和您的收入都不会中断。如果用户在 60 天后重新订阅,则付费服务的天数将重置,您将收到一年的标准订阅费用,直到付费服务满一年为止。
价格上调同意状态。当您提高订阅价格时,Apple 会询问受影响的订阅者是否同意这个新价格,您可以在价格变动生效之前跟踪用户的同意状态。在向受影响的用户显示价格上调单之前,您可以显示一条 App 内信息,说明订阅的好处和价值,以及价格上调将如何改善服务。如果用户没有对上调做出反应,他们的订阅将在当前结算周期结束时到期。
简单来说,通过订阅通知,分析用户的忠诚度,根据用户不同的行为习惯和选择决定(通知),然后分析用户行为的背后原因,从而优化开发者的服务,从而提升订阅的忠诚度!
App Store Connect
App Store 相关的调整不多,都是细节优化。
Sandbox & Test
开发人员将能够更轻松地创建沙盒用户,并测试沙盒购买。相比以前少了 安全提示问题
、安全提示问题答案
、出生日期
三个选项。
增加了 Allow Purchase & Renewals
开关,用于测试订阅到期自动扣费和失败重试。
Xcode StoreKit 测试中添加了更多测试用例,例如退款请求、优惠代码兑换、订阅涨价、账单扣款重试等。这是一个不错的改进,但目前测试内购功能的开发者还不多,详细参考 What's new in StoreKit testing - WWDC22。
App Store Connect API
App Store Connect API 增加了查询沙盒账号、清除沙盒内购历史记录、设置中断内购状态等,也增加内购、用户商店评论内容和回复、App 挂起诊断数据等接口。
最重要是,增加了内购项目的创建!
内购品项和订阅品项的相关 API:
新建订阅品项
创建、编辑和删除品项
管理定价
提交审核
创建优惠和促销代码
目前截止本文发表,苹果 App Store Connect API 文档,依然还没有看到这些接口的描述!
最后,是苹果弃用 XML 流文档的形式与 App Store Connect 的交互,未来开发者,都需要迁移到 App Store Connect API!
这个怎么理解?参考我们之前开源的一款苹果 macOS 工具:《AppleParty(苹果派)》,它使用到了苹果 Transporter 命令工具,批量上传内购商品列表和上传 IAP 包文件等。预测 Reporter 和 altool 等命令也会被弃用。
苹果表示,今年秋天开始停用 XML 提交,强制推荐使用 App Store Connect API 接口。但目前还没有看到官网相关的说明文档!
App Store
今年 App Store 相关更新,可能最引人关注的功能,就是这个 Benchmarks in App Analytics
(App 分析中的基准)功能,,基准通过将与获客率、使用和盈利情况相关的绩效指标置于具体情境中,在整个客户旅程期间提供有价值的见解,这样您就可以很容易地看到您与同行相比的表现,并做出相应决策以实现业务目标。
查看自己 app 与同行相比的表现,并做出实现业务目标的决策。使用差异隐私技术,以确保机密信息的安全和私密性。苹果表示这个功能明年 2023 年初才上线,目前官方文档也没有找到详细的介绍。差异隐私技术介绍可以参考我们之前的文章《WWDC22 - Apple 隐私技术探索》。
关于 app 数据,Xcode 提供了功率、性能指标和诊断等新接口。
分析和解决 App 挂起(hangs:延时、慢、卡顿)
查看诊断签名
下载详细日志
详细功能可以参考:Identify trends with the Power and Performance API - WWDC20 和 Track down hangs with Xcode and on-device detection - WWDC22。
在 App Store Connect app 中可以送审内购、新版本、In-App Event、产品面优化、自定义产品而等。
目前苹果支持送审的内容:
可以看到 iOS 除了新版本 app 送审,现在支持 In-App Event、自定义产品、产品面优化测试等。而 tvOS 和 macOS 目前还没有,可能明年 WWDC23 应该就支持一波了吧!
另外,需要提示一下,送审新版本 app 、In-App Event、自定义产品、产品面优化测试等,苹果是建议开发者可以合并提交一起送审,因为这样苹果会以当前送审的内容一起审核,提高苹果的审核效率?总之,提审这些项目后,如果有项目审核不通过,可以单独发布审核通过的内容。
关于 App Store 的优化,2022 年 1 月 20 日 推出适用于订阅的自定优惠代码,开发者可以自定义,如 VIP888
的优惠代码,用于推广活动,自定代码可通过直接 URL 或在您的 app 中兑换。2022 年 4 月 29 日 阐明 App Store 改善流程的标准和新的限期延长,苹果明确了 App 长期不更新被下架的细则,当一款 App 在过去三年内从未更新且未达到最低下载量 (即该 App 在连续 12 个月内完全没有或只有极低的下载量) 时,其开发者将会收到电子邮件,告知该 App 已被识别并可能从 App Store 中被移除,开发者收到通知起,有 90 天的时间来更新他们的 App。
总结
关于 In App Purchase 和 App Store,随着这几年苹果的开放,已经很大程度上解决了开发者大多数的问题,从退款查询到所有订单查询,从被动通知到主动获取通知,从内购税率降低到提高 App 曝光量,苹果已经提供了非常多的接口、案例展示和建议。比如,自动续期订阅类型,目前已经复杂到不能再复杂,订阅群组、免费试用期限、推介促销优惠、促销优惠、优惠代码、计费重试、重新激活、续期等。
最后,大家觉得 In App Purchase
和 App Store
还有什么疑惑或痛点吗?
欢迎大家评论区一起讨论交流~
欢迎关注我们,了解更多 iOS 和 Apple 的动态~
参考引用
Update on dating apps distributed on the App Store in the Netherlands - Apple Developer
Distributing dating apps in the Netherlands - Apple Developer
Additional details available for dating apps in the Netherlands - Apple Developer
Update on StoreKit External Entitlement for dating apps - Apple Developer
Distributing apps using a third-party payment provider in South Korea - Apple Developer
App Store Server Notifications | Apple Developer Documentation
版权声明: 本文为 InfoQ 作者【37手游iOS技术运营团队】的原创文章。
原文链接:【http://xie.infoq.cn/article/361b8f01dfb49954f8920b151】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论