Hi, everybody. My name is Aubrey Ness. I'm the App Store Operations Manager. And welcome to session 308, Managing Subscriptions with In-App Purchase. Is in-app purchase important to you? As you know, in-app purchase has been wildly successful on the app store. Another thing you might not know is that some of the most popular apps, the ones that are on our top grossing charts, are making their revenue solely from in-app purchase.

Whether or not it's a paid app that has in-app purchase to unlock new features or add additional content, or if it's not even a paid app, it's a completely free app for download, they're also making their money off of in-app purchase. And that is amazing to us, that these guys can be part of the top grossing charts on the store.

Furthermore, we know that iOS users expect a lot from you. They want you to update the app to give them new content. They want you to fix bugs. They want you to continuously giving them something new. And subscriptions are a really great new way to take advantage of that. It's sort of like you're establishing this long-term relationship with your customer.

It's really kind of a communication and dialogue that you're doing within the app. And we want you to take advantage of the subscription model to be able to deliver those recurring new pieces of content you might have. And then it gets your customers more excited to download your app, gets them more excited to launch the app every day and kind of see what's new.

So with that, today's agenda, we're going to talk about how to actually implement auto-renewable subscriptions Then we're going to talk a little bit about our older model of subscriptions, non-auto-renewing subscriptions. And we really want to make it clear to you which one will be better for your business.

Then we're going to talk about iTunes Connect setup. We want to make sure that you're setting all this up correctly so that you can be successful in the app store. We're going to talk about the customer experience based on what you set up in iTunes Connect. And finally, we're going to discuss some best practices and some pricing information that you can take away at the end of this session to go implement. And to kick us off, we'll go ahead and bring up David Neumann from iTunes Store Engineering to give you some education on Subscriptions 101. Okay, thank you.

The key attribute of these things are that they are iOS only today. They're restorable. Now, non-consumables are an in-app you may be familiar with are also restorable. But there's also these things called consumables which aren't restorable. And you'll find that auto renewables are kind of a hybrid of both these things. They are both restorable and consumable in that you can buy the same one over and over again.

Now, let's zoom into one of those periods and talk about some of the details that happen in each one. So, the first thing we're going to do after the user buys for the first time, but only after that initial purchase, is we're going to send this welcome email to the user.

It says purchase confirmation, but basically it introduces the user to the subscription. It tells them how they can control their auto-renew settings or if they wish to auto-renew where they can go to turn it on or off. It has privacy policy information and a bunch of other stuff. That's just sent once.

After that gets sent, you actually have this active subscription now. Now, if someone clicks a buy button in the middle of your app when it is active, we're going to raise a dialogue that looks like this. It says you're currently subscribed to this. Basically, we know whether you're subscribed to it and we won't let you buy it again.

So, another thing we're going to send during the lifecycle of this is a renewal reminder. Now, I have like 20 subscriptions and most of them are monthly. And not all of them, but most of them. And it would be kind of annoying if we sent 20, for people like me, 20 renewal reminders every single month when something got close to expiration. So, we don't do that. We actually aggregate these things on the store. We look at everything in the next month that's just going to expire or everything in the next month that's going to renew.

And we have, you know, at most two aggregated emails which go out at most once a month. But again, we're only looking at stuff which is going to expire or renew soon. So, if you had a yearly subscription like in our previous example, in that case, you're only going to see one of these emails and it's basically going to be, you know, basically like the end of the life of it. Anyway, enough of that.

So, that gets sent. Important point that's not in any docs anywhere is what we do at T-minus 10 days to expiration. And to illustrate kind of what we're doing, we're going to send a new subscription to iTunes Connect. And to illustrate kind of what we're doing there, I want to just talk about what happens for a particular event like a price increase. In this scenario where you may be accidentally, may be on purpose, but sometimes accidents happen and you may have accidentally increased the price, it goes up, it goes down.

