Take the 2-minute tour ×

Here’s my situation: I have a free app which I plan to provide access to through a $0.99 monthly (auto-renewable) subscription.

I am still testing in the sandbox, so the way I see how auto-renewable subscriptions really work may be distorted. My questions below are as follows:

1) What is the minimum version of iOS that can support auto-renewable subscriptions? How will users of earlier iOS versions experience said functionality?

2) If I understood it correctly auto-renewable subscriptions are classified as “non-consumable” items, that can be bought only once. What happens when I try to re-purchase a subscription before its expiry date (or the date where renewal is set to kick in): I won’t get charged again, will I?

3) Will my app get notified if the subscription auto-renews? I would imagine that the app will automatically be sent a paymentQueue:updatedTransactions: method call in my SKPaymentTransactionObserver but I’ve never been able to see this happen while working in the sandbox. In my case I have to run a local timestamp check against the purchase receipt’s expiry date during startup.

4) If I have to communicate with the iTunes server, using the receipt I saved from the initial purchase (or from successive renewals), how do I properly check with iTunes if a subscription is still active or if the user has already disabled auto-renewal?

5) My in-app purchase item is the subscription itself, whose product code is known to the app... Is it really necessary to retrieve the product details when you already know what it is? Apple’s IAP Guide seems to makes it pretty clear that I need to do this but it seems just overhead for me.

share|improve this question
add comment

1 Answer

up vote 7 down vote accepted

Did you try with my MKStoreKit? http://blog.mugunthkumar.com/coding/mkstorekit-4-0-supporting-auto-renewable-subscriptions/

Point 1: Not sure of this, but my best guess is iOS 4.3.

Point 2: When you re-purchase, AppStore sends a message that you are already subscribed to this product. Technically you shouldn't show the button that allows the user to subscribe (Disable it when subscription is active, MKStoreKit provides Notifications to do this)

Point 3: Yes your app will be notified. MKStoreKit consumes this notification and automatically stores the latest receipt for you

Point 4: At launch you should post the last receipt you got from iTunes server and check if it's still valid. AppStore returns you the purchase date of the latest receipt. From this you have to calculate the validity of the receipt (since you know the length of the subscription. Note that iTunes App Store server doesn't send you any info about the length of the subscription)

Point 5: All product details should be fetched when app is launched. Otherwise when a customer makes a purchase and before completion he quits the app (due to a phone call) you will not be able to know which product he bought when your app resumes. Delay loading doesn't really makes sense with In-App purchases.

share|improve this answer
Those are well thought-out answers. Thanks. Regarding point 5, I only have one in-app product, so there will be no confusion at all. –  Aldrich Co Jul 29 '11 at 8:32
Mugunth, to Point 3 you haven't answered his question (because it's my question too). All you've done is tell him what your framework does. But what's going on exactly, where is this notification arriving? Is it really SKPaymentTransactionObserver as Aldrich asked and as I too suspect? –  Rich Dec 8 '11 at 13:28
Nevertheless, thanks for the clarification on Point 4. That's what I was suspecting, but until now unable to confirm :-) –  Rich Dec 8 '11 at 13:30
SandBox: sometimes there is a alert "you already subscribed to the product" if I am trying to purchase same product in a small interval. So I can I track this alert programmatically? Debugger never goes inside SKPaymentTransactionStateRestored! –  Vaibhav Saran Jan 17 at 6:44
add comment

Your Answer


