【问题标题】:How to support multiple devices with non-renewing In-App Purchase?如何通过非续订应用内购买支持多台设备?
【发布时间】:2012-03-18 13:43:08
【问题描述】:

我正在构建一个 iOS 应用,其中将包含一个具有非续订订阅的 IAP。 Apple 在他们的overview of IAP 中提供了这个金块:

您需要为用户拥有的所有设备提供非续订订阅。 Store Kit 不会自动将非续订订阅同步到所有设备;你必须自己实现这个基础设施。例如,大多数订阅是由外部服务器提供的;您的服务器需要实现一种机制来识别用户并将订阅购买与购买它们的用户相关联。

我希望遵循以下规则:我希望我的用户能够在其他设备上利用他们在一台设备上购买的订阅。那么如何在他们的 iPhone 和 iPad 上识别同一用户呢?我了解您不能使用 Apple ID,也不能依赖注册方法。

我刚刚找到this question;那里给出的答案似乎不可行。肯定有比别人做得更优雅的东西。

【问题讨论】:

  • 那么是不是说当你在原本不用于购买订阅的设备上调用[[SKPaymentQueue defaultQueue] restoreCompletedTransactions] 时,交易收不回来?
  • 对于非续订订阅者,这是正确的。您必须自己管理它们。

标签: ios in-app-purchase app-store-connect storekit


【解决方案1】:

Gavin McKenzie 给了我一个建议,这听起来是我听过的最好的选择:

购买订阅后,为用户提供一个“短代码”。该代码也将存储在服务器上,与该用户的帐户相关联。当他们在另一台设备上点击恢复时,向原始设备和帐户请求短代码,从而将这些设备捆绑在一起。

Gavin 进一步建议在类似于蓝牙的“配对”方法中使用它:恢复时,在设备 A 上启动配对,设备 A 会生成短代码并将其推送到服务器。然后设备 B 可以使用该代码。五分钟后,或者配对屏幕消失时,代码被删除。

我不确定如果您想恢复到同一设备(例如,在删除手机并恢复后),这会怎样。但这感觉像是一个好的开始。

【讨论】:

  • 这里的聚会迟到了,但我怀疑这可能行不通——即使此人丢失了代码,您仍然有责任恢复订阅。
  • 我只是碰巧回来看看这个。是的,我可以肯定它完美无缺!我的应用程序已经在商店上架了一个月,通过两次更新,它已获得批准。与我上面写的一个区别:除了令牌之外,我还包括了一个用户名。不确定这是否重要,但总比抱歉更安全......
  • 这个方法的一个修改可能是制作一个唯一的代码(也许不是那么短),它对用户不可用,但在应用程序和服务器之间共享。告诉用户,如果他们想稍后进行恢复,他们需要创建一个帐户(用户名/密码)。然后,在您的服务器上,您可以将用户名/密码与唯一代码相关联。
【解决方案2】:

如果您可以放弃对低于 5.0 版本的 iOS 的支持,则可以使用 iCloud 在用户的设备之间同步键值对。

【讨论】:

  • 这是一个新的应用程序,所以我很满意。但苹果会接受 iCloud 作为一种机制吗?如果他们没有启用它怎么办?
  • 我认为 Apple 没有任何理由不接受这一点。但是,如果用户关闭了 iCloud,那么是的,你不走运。
  • 我试过了!苹果不喜欢它。我什至向审查委员会提出上诉(几周后),他们打电话说我需要实施一个可选用户名/密码系统。我所做的是将生成的唯一标识符存储在用户的 iCloud 帐户中(以及我的服务器上)。当新设备启动时,我会检查那个 ID,如果它与以前的用户匹配,我会扩展这个设备相同的权限。 Apple 并没有说我不允许存储键值对,只是说我不能这样做来代替 可选 用户名密码系统。
  • 哇,他们太傻了。感谢您告知我们。
  • WWDC2012 会议“使用应用内购买管理订阅”深入讨论了这个主题,并且实际上规定使用 iCloud 作为跨设备同步非续订订阅收据的最佳机制(大约 30:00进入视频)。演示者说您可以选择实现涉及您自己的服务器的注册机制,但建议这比必要的工作更多,并且基于 iCloud 的同步完全足够了。
【解决方案3】:

看这个:

http://iphonedevsdk.com/forum/business-legal-app-store/88698-floored-by-new-rejection.html

显然,您可以在购买前要求提供用户名/密码。这确实是唯一有意义的方法。一个代码可以被数千人共享,这很糟糕。

【讨论】:

  • 正如许多人在该线程中争论的那样,在购买之前要求注册是一种有问题的用户体验。我更喜欢我的方法——顺便说一句,这种方法效果很好——为每个用户分配一个令牌。
【解决方案4】:

查看Frac.as。它做了上面建议的“短代码”配对的变体,但有一些内置的智能来防止滥用。它是一个 SaaS API,提供大量免费层。

【讨论】:

    猜你喜欢
    • 2013-04-06
    • 1970-01-01
    • 2013-03-31
    • 1970-01-01
    • 1970-01-01
    • 2014-07-19
    • 1970-01-01
    • 1970-01-01
    • 2017-10-29
    相关资源
    最近更新 更多