For this user, since it happened before this 10-day period or time in this subscription, those changes are invisible to this user. Now, if they happened after the 10-day period and you're in the subscription, you're going to have to wait a little bit longer. So, you're going to have to wait a little bit longer.

And you're in this 10 days to expiration. We're actually going to be looking for price increases. And if we see them, we're going to turn off auto renew. And we're going to send an email to the user. And if the user approves the higher price, then we're going to turn auto renew back on and you're back in business.

Okay. Now, another thing we're going to be doing during this period is testing for the user's ability to pay. If a user maybe had a credit card when it started, obviously, but maybe they pulled the credit card off, maybe they tried to buy a song and their card gets to go. Maybe their card is expired.

You know, there's a lot of things which can go wrong. If something goes wrong, we're actually going to start looking for it now and we'll send out an email to the customer if it looks like we think they're not going to be able to pay because we don't want them to, you know, lapse on their subscription.

Okay. Now, at T minus 24 hours to expiry, this is the window within which we're actually going to try and renew the thing. Now, this doesn't mean we're actually going to try and fire off renewal purchases at T minus 24 hours. It just means that somewhere in there, that's when we're going to start to see a lot of changes. We're going to start doing it. Now, if it fails, we're going to keep trying to renew this subscription. But eventually, a little bit after expiration, we're going to basically give up.

Send a billing problem email if we think that we had to give up because of a billing problem. Now, the user will get that email. Hopefully, they will either go into iTunes and basically fix their billing info and then, you know, inside iTunes, interactively renewal there. Or they might, in your app, click buy again.

Now, when it was active and they clicked buy, you know, they got that other dialogue which says, hey, you're already subscribed. Well, now they're no longer subscribed. So instead, you just get the same confirmation type dialogue and the purchase happens again. Except in this case, I call it interactive renewal buy has occurred.

Their subscription is active again in this case. But you have this service gap. Now, if you have an audio streaming or video streaming type service or something like that, you don't really care. But if you have a subscription to discrete content like magazines and so on, well, that could be a deal. I mean, because if that gap is big enough, you know, might have missed -- that customer might have missed an issue they otherwise would have been entitled to.

Okay. Now, I just mentioned cancellation, so a note on that. Users cannot cancel. They can't do anything in a live subscription inside iTunes that will cause the service to be terminated and for their money to be returned. However, iTunes customer support does have this capability, and for customer satisfaction reasons, they can go in and cancel something. And when they do, that's when you see this cancellation date show up in the receipts. And furthermore, that's when verify receipt, which we'll talk about more in a sec, will return inactive and return active immediately.

All right. So a few other new things. These are the timestamp additions. There isn't any new data here. It's just we're providing PST and milliseconds in the receipt for all these different timestamps, expires date, purchase date, original purchase date, and so on. These are just a developer convenience. The milliseconds is just more machine friendly. It was available for some timestamps but not all. This makes it consistent. PST format is more human friendly. And you might be wondering why add PST when we already had GMT in there.

We wanted PST in there because in the iTunes store we do calendar-based renewals. That means if I buy something on the 5th of March, the 5th of April, the 5th of May, the 5th of June, and so on and so forth, it's always going to be on the 5th.

Customers can predict when the renew is going to happen. But that means, as this example illustrates, some weird things can happen. And I just want to give you the example so you understand. If you order a monthly subscription, for example, at 2 a.m. on April 1st in New York City, that's Eastern Standard Time.

Now, in California, that's March 31st. So why does that matter? Well, the customer, they're looking at their calendar, they see the 1st. But when they see dialogues from us, when they get e-mails from us, when they look at the UI from us, they're going to see something talking about essentially the end of a month and not the beginning of a month. So if you've ever wondered why you saw something like that on occasion, this hopefully will shed some light on that.

All right. So let's talk about how these receipts are used when you do something like a purchase. So the players we have up here is the iPhone representing your app. You've got the iTunes store there at the top with the little note icon by it. And this is supposed to be your server down here at the bottom. Okay. So we do the buy request and a receipt is generated. Basically a transaction record is generated. It is returned to your app. And you take that receipt and what you should do is unlock content. So you want to pass that to your server to do that.

