24
votes

Have any of you implemented something similar to the below scenario?

Consider an app which provides audiobooks:

  • The books are maintained dynamically from a web based UI by the authors.
  • The books become available for users of the iOS app, as in-app purchase items.

By default Apple guidelines suggests using non-consumable IAP, and adding continuously as many IAP items as many books we have. But this is not proper for us, as the authors won’t have access to iTunesConnect, so it cannot be dynamic, “self-serving”.

Therefore we are planning to create a set of generic "consumable" IAP items like “Book worth $0.99”, “Book worth $1.99”, and so on. Then in the app we’ll show the corresponding IAP item for the books as specified by the authors, when they added it to our system.

Of course we store the purchased items on the server side, so the user will always have access to the purchased items -- even if they access it later from another device.

Will Apple approve this implementation?
Does it fit with their IAP policy?

I’ve found some similar quite old topics in the forum but the answers were confusing. Have you implemented something similar and get approval from Apple?

3
How this you end up solving this problem?ArkReversed
Hi, Apple has accepted our solution, as described in the question. The point was, as suggested below by others, that you need to provide the possibility to restore the items later. As we are storing every purchase in our database, and our users are authenticated (they need to register and log in to purchase), we are able to provide them access to the purchased items forever, even when accessing the app from other device. We are also storing the associated in-app-purchase's ProductID from iTunesConnect, plus the userID, price, date to have a detailed register of all purchases.Zsolt K.
@ZsoltK. How do you identify the book that the user has purchased when the StoreKit transaction observer is called?Ian Warburton
@IanWarburton Looking into same problem. Do you have a solution for this?Haagenti
@Haagenti I had the code assume it was the last product the customer ordered according to the database. Didn't finish the project though, so I don't know if it would have worked.Ian Warburton

3 Answers

6
votes

Apple has accepted our solution, as described in the question.

The point is, as highlighted correctly by @RomOne and @ge0rges that you need to provide the possibility to restore the items later.

As we are storing every purchase in our database, and our users are authenticated (they need to register and log in to purchase), we are able to provide them access to the purchased items forever, even when accessing the app from other device.

We are also storing the associated in-app-purchase's ProductID from iTunesConnect, plus the userID, the price, and the date, to have a detailed register of all purchases.

Important: Apple has rejected our first solution, because they didn't understand how it works, and how a purchase can be restored.
The key to success was describing in detail how the system works and providing a test user access to our web admin site. This allowed the Apple reviewers to see the whole system.

3
votes

Yeah in my point of view they will accept it. As long as you allow users to retrieve their purchases later on. Your system make me think about a virtual currency I have made where I had to make generic consumable that needed to be actually saved for the user. Apple approved it (and still does) because I was saving all purchases, even if it didn't fit perfectly with IAP policy ;)

1
votes

The key here is to make sure these purchases are restorable, always. So make sure to store the "IDs" or however you identify the different item in a way that is associated directly to the Apple ID (not account, but Apple ID).