This is a blog post by site administrator Ray Wenderlich, an independent software developer and gamer. A while back on the weekly tutorial poll on the sidebar, you guys voted for a tutorial on In-App Purchases: consumables and receipt validation. As always, your wish is my command! :] This tutorial picks up where we left […]

Version

Learn how to implement consumable In-App Purchases and validate receipts!

This is a blog post by site administrator Ray Wenderlich, an independent software developer and gamer.

A while back on the weekly tutorial poll on the sidebar, you guys voted for a tutorial on In-App Purchases: consumables and receipt validation. As always, your wish is my command! :]

This tutorial picks up where we left things off in our previous In-App Purchases tutorial. As a reminder, in that tutorial we developed an app called “In App Rage” where customers could purchase rage face comics as non-consumable In-App purchases.

In this tutorial, you will extend the app to add a new consumable In-App Purchase – after all, those are often way more lucrative than non-consumables, since customers can purchase them more than once! You will also add receipt validation to add some extra security into the app.

Note that this tutorial (and the previous) are focused on the “simplest and easiest” way to do things, not the most “robust and flexible” way of doing things. If you’re more interested in the latter, check out our book iOS 6 by Tutorials, where you’ll learn how to develop an extremely flexible server-based In-App Purchases system, with downloadable content hosted on Apple’s servers!

So without further ado, let’s dive into some more In-App Purchases info – you’ll see it’s pretty easy, and there’s no need to rage about it! :]

Getting Started

Note that the starter project is not the same as where we left things off in the last tutorial – I’ve added a few extra things for you:

Added the ability to see a rage comic after purchasing it (which was left as an exercise at the end of last tutorial).

Added the skeleton for the “random rage face” feature. Right now you can do this an unlimited amount of times for testing.

Gratuitous icons and iPhone 5 screen size support! :]

You’ll have to make a few changes to this project for it to work for you:

Open RageIAPHelper.m and MasterViewController.m and search for “com.razeware” – you’ll see the product identifiers I set up. Replace those with your own product identifiers you created last time in iTunes Connect.

Open In App Rage-Info.plist and update your Bundle Identifier to your own bundle identifier.

Once you’re done, try out the app on your device and purchase a comic and make sure the purchase succeeds, and that you can view the comic after you buy it. Also, try out the new random rage face feature!

Creating a Consumable In-App Purchase

You have an sneaky plan to make money – instead of allowing the user to see cool random rage faces as often as they’d like, instead you’ll add an arbitrary limit to it, and charge users to purchase more, mwuhahaha!

This way, there’s no limit to how much money users can spend on your app, hopefully keeping the bucks rolling in!

Note: This is just the beginning of ways you can use consumable In-App Purchases to (arguably sneakily) increase your app’s revenue. To learn more, check out the many blogs and talks about freemium game design, gamer psychology, or any games by Zynga ;]

Just like you did with consumable In-App Purchases, the first step to make this all happen is to create a new In-App Purchase entry in iTunes Connect.

Here you add some special case behavior for the consumable In-App Purchase you added. When a customer purchases this, instead of simply setting a flag indicating whether it’s purchased or not, you increment a value that keeps track of how many rolls the user currently has.

Note: This works but isn’t the ideal way of doing things, because now your IAPHelper class has hard-coded logic for a particular In-App Purchase so isn’t as reusable. For a more reusable way of doing things, check out iOS 6 by Tutorials.

Next open MasterViewController.m and replace your tableView:numberOfRowsInSection: and tableView:cellForRowAtIndexPath: methods as follows:

Here you have removed the “test” row that the sample project had earlier, since now you have a new consumable In-App Purchase to display instead. You also add some logic so that you always display the “Buy” button for the consumable IAP.

Finally, open RandomFaceViewController.m and replace the buttonTapped: method with this (and these additional two methods):

This is some basic logic to replace the unlimited button taps with using the new value you're using to track the user's spins.

And that's it! Build and run, and purchase a few spins. Then test out your the random rage face button and make sure it works as expected!

Receipt Validation