So you're going to present the receipt to your server and your server should turn around and call verify receipt. So it calls verify receipt and when it does it passes the receipt and it passes the shared secret. The shared secret is one of these things you configure in iTunes Connect and here's a place where it actually gets used. Now what we're going to do is return one of these statuses.

Okay. So let's talk about why you'd want to call verify receipt. Initially after a buy, after a buy, you're going to want to call verify receipt. after a purchase, I should say. If you call this, this assures you that that purchase really happened. Your server doesn't know from Adam this thing that's coming in and sending it the receipt. It could be a receipt for a totally different app. It might be just a bunch of characters that have no meaning whatsoever. Is your server just going to take its word for it and provide service to whatever called? I don't think so.

So you call verify receipt, you can find out if it's really a receipt that's actually signed by the iTunes store, and furthermore, since you can get the properties of the receipt last, you can find out that it's actually for your app and not someone else's. So this is important. If everything is in good shape, we're going to turn green there. That's zero, active. But if there's something tampered with or something not right about that receipt, we'll return malformed. So that's why you want to call it initially after a purchase.

Now, in the time after the initial purchase, you're still going to want to call verify receipt because this is how you're going to learn about renewal on an expired receipt if that's all you have on your server. This is how you can find out about cancellation immediately after someone -- basically, you can have a receipt that hasn't expired yet, but if you call verify receipt, say, every day or every month or whatever, you can find out about cancellations more promptly and maybe terminate service if that's your business model. Also, if it's active, you're going to get the latest receipt.

You don't actually have to wait for the client to send it to you for you to get the latest receipt. You can actually find out for yourself on the server. And finally, we're always going to give you the last good receipt. So you can find out for yourself on the server. And finally, we're always going to give you the last good receipt.

And finally, we're always going to give you the last good receipt. And finally, we're always going to give you the last good receipt. And this could be useful because even if it's expired, you're going to get info about that last good receipt. And if you know when something lapsed, that helps you compute a meaningful maybe grace period.

Okay, so let's go back to this diagram here. Let's say we've returned status zero for success because everything worked. And now that our server is completely satisfied that this purchase is in order, your server is satisfied, your phone is satisfied, now is the time to finish the transaction.

So, we still don't have any content yet. So, let's see about getting that. So, we call get content and this is something you might call right after the purchase or this might be something you call in the hours and weeks and days after that initial purchase. The point is after the purchase, your clients are going to be coming in and asking for content. Now, when they do so, they should probably just present the receipt.

They could present the original transaction ID and we go through this whole cycle of, you know, verifying the receipt again and all that. But the point is you come back after you finish the transaction and over the space of the life of the subscription, you're going to be calling get content in some way or another. So, in this case, there's like this new issue of a magazine.

It gets returned to your phone in that case. In this situation, we have paid with the iTunes store. You verified that the payment is all in order with your server calling ours for verified receipt. Once you know you're in a position to fulfill the customer's purchase, you finish the transaction so that gets out of the queue. And then finally, over the course of the days and months, you've delivered some content.

All right. Now, for this renewal example, I want to just pretend that someone actually would put their phone in a drawer when they went on vacation. So the phone is not on. The app isn't running. But meanwhile, the iTunes store is running and we're renewing this thing. So maybe a month goes by and another month goes by and we've got two renewals sitting out there. So what happens when the user comes back from vacation? They come back, they fire up their phone, they go to your app. Right now, the app just has one issue of the app. issue of a magazine and it's got one receipt.

Well, StoreKit is going to recognize that there's some outstanding transactions for this user and it is just going to go get those transactions and pull them down. So now your phone knows about these three receipts, but it doesn't have any content yet. So once you do that, whenever your app wakes up and it finds these transactions, just like you would do after a buy or purchase, you're going to pass that content to unlock anything associated with it. In this case, we're passing two receipts down to your server. We're going to verify those receipts just like we did after the original purchase, make sure nothing got canceled, and so on.

