In-App Purchases: Auto-Renewable Subscriptions Tutorial

In the article you mention setting up the Agreements, Tax and Banking info. I got the impression I didn’t need to actually provide banking and tax info to Apple (which seems crazy until you are serious about the app)… yet their documentation says that is required… is this true?? I can’t get the sample app downloaded from here to work. the subscriptions come back with an “invalid identifier”. (a second developer also tried this on his own and is getting the same results… neither of us have banking and tax info entered in iTunes)

from their doc: "You must have a Paid Applications contract in effect with Apple and have provided your tax and banking information in iTunes Connect "


I’m going with, yes. It’s required.

thanks @cwagdev this was purely to learn about handling the iOS Subscription receipts on the backend… which in turn requires an app and to have that I have to give apple my bank and tax info… well not worth it… truly sad… excellent tutorial though… if I ever succumb to the dark side again I’ll be back on this site reading up… thanks again…

Following my earlier comment - I am guessing that either:

  1. Extraneous variable in SubscriptionService:
    ‘purchaseSuccessfulNotification’ & ‘restoreSuccessfulNotification’ should be replaced with a single variable:

static let SuccessfulNotification = Notification.Name("SubscriptionServiceSuccessfulNotification")

2) Typo : Duplicate Notification variable:

static let restoreSuccessfulNotification = Notification.Name("SubscriptionServiceRestoreSuccessfulNotification")
static let purchaseSuccessfulNotification = Notification.Name("SubscriptionServiceRestoreSuccessfulNotification")

Suggest Changing to:
static let restoreSuccessfulNotification = Notification.Name("SubscriptionServiceRestoreSuccessfulNotification")
static let purchaseSuccessfulNotification = Notification.Name("SubscriptionServicePurchaseSuccessfulNotification")


Nice example. Except there is one fatal mistake. The name and descriptions you have given for the auto-renewals will fail Apple’s review process. You cannot state the time period in either the name or description field. I’m going through this hell at the moment - how can you differentiate subscriptions when the only difference is the lengths! I’ve been rejected for not stating the length and for stating the length.

It also doesn’t help that the description has now been cut down to 45 characters. It used to be about 140.

Any help on this would be appreciated.

Wow, I completely missed that. I looked around the AppStore and couldn’t find any that have time periods, so it definitely seems to be the case. A lot are either not uniquely named but have different prices. I assume they describe it somehow outside of the IAP item name? Others use terms like “plus”, “premium”, or “unlimited”.

Strange rule!

It makes it very difficult and so far I have not found something to satisfy their silly rules. Mine are differentiated just by the time period. That makes it difficult to describe, or even give a heading to. Having been rejected three times, I’m beginning to lose the will to live…

1 Like

Curious if you can query the list of renewable IAP’s via an API outside of iOS Storekit? for instance from the same server that you are keeping track of the receipts. the receipt only has the product ID but no other info about the product. If one wanted to show in a web interface that the user is subscribed to Plan XYZ at $##.##/Period… You can’t do that without the product info from iTunes connect

Good day.
I do not understand where to get YOUR_ACCOUNT_SECRET key

Take a look at the “Obtaining a Shared Secret” section.

As you suggested here I keep my receipt on the server. And I am able to validate it with Apple server. But after an expiration of the subscription we are getting an error as “receipt is invalid”. After the renewal of subscription by the user, we are still getting “receipt is invalid”. My question is, this will happen only in sandbox mode and it will work perfectly in production mode? if not what step do we need to do take here?

Note:- We are not sending a new receipt to the server after user renewal of the subscription.

Thanks for the tutorial :slight_smile:

Very nice tutorial! I was able to implement it and it was working fine. But recently I installed iOS 11 Beta 9 and looks like it is broken somewhere. I can restore purchases but when I click to buy one then it asks for user ID and password 3 times then it says purchase failed. Its neither working on my App not on RWSelfie… Can someone please help with this???

Hi great tutorial :slight_smile: I have a question after validating receipt on my server, how can i link that receipt to my current logged in user? which field i can save in my DB and than i can again validate the receipt for that user on my server?

I’m not sure, I would personally use TestFlight to test in production before releasing the app.

As always, if you find something not working in beta that worked before, check the new docs to see if it is a known change, if not file a radar for Apple to take a look at.

There are a number of ways you could go about this. One simple one might be to have a LastUploadedReceiptData column that is a binary storage type where you save the receipt file for each user.

So should i save the binary 64bit string value in that column?

But i am also implementing Server-To-Server Status updates which also returns a receipt data than how i ll identify which user belong to that subscription information?

It would depend on your database. I’m not sure the best option.

You need to keep track of what user originally submitted it and hold on to that information in your server-to-server requests.