Generic In App Purchase Products Implementation

14
votes

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.

2
iosin-app-purchase
have you implemented this the way you describe here? I thought to do the same with a new app of mine but was not sure if they would approve... – Duck
How do you plan to pay the writers? – Sonny Parlin
@RubberDuck - Yes we implemented it this way. The app was rejected in the first try. The client had to fight with Apple to get it approved as per this implementation. – Pritam Barhate
@Sonny Parlin - The writers (who were not writers I was just using an example to keep the original concept under the wrap because of NDA) were given a web based account to see what their earnings were and their account was to be settled every month by sending them checks or payment in other non automated way. – Pritam Barhate
@PritamBarhate is this app still in the store? If so, did it have problems with further updates? I'm considering adopting the exact same model (consumable in-app purchase that represents a price tier) but it feels shady and likely to attract trouble with Apple. – ArkReversed

2 Answers

2
votes

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.

0
votes

Pritam

For delivery dynamic content you should be using a Subscription, not a consumable. Using a subscription solves your problem by allowing you to charge for each update AND distribute new content at the same time.

You can looking into 3rd party services like UrbanAirship that will significantly reduce the amount of time you spend trying to dynamically deliver your content, track subscriptions and expirations, etc.