I am working on an Auto-renewable subscription based application. We are using In-App purchase (StoreKit) option for the payment. I have 2 subscription plans.

  1. Monthly subscription

  2. Yearly subscription

At the time of registration, the user should purchase any of the subscriptions mentioned above.

The problem I am facing can be stated as follows:

-> The Apple device is logged in using an iTunes id [email protected]

-> One user say, [email protected] creates an account in my app, and purchase a monthly subscription plan.

-> Now the purchased subscription is associated with iTunes id [email protected]

-> Now, suppose if a second user say, [email protected]m tries to create another account with the same iTunes id [email protected]

-> My requirement is that I should not allow the user to create a second account with the same iTunes id. How can I accomplish this?

-> If I allow the user to proceed and if the user tries to buy the same Monthly plan, apple store will return something like You are already subscribed to this plan. But if the user tries to purchase the second plan, that is the Yearly plan, An upgrade will happen which will completely mess up my backend.

-> Is there any way to get some data which will uniquely represent each iTunes id? So, using this I can solve my issue. Or else what I can do to stop the user from creating another account when there is already a subscription exists with the same iTunes id?

Note: Restore purchase was one option(not a good option, still). But it will confuse the user when there is a fresh registration happens and I don't think that is a good approach.

  • This might be a bit off-topic for this site because the answer will depend on how you code the receipt you get from Apple. Subscriptions are tied to user's Apple ID. Two users should not be using the same Apple ID so, in reality, Apple's response back is correct.
    – fsb
    Feb 3, 2020 at 16:26
  • @fsb Your point is correct. But from the receipt, we will not get any information which we can use to recognise the user. That is the problem.
    – AKA
    Feb 4, 2020 at 6:52
  • The purchase is tied to the user's iTunes Account which can differ from their Apple ID account. Feb 4, 2020 at 21:18

1 Answer 1


The user's iTunes ID differs from their Apple ID. It is easy to 'share' your iTunes ID but hard to share your Apple ID.

Your concern is a valid one but for a different reason. No need to be concerned about two different users purchasing two different subscriptions. But you could be concerned that two different users will share their iTunes ID and both benefit from a single purchase.

One approach is to forget about it; it's a theft but not necessarily a loss of a real sale. Another approach is to associate each purchase with the user's Apple ID using their iCloud key-value file. Use that key-value file to implement your own restoreCompletedTransactions. Do not allow a repurchase for free.

  • Understood. So, the issue can't be solved by writing a key-value pair to the users iCloud account. Because iCloud account is associated with Apple ID where the purchase details (Subscription info) will be associated with App Store ID. The user can change the Apple Store ID and can try a purchase. If that App Store ID doesn't have a subscription purchased, I should allow them to purchase, right? But if I look after the iCloud key-value pair, I won't be able to allow them because there exists a key-value pair in the iCloud which represents a purchase from another App Store ID.
    – AKA
    Feb 7, 2020 at 6:37
  • Your app can tell the user that subscriptions will be associated with their Apple ID. Then using the key-value file in iCloud will work fine. If the user changes their App Store ID and makes a second purchase your key-value file can show two subscriptions. Or you can tell the user they made a mistake and they should cancel one subscription. IMHO your concerns are edge case and mostly irrelevant. The issue is not a user that over purchases, it is a user that over distributes a single subscription. Feb 8, 2020 at 22:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .