Connecting iOS In-App purchases to server's user account

I have an iOS app where I sell digital music. I also have a site and soon an Android app where I want users to have access to the content they purchased on their iOS device. Right now, I'm using non-consumable In-App purchases per Apple's recommendation. However, I see some problems in trying to sync the user's purchases with my user database.


What if apple user A_apple is logged in as user A_myapp on my server and purchases song X? Now, when A_myapp logs out, but is still logged in as A_apple, am I allowed to deny access to the content? And what if A_apple now logs in on a different device and tries to restore their songs, but they're not logged in as A_myapp? Can I disallow access (and possibly give a warning about them not being logged in with the right account)?


One possible option is using consumable purchases. I would love to do this as it would give me more flexibility with the In-App purchases, and it would completely resolve the above issue as I would just keep track of the purchases using my own system. The In-App purchases would just be virtual currency. I'm worried that my app will get rejected if I use this.


Hope to get some answers from people with experience and/or references.

YOu can certainly use a consumabe Token system in which the user exchanges Tokens for access to some content. This is typically done when the content entries are too numerous or variable to assign an IAP product to each entry. You may need to manage the user's purchases (i.e. the content that they obtained by exchanging a Token) and give them the ability to 'restore' all of their content on all of their devices because, in actual fact, your final IAP product is not a 'consumable' even though it is purchased through a consumable IAP 'Token' system.


You have another issue - how to you manage content purchased in iOS/Android if the user also has the complementary Android/iOS device? One way is to ignore the problem and assume all users will be in one or the other world but not both. Another is to operate as a 'reader' app (3.1.3) in so far as purchases made under Android is ported into iOS.

Thanks for your response PBK. Regarding the last issue about users who own both an Android and iOS device (not an unthinkable scenario). I don't really see an issue here. Since all the purchases are stored in my database, a user who purchases on iOS can restore on Android and vice versa. Or maybe you're thinking that Apple might object to Android users being able to use the iOS app without using IAP?

With the exception of a 'reader' app (3.1.3) the problem is that a user will be able to unlock code or functionality within their iOS app with a means other that iOS IAP (i.e. they buy the product on their Android) in violation of 3.1.1

Copy

Yes, but as long as we don't advertise the Android app inside the iOS app, I don't think it should violate 3.1.1?

You are creating a method that unlocks functionality within your app using a purchase mechanism other than IAP:

3.1.1 If you want to unlock features or functionality within your app.... you must use in-app purchase.


Unless - you mean you are operating under 3.1.3:

3.1.3 “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions ..... provided that you agree not to directly or indirectly target iOS users to use a purchasing method other than IAP, and your general communications about other purchasing methods are not designed to discourage use of IAP.

Connecting iOS In-App purchases to server's user account
 
 
Q