Hi, I'm Paul Marcos, Application Services Evangelist at Apple. In-App Purchas is an exciting technology that lets you offer services, products and subscriptions for sale directly within your application. By taking advantage of In-App Purchas, you can create your own virtual storefront in your app and tap into a whole new revenue stream.

Because you design and develop the user interface, you can focus on tailoring the experience so it's perfectly suited to your content and the needs of your users. To get you started, I'm going to explain how In-App Purchasse works and highlight a number of best practice tips to help you avoid some of the common pitfalls you might encounter when adding In-App Purchasse to your application.

I'd like to start off by providing some context about how applications are making money in the App Store. In iTunes, you can see a list of the top-grossing apps that are currently being sold. This list changes constantly, but here we have a typical example of the top 25 grossing apps. Looking at this list, we can see something very interesting. If we focus in on the top five apps, we see that they're actually free applications.

And if we look at the entire top 25, 17 of them are free. It's pretty common to see anywhere between 12 to 20 of the top 25 apps being offered for free. So how can these apps wind up as the top-grossing apps in the App Store? Well, they do so by generating revenue using In-App Purchas, which clearly shows just how well this model works. So what I want for you to get out of this presentation is an understanding of how you can include In-App Purchase in your application to generate sales.

To do this, we'll hit three main topics. First, we'll look at a few examples of how applications are integrating In-App Purchasse, and I'll highlight some key elements to a successful integration. Second, we'll spend the bulk of our time looking at the details of how you actually integrate In-App Purchasse. And lastly, we'll look at our newest type of In-App Purchasse, auto-renewable subscriptions. Let's get started with a few examples.

First up is Smoothies by Callaway Digital Arts. Smoothies is a beautiful app that provides different recipes for delicious smoothies. As you can see, it's a really vibrant app using rich colors and a simple UI to engage the users. Smoothies provides a base set of recipes and then users can add new recipes to their libraries.

Take a look at how they've implemented their In-App Purchas in a simple and intuitive way. You can find recipes by taking into account what ingredients you have on hand. They've presented this unique way of indicating what ingredients you have. For example, first I can specify that I want a citrus smoothie.

Now I can define the type of smoothie I want in more detail. So let's select tofu. I'm not sure I've ever seen a tofu citrus smoothie, but I'm willing to try one. As you can see, the app presents me with two recipes I have available in my library and an additional recipe pack I can purchase.

What's great about this implementation is that the store is essentially embedded in the UI. See something you don't have? Buy it! All without having to go to a dedicated store area in the app. It's a very seamless experience, which is what I really like about this example. Now let's take a look at the AmpliTube Fender app by IK Multimedia. Fender is a well-known manufacturer of guitars, amplifiers and effects pedals. What they've done with this app is to provide an innovative new medium for musicians to plug in their instruments to an iPad and process various effects through the app.

With In-App Purchas, they've allowed musicians to add on various effects, such as a phaser, overdrive pedal, echo and blender pedal. By offering this at an affordable price, In-App Purchas is a great way for Fender to introduce these products in a digital manner so musicians can then purchase the physical hardware.

Now let's take a look at Real Racing 2 HD by FireMint. FireMint is always at the forefront of adopting new iOS technology. For example, in Real Racing 2 HD, they're taking advantage of new features in iOS such as AirPlay mirroring. They've also implemented In-App Purchas as a way to provide virtual currency within the app.

You start the game driving a Volvo, and as you progress through the game, you can win prize money. You can use your prize money to buy new cars and upgrades, like this gorgeous Lotus. Now, I'm not a very good racer, and thankfully I've got an alternative. Using In-App Purchasse, you can upgrade your car with virtual currency.

For an $8 In-App Purchasse, I can now buy that Lotus. So this is an example of using In-App Purchasse as a way to accelerate the advancement within a game by using virtual currency, which can help keep your users engaged and let them get the most out of your application.

For our last example, let's take a look at the latest type of In-App Purchase, Auto-Renewable Subscriptions, which were made available in iOS 5. Auto-Renewable Subscriptions are the definitive way to offer traditional subscription support to your customers, allowing users to subscribe and be billed automatically, while having new content pushed directly to their devices, without any need for manual intervention or downloads. Let's take a look at how Esquire is offering their subscription in a totally revamped, digitally interactive version of their app.

