Ray*_*ope 9 subscriptions in-app-purchase ios swift auto-renewable
我们正在开发一款适用于iPhone的iOS应用程序,该应用程序将免费提供功能,应用程序将具有4种应用内购买自动更新订阅选项的高级功能,如下所示
我们将在应用程序内部有一个商店屏幕,可以选择订阅我们的应用程序提供的各种订阅.
我们发现用户可以转到设备设置并管理他们的应用内购买订阅.
我们还计划提供用户可以从一个订阅升级到另一个订阅的选项,用户也应该能够降低他们的订阅等级,这将是相反的所有选项并返回到免费版本可能的升级选项:
可能的降级选项:
注意:
查询:
如果任何人可以分享他们的观点或提供一些关于我们应该走哪条路的指导,或者如果我们偏离苹果政策那将对我们有很大的帮助......所有这些反馈都会帮助我们获得事情在这里移动.
谢谢
Mar*_*ock 15
- 我们对如何在iOS应用程序中管理订阅有疑问?
由于您使用的是自己的用户管理系统,因此应该在数据库中保留与用户关联的订阅状态.当用户在应用程序中创建购买时,应用程序应将此收据发送到您的API,然后API将继续验证它.
保留后,将预定流程入队以在订阅到期日期运行,以无限更新记录和无限期,直到将来不再有到期日为止.
当用户打开应用程序以确定其订阅状态时,您的应用应查询您的API.不要依赖应用程序本地收据,因为您的用户的家庭成员设备不会关联此购买.
- 设备设置选项如何显示我们用于升级和降级的4个In App Purchase选项,将一个选项显示给其他选项?
如果iTunes Connect中列出的所有产品都是相同的"订阅系列",则它们将显示在用户iTunes帐户的"订阅管理"页面中.
当用户在产品之间切换时,将创建一个事务并将一个SKPaymentTransactionStatePurchased事件添加到SKPaymentQueue.这将是与使用来自同一订阅系列的产品进行的首次购买相同的原始交易标识符的新交易,其中产品标识符反映新产品.
因此,您希望在后台运行的应用中使用您的事务观察器来接收任何新事务.收到新交易后,您可以a)将整个收据发送给您的API,或者b)通知您的API已收到新的交易,并重新验证持久的收据.
与(a)一起使用可能会成为问题,因为随着时间的推移收据将变得更大,每次都需要来自用户的更多带宽.
与(b)一起使用也有它的缺点,因为你可能会遇到像用户切换iTunes帐户这样的边缘情况.解决方案是将应用程序identifierForVendor与收据一起存储,并要求应用程序在不匹配时发送整个收据.大多数情况下,您只是通知API已发生交易,并且在少数情况下标识符不匹配,它将发送新的收据.
- 作为iOS开发人员恢复自动续订订阅,我们需要注意什么?如果用户试图在我们的应用程序中使用具有多个用户帐户的iTunes帐户进行恢复,我们不清楚可能的情况,当用户购买订阅一次并尝试恢复多个用户帐户时,苹果允许哪些预防措施?
恢复时,将创建具有新事务ID的新事务,但原始事务ID将是相同的.如果在数据库中创建事务表,则可以确保事务,并且它的原始事务仅与单个用户关联,从而阻止用户在具有不同用户的其他设备上恢复购买并获得对订阅的访问权限.
恢复的事务将被推送到队列中SKPaymentTransactionStateRestored,因此当发生这种情况时,我建议将收据发送到您的API并正常处理收据; 将任何新交易与原始用户相关联.
- Apple将使用自动续订订阅选项拒绝自定义家庭共享选项?
我对此表示怀疑,但我不是苹果公司所以不要接受我的福音.Spotify有一个名为" Spotify Family " 的类似方案,用户可以与他们的家人分享他们的Spotify帐户,但不确定是否为他们的iTunes应用程序启用了这个帐户.
- 如果我们可以使用上述功能,那么我们需要注意哪些要点苹果将无法处理?
original_transaction_id.确保该transaction_id列是唯一的.
- 如果我们使用iOS应用程序的上述功能,有什么可能违反苹果指南和应用程序拒绝?
除了第17.2节,我在准则中没有看到任何内容:
要求用户共享个人信息(如电子邮件地址和出生日期)才能运行的应用将被拒绝
我认为这个有点矛盾,因为在17.5中它说:
包含帐户注册或访问用户现有帐户的应用必须包含隐私政策,否则将被拒绝
我想通过这个,这意味着用户必须能够使用该应用程序而无需注册,但我知道很多应用程序的例子正是如此.
| 归档时间: |
|
| 查看次数: |
2839 次 |
| 最近记录: |