iOS订阅很难
使用正常的IAP流程进行购买
除了不同的用户界面副本外，购买订阅产品与购买非订阅应用内产品相同。 不同之处在于，订阅产品将续订，稍后会在StoreKit队列上生成未经请求的交易。 订阅应用内交易在收据数据中也有一个expiration_date字段。 您将使用此字段来确定用户有权获得哪些产品或服务。
设备上收据验证
为了保护自己免受IAP盗版并提取用户的交易历史记录，您需要验证您的App Store收据。 如果没有服务器，则可以在设备上执行此操作。 我不会在这里介绍整个过程，但是我过去已经写过。
Apple不提供用于验证收据文件的内置方法。 他们认为，这些内置方法将仅成为IAP破解程序的目标。 相反，他们建议每个人都自己滚动，以确保标准的IAP破解程序不会破坏您的应用程序。 但是，用于验证设备上的收据文件的代码并不简单。
解析到期日期
解压缩收据文件后，您只对最新的expiration_date感兴趣。 通过遍历收据中的所有应用内购买记录并找到最新的expiration_date字段，然后将其缓存（通常在NSUserDefaults或类似方式中），可以提取此内容。
处理续订交易
处理续订是常见的错误区域。 在标准IAP流程中，您只需要担心用户完成购买时StoreKit付款队列的状态。 有了订阅，您的应用程序需要随时准备处理这些交易。 现在，您需要从应用程序中的任何位置处理购买； 需要在每个屏幕上考虑用户订阅状态更改的影响。
处理该问题的适当方法是：一旦它出现在StoreKit队列中，请验证收据并更新用户的权利。 但是，这可能很困难。 例如，如果您的应用程序有一个帐户系统，那么您如何处理没有用户登录时发生的交易？ 或者考虑发生在某个流的中间的事务，该事务取决于用户的订阅状态。 设计应用程序时，您必须计划所有这些可能性。
设备端订阅中的差距
设备端收据处理使一些重要的事情变得困难或不可能。
首先，您的订阅状态被困在设备上。 如果您想将服务扩展到当前应用程序之外，则需要针对用户的当前订阅状态设计一些精心设计的转义计划。
将订阅处理限制在设备上也会使您难以理解您的业务绩效。 iTunes Connect已经变得更好，但是如果您想逐个用户了解任何内容，则仍然缺少iTunes Connect。 苹果公司的所有仪表板都完全匿名。 如果只需要鸟瞰，汇总指标就可以了，但是使用Apple的仪表板，即使是简单的数据问题，您也将很快无法回答。
我认为避免仅设备订阅的实现的最大原因只是受StoreKit队列的支配。 如果由于某种原因您的代码或StoreKit出现故障，您可能会错过一笔交易。 这可能会剥夺付费客户或其服务。 如果仅使用设备端订阅，则可能很难调试或补救这种情况。
使用服务器确实很有意义。
服务器订阅
使用服务器意味着：您无需在设备上解析收据，而是将该收据发送到服务器以进行验证和解析。 在设备上，实现与设备端订阅的实现类似，但有一些关键更改：
- 正常的IAP流量
- 收据被发送到服务器进行验证，解析，存储并返回数据
- 服务器响应存储在设备上
- 续签交易的处理（半可选）
将收据发送到服务器
步骤2表示与设备端订阅最根本的不同。 您可以通过HTTP将收据发送到服务器，而不是在应用程序中实现收据解析和验证。 这样做有两个明显的优点：
- 您可以使用Apple的
/verifyReceipt端点 - 您可以将收据文件保留在服务器端，以用作用户订阅状态的刷新令牌。
能够使用Apple提供的终结点来验证收据将为您节省大量时间。 它还提供了设备端收据验证无法提供的功能：最近交易的列表。
当您解析收据设备端时，文件中的任何事务就是您得到的。 当您使用/verifyReceipt ，Apple会发送最新订阅交易列表。 收据文件充当获取令牌以从Apple轮询数据。 此轮询对于构建完整的订阅服务器至关重要。
轮询和状态通知
存储回执文件服务器端的优点之一是能够使用户的订阅状态保持最新。 为此，意味着轮询/verifyReceipt端点并使用Apple的新状态更新通知。 进行此设置可能会增加后端的复杂性。 现在，您需要一项工作来定期检查收据并能够处理Apple的POST。 另外，您多久轮询一次？
当用户具有有效订阅时，答案相对简单。 您可以在它们即将更新时开始检查，但是您会错过退货的机会。 一旦客户取消订阅，便会带来复杂性。 他们有可能在将来的任何时间重新订阅。 如果他们在您的应用程序中执行此操作，则您将能够发送新的收据，并告诉您的后端更新其状态。 但是，用户也可以从App Store设置页面重新订阅。 您需要依靠轮询和状态通知的某种组合来完全了解用户的订阅状态。
在服务器端存储什么
收到并验证收据后，由您决定存储在服务器上的内容是什么。 您可以节省的越多越好，但这取决于您的需求。 最简单的实现就是存储最新的expiration_date ，从而为您提供一种确定用户订阅状态的快速方法。
但是，仅存储最新的有效期会使您与收据提供的许多有趣信息区分开。 更好的实现方式是存储用户的完整交易历史记录。 存储完整的历史记录使您能够了解更复杂的订户行为，例如平均订户寿命，取消以及付费订户基础的日趋演变。
指标
如果没有服务器保存您的收据，很难获得良好的指标。 如果您打算了解LTV并可能对用户获取支出做出一些决定，则需要了解每个用户所花费的金额。 跟踪用户的总交易历史可启用此功能。
您可以尝试在现有分析基础架构之上执行此操作。 事件跟踪服务（例如与Segment集成的事件跟踪服务）通常可以跟踪StoreKit交易，但是您受应用程序，用户设备以及所使用的任何第三方跟踪器行为的影响。 当您尝试确定是否在广告支出上达到收支平衡时，您希望消除尽可能多的系统错误，并且基于事件的跟踪器中充满了这种错误。
拥有一个系统，该系统可以解析用户的整个交易历史记录，并将美元价值附加到每笔交易中，从而为您以最准确的方式回答您的任何获利问题奠定了基础。
客户服务
基于服务器的订阅跟踪提供的最后一个主要优势与客户支持有关。 支持Apple订阅客户可能会很痛苦。
开发人员无法通过编程方式访问用户的帐户历史记录，也无法修改或取消其订阅。 通常，我们最好的做法是告诉用户如何与Apple联系，或向他们发送有关通过App Store设置管理其订阅的说明。 使用服务器，我们可以做得更好。
通过后端可以访问用户的整个历史记录，您就可以更好地了解用户的情况。 IAP交易会以怪异的方式失败，使用户感到困惑，并且在涉及金钱时情绪会高涨。 触手可及的用户整个订阅历史记录将为您提供一个更好的起点来了解客户的问题。
使用服务器作为客户订阅的真实来源，您可以解决的支持票证要多于设备端的支持票证。 将“支持”交易记录添加到用户的历史记录中，可以让您向用户授予订阅的时间，只要您愿意。 这需要在后端进行一些工作，但确实可以避免1星级评价。
使用服务器
如果该应用程序有可能成为一项严重的赚钱活动，那么从一开始就让服务器跟踪您的订阅将使您的生活更加轻松。
上述服务器功能代表了大量工作。 如果您只有时间去做一件事情，我建议您使用服务器进行收据验证， 存储收据文件。 拥有收据文件将使您能够在以后建立其他所有内容。 如果您的收据被困在设备上，则您的选择将受到限制。
如果您想更快地启动和运行订阅并可以访问上述所有功能，则可以尝试使用RevenueCat。 我们的使命是填补苹果和其他平台留下的空白，并为开发人员提供出色的订阅实现，以使其迅速起步。