As you can see, they've totally reinvented their publication to take advantage of all the interactivity the iPad offers. Subscribers get the great content they're accustomed to, but now they have the ability to receive their monthly issues automatically, just like they do for their paper versions. In addition to subscriptions, users can purchase individual issues directly in the application.

But they've gone a step further and offer older issues for free to get users acquainted with this exciting new digital format. The examples we've seen are just a few of the countless ways you can use In-App Purchas to enhance your application and tap into this potentially lucrative feature.

So let's talk about some of the benefits of In-App Purchasse to both you as the developer and to your customers. As a developer, you get these benefits right out of the box. First, you don't have to worry about collecting any of the payments from the users. Just like selling your application in the App Store, Apple handles all the payment details. Next, you can broaden the reach of your customer base by offering your products with localized pricing and product details. Lastly, all the sales reporting comes to you via the familiar iTunes Connect interface, just like the sales reporting for your application itself.

Using In-App Purchasse also presents great benefits for your customers, making them more inclined to make purchases within the app. First, the purchase experience is immediately familiar. It's the same as buying music, movies, books or apps. Second, the user doesn't have to re-enter any payment information. No need to dig up their credit card or fill in unfamiliar web forms. In fact, the user is not taken out of the app at all. Finally, the receipts for purchases come from a known, trusted place. It's all the same invoicing from the App Store that users are already familiar with and comfortable with.

So lots of options on how to integrate In-App Purchasse into your application, tailored to your application, and plenty of benefits for you and your users. Let's move on to look at the implementation steps for adding In-App Purchasse to your app. As we go through these steps, you'll see this energy-efficient light bulb pop-up. It will highlight key tips and techniques that will help you avoid some of the common pitfalls developers sometimes encounter when implementing In-App Purchas. So if you pay attention to these tips, you'll find your implementation experience much simpler, smoother and more energy-efficient.

In-App Purchas relies on the Store Kit Framework available in iOS, and as of last summer, OS X Lion. While I'm going to be focusing on the iOS side of things, much of what I'll be covering with the Store Kit implementation can be directly transferred to your OS X Lion app development. You'll find the Store Kit Framework is exactly the same on both platforms. All the tips and tricks you learn here can be used when you want to offer In-App Purchas in your Lion apps on the Mac App Store.

As you consider adding In-App Purchasse to your application, it's important to plan ahead. I want to spend a few minutes talking about a couple of the most common questions I get related to In-App Purchasse. First, what products are you allowed to sell using In-App Purchasse? And second, when configuring your items in iTunes Connect, what is the correct purchase type that you should use? Let's talk about the types of things you can sell.

In-App Purchasse should be used to sell digital content or services that are used directly within your application. This might be content that the user gets access to locally on their device or services that you might be providing over the internet. Regardless, the expectation is that the user will make use of those content or services by way of your application.

Let's look at a couple concrete examples of what you can and cannot sell using In-App Purchas. Here's a fitness app which sells digital versions of workouts. This is a great use of In-App Purchas. However, if you wanted to sell a membership for a gym down the street, that would not be allowed with In-App Purchas because it's not a digital good. Similarly, digital books can be sold within your apps, but physical copies of books cannot. Physical or real-world goods cannot be sold with In-App Purchas.

Once you've determined what you'll be selling, the next step is to determine what purchase type it fits into, so let's take a look at those. There are five different types of purchases you can offer. Consumable and non-consumable are the two basic types. And then there are three types of subscriptions, including non-renewable, auto-renewable and free subscriptions. Let's go through each of these in more detail.

The first type of In-App Purchas are consumables. Consumables are what I call single-use items. That is, each time the user wants to use the item, they have to pay for it. After they've used the item, it's consumed. And if they want to use it again, they have to purchase it again. Some examples of this would be items used during gameplay, like pet food or the virtual currency we saw in Real Racing that lets you advance through a game. Consumable items are available for both iOS and Lion.

Serving as the opposite to consumables are non-consumables. These are considered durable goods. Once they're purchased, the user gets to keep them and has ongoing access to them. When a user purchases a non-consumable item, it must be made available on all the devices the user has. So if they make a purchase on an iPhone, they'll be able to make use of that same item on their iPad as well.

We've seen a number of examples of this type including the Recipe Pack from Smoothies, a new Effect Pedal in Amplitube, or individual issues of Esquire Magazine. But it can also include things like giving access to additional features in an app like the ability to save documents. Non-consumable items are available on iOS and Lion as well.