And finish the transaction once we're satisfied, once our server has told us, yes, I've processed these receipts, everything's in good order, go ahead and finish the transaction. So you do. And now when you get content by maybe presenting the receipt again and going through the whole verify cycle, well, it turns out there were two issues of a magazine that this user was entitled to because of the two previous purchases that had happened while they were out. So we return that to the user.

Okay, so we have renewed on the iTunes Store. A few weeks go by. The app, when it wakes up, is going to discover this content. That content, the proof of those purchases have been sent to our server, sent to your server. You verify them. Once all that has been acknowledged, we finish the transactions in the iTunes Store. And as it turns out, we've delivered some content. It turns out, you know, two issues of a magazine.

Okay. Now, for Restore All, this isn't new for auto renewables. You'd want to do it for other kinds of in-apps, too, like non-consumables. The thing that's unique about Restore All for auto renewables is the fact that you're not going to get just one receipt back. You're not going to get the first one. You're not going to get the last one. You're going to get all of them. So if you have 24 months of a monthly, when you call Restore All, that user is going to get 24 receipts back.

Now, why do you want to do this? The most obvious reason is because, well, devices can get wiped out. Apps can get deleted. You want to be able to allow users to get, you know, their service re-enabled or get the lost content. Now, another thing you think you should be aware of with Restore All is what happens with multiple devices. So you have this phone, and you've bought the app, and you've got the receipt on it. Great. Now, you get another phone. You do a Restore All.

Something happened when that Restore All happened in the iTunes Store. Not only did it get restored, iTunes Store now knows about both of these devices. That means when a renewal happens, we actually put a transaction back in the iTunes Store. So you can see the transaction in the queues of both devices.

And if a third device comes along, you can restore on that. Notice in this case two receipts came down instead of one. When renews happen, there's going to be transactions in the queues for all those devices. So this way, it's sort of like auto-download for in-apps with auto-renewables, just so you know that's going on. So some things about the sandbox.

Now, one last thing about the Sandbox I want to talk about is some app review considerations. This happens to everybody who uses auto renewables. It's a tricky thing and the best way for me to explain it is first to talk about the development environment, then the production environment, and then the hybrid environment that is app review. So in development, you have a dev-signed app. Dev-signed apps are hardwired into talking to the iTunes Store Sandbox.

Now, dev-signed apps are also hardwired to probably talking to your test server. Of course, test servers are going to want to talk to the iTunes Store in test. So it's test, test, test. And that all makes sense. Now, you go into production and it's the same deal except it's a production-signed app. Production-signed apps talk to production iTunes Store. Production-signed apps talk to your production server. Production servers verify receipts against the production iTunes Store. And this is all consistent. Production, production, production.

Okay. But in app review, you have this hybrid deal. You have a production-signed app, okay, but it just thinks it's talking to production iTunes Store, but it's not. It's talking to the Sandbox. But your production-signed app is hardwired to talking to your production server. So you have this situation where you have your server having to, in one case, talk to production iTunes Store, and in another case, talk to Sandbox.

Okay. So what can you do about this? There's several different strategies. I'm just going to mention two. One I call the smart production server. In this case, what you do is you pass to your server the version ID of your app. And hopefully your server is aware of what's in production and what isn't. And if it sees like a 2.0 and it knows the highest version that is actually in production is 1.5, it can discriminate and send the verify receipt request to the right place.

But I think a more bulletproof and probably higher performance way to go is the reactive production server. So in this case, your production server always talks to iTunes Store production first, and 99.9% of the time, that's going to be the right thing. But once in a blue moon, the next version of your app will be reviewed in app review.

