- 我们有一些疑问如何在 iOS 应用程序中管理订阅?
由于您使用自己的用户管理系统,因此您应该在数据库中保留与用户关联的订阅状态。当用户在应用程序中创建购买时,应用程序应将此收据发送到您的 API,然后该 API 将继续验证它.
一旦持久化,将计划的进程排入队列以在订阅到期日期无限更新记录,直到过期日期不再是未来。
当用户打开应用程序以确定其订阅状态时,您的应用程序应查询您的 API。不要依赖应用程序中本地的收据,因为您用户的家庭成员设备不会关联此购买。
- 设备设置选项将如何显示我们的 4 个应用内购买选项,用于从一个选项升级到另一个选项?
如果 iTunes Connect 中列出的所有产品都属于同一“订阅系列”,则它们将显示在用户 iTunes 帐户的订阅管理页面中。
当用户在产品之间切换时,将创建一个交易并SKPaymentTransactionStatePurchased
事件将被添加到SKPaymentQueue
。这将是一笔具有相同内容的新交易原始交易标识符作为首次购买同一订阅系列的产品产品标识符反映新产品。
因此,您希望应用程序中的事务观察器在后台运行以接收任何新事务。收到新交易时,您可以 a) 将整个收据发送到您的 API,或者 b) 通知您的 API 已收到新交易并重新验证保留的收据。
采用 (a) 可能会出现问题,因为随着时间的推移,收据会变得越来越大,每次都需要用户提供更多带宽。
使用 (b) 也有其缺点,因为您可能会遇到边缘情况(例如用户切换 iTunes 帐户)的麻烦。解决方案是存储应用程序供应商标识符与收据,并要求应用程序发送整个收据(如果不匹配)。大多数情况下,您只会通知 API 交易已发生,并且在标识符不匹配的少数情况下,它会发送新的收据。
- 作为 iOS 开发者,恢复自动续订订阅需要注意哪些事项?我们不清楚如果用户尝试在我们的应用程序中使用具有多个用户帐户的 iTunes 帐户进行恢复,可能会出现什么情况,当用户购买一次订阅并尝试在多个用户帐户上恢复时,苹果允许采取哪些预防措施?
恢复时,将创建一个具有新事务ID的新事务,但原始事务ID将相同。如果您在数据库中创建交易表,则可以确保交易及其原始交易仅与单个用户关联,从而防止用户使用不同用户在其他设备上恢复购买并获得对订阅的访问权限。
恢复的事务将被推送到队列中SKPaymentTransactionStateRestored
因此,当发生这种情况时,我建议将收据发送到您的 API 并正常处理收据;将任何新交易与原始用户相关联。
- 苹果将拒绝使用自动续订订阅选项的自定义家庭共享选项?
我对此表示怀疑,但我不是苹果公司,所以不要相信我的话。 Spotify 有一个类似的计划,称为“Spotify 家族“用户可以与家人共享他们的 Spotify 帐户,但不确定他们的 iTunes 应用程序是否启用了此功能。
- 如果我们能够使用以上功能,那么最终我们需要注意哪些点是苹果无法处理的呢?
- 您需要自己的 API 来进行用户管理和家庭关联
- 您的用户需要在您的应用程序上登录/注册
- 如果家庭用户的家长帐户已经购买过商品,您将需要阻止其购买。
- 将收据和供应商标识符保留在数据库中。
- 使用处理收据验证验证API.
- 持久保存一个事务表,并认为该表是自引用的,以便事务可以通过以下方式属于原始事务:
original_transaction_id
。确保transaction_id
专栏是独一无二的。
- 每次交易到期更新时验证收据。
- 如果我们在 iOS 应用程序中使用上述功能,违反苹果指南和应用程序拒绝的可能性有哪些?
我在其中什么也没看到指导方针除了部分17.2:
要求用户共享个人信息(例如电子邮件地址和出生日期)才能运行的应用程序将被拒绝
我认为这有点矛盾,因为17.5它指出:
包含帐户注册或访问用户现有帐户的应用程序必须包含隐私政策,否则将被拒绝
我想这意味着用户必须能够在不需要注册的情况下使用该应用程序,但我知道很多应用程序的例子正是这样做的。