Moving on to the subscription types, auto-renewable subscriptions are the latest type of In-App Purchas. With auto-renewable subscriptions, you can enable true subscription support within your app, allowing users to subscribe to your content once and be automatically billed each time a subscription term is up. Users can easily opt out on their next renewal at any time using the Manage Subscription Interface in iTunes or the App Store.

Auto-renewable subscriptions are primarily used for providing dynamic or episodic content to your user. That is, content that is updated on a frequent and regular basis so that the user is getting something new as they continue paying for the subscription. There are a variety of duration options ranging from 7 days up to a year with several choices in between.

As with non-consumables, when a user subscribes to something, that content must be made available to all the devices they are using. All Newsstand apps are required to use auto-renewable type for subscriptions, but auto-renewables are not limited to Newsstand apps only. Auto-renewables can be offered in any type of application. Finally, auto-renewable subscriptions are only available on iOS 5.

Free subscriptions are also a new type of In-App purchase. The implementation of free subscriptions is virtually identical to auto-renewables with the exception that there's no expiration date. Instead of expiring, users simply turn off the subscription like they would opt out of an auto-renewable subscription. Just like auto-renewables, the content is available to the user on all their devices. Free subscriptions are only available in iOS 5 and can only be offered by Newsstand applications.

The last subscription option is the Non-Renewable Type. Non-Renewables can be used for a wide variety of purchases such as access to static content or online services where the access is only provided for a limited amount of time. As the name implies, when the subscription period is over, the subscription simply ends. In order to continue access, the user would have to make another purchase of the subscription. Some examples might be providing voice navigation service for a few months while a user is traveling in an unfamiliar country, or allowing the user to scan business cards for a year.

Non-renewable subscriptions are an older purchase type, and as such, they don't have all the bells and whistles that the other subscription types offer. In order to use them, you have to explicitly keep track of purchases that the user has made and give the user a way to transfer those subscriptions to all of their devices.

You also have to manually track the expiration date of the subscription. Lastly, if you want to prompt the user in order to let them purchase another block of time, you have to implement that yourself. Non-renewable subscriptions have been available on iOS since 3.0 and are still appropriate for use with a wide variety of offerings.

Let's dive into the details about how you actually implement In-App Purchas. We're going to cover four key topics. Our first stop will be to set things up in iTunes Connect. Next, we'll move to implementing your code using the Store Kit framework. After writing your code, you'll need to test things in the Sandbox environment. And once you've gotten everything up and running great, you'll submit your app and products for review. Let's start with how you set things up in iTunes Connect.

The first thing you want to do is verify that you have a paid applications contract in effect. You'll need this if you're selling items via In-App Purchas, even if your application itself is free. And here we have our first energy saving tip. This one is simply to double check that you have a paid applications contract in effect.

It's easy to forget to do this and later have issues with testing in the sandbox or submitting your In-App Purchas items. Next, you'll start by adding your In-App Purchas products by specifying the metadata for each product you want to sell. Begin by going into the Manage In-App Purchases module of your application.

In this module, you can add a new product. When you do, you'll have to choose the purchase type from the list that we looked at before. We'll first focus on how to add consumable or non-consumable items. We'll look at adding subscriptions a little bit later. The first thing you'll provide is a reference name and product identifier for your item. These will show up in iTunes Connect and on your Sales and Trends reports.

The product ID is what your application will use to indicate which product the user wants to purchase. It's important to remember that product identifiers must be unique across both applications and platforms. If you have multiple applications on OS X or iOS, it's a good idea to prefix your product IDs with the bundle ID of your app.

Next, you can provide localized display names and descriptions for your items. Your application can access this information via Store Kit in order to display product information to the user. If you haven't localized your application or provided localized product information, it's well worth your time to do so. It can significantly broaden the reach for your products, translating into more sales.

Paul Marcos Moving on to the next section, you'll select pricing and availability for your item. This is a similar experience to setting the price for your main application, where you select from a range of price tiers. Paul Marcos Lastly, you'll submit a screenshot for review with your In-App Purchas item.

This screenshot is not seen by customers or displayed anywhere within the app store. It is used solely by the app review team to get a general understanding of what you are trying to sell. Now you're all set with regard to iTunes Connect and you've specified the products you want to sell. Time to roll up your sleeves and let's write some code.

This diagram shows the start to finish steps necessary for implementing In-App Purchases. As you can see, there are a number of steps required, and it's pretty easy to overlook some things along the way, so we'll go through the whole process together. Well, it looks like there's a lot of work for you to do here.