So that production server will get one of these Sandbox receipts. When it does, we're going to return status 21007, that's Sandbox receipt received in production. And that's your signal to go off and, okay, that's not -- this is a Sandbox receipt. Someone's doing some app review. I'll just go and talk to iTunes Sandbox to handle this receipt.

All right, so using non-auto-renewing subscriptions. This subscription name so poorly I gave it a new name. So here's what it's about. Basically, these kinds of subscriptions are a kind of consumable. You can buy them again and again, which is what you want with something that's a subscription. You want to have the same thing. You can buy it again and again. That rules out non-consumables. So it's a kind of consumable. All purchases happen interactively in the app.

There's no background purchasing with this sort of thing. So it's all upfront purchasing. You're in the app doing the renewals. So those sound like downsides. And maybe they are. But the reasons you'd want to use this are you do theoretically have more control over the situation. And so do your users. So that's nice. But bottom line is not all apps are going to be allowed to use auto-renewing subscriptions. So this is what you have to work with.

So what are some strategies you can use for something like this? There's several. I'm going to talk about one in some detail and touch on another one. But one of the things I'm going to talk about is the fact that you can use auto-renewing subscriptions. One strategy is iCloud strategy. So the idea here is that you save the purchased receipts in iCloud.

Being consumables, these receipts can't be restored on demand from the iTunes store once they're finished. That's why you have to save them someplace. And iCloud is a pretty convenient place to put them. Basically, you can access these receipts if they're saved in iCloud from any device. So it kind of handles some restore scenarios.

There's no extra registration step for iCloud. I mean, users are registered by the time they turn on their phone, if it's iOS 5 or higher. So that's nice. Now, regardless of where these receipts are stored, you need to, you know, test if something has expired or not in the app.

So how can you do that on something where the receipt that you have doesn't have an expiration date? Well, fortunately for you, there's no opt-ins and there's no trials. So you actually can take the purchase date, combine that with your product ID from which you can derive the duration and you can figure, you know, what your expiration date is and do some expiration testing when people are using your app. So let's just kind of diagram this out and look at how it might work. All right. So you've got your app and you buy one of these consumable-like products. You get a receipt back for it.

You And the very first thing you do is you store this in iCloud. So once your app stores it in iCloud and your app knows it's successfully stored in iCloud, then and only then do you finish the transaction. Okay, because once that transaction is finished, it's gone. It's gone from the queue.

And you want to finish the transaction because if you don't, that transaction will hang around in your queue and every time a user goes to their app, they're going to be prompted to log in to get it. So you need to finish it, but you just need to finish it at the right time.

All right. So you've got that receipt. Now you just unlock service pretty much like we did in the first example. So receipt gets passed to your server. You verify that it's actually a legitimate receipt from the iTunes store and you can unlock service. So the user is paid. You've persisted the thing someplace, in this case iCloud.

Once you know you've successfully persisted it, you've acknowledged that with the iTunes store by finishing the transaction and then finally you've flipped on service when you told your server about that purchase. Now, the renewal is manual. It all happens in the front. So what is that like? Your phone wakes up. Every time it launches, it should check for receipts, in this case in iCloud. It gets the receipt.

It checks for expiry. Now, you know, 99% of the time when it checks for expiry, nothing's expired. But eventually it's going to be expired. And when it does, you can present the buy button to the customer and ask them, hey, do you want to renew your subscription now? If they agree, they click buy. You buy the consumable again. You get another receipt. This is receipt number two. Store that. Once you're sure that's stored, finish the transaction and then you unlock service. Just like we did in the previous case. Pass the new receipt, verify it, and you're back in business.

All right. So we've queried for status by looking at our stored receipts in iCloud. We know the purchase date of all those receipts and we have the product ID in all those receipts. So we know when each of them expired. And if things have expired, well, we're going to let the user buy again. We'll persist that new receipt. We'll acknowledge that by finishing the transaction and then we'll extend service.

