How to be top grossing on iTunes app store with free iphone apps – in-app purchase Tutorial

Disclaimer: This is a very long tutorial on iOS in-app purchase. If you are fond of copy-pasting the code, jump here & know how to get it. Otherwise, read on to know how to catch the fish.

We have arrived. (To know from where, click here)

Obviously you don’t need those type of directions – I know.

In our ever-exploring and exploiting series of articles on How to make money on App Store, we have finally spotted a lamppost.  I am recounting my struggle of early days as indie developer, and how I suffered the most during IAP development. I am going to take some of that pain off you – my readers’ shoulders. So here we go – learning to build complete iOS moneymaking engine – as part of our in-app purchase tutorial.

What’s different about this in-app purchase Tutorial?

As part of this in-app purchase tutorial, we will not cover how Apple documentation has covered this topic. We will rather focus on how you would learn it if it was part of your computer science theory class (and I was your teacher, LOL). We will definitely focus on hard bits and bytes, but that isn’t the primary goal. Direct examples lead to copy-paste code which is making rounds of the planet and has encircled it million times – especially when In-app purchase tutorials are concerned.

So in this in-app purchase tutorial – against all conventions, we shall be hypothetical, we shall be wordy. The theory is code-tasted by me, and I want to ensure you will not write bad code as part of your in-app purchase implementation after completing this blog (well, I am hopeful about it :-) )

Anatomy of In-App Purchase:

Anatomy of In-App Purchase

Anatomy of In-App Purchase

 

That’s that – the blue boxes define it entirely. The orange boxes don’t matter. Well, they actually do, I made a heinous mistake of ignoring them. It’s like – blue boxes tell how you hit your opponent. You don’t worry about anything else – until he comes back thrashing you (orange boxes)!

Let’s dissect.

1 – User Requests Products from Store

This step is all about getting product data from itunes store. Whose store it is? It’s the one you set up on Apple servers.

  • It’s your products, Apple’s space.
  • Your product database resides on URL itunesconnect.apple.com.

As part of this step, all you do is fetch it by supplying their names. And yes, only your app can fetch it, no one else. Itunesconnect refuses to divulge any product data if your app’s bundle ID doesn’t match the one set up there.

Requesting Products from Apple Store

In-app Purchase Requesting Products from Apple Store

Why it’s done? To Populate the Store.

Who calls the shots?  SKProductRequest – requests the products.

Who does the work? SKProductRequestDelegate – returns the products as part of SKProductResponse. You should populate your UI from the array which you get as part of SKProductResponse products NSArray.

2 – Paying to Apple (70% to you):

Isn’t it the interesting bit? It is, but so are the rules (yikes).

Whenever user taps a product – this step should be performed. You should write code for this step in response to user selecting a product to buy – maybe through a BUY button or something similar.

Adding Payment to Payment Queue

In-app Purchase Adding Payment to Payment Queue

Why it’s done? To enable user to make the payment for IAP Product.

Who calls the shots?  SKPaymentQueue – adds payment to transaction queue on Apple servers to track it.

Who does the work? SKPaymentTransactionObserver – this protocol, through it’s required method updatedTransactions – does all the tracking what happened to the payment user made to your product. But this is part of the next step – the most crucial step of in-app purchases.

3 – Delivering Product (Or the bad news):

This is direct sequel to Part 2 above. The response of Part 2 is handled in this step. Apple servers keep sending status updates about transaction your user just initiated in step 2. These status updates must be handled properly by you inside delegate method updatedtransactions. If you have scoured the net, you will find identical copy-paste implementation of this method, which is quite incorrect.

The following diagram will clear many doubts:

Monitor the Transaction Queue

In-app Purchase Monitor the Transaction Queue

Why it’s done? To enable iOS app to track the transaction status for the transaction(s) user initiated, and at the end of it, either deliver the product, or show proper status (error) message.

Who calls the shots?  Nobody! Shots are already fired in Step 2…we must either hit them or miss them…phew…

Who does the work? SKPaymentTransactionObserver‘s required method updatedTransactions implementation decides what should be done for each status. It’s Apple Framework’s (Storekit’s) job to call this method, but it’s your job what you do inside it. The diagram more than tells you what should be done, what’s redundant, and what’s essential.

At the end of this step, user must either be able to use the product, or receive proper error message. Unless the user is a minor & status is Deferred – in which case nothing should be done / reported because status will turn to Purchased / Failed depending upon result of parent approval.

4 – Reliving the old memories:

“Remember I purchased that invisibility cloak in previous life of Unsung Hero Saga? I can’t place it now! It was supposed to last forever, but alas! I got my iPhone repaired – the store guy did the factory reset – what do I do?”

If your user gave a 1-star review – it must be due to this: All your non-consumable purchases (those which are ‘supposed to last forever’) must be capable of restoring themselves.

Well they aren’t, so you need to provide a button to the user, write code to restore them, so your users can relive their memories. Such a button usually resides inside your “Settings” screen. Upon pressing this, you should usually call SKPaymentQueue’s restoreCompletedTransactions.

Restore can actually happen through duplicate purchase of non-consumables too. Apple doesn’t charge your users again for non-consumables – so whenever user attempts a re-purchase by mistake, Restored status is all you get inside Step 3.

Restore flow – in both use cases – by user action & by duplicate purchase – is shown here:

Restoring Transactions by Restore button

In-app Purchase Restoring Transactions by Restore button

 

Restoring Transactions - Duplicate Purchase

In-app Purchase Restoring Transactions – Duplicate Purchase

 

Was it really an in-app purchase tutorial?

It was intended to be one. Yet no code. Nothing to copy-paste. That’s how I intended it to be. To develop understanding, to make you think what you should be writing inside those blocks (not the ^ ones, but the blue and orange ones  ;-) ).

If you are still wondering if code could help you out, or some part could be better understood – words have limitations. As I stated initially, this was to be like a theory lecture. And by all means I attempted it to make it like one.

But if you still think explanations aren’t like a staircase but an ever-growing tree, or this could be better with some real code – here is my complete video tutorial on iOS in-app purchases, along with free code sample. This is ready to integrate code based on iOS 8, compatible for Objective C & SWIFT.

Please note – that this is 66% discounted price – and the promotions won’t last long. Note that regular subscribers save even more during special promotion times!

So keep making money, and keep saving – hail In-app purchases!

Tagged with:

Leave a Reply

Your email address will not be published. Required fields are marked *

*