Using Generic In-App Purchase Items for a Dynamic Range of Digital Products

Using generic in-app purchase items for a dynamic range of digital products

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 ;)

Generic In App Purchase Products Implementation

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.

Using a Generic In-app Purchase

Once the successful in-App message returned from apple...

1.Its better to store the ProductID in a dictionary and delete the ProductID from dictionary once you successfully update the server.

2.Ignore any events till the transaction is complete.

3.Better to keep track of transactions i.e., storing the transaction information(ProductID,user,transaction recipt) in server side.

3.Optionally you can provide service from website, so user can mail you if he lost his money during in app purchase.

dynamically displaying prices of in app purchases in multiple currencies

Something like this should work for you. The following code prints the localised title, currency code and the price.

    let product = ... //your SKProduct
    if let currencyCode = product.priceLocale.objectForKey(NSLocaleCurrencyCode) as? String {
        print(product.localizedTitle + " : " + currencyCode + " \(product.price)")
    }

Is In-App purchase applicable for eBooks/Audiobooks?

Apple requires non-physical purchases to go through the In-App purchase feature.

The examples they give are:

• App premium features
• Magazine app that lets users purchase and download new issues
• A game that offers new levels to explore
• An online game that allows players to purchase virtual property

Audiobooks and ebooks fit that description. That means the app has to use IAP and Apple will get 30%.

Note that some apps manage to get around it (Kindle app for example) by not providing the ability to purchase ebooks in the app (not even links to the website). The app has to be a simple reader. This is what you have now, if I understand correctly.

In my experience, you won't be allowed to use your own credit card payment system unless it is for physical goods, so you can sell you hard covers this way, but not the ebooks or audiobooks.

To manage thousands of books with IAPs, you might want to create generic consumable IAPs as described in this question:
Using generic in-app purchase items for a dynamic range of digital products.

---

Related Topics