Okay, so in this restore example, we've got a phone that has just been wiped. Okay, so it's completely empty. It's just like in the previous example. There's really no difference. As long as your app is always set up to always get receipts from iCloud first, this app is going to discover, oh, look, I've got two purchases. It's going to pull those down and unlock service.

and verify the receipts just like before and you're back in business here. So we can query status just like we did in the previous example. We verified with the iTunes store when we verified the receipt and we've enabled service. Now that all sounds great except there is this one downside.

And I don't know how common this is and maybe it's not a big deal but it's just a problem. So you've got this phone. It's your phone. You're still you. You've not logged out of it at all as far as the iTunes store is concerned. But maybe you log out of iCloud.

I don't know why but maybe you do. If you do, you log out. Log in as a different user. Those receipts have essentially disappeared from this app. This app is going to look for those receipts. It's not going to find anything. So, you know, status is queried. No receipts. No service.

So what can you do about this? This is a totally optional strategy, I just want to stress, but you could register the user. I mean, it basically could be an account registration step. The idea here is you ask the user to register before they purchase, after they purchase, but before you finish the transaction, you need to do two things.

You need to take that receipt and that account they just created, you need to pass them in one transaction to your server, make sure that receipt is saved, make sure you've associated it with that registered account, return success, and only when you've returned success that your servers accomplish this, that you finish the transaction. And now moving forward, you consult your server for receipt restoration instead of iCloud. You consult your server for this expiration testing instead of iCloud. So the basic responsibilities are you need to associate receipts with a user.

And iCloud kind of does that automatically, so that's nice, so that's easy. But if you don't want to use that, you need to do it yourself and you need to ask the user to register, which is a little more work for both you and your user. You need to persist the receipts.

You can either use iCloud storage in the previous example or your own server in the second example. But no matter where they're stored, you need to provide a way for users to get at those receipts so they can do restore-alls and get their content back or their service back regardless of which device they're on.

Okay, so let me just talk about up everything I talked about in this little section. We talked about the subscription life cycle. I wanted you to know what happened when, the kinds of checks we do, the kinds of emails we send and why we send them and when we send them.

I wanted you to have a better idea of the kinds of things which are important in a receipt for auto renewables and how those receipts fly around between all the different parties, your app, store, your servers. We've talked about some limitations and considerations in the sandbox. And finally, we've talked about some approaches for using non-auto renewables. For talking about customer experience, here's Aubrey talking more about iTunes Connect.

Thanks, Dave. So, we have a bunch of different ways that you have an opportunity to interface with your customers. And Dave talked a little bit about all of these different email confirmations that go out throughout the subscription life cycle. So, I'm going to step through some areas of iTunes Connect and show you exactly the impact that what you enter in iTunes Connect will have in these email confirmations.

I'm also going to cover just basic device UI. So all of the UI that is generated for your customer, you might be wondering how the information you're entering in ITC is actually showing up to that customer. We get these questions a lot and we just want to make it really clear for you.

So if you're currently selling on the App Store, you're all using iTunes Connect. And I'm going to cover three different areas of iTunes Connect that relate to your customer's experience. The first is going to be metadata. Second, pricing. And third, availability. So let's talk about metadata. Now, what is metadata? Well, it's just information that you're entering. We know that iTunes Connect is the gateway to the App Store and everything that we collect from you in iTunes Connect ultimately will display in the App Store with the exception of a couple pieces of information that are facing just for you for reporting, et cetera.

So let's talk about the most important piece of metadata that you will enter in iTunes Connect when it comes to your subscriptions. That's the In-App Purchas display name. And if you take one thing away from this session today, it's that this needs to be right. And that really is because this shows up in the most areas for your customer.

And I think you'll be surprised to see all the different places this will show. Imagine if you spelled it wrong. Probably wouldn't be a great thing for your customer. And this is why we call this your subscription brand. It's your opportunity to brand your In-App Purchas to name it correctly to describe exactly what you're offering to your customer.