It's actually nowhere near that bad. You'll find that most of the work is provided by the Store Kit Framework. As with many of our other technologies, the Frameworks guide the overall process and you hook into a few well-defined places in the flow to complete the picture. Let's see how this all fits together.

Before offering your user the option to buy anything, you'll want to verify that the device is not restricting In-App Purchases. You do this by calling CanMakePayments on the SKPaymentQueue class. Sometimes parents will enable this restriction so that their children cannot purchase items without them knowing about it. Keep in mind that the user can enable or disable this restriction at any time. It's not a setting that will change often, but do pay attention to it in order to prevent confusion with your user by letting them try to buy something that will ultimately fail.

In order to show the products you have for sale, you'll need to fetch the details about the products from the app store. You do this by gathering up a list of product IDs you want to present. This list could be baked into your application directly, or for more flexibility, you could dynamically load this list from your server.

These product IDs would be the same ones you entered in iTunes Connect, so watch out for things like typos or changes in iTunes Connect that need to be reflected in your app. Once you have your product IDs, you use the SK Products Request class in Store Kit to fetch the product details. These requests are asynchronous, so you provide a delegate object that will be called back after you start the request.

After Store Kit fetches the details from the store, your delegate will be called back using ProductsRequestDidReceiveResponse method, passing an SK Products response object. The response object contains two arrays, one in response.products and the other in response.invalid product identifiers. The Invalid Product Identifiers array is the list of product IDs that are currently not available on the store. This could be because you don't have the paid contracts in effect, you might have a typo in the product ID, or the product may not be cleared for sale yet.

The Response.Products array holds instances of SK product representing the items that have been approved and are actually available to be purchased. These objects hold the localized product details and pricing information that can be shown to the user. So at this point, you're now far enough along to let users shop and pick out the items they want to buy. And remember, only products with the "Cleared for Sale" flag set to "Yes" in iTunes Connect will be returned here.

Once the user has decided what they want to purchase, they'll hit the Buy button. One of the major benefits of In-App Purchasse is that Store Kit will handle all of the payment processing for you. All you need to do is use the SKPaymentQueue class to request payment. As you add payment requests to the queue, Store Kit will asynchronously process those payments.

You'll participate in the process by providing a Transaction Observer on the queue. The Transaction Observer will be notified as a payment request is updated. It's important that you register your Transaction Observer in application did finish launching, because payment requests may be updated in the background while your application is not running. In order to get those updates, you'll need to set up your Transaction Observer during your application's launch sequence.

To begin processing a payment, you create an SK Payment object using one of the SK Product objects which we saw earlier. For those of you familiar with pre-iOS 5 versions of In-App Purchasse, note that Payment with Product replaces Payment with Product Identifier. Once you've done that, you simply add the payment to the queue and Store Kit swoops into action taking it from there.

Store Kit will prompt the user for confirmation and authentication with the familiar blue dialogues like purchasing an app. Store Kit will call the Payment Queue Updated Transactions method on your Transaction Observer when there are updates to the purchases in the queue. This is where you would handle the various states a purchase can be in. It might have completed successfully or the user might have canceled the request. Regardless of what the outcome is, this is your place to keep track of what's going on.

Once a payment has completed, you have access to a receipt for that transaction. This receipt is really important and can be used to validate the transaction which was made. It's a cryptographically signed piece of data and you can use it to get details about the purchase transaction. To verify a receipt, you take a Base64 encoded version of the receipt and send it to the App Store by way of a web-based API.

There are two different entry points depending on whether you're working in the sandbox environment or the production environment. Once you've verified the receipt, you can deliver the product to the user purchased. Receipt validation is imperative for protecting against piracy. This is your front-line defense against things like jailbroken phones.

Let's take a look at the transaction receipts you'll receive after a payment is made. After a successful transaction, your application can access the Transaction Receipt property from the resulting payment transaction object. It will be signed and will contain information about the purchase, like an original transaction ID, the date the purchase was made, the product ID, the quantity the user bought, and so on.

You can then take this receipt and Base64 encode it, wrap it in a JSON payload and pass it to the Web API for validation. It's best to do this on your server, although it can also be done directly from your application. The verification server will reply with a JSON response containing a status code along with the receipt details. A status code of zero indicates success, letting you know that the transaction is valid. After the payment and verification is complete, you can go ahead and unlock the items from within your app, or if your content is served remotely, deliver that content to the application.

