我们正在开发一款适用于iPhone的iOS应用程序,该应用程序将免费提供功能,应用程序将具有4种应用内购买自动更新订阅选项的高级功能,如下所示
-
单月订阅
-
单年订阅
-
家庭月度订阅
-
家庭年度订阅
我们将在应用程序内部有一个商店屏幕,可以选择订阅我们的应用程序提供的各种订阅 .
我们发现用户可以转到设备设置并管理他们的应用内购买订阅 .
我们还计划提供用户可以从一个订阅升级到另一个订阅的选项,用户也应该能够降低他们的订阅等级,这将是相反的所有选项并返回到免费版本可能的升级选项:
-
免费提供任意4种订阅选项
-
单月每月一次
-
每月每月一次到家庭
-
每月一次到家庭
-
家庭每月每月到家庭
可能的降级选项:
-
每年家庭每月到家庭
-
家庭每年一次到每月一次
-
家庭每月到单月
-
每年单月至单月
-
从任何4个订阅选项到免费版本
注意:
- 据Apple称,我们无法使用Apple家庭共享选项分享In App购买,因此我们正在开发应用程序中的家庭共享选项 . (参考:https://support.apple.com/en-in/HT203046)
Queries:
-
我们对如何在iOS应用程序中管理订阅有疑问?
-
设备设置选项如何显示我们用于升级和降级的4个In App Purchase选项,将一个选项显示给其他选项?
-
作为iOS开发人员恢复自动续订订阅,我们需要考虑什么?如果用户试图在我们的应用程序中使用具有多个用户帐户的iTunes帐户进行恢复,我们不清楚可能的情况,当用户购买订阅一次并尝试恢复多个用户帐户时,苹果允许哪些预防措施?
-
Apple将使用自动续订订阅选项拒绝自定义家庭共享选项?
-
如果我们可以使用上述功能,我们需要注意哪些点苹果将无法处理?
-
What are the possibilities of violating the apple guidelines and app rejection if we are going with above features with iOS application?
如果任何人可以分享他们的观点或提供一些关于我们应该走哪条路的指导,或者如果我们偏离苹果政策那将对我们有很大的帮助......所有这些反馈都会帮助我们获得事情在这里移动 .
谢谢
1 回答
由于您使用的是自己的用户管理系统,因此应该在数据库中保留与用户关联的订阅状态 . 当用户在应用中创建购买时,应用应将此收据发送到您的API,然后将继续validate it .
保留后,将计划的进程排入Subscription Expiration Date以无限更新记录和广告,直到过期日期不再存在 .
当用户打开应用程序以确定其订阅状态时,您的应用应查询您的API . 不要依赖应用程序本地收据,因为您的用户的家庭成员设备不会关联此购买 .
如果iTunes Connect中列出的所有产品都是相同的“订阅系列”,则它们将显示在用户iTunes帐户的“订阅管理”页面中 .
当用户在产品之间切换时,将创建一个事务,并将
SKPaymentTransactionStatePurchased
事件添加到SKPaymentQueue
. 这将是与使用来自同一订阅系列的产品进行首次购买相同的Original Transaction Identifier的新交易,其中Product Identifier反映了新产品 .因此,您希望在后台运行的应用中使用您的事务观察器来接收任何新事务 . 收到新交易后,您可以a)将整个收据发送给您的API,或者b)通知您的API已收到新的交易,并重新验证持久的收据 .
与(a)一起使用可能会成为问题,因为随着时间的推移收据将变得更大,需要来自用户的更多带宽时间 .
与(b)一起使用也有它的缺点,因为你可能会遇到像用户切换iTunes帐户这样的边缘情况 . 对此的解决方案是将应用程序identifierForVendor与收据一起存储,并要求应用程序在不匹配时发送整个收据 . 大多数情况下,您只是通知API已发生交易,并且在少数情况下标识符不匹配,它将发送新的收据 .
恢复时,将创建具有新事务ID的新事务,但原始事务ID将是相同的 . 如果在数据库中创建事务表,则可以确保事务,并且它的原始事务仅与单个用户关联,从而阻止用户在具有不同用户的其他设备上恢复购买并获得对订阅的访问权限 .
恢复的事务将被推送到队列
SKPaymentTransactionStateRestored
,所以当发生这种情况时,我建议将收据发送到您的API并正常处理收据;将任何新交易与原始用户相关联 .我对此表示怀疑,但我不是苹果公司所以不要接受我的福音 . Spotify有一个名为“Spotify Family”的类似方案,用户可以与他们的家人分享他们的Spotify帐户,但不确定是否为他们的iTunes应用程序启用了这个帐户 .
您需要自己的API以及用户管理和家庭关联
您的用户需要在您的应用上登录/注册
如果他们的父帐户已经购买,您将需要阻止家庭用户购买 .
在数据库中保留收据和identifierForVendor .
使用validation API处理收据验证 .
保留一个事务表并将此表视为自引用,以便事务可以通过
original_transaction_id
属于原始事务 . 确保transaction_id
列是唯一的 .每次交易到期时都要验证收据 .
我在guidelines中看不到任何内容,除了 17.2 部分:
我认为这个有点矛盾,因为它在 17.5 中指出:
我想通过这个,这意味着用户必须能够使用该应用程序而无需注册,但我知道很多应用程序的例子正是如此 .