It's entered right here in iTunes Connect. And you do have an opportunity here to think globally. We offer 28 different languages for localization in iTunes Connect. And we really want to encourage you to take advantage of that because it's a great experience for the customer. We base all of these settings on the customer's iOS language or OS language. So we will make a smart decision about what translation of your In-App Purchas display name will show up to them. So we want you to take advantage of it. The most successful developers are the ones that are localizing and moving globally.

Now, first example, we're going to go through my New Yorker subscription. So In-App Purchase display name shows right there in the subject line of the email and in the body of the email. And this is that subscription confirmation that goes out immediately after a purchase. We also show you display name in the receipt. and in the price increase notification that goes out in the subject line and in the email itself. And I'll talk a little bit more about these price increase emails later when we talk about pricing.

Also, your auto renewal reminder, so when the customer gets that nice reminder email letting them know they have something renewing soon, again, right there in the renewal. In the Manage Subscriptions UI, title bar of the iPhone and in the Manage Subscriptions, every time they go visit this area of the App Store, they will see your display name. and if not the most important dialogue, the gateway to get them to purchase your subscription. Right there in the UI, you'll see the display name.

And now after you're live on the store, you're doing pretty well on your app product page. There it is again. You also have the ability to customize this using SK Product Class and StoreKit so you can pull in the display name that you enter in iTunes Connect to display right in the UI. You can also take advantage of the pricing. You can pull that in and the description.

So we like to show examples of what not to do. And we really don't want you to name your In-App Purchasse subscription because subscribe to the subscription looks a little weird and probably is not going to lead to a lot of subscriptions. So keep that in mind. Another thing, don't encode the duration of the subscription into the name. Subscribe to one year subscription for one year. It's a little redundant. And we have seen this, by the way. So keep that in mind. And moving on to the second piece of metadata I want to cover, publication name.

Now, this is an opportunity to take advantage of the marketing opt-in that Dave talked about. And we wanted to give you some flexibility about displaying a different piece of metadata just for this information. So this is another opportunity to brand yourself as a publication. Maybe you're not specifically a publication, but you can still use this to have that pop-up in the UI.

Now, it's entered in iTunes Connect just like the display name. And this is actually new for 2012. And this was a direct request from developers. They wanted more flexibility to be able to enter a different piece of data. It's another opportunity to localize. Take advantage of this. 28 languages worldwide.

And to show you exactly where this shows up, we have House and Garden here. House and Garden wants me to share my personal information. Well, that's a big decision for me as a customer, so I want to know exactly who I'm sharing that information with. Putting in your developer name is not a great strategy, so we want to recommend that you always think about what the publication name is going to be because it's going to lead to that really valuable piece of information that you're going to have in your opt-in reports.

Privacy Policy URL and Support URL, another piece of metadata. Entered for your apps in iTunes Connect. The Privacy Policy URL is required for free subscription. It's also required for auto-renewable subscriptions, so we will ask for this. And we do display these, both the support URL and the privacy policy URL in the email confirmation.

We display the support URLs all over the App Store. As a marketplace for you, we want to make sure that we're putting your customers in front of you to get the help and offer the feedback about your apps. So it's really critical to get this URL right. Make sure that it sends the customer somewhere to where they can actually reach you to get the support.

You'd be surprised at how many of the reviews we see on the store from customers that are dissatisfied with not hearing from the developer if they're trying to reach out to them through the support URL. And if the support URL is dead, it's likely going to get you an unhappy rejection from App Review. So keep that in mind, too.

The last piece of metadata I want to cover is product IDs. Also very important for your code, best practice we want to recommend here is entering the duration into your product ID. This is great for the non-auto renewing because then you'll be able to identify what the duration is. And your reports for each transaction in your sales and trend reports and in your payment financial reports are going to reflect the product ID. So it's really convenient if you actually have the duration encoded right there in the product ID.