From your user's perspective, the process is now complete. But as the developer, you've got a little bit of final bookkeeping that you need to take care of. During this whole process, the SK Payment Object has been sitting in the Payment Queue. Once you've verified the receipt and unlocked the product, the transaction is complete and you need to remove the Payment Object from the queue. You do this by calling the FinishTransaction method.

Depending on the purchase type you're using, you might also need to store the receipt on your server in order to provide the purchased item to the user's other devices. Finally, it's important to note that you might not be able to perform the verification of the receipt immediately. The user might have lost their network connection, for example. So it's best to not call Finish Transaction until after you've received the response from the Verification API.

Let's talk about restoring transactions. Just like with songs, apps or movies, a user who purchases a non-consumable item or a subscription must be able to restore that item back to a device they have, or to a new one. It's important to make the restoration process easy and intuitive for users.

Here are a couple examples of apps that present the restore UI in a user-friendly location. Often developers will bury this feature in the settings of their app, making it confusing for the users who want to restore previously purchased items. So be sure to make this an easy and intuitive operation for your users.

If you are offering non-consumable, auto-renewing or free subscriptions, you can use the Store Kit Restore API to give the items back to the user. When a user clicks on the Restore Purchases UI, you would call the Restore Completed Transactions method in Store Kit. The user will be prompted for their Apple ID and password, and then all their previous transactions will be replayed to your application. Your app will see all the transactions come through as if the user had just bought them, but the user won't be charged again.

So those are the steps required for implementing In-App Purchas. Like I said, it may seem like a lot, but it's really pretty straightforward and Store Kit does most of the work for you. Now that you have things in iTunes Connect set up and you've written your code, it's time to turn your eye towards testing things in the Sandbox.

In order to test something in the Sandbox, the items should be in the Ready to Submit state in iTunes Connect. So double-check that your items are in this state before trying to access them in the Sandbox. You do not have to submit your items for review in order to test them in the Sandbox environment.

The Sandbox environment is completely separate from the Production environment and you cannot mix the two. In order to test purchases in the Sandbox, you'll need to create a test user account for each country you want to test in. Because the environments are separate, you cannot use an existing iTunes Store account for your test user.

You will have to create a new Apple ID for each test user, and you should be careful to not use these test accounts in the production environment. If you do, then you won't be able to use them in the sandbox anymore. Also note that email verification is required for each test user you are setting up.

The second thing to remember for testing your In-App Purchases is to sign out of the store settings on your device. Make sure that no user is logged in. You should not log in with your test user account in the store settings or in the app store. You'll be able to enter the test user account username directly in the authentication dialogs when you test your purchases from your application.

You should also note that the same test user accounts can work across both iOS and Lion. You do not need to create a separate In-App Purchase test user for testing your items across the two platforms. However, a test user can only be assigned to a single country, so you will need to create a different test user for each country where your application is being sold. Lastly, remember that when you are testing your purchases, you should verify your receipts against the Sandbox Web Validation API, not the production one.

Once you've tested everything in the Sandbox environment and things are working for you, you're ready to submit your app and In-App Purchas items for app review. There are a couple things I want to point out about the app review process which can cause some confusion. To complete your setup, you'll hit the Submit for Review button in iTunes Connect.

This will send your In-App Purchas items to the app review team for approval. When you first add In-App Purchasse support to your application, you'll need to submit a new app binary at the same time you submit your In-App Purchasse items. Subsequent editions of In-App Purchasse items can be submitted without a binary.

Normally, while you're doing your development and testing, your development-signed application is using the sandbox environment for In-App Purchases. That's pretty straightforward, and your app will use the Sandbox Receipt Verification APIs. After AppReview has approved your application and users download it, the production-signed version of your application will be talking to the production environment.

That's also pretty straightforward. In this situation, your app will be using the production receipt verification APIs. The confusion comes in during the AppReview process itself, where the AppReview team is using a production-signed version of your application, but testing them against the sandbox environment. since your in-app purchase items haven't yet been approved.

This means that your application needs to be prepared to handle sandbox receipts in a production application. It's not uncommon for developers to take a sandbox receipt and inadvertently send it to the Production Receipt Verification APIs. If you do this, you'll get back a 21007 status code indicating an error. There are a couple ways you can handle this situation.

