Hi, everybody. My name's 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, you may be asking. 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. 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.

Okay. So I'm going to cover four main areas here. An intro to auto renewables. And in this I'm going to be talking about the life cycle of these things, the timeline, some things which aren't in the APIs but happen from a business perspective and a developer perspective. Then I'm going to talk about receipts, specifically what's in the receipt, and then how those receipts are used in interactions between your app, the iTunes store, and your server.

And then I'll talk about some sandbox considerations with auto renewables. And then finally, we'll talk about non-auto renewing subscriptions, which are also known as the non-renewing subscription, which is an interesting name. Okay. Now, for folks out there who are maybe new to using auto renewables or want to, there are three areas that are pretty good examples of where you can see this in the store today. A stream of daily original content like the Daily or a newspaper like the New York Times. On demand all you can get access. like a video streaming service or an audio streaming service, something like that. And then finally, of course, magazine subscriptions.

into this stuff. 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. They're 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 and that you can buy the same one over and over again.

There's durations that range from a week out to a year. Most people probably do use a month. There's some management features associated with these, and there aren't for any of the other in-apps. For example, you can go into iTunes on Windows or on a Mac, or you can go into Settings on iOS, and you can find all of your subscriptions that you as a customer subscribe to, and you can manage how they renew. And then there's a bunch of e-mails associated with these.

I'm not going to go into the details of the bodies of them, but just sort of the kinds and when some of them get sent. And then finally there's two features, marketing opt-in and free trials, which affect the timeline. So I'm going to talk about these two things a little bit so you know what they are. Then I'm going to tell you how they affect the life cycle of a subscription, because some things aren't maybe as clear as they could be. So first, marketing opt-in. It's all about personal data sharing. It's not allowed for all apps, so even though you see it in a sandbox perhaps when you're developing doesn't mean it will actually be turned on for you in production. And there's an optional, not required, but optional bonus time incentive if it does turn out to be enabled for your app.

In the example here, and I apologize for the small type of the non-retina graphics there, but it talks about sharing your information with Motor Trend. This is actually on a subscription I subscribed to myself when I got this. And it also has on there your subscription will be extended by three months if you choose to share your information. So if I click allow, then I'll get that extra time. But what does that extra time mean? So we'll talk about that in just a sec.

Now there's free trials. This is a new feature for 2012. Today it's only allowed for newsstand apps. The period, just like the bonus time, is configurable in iTunes Connect. Auto renew from a business standpoint is enabled by default. So when a user clicks confirm on this dialogue without them doing anything, at the end of the trial period, we will renew and in this case charge the customer $19.99 after the two-month trial is up. And from a developer perspective, a trial period is just like any other period. It just happens to be free and it happens to be the same or shorter length than the thing you're actually subscribing to. It's going to have a receipt. It's going to be restorable.

It works. So let's just talk about a typical life cycle. And I just want to stress one thing about this, even though this is all very simple. You purchase, it expires, it auto-renews, daughter renews. Now, what we do here in the iTunes store is we do prepaid, okay? You basically purchase up front, you get some service, and then it's up to you to purchase up front again, and automatically we do that purchase up front for you. This isn't like a postpaid phone plan. This is like a prepaid phone plan. So just so you know that. Now how does that timeline get affected when you have one of these bonus times? This is an example of what it looks like when you have this opt-in bonus time added on.

What we do is we add the bonus time to the first period. We don't add it to all the periods, just the first one. In this case, it gets bumped out by three months. So instead of expiring in a year, this one's going to expire in a year and three months. Now, if you have a free trial and only a free trial, then it would look something like this in our example. This is a two-month free trial. We have an initial purchase cost zero, and it's just going to end a little bit earlier than it otherwise would have, in this case in two months. Now if you have both of them, you have something that looks like this. We have an initial period that's two months, and we're going to jack it up by three months because that's what we do. The bonus time only applies to that initial period. So in this case, that initial period is five months, and the user's first payment will be five months after they click to confirm.

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 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.

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 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 e-mail 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 declined. 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 e-mail 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 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 the -- if 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, they got that other dialogue which says, hey, you're already subscribed. 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.

So we'll talk about receipts. And to talk about that, I first want to talk about what's in them. There's a lot of things in these things. There's just a few things, though, which are specific for auto-renewing, or at least important for auto-renewing. The most important, probably, is the expire date. This is unique for auto-renewables. It's not in any of the receipts for any of the other things. All the other things are basically common across all the in-apps.

Now, there's a couple new -- not new features, but the original transaction ID and the purchase date, They exist in other receipts, but they carry new importance for auto renewables. So about these things. Obviously the expires date is how you know when something expires. Now, you might think, well, I know the purchase date. I've got the duration. That tells me when something expires. Well, it really doesn't. As we saw in that previous timeline example, the fact that you subscribe to a yearly subscription, if someone has bonus time or trials or combinations, the expiration date can be very different than you might think based on the purchase date and the duration. So the next thing is that expires date less that purchase date, that is your signal to describe what that receipt represents in terms of the user's entitlement to content like magazines.

