Validate iOS auto-renewable subscriptions from multiple apps

Question

I work for a game developing company which releases at least one game a month. For our true fans we want to start providing a subscription to our games, so they can play all our games (on any platform) without constantly having to buy them.

The idea for iOS is to use the in-app auto-renewable subscription. This results into a receipt which we store in our backend. The backend can validate this receipt and provide the apps with information about the subscription of the user. This system will solve a lot of problems: You can take the subscription in 1 game, and play all the games as well, on any device you like.

But now we come to the problem: After a month the receipt is not valid anymore, and we need to check in the iTunes store to see if the user still has a valid subscription.

My first idea was to use the "latest_receipt_info" field, to get the latest receipt and validate this. But according the documentation this feature should only be used for iOS 6 receipts:

"Only returned for iOS 6 style transaction receipts for auto-renewable subscriptions."

source: https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateRemotely.html#//apple_ref/doc/uid/TP40010573-

Even though I can actually still use this field with my brandnew iOS 10 receipt, I don't think it's smart to use it since it's deprecated.

(another source telling you shouldn't use it anymore: https://forums.developer.apple.com/message/156580#156580)

The advised solution of apple is to implement a SKPaymentTransactionObserver in the app. This will retrieve the latest receipt when it's available, and send this to the backend. Even though this is far from ideal, this could work... however:

This means the app has to be active to retrieve the latest receipt. And in our case it's very well possible a user takes a subscription in app1, and after a couple of days downloads app2, 3 and 4, but never uses app1 again. So in this case the latest receipt will never be fetched (because only the observer of app1 can access the receipt)

To fix this problem we should be able to fetch the receipts from this subscription from any app in our subscription group. But according the documentation on the apple site (https://developer.apple.com/app-store/subscriptions/ ) you can only access a subscription from 1 app, and you have to do the multiple app thing yourself:

You can offer auto-renewable subscriptions to access multiple apps in your portfolio. Each app must be approved to use auto-renewable in-app purchases and must be published under the same developer name on the App Store.

In iTunes Connect, you’ll need to set up separate and equivalent auto-renewable in-app purchases in each app offered in the multi-app subscription so that users can subscribe from any app. To avoid users paying multiple times for the same offering, you are responsible for verifying that they are subscribers in one of the apps before showing any subscription options. To do this, consider maintaining an account management system in which users create an account with your business to sign in to each app.

So is there any way to do what we want, without forcing the user to go back to the app he used to purchase the subscription every month?

Answer 1

On the last WWDC we went to StoreKit labs and personally asked StoreKit evangelist about this. We were told that the 'latest_receipt_info' field return by iTunes validateReceipt endpoint is exactly what we are suppose to use in order to check if the subscription was renewed or not. This is not going to be deprecated in the near future but they do have plans for adding some server-to-server communication that solve few of the problems we ran into:

1. Your server will be able to get notification from Apple regarding any subscription renewal, cancellation, downgrades etc.
2. In the latest_receipt_info returned by the validateReceipt endpoint few fields will be added, providing information like whether the subscription will be renewed after current one is expired, whether there was a problem charging the user's credit card etc.

Sources:

WWDC 2017 Session 303 - What's new in StoreKit
WWDC 2017 Session 305 - Advanced StoreKit