Generic In App Purchase Products Implementation

Question

Consider following example. Let's say we have an app in which professional writers write stories from a web based UI. And then these stories become available for user of the iOS app as in app purchase items.

As you may know we need to create in app purchase products in advance. But in our situations it means that for each of the story created by the writers we will have to create a new IAP product and wait for Apple to approve it.

To circumvent this, I am planning to create generic "consumable" products in IAP like story worth $1.99, story worth $2.99, so on, so forth. Then in the Application UI I will show the list of stories of created by the writers and show corresponding prices for the stories as specified by the authors when they created the story. Once the user taps on the buy button, I will show the purchase for the generic consumable product of the same price and complete the in app purchase process.

Now the question is will Apple approve of such implementation? Does it fit with their IAP policy? I am asking as I couldn't find a guideline for a workflow such as this.

Another approach to implement this is by implementing an in app credit/currency system, like games use. Where people buy credits/coins and then they purchase items with coins. This is a tried and tested approach but it doesn't fit in my analogy of the app, hence the question.

Answer 1

What you want to achieve is perfectly feasible, the only thing is your purchasable content has to be dynamic. You will have to download the product IDs from a server rather than having them hardcoded in your app.

To refer to your example, I can imagine a table view being fed with a list of objects that would have the SKProduct ID stored on them. You would have to do this because, at the time of writing, you can't retrieve all the available product IDs for your app from Apple servers. I know it's a pain in the ass they didn't implement this feature but to be honest, if they haven't already I don't think they will ever do.

This is the method I'm referring to: initWithProductIdentifiers

You provide it with a NSSet with all the identifiers you want to retrieve, but if you provide an empty set or a nil, it doesn't reply with all the existing. You can file a bug with a Apple if you feel this doesn't work as it should. Please check this SO answer if you still have any doubts: link

Another important thing to note is, you will have to upload your products manually. Apple doesn't expose any API in order to have the process automated. This means, every time a writer uploaded something to your server, you would have to log in into iTunes connect and create a product. Plus, you would be limited to 10,000 products because that's the maximum amount of different products you can register with Apple. I'd also recommend you to have a quick read to the iTunes Connect guide, which has some important information like the one I just mentioned: iTunes Connect

Regarding 3rd party frameworks, like the aforementioned UrbanAirship, they will just save you from having to implement receipt validation on your servers. Apart from that, I don't see any major advantages.

Said this, I'd recommend you to reconsider your business model. Is it really worth it all the hassle of uploading the products one per one? Or is it better to go the subscription way, in which your users pay a fixed amount of money for downloading a number of articles per month. You could have different tiers, like, basic, premium (unlimited downloads) an so on and control the delivery of the articles from your servers. That's up to you, but for me the answer is pretty clear.