So let's move on to pricing. Great thing about the App Store is that you have the ability to price freely and accordingly based on the content you upload at the app level and at the In-App Purchas level. You can change this at any time in iTunes Connect and it is live immediately in the App Store to your customer.

So looking at the price increase notification that goes out, Dave described how and when we send this. But I wanted to sort of zoom in here on the area where we show the before price and the after price that will go out to the customer. We want you to be aware of how this functions, because if you do go in and you do change pricing, we do recommend that you understand how this is going to affect the customer. It's not going to immediately necessarily blast out your customer base, but we want you to know that it will disable the auto renew.

So you can see here for my New Yorker, they raised the price on me during my subscription, and they want me to go ahead and opt in again at the higher price. So you can see on the right, we have the manage subscriptions UI again, and I have to voluntarily opt in.

And you can run sales in iTunes Connect. You can set pricing in advance. You can set your In-App price. Maybe you want to run a specific sale on a specific date. And we encourage you to do this. Just be very aware of how it's going to affect your end user. And just something to note, price decreases don't send out notifications to your user. It's just kind of an added perk for the customer to get the auto renew at the lower price.

And last but not least, we have availability. Cleared for Sale. Kind of want to demystify what that cleared for sale button does in iTunes Connect. We get the what does this do question quite a lot. And it's just a radio button, yes or no, set for every In-App Purchas in iTunes Connect.

And just to kind of highlight what happens when you do set this to no, I wanted to walk through all these available actions for you. So a new purchase for a customer. We require that the In-App Purchas is cleared for sale in order for new customers to purchase the In-App Purchas.

If it's not cleared for sale, then they cannot purchase it. You as a developer can deliver content regardless of the setting. So it doesn't matter if it's clear for sale or not. We want to allow you to take care of your existing customers that already have your content on their device.

Restore. You can restore content regardless of the setting. And the auto renew setting will be disabled if it's not cleared for sale. So you should kind of keep that in mind when you are messing with this. It tends to be sort of a mystery. So we wanted to just make that a little bit more clear.

And none of those settings actually apply for Sandbox, so you don't have to worry about that. You can set something to not clear for sale and actually have it return in Sandbox for you. Now, if you come to a time where you need to discontinue a subscription, we want to make sure that you know that this is possible, but we do want you to honor all of your existing customers that are expecting content from you.

Again, better customer experience. If I've subscribed to something for one year and maybe you as a developer are no longer going to offer that subscription for additional customers, I want to make sure that as a customer I receive that content for a year. So please remember that you do need to honor that agreement you've made with the customer.

But the best advice we can give if you need to discontinue a subscription is remove the In-App Purchas from sale first and then delete it out of iTunes Connect. You no longer need to see it, just tends to get confusing and you can delete it. And like the price increase email notification, we will send a notification to let the customer know that the subscription was actually discontinued. We want to present them with the option to go in and subscribe to any new duration you might have available.

So to summarize best practices, remember, these are your customers. We're very happy to provide this amazing marketplace and we're so excited that you're there to develop apps for us in the store. But these are your customers. Take care of them. The great thing about subscription is that it is long term. You're establishing that relationship with them because they're going to keep coming back. They're going to want to get more content. They're going to auto renew. It's a great relationship between the customer and developer.

And think global. We are moving very fast globally and we just announced this week that we're going to be moving into more app stores worldwide and we want you to come with us on that journey. We really give you a lot of tools to localize your content and we think that's really, really important.

So for more information, please contact our wonderful app services evangelist, Paul Marcos. Documentation that we recommend you check out. In-App Purchasse programming guide is a really great resource, covers a lot of the information you've seen today. And then our iTunes Connect developer guide, it's really great, includes all the setup step by step for you.

Getting started with In-App Purchasse, great resource for links and developer forums. Get help from your fellow developers. Some related sessions we had yesterday, the selling products with StoreKit, great session. We had the building great newsstand apps a little bit earlier today. If you're a newsstand developer, check that out on video. And then what's new in iTunes Connect for app developers took place this morning.