The simplest is to always use the production verification APIs and then watch for that status code that indicates you've sent a sandbox receipt to the production server. If you get this status code back, then you can just simply turn around and re-issue the verification request to the sandbox URL instead.

Since this situation really only happens during app review, it's pretty uncommon, but it is worth paying attention to since it can cause problems during the app review process. Now that we've covered the details of adding In-App Purchasse of consumable and non-consumable items to your application, let's move on to the newest type of In-App Purchasse: Auto-Renewable Subscriptions.

First, let's take a look at the differences between subscriptions and the other purchase types. With subscriptions, the developer is responsible for validating receipts in order to verify the subscriptions. You'll need to do this in order to determine whether a subscription is currently active or to determine the date ranges that the subscription covered. Second, when doing receipt verification, an additional layer of security is used in the form of a shared secret that you pass along in the JSON request.

Third, auto-renewable subscriptions allow you to offer a marketing opt-in incentive to your users. When users opt-in, they agree to provide you with their name, email address and zip code, and in return, you agree to give them a small free extension on their initial subscription. The publisher is responsible for determining and displaying this duration bonus, and it can be up to three months.

Since you may have the option to collect user data via the marketing opt-in incentive, a privacy URL for your company is required and is displayed on customers' invoices. We want to be sure that our users understand how their personal information is being used. There are also a couple additional things you'll need to do in iTunes Connect, so let's take a look at those now. First, you'll provide a reference name for your subscription. This is just a name you give to your collection of subscriptions in your application.

Keep in mind that this is never displayed to a user. It's only shown in your iTunes Connect sales reports and in the iTunes Connect mobile app. Next, you'll provide the Display Name for your item. This is the name that will appear next to the Buy button in your app and it can be localized. Users will also see this name in the Manage Subscription pages in iTunes and in their confirmation emails.

Now you can determine your subscription durations as well as provide the product identifier for each duration. Remember that the product identifier is what you pass to the App Store via Store Kit in order to determine which subscriptions your application can offer the user. Incentive duration is the field you populate if you plan on offering that marketing opt-in incentive for your subscription. For your product IDs, it's a good practice to encode the durations into your identifiers in order to easily know which duration the user chose. For example, you might just append an indicator to the end of your product IDs to show what duration the purchase was for.

Now you can add the URL to your privacy policy. This will appear on customer invoices and in the App Store itself. One note about displaying privacy policies. If you plan to include them within your application, make sure they are embedded directly within the app and not presented as a hyperlink that would take the user out of your application and over to Safari.

If you link outside of your app, the app review team will request that you change this behavior. Within iTunes Connect, you'll now be able to generate the Shared Secret, which you'll use when making requests to the Receipt Validation Service. This Shared Secret can be used across all of your auto-renewable subscriptions, so you only need one.

Let's take a look at how this all looks to the end user. In the Manage Subscriptions section of the App Store, the user will first be presented with the apps for which they have subscriptions. Clicking on an app will reveal the display name that you entered in iTunes Connect for the item.

And clicking on each display name will reveal the offer names for the subscriptions. As you can see, these are tied directly to the product identifiers. The user can always choose a different duration, which will take effect on the next auto-renewal of their subscription. This is also where users can opt out of the auto-renew functionality altogether. It's really as simple as just flipping a switch.

When you look at the invoice a user receives after subscribing, you'll see all the familiar fields. First, there's the display name of the subscription, followed by the app name, then the offer name, and lastly, the privacy URL you provided. One important note if you choose to offer auto-renewable subscriptions: don't forget to update your base application's metadata with information about your auto-renewing subscriptions. Make sure all the information in the Paid Applications Contract, Section 3.8b, is included in the application description on the store. This includes items such as your privacy policy, durations, and auto-renewing policies.

When we previously discussed implementation, we covered all of these steps, and for auto-renewable subscriptions, almost all of these are exactly the same. The only change you'll have to make is how you handle receipt validation. As we saw earlier, the App Store will pass back a transaction receipt to your app after a purchase.

You'll get back a receipt for the original purchase of the subscription, and then each time the subscription automatically renews, a new transaction will be generated, and each of these transactions has its own receipt to go along with it. When considered all together, these receipts paint the picture of the timeline of your user's subscription. This is the information you would use to determine what specific dates a user's subscription was valid for.