When you make an In-App Purchase, you can't 100% trust that the response that comes over the network saying "everything went OK" really came from Apple without using a technique called "receipt validation."

When you make an In-App Purchase, Apple sends you back a special piece of data called a "receipt." This is a private piece of data that records cryptographically-signed information about the transaction. The idea is that for your app to be secure, you shouldn't blindly trust that a purchase completed - you should send the receipt to a special "receipt validation" server that Apple has set up to double-check that everything is OK.

The dangers of not performing receipt validation were proven pretty spectacularly recently. A Russian hacker developed an easy-to-install In-App Purchase hack that allowed users to receive almost any In-App Purchase for free - at least, if the app wasn't doing proper receipt validation.

The hack is a classic "man in the middle" attack. You configure DNS records so your devices is routed to the "hack" servers rather than Apple, and you configure a fake certificate on your device so the OS trusts the "hack server" you're connected to. Then, whenever you make a request to make an In-App Purchase, the request goes to the "hack server" instead. The hack server will always say "done and paid for!" so the app will unlock the content without knowing it's been had - for free!

This hack will no longer work on iOS 6. However, there are other variants hackers could employ in the future, so it's still a good idea to use receipt validation.

Note: For more information on the In-App Purchase hack described above, check out this article.

The No-Server Solution

Apple's official recommendation to perform receipt validation is to connect to your own server, which then connects to Apple's servers to validate the receipts.

For a number of reasons, this is more secure than connecting to Apple directly, and this is the approach you take in iOS 6 by Tutorials.

But in this tutorial, the focus is on the simplest and easiest way to implement In-App Purchases, and it would be a major pain to have to set up your own server just to validate receipts.

A lot of other developers feel the same way, and so they wrote code to connect to Apple's validation server directly from their apps rather than going through an intermediate server (despite Apple's recommendations). It became so common that Apple provided some sample code demonstrating a fairly secure way to verify receipts by connecting to Apple's servers directly.

In this section, you're going to integrate Apple's provided code into the app to validate receipts before unlocking the purchases.

Note: The original code was missing some pieces (such as the base64 routines) as well as some logic (like returning results to a caller), which I added in. Also, I cannot vouch 100% for the robustness of the Apple code, as it looks a little thrown together, so use at your own risk!

Go ahead and download the resources for this tutorial, and drag the folder into your project. Make sure Copy items into destination group's folder (if needed) is checked, Create groups for any added folders is selected, and the In-App Rage target is checked, and click Finish.

The code requires the Security framework, so let's add it to your project. To do this, click on your In App Rage project root in the Project Navigator and then the In App Rage target. Select the Build Phases tab, scroll down to the Link Binary with Libraries section, expand it if necessary, and click the + button. Select Security.framework and click Add. At this point, your list of libraries should look like the following:

Then switch to IAPHelper.m and add the following import to the top of the file:

Build and run, and your app should work as usual - but now with a great deal more security!

Note: If you are going to use this verification controller in your app, remember that it is currently configured to use the sandbox server (see the verifyPurchase:completionHandler: method). You will need to switch this to production before you release your app.

Where To Go From Here?

Congrats - you now have implemented both non-consumable and consumable In-App Purchases, added the ability for users to restore transactions, and are validating receipts!

Like I mentioned in the previous tutorials, for a lot of simple apps this is more than enough. But if you want to take things even further and learn how develop a robust and extensible server-based system, check out iOS 6 by Tutorials!

I hope you enjoyed this series, and wish you best of luck with your consumable In-App Purchases! Just don't be too sneaky/evil, one Zynga is enough ;]

If you have any questions or comments on this tutorial or In-App Purchases in general, please join the forum discussion below!

Contributors

Ray is part of a great team - the raywenderlich.com team, a group of over 100 developers and editors from across the world. He...

Author

This is a blog post by site administrator Ray Wenderlich, an independent software developer and gamer. A while back on the weekly tutorial poll on the sidebar, you guys voted for a tutorial on In-App Purchases: consumables and receipt validation. As always, your wish is my command! :] This tutorial picks up where we left […]