And also, the original transaction ID, that is something that is important because it's consistent across every single receipt. It doesn't matter how many renews happen. It doesn't matter how many times those renewals are restored. The original transaction ID is constant across it. So it's kind of like your closest thing that you have to a customer ID for this user. Anyway, there's a couple other new things in the receipt that are on this guy. This is the Web Order Line Item ID. And at the bottom there, the cancellation date.

Now, the cancellation date is what happens when this particular subscription purchase gets refunded. It's basically how an active-looking subscription could appear inactive. If you've ever seen something in production, maybe you've passed a receipt to our verification servers, it's not going to expire for months, and we come back with a status which says it's inactive, and you might be scratching your head, what is going on there? This will hopefully help demystify some of that. The other thing about this date where it might be useful from a business standpoint is that, again, if you're in the magazine business, if someone has canceled a purchase, you know, maybe you don't want to continue restoring content for that particular purchase event. Now, this last one, the Web Order Line Item ID, It's basically your invoice number. We really never had a good version of this. We didn't have something for this role that was very good until this got added. Your best alternative before this was added was the purchase date. And purchase dates don't make very good IDs represent something atomically. So this is an improvement there.

Hopefully it will make your development a bit easier. Now, some folks might be tempted to look at the transaction ID and think, oh, well, I'll just use that to represent the purchase events. The problem with that is, while, yes, it changes every time something renews, when you restore on different devices or on the same device, that transaction ID will change every time. It literally is a transaction ID. For every transaction, it changes. So it's not suitable for what this ID is for.

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, you know, March 31st. So why does that matter? Well, the customer, they're looking at their calendar. They see the first.

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, you know, 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 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? You know, 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 passed, 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'd 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. 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 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'll 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've verified that the payment is all in order with your server calling ours for verify 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 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. They've been 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, but 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, 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 in the queues of both devices. And if a third device comes along and you restore on that, you 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.

What can you do in this thing? Well, of course you can make in-app purchases. We'll do renewal purchases for you. We're going to allow you to restore transactions, verify receipts. You can resume an expired subscription, and you can resume with different durations and create some complex purchase histories.

One thing which enables this are actually two things. It's about the subscription timing, at least for part of the things that you can do that you otherwise might think you might not be able to do. We renew these things really quick. As you can see, seven days last three minutes in the sandbox. One month lasts five minutes. One year lasts 60 minutes. So these things renew pretty quick.

Now, we're going to cap these renewals at 6:00 because we don't want this stuff just spinning out of control with millions and billions of renewals going on. But it also serves a very practical purpose, as I'll get to in a second. Now, about this cap, about us stopping renewals on a subscription after 6:00, it's not a hard cap, okay? After eight hours, if you interactively buy that subscription again in your app, you're going to get another six renewals. So you don't have to keep creating accounts to just keep retesting odd renewables. You can use maybe one, maybe a family of accounts and rotate through them.

And you always have one account, the next one you use maybe has some renewals ready for it. So what's not available in the sandbox, there's no management UI. So you do not have access to the same UI that your customers would. You can't go into iTunes and manage your subscription. So that's a downside. There's no e-mail sent. There's no spamming in the sandbox. And there's no billing failure. But we have that renewal cap. And that renewal cap is actually key. That is how the subscription becomes inactive. And as I showed earlier, when a subscription becomes inactive, that's when you can go and buy something else inside your app. So maybe you can't use iTunes on your desktop to manage your subscription, but you can use your app to manage your subscription because you can choose a different duration to renew with. You can choose how long to wait before you renew. You can have these active, inactive, active with a different duration. You can basically model any kind of complex purchase history you want.

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. And 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 thinks it's talking to production iTunes It's not. It's talking to the sandbox. But your production-signed app is hard-wired to talk into your production server. So you have this situation where you have your server having to, in one case, talk to a production iTunes store, 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 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, And 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, 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 is 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 where you're in the app, you know, doing the renewals. So those sound like downsides. And, you know, 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 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 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.

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 a 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, you know, 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 accomplish this, then 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 e-mails 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 these different email confirmations that go out throughout the subscription lifecycle. 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 purchase 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 purchase, 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 purchase 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 purchase subscription, because subscribe to the subscription looks a little weird. And it 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 purchase 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 gonna affect the customer. It's not gonna 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 managed 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 purchase 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 purchase is cleared for sale in order for new customers to purchase the in-app purchase. 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 this 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 subscribe 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 purchase from sale first, and then delete it out of iTunes Connect. You no longer need to see it. 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 purchase 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 purchase, great resource for links and developer forums. Get help from your fellow developers. Thank you. 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.