The receipts you get for auto-renewable subscriptions will differ slightly. Let's take a look at the fields you'll find in this type of receipt. The first is that you will find the purchase date. For non-consumables, this corresponds to either the date of the original download or the date an item was last restored to a device. For auto-renewables though, this will always be the date of the original buy or of a renewal.

You'll also get an original transaction ID. This will be constant across all receipts a user has for a particular subscription. So it's a good candidate for something like a customer ID. You'll get an expiration date and lastly, we'll always include the latest receipt information with every receipt for handy reference to the most recent transaction. If a subscription has expired, you'll get the latest expired receipt instead. When verifying an auto-renewable subscription receipt, the JSON response from the App Store will contain a status, the receipt you passed, as well as the latest receipt info.

Now a status code of 0 will indicate that a subscription is currently valid, but you can also get one of these other status codes back. I'd like to focus on status 21006 and 21007. As I mentioned before, the status code of 21007 indicates that a sandbox receipt was sent to the production server. You might see this status code during app review. 21006 is the status code that indicates a subscription is no longer active. Most commonly, this would tell you your user turned off auto-renewal and let the subscription expire.

But there's an edge condition where this might happen when the subscription hasn't reached the expiration date. Users cannot normally cancel subscriptions partway through a duration. They can only turn off the auto-renewal at the end of the current duration. In some rare cases, iTunes customer support will cancel a subscription midstream and in those cases you'll get the 21006 status code indicating the subscription has been cancelled.

Now let's talk about restoring subscriptions. Just like physical magazines don't vanish when a subscription expires, we don't think digital ones should either. This is a key takeaway with regard to restoring auto-renewable subscriptions. When a user chooses to restore an auto-renewable subscription, you'll need to make sure you give the user access to all the issues they're entitled to.

You can do this with the Restore Previous Transactions API. You'll get back a receipt for the original subscription as well as each renewal period. You can then pass each of these receipts for verification, and the purchase and expiration dates will let you know what content a user qualifies for.

If you're selling content or publications, this is very valuable to you. However, if you're selling access to a service, such as a streaming, audio or video service, you may not care about the date ranges. You really only care if the subscription is currently active. When we talk about renewing subscriptions, the beauty is that they will automatically renew, so you don't have to worry about posting dialogues or notifications about expiring accounts.

However, there are circumstances where a user may click on the Buy button when they already have an active subscription. In this case, the user will receive a dialogue explaining that the subscription is active and they will not be charged again. They'll be given a link to the Manage Subscription page, which will allow them to edit their subscription if that's what they wanted to do.

Since this might be confusing to a user, you might want to avoid this situation altogether. If your app has already validated a user's subscription, you shouldn't even present the option to buy the subscription again. However, if the user's subscription has expired, then you should allow them to buy the subscription again.

This will let the user renew right within the app. While the experience is similar to the original buy, one difference is that they will not be presented with the marketing opt-in incentive again. Two points here are that renewals typically occur a few hours before expiration and that if the price of your subscription goes up, auto-renew will be disabled and the user will be notified via email.

Just like with other types of In-App Purchasese, you'll follow the same steps to test in the Sandbox environment. One key point to note is that when you are testing auto-renewables in a sandbox, there is a limit of six renewals per purchase, and then the subscription will expire. This allows you to test a wide variety of scenarios and make sure that your app handles receipt verification correctly for each of them. You should obviously test how your app responds to the base case of the subscription expiring.

Then you should move on to test the more complex cases like non-contiguous renewal histories as well as changing durations between renewals. You want to make sure your application handles the wide variety of renewals and time periods that can happen. Be sure to verify you handle these situations correctly after doing a restore to a different device as well.

Also, the subscription durations are accelerated in the sandbox environment, so you don't have to wait a whole year just to make sure your app is working right. The values are displayed in this table. Be sure to keep these shortened durations in mind while you're testing. You could easily get up and leave your computer to get a cup of coffee and find that your subscription has already renewed six times and now it's expired. It's pretty common to do development using the longer durations like six months and a year since that gives you more time to get work done. Finally, the Managed Subscription Interface is not available in the Sandbox.

Well, that covers all the details about auto-renewable subscriptions that I wanted to talk about and brings us to an end of this presentation. Now you have all the details you need to integrate In-App Purchasse into your application. By paying attention to the highlighted tips, you can avoid some of the common issues and have a smooth implementation experience. You'll find that it won't take long before you're offering compelling and exciting products with a familiar and convenient user experience. And I'm sure you'll enjoy the additional revenue potential.