关于iOS 订阅、自动订阅 本身功能开发很简单。跟正常的购买没什么大的差异。唯一需要特殊处理（自动订阅）的是，
因为自动订阅，除了第一次购买行为是用户主动触发的。后续续费都是Apple自动完成的，一般在要过期的前24小时开始，苹果会尝试扣费，扣费成功的话 会在APP下次启动的时候主动推送给APP。所以，APP启动的时候一定要添加上面的那句话。
2、服务器在向苹果服务器校验receipt时候，不仅需要传receipt，还需要传秘钥。
重点都不是上面的，重点是测试，如何测试？尤其自动续费怎么测？先看下Apple原文档：
答案：视需求吧。有少量文章说2014年起苹果审核严格了，必须要有一个按钮实现restoreCompletedTransactions。另外，我听百度一位同学说，爱奇艺2015年因为这个被拒过。但是，目前来看很多使用了订阅的应用或是游戏，并没有这个功能。我是感觉，看需求了。订阅 是跟着 userid 唯一呢？ 还是跟着apple id 呢？在国内，一般都是前者。
a. 苹果设计自动订阅的初衷是 ，订阅一个服务， 这个服务需要跟着 Apple ID走。说白了，就是你A设备 用了Apple账号100001购买了，你换了B设备 用Apple账号100001登录app store，你同样能享受到服务。国外的一些音乐类型、杂志报刊等用的比较多，游戏类的少，苹果自己的Apple music也有自动订阅（首创）。b. 目前国内的一些应用或是游戏，希望的是自动订阅 关联的是 APP的 user id ，而不是Apple ID。说白了，就是你购买了一个自动订阅服务，我不管你哪个apple id 支付的， 但是只能我一个 APP的 唯一用户可以享受服务。这时候就需要APP自身做处理了，就是记住首次购买的transaction-id，并且绑定某个用户。以后自动续费的话，都会有original-transaction-id，这个id 是第一次购买的transaction-id，根据这个服务器可以联系初始购买的服务求一个美国苹果id账号。有点描述偏了，当transaction-id绑定了用户，再次收到其它用户transaction-id请求时候，视情况处理了。（你也可以根据unique-vendor-identifier处理）
2.同一个Apple ID购买完的自动订阅，可以再次点击购买吗（有效期内）？
这种情况一般发生在沙箱环境，一个账号多次测试订阅会偶发遇到，这里要注意这些票据的校验，要不批处理，要不通过信号量控制一下请求数。（PS：处理不好容易造成内存问题，小心！）
答：sandbox会出现这样的现象，建议通过信号量 或是 批处理 进行处理苹果美国id的expires怎么填，处理不当会crash。（不懂信号量的自行google）
答：自己模拟啊，模拟苹果的post请求，先看苹果的server-to-server（），其中notification_type 对应值为 CANCEL ，其它字段按需要改成之前订阅的数据，向你们服务器发送请求啊，就点拨到这了。
服务器需要做个定期（每天）检测，检测目前已有的所有订阅订单是否过期，如果发现过期了，就去苹果服务器验证receipt，其中苹果返回的latest_receipt_info 字段，会告诉最新的订阅订单情况，你可以校验expires-date与当前时间比较，判断该订阅有没有续订成功，并同时更新上述让记录的record_expires_date字段.
我们为什么做上述的处理？大家都知道苹果服务器会在订阅过期的前一天，对用户进行自动扣费，如果扣费成功了，苹果服务器并不会通知我们的服务器，这是重点。不过有个特例，如果苹果订阅过期前一天扣费失败了，苹果服务器后面几天还会尝试对用户自动扣费，如果后面扣费成功了（这时候用户实际状态是没有续订成功），苹果会通知我们的server的，其中notification_type 对应值为 RENEWAL,对于RENEWAL我们还是需要给用户更新为正在订阅的状态。
正式环境下，用户主动取消订阅，苹果会通知我们的server的，其中notification_type 对应值为 CANCEL，我们需要更新用户订阅的状态为取消。
总结，对于自动续订订阅，我们自己的服务器完全可以与apple server的交互应对用户的订阅状态，只需要确定客户端传来的用户第一次购买， user id 对应 original-transaction-id的关系。后面的续订，取消，变更套餐，完全不依赖于客户端传来的信息。
