Good morning, everybody. I'm David Duncan with the iAd Group, and we're going to talk about iAd Implementation Best Practices. So just going to go over quickly first, what is an iAd? I'm sure a lot of you have seen them, but for those that haven't, we're just going to go quickly on what iAd is and what is the experience that your customers are going to see when they actually launch an iAd. After that, we're going to spend a little time talking about some mobile advertising 101, just all those terms that you'll see in the portal on your reports so that you'll understand exactly what we're telling you has been going on in your application with respect to ads.

Once we've gotten that done, we're going to go ahead and jump into the nitty-gritty of actually integrating iAd into your application, configuring your application in the portal so that you'll get iAds when you actually ship to the App Store, as well as adding banners or interstitials to your application so that users will actually see those ads. And finally, a few best practices, things that you should keep in mind when working with iAd and just with iOS in general.

So with that, let's go ahead and take a look at what is an iAd. iAd is just a really great ad experience using all those technologies and features of iOS that you take advantage of in your application in these really great iAds, like the inline video, gyroscope and accelerometer, in-ad downloads. You can get ads that actually download applications and songs and all those things to your users' devices. And it integrates really nicely with your application. It's this beautiful banner with this beautiful content that just flows great and is worthy of your application.

It's self-contained, which means that you don't have to add anything aside from a framework that already exists on iOS to your application. And the greatest part is when a user goes into an iAd, they stay in your application. There's no exiting to anything. They come right back when they're done and continue on with the experience inside of your application. These are really well-known brands, things like BMW and Nissan and Target, things your users are already familiar with, things that they're willing to take a look at and go in, which means that you're going to see the advertising revenue from them actually going and exploring these ads.

And we're always expanding. We're always looking to go further. We're in all these countries, and we're expected to get into Japan sometime this year. And so you'll be seeing ads in more places all the time. And finally, we take care of all those privacy concerns. With a lot of the other groups, you have to go ahead and collect things from the device so that you can identify what that device is. You don't have to worry about that with iAd. It's taken care of for you, and users will appreciate the enhanced privacy that iAd has to offer.

And finally, it's really easy to implement. You put one of these banners and integrate them into your application, and you start receiving ads. And of course, the thing that you're all interested in, you get ad revenue. 60% of the revenue that we get is your cut. So once you start putting these banners in, you'll start seeing that cut of the revenue. And so with that, a few advertising terms.

So the first thing that you should be aware of is requests. And requests are a really simple concept. When you go ahead and you create your iAd banner, then it'll start making requests in the network. And that's basically saying, please give me an advertisement to show. And when you get a successful request and you get an advertisement, Then you'll see that beautiful ad pop in. You just move the banner on screen and you get what's known as an impression. What an impression means is that you've displayed the banner to the user and there's been enough time that's gone by for the user to actually have seen the banner. So that's the impression.

And once you know what requests and impressions are, we can start looking at fill rate. So every time you make a request, we'll try to get a banner. Sometimes we might not succeed, and so we want you to hide the banner. But as long as you succeed and you display the banner, you get that impression, and you get what's the fill rate. And so all that is is impressions divided by requests. And so in our little example here, we made three requests and got two impressions, so we had a 66% fill rate. It's really that simple.

Similarly, there's the term click and click-through rate. And those are very similar when the user taps on a banner and starts engaging with the ad. So they're manipulating it, they're tapping on controls. They're actually inside the ad. You get what is known in advertising terms as a click.

Obviously, we're on a mobile device, so everything's taps, but the advertising term is a click. Now the click-through rate is, again, just the ratio between those clicks and those impressions. So in our example, we had a 50% click-through rate because we only made a click. 'cause we only made two impressions and only got one clip.

So what is it that advertisers are actually after? Well, as we said, they want those eyeballs, those impressions. They want people to see their banners, and they want people to know that their brand exists. But even more so, they want people to actually engage with those banners. So while impressions are great, clicks are better. When users actually tap on the banner and engage with the content, that's a lot better for them. And advertisers are willing to pay for that.

They're far more willing to pay for people to actually tap on those banners and engage with the ad than just for impressions. But together, those give you revenue. And a statistic that you can use to track the performance of ads in your application is just called ECPM. And we'll discuss that a little more in a moment.

So what kind of advertisements are actually provided by the iAd Network? Well, as we discussed earlier, brands, all those Targets and BMWs and Nissans, those are the brand advertisements. They're those gorgeous ads that you see that tout the features of the latest Nissan Leaf or whatever else is going on in there.

You also have the developer campaigns. These are when you decide you want to advertise your application with iAd, and you're able to say, "I want to spend this much money," and your banners will start appearing with iTunes links so that users can download your application right from the ad.

Now, brand advertisements, they pay for both impressions and clicks. So those advertisers are willing to pay for every eyeball that sees their banner, as well as every time those users tap on the banner and engage with the full ad. Developer advertisers only pay for clicks. Since these are typically from developers, they only really want to pay for when users actually engage with the banner and are interested in downloading those applications. And again, you get 60% of the revenue. So 60% is what you get is for you.

Now we mentioned eCPM earlier, and that's really just a way to determine the performance of advertisements in your application. Now the formula is there, but what that really means is how much money you're expected to make, how much total revenue you're expected to get per 1,000 impressions. So 1,000 impressions comes in, you make that much money, that's the eCPM.

Now, we've always had some common questions when working with the iAd Network, such as what affects the requests that are actually made from your application? Well, the first thing, of course, is just how many customers you have. The more customers you have, the more people that are actually launching and using your application, the more requests are going to be made.

Similarly, banner placement can have a really important effect on how many requests you make. For example, if you only put your banner on some introductory screen and never show it anywhere else in the application, you're going to make a lot fewer requests than if you have that same banner placed on the most active part of your application. So it's really important to think about where you're going to place the banner in your application so that you can get those requests as opposed to just making a few requests when the user first launches it and never seeing any more afterwards.

And finally, time spent in the application. If a user launches your application once a week and only spends a minute or two in it, you're going to make fewer requests than someone that launches that app daily, multiple times a day, for longer periods of time. So if your application-- the more time people spend in your application, the more requests you're going to make, and thus, the more requests you're going to make on the network.

These next two questions, however, are kind of the same thing. Recall that our definition of fill rate is just the number of impressions you got per request. So when you ask what affects my impressions and what affects my fill rates, it's really the same kind of thing because it's all coming back to those impressions.

David Duncan Well, what does have effect on that? Again, banner placement can have a huge effect on the number of impressions you get. If the banner doesn't actually get shown to the user, as we showed before, you're not going to get an impression. So you need to make sure that whenever there's an ad available, you want to show it as soon as possible.

Similarly, the available advertisements for your application. Some applications will be compatible with more advertisements than others, and depending on what time of the year it is, there'll be more or fewer advertisements available. So the available advertisements also has a huge impact on both impressions and fill rate. And finally, your customer location. These are the places that we expect to be in by the end of 2011. But if your users aren't in one of these locations, then we don't have to serve ads there. And so you're not going to see any impressions no matter how many requests you make.

And finally, why does my fill rate vary? Well, advertising is implicitly seasonal. Advertisers want to advertise when your customers have money to spend. When do your customers have money to spend? Well, common time is right before the holiday season or right before back to school. It's at that point that advertisers want to spend the most money on advertising because they want to lock in those customers and get as much of their money as possible.

After they've spent their money, there's less interest in actually doing advertising because they know they're not going to get any more money. So, as the seasons change, as the time of the year changes, you're going to see your fill rate vary just because advertisers are going to want to spend more or less advertising money.

So in terms of your own application, what are the qualities of a successful application that actually use advertising? Well, One of the most important qualities is stability. If a user launches your application and it crashes, or they're using your application and something doesn't work quite right, they're going to use your application less, they're not going to get as much out of it, and more importantly, if they're in the middle of experiencing one of these great iAds and your application crashes, they're going to be pulled out of that ad.

So you really want to make sure that your app is as stable as possible, and we've got a session tomorrow morning improving the stability of your application that if you have any issues or any questions you want to ask of those engineers, I recommend you go over there and take a look at that session.

Next quality is your application itself should be engaging. Our iAds are highly engaging. People love to go in them and take a look and see what they can see. But your application should also be engaging. That means that they're going to spend more time, like we said earlier, and the more time they spend in your application, the more times they launch it a day, the more integrated it is in their own daily routine, the more ads you're going to request, the more ads that they're going to actually see, and the more money you're going to make.

And finally, even if you have that great engaging app and that really stable app, you really need to get the word out. You need to make sure that you have those loyal and active customers. These are the people that will take your app out at a dinner party, show it to all their friends, tell them how to get it, and just grow your application's network.

So you want to make sure that you can pull in as many of those loyal active users as you possibly can, because that'll mean that more people are running your app, you're making more requests, you're getting more ads, and you're making more money. more money. And so with that, let's switch over to actually the first part of implementation, configuring the iAd Network.

The first thing you want to do is go into iTunes Connect and make sure you accept the iAd contract. If you don't accept the contract, nothing else will actually be available to you. All you do is you request the contract, a PDF will pop up, and you sign a digital.

The next thing is you want to make sure that you properly configure the primary audience for your application. This is a hint to us as to what your application is targeting, what users there are, and what kind of ad content we should actually display in that application. You can either set it to yes or no, but be aware that if you set it to yes, that you are targeting those users that are under the age of 17, you cannot change it for that application.

In order to change it, you actually have to resubmit the application under a new bundle identifier and basically start over with your customer base. So make sure you set this correctly the first time. We want you to do this honestly, but we can't change it afterwards. So make sure that you set it correctly.

And finally, you want to enable iAds. This is what actually lets you get ads in your application once you've published to the App Store. If you haven't done that before submission, then you're going to have to resubmit. You're going to have to enable iAds, resubmit your application, go through iAd App Review again in order to get this enabled. So make sure you do it. I would recommend that as soon as you decide you're going to integrate iAd into your application, just go into the portal and do this.

So what will you see? Well, while you're developing your application, you're running it in the simulator, or you're running it on your own device with a development certificate, you're going to see test ads. And we intentionally vary the fill rate, because we want to make sure that you can test the case, both when you do and don't get an ad. So you'll see test ads. You won't see them all the time, but be aware that you'll only see them in your development.

Once you actually publish your app to the App Store, and your users and customers start downloading and using the app, they will always see live ads. So you don't have to worry about any kind of configuration for that. They'll get live ads. You're going to get test ads. And with that, we'll actually get into doing the code at iAd to your application.

The iAd framework provides two classes, the AD Banner View and the AD Interstitial Ad, to actually provide content and that from advertisers in your application. The iAd Banner View is this traditional small banner. You place it at the bottom of your UI, users can tap on it, and they'll go into a full ad when they do. We introduced this on iOS 4.0 and we brought out the iPad on iOS 4.2.

And it automatically cycles in new ads. Once you've created one of these, it'll make requests on the network periodically, get new ads, and all you have to do is listen to the delegate methods and display it. And for those delegate methods, that's the AD banner view delegate protocol. So that's how you communicate with the banner, and that's what those are. The other one, the iAd Interstitial ad, provides what we call full screen banners. These are basically like pages in a magazine.

We introduced this with iOS 4.3, and these are available on iPad only. They provide persistent content. What that means is that we'll go ahead and we'll fetch a banner, and if we're successful, that banner is in your application for a long period of time. You can use it, reuse it, and do a few special things with it. And similar to the banner view, it communicates with the interstitial ad delegate protocol. So how do we actually use these? And we'll start with the banner view.

The first thing, of course, is banner placement. Where are we going to put this in our UI? Well, you don't want to put it in the center. If you put it in the middle of your content, then your users are going to get frustrated, either because they want to work with your application and they're accidentally tapping on a banner that they're then going to have to close and you're not going to get any revenue for, or they're going to want to work with the banner and accidentally do something in your application that they're going to have to undo.

It basically is just a mess. Always make sure that you place it away from your content. We recommend at the bottom of your application. And of course, to accommodate both portrait and landscape UIs, the banner can be configured to one of two sizes for either portrait or landscape layouts.

Creating a banner is as easy as can be. You just alloc and edit. And you set the delegate. In this case, we've got a very simple application. It's just got one view controller, and it manages the whole UI. So we're just going to use that view controller to manage those same delegate protocols.

Now, when you actually do get content, we're going to send you a variety of messages so that you can react appropriately. New on iOS 5, the first message we're going to send is this banner view will load message. We only send that on 5, so if you're targeting earlier releases, you'll have to do something else.

But we added this particular method because a lot of our developers said, well, I want to display house ads or ads from another network while also using iAd, but iAd might take a little bit before it gets content to me. So this method is called as soon as possible after we get a response from the server saying, we've got an ad on the way, so if you want to display iAd, this is a great time to do so. We recommend that you lead with iAd, so if you get this message, we recommend that anything else that you want to display, you put it off and you go ahead and display your iAd.

But not just yet, because the next method that you'll get... is this banner view did load add. And what that means is that we've gone, we've gotten all that content from the server, we've prepared it, and it's ready to display to the user. Now is the time for you to add that banner to your UI. Animated in, it's displayed to the user, and you'll get that impression.

Now, we'll continue to make requests for new ads, and we might not be successful, in which case we'll send you this banner view did fail to receive ad with error method. That's your cue to pull the banner out of your UI and hide it so that the users don't see a blank space. That's all that is to handling those content events, those three methods.

Now the next thing is if you've got that portrait and landscape UI, you're going to want to make sure that you size the banner correctly for both. So in your will animate rotation interface orientation method, this is really all you have to do to make sure the banner is the correct size for either portrait, or landscape. Just make sure that you check what the new orientation is and set the banner's current contents identifier appropriately for either portrait or landscape. You then have to just go ahead and rearrange the rest of your UI as appropriate and the banner view will integrate nicely.

So as we've said earlier, we're all interested in users actually tapping on that banner and interacting with it. So how do you know when that's happened? Well, when the user taps on the banner, we'll send you this action should begin method. And that's your cue to make your application as amenable to that ad unit popping up for the user to interact with. And what does that mean? Well, very shortly, a view controller is going to be presented over your application. So you should make sure that you reduce your memory usage. Anything that you're doing in the background, you want to settle it down.

Any network access you're doing, you probably want to stop it or pause it. And you just want to make sure that your application is doing as little as possible because you want the user to have as great an experience in that iAd as they've been having in your application.

The more you do to quiesce what your application is doing, the faster the iAd will load, the more likely the user is going to want to stay with it, and the more time and fun they're going to have with the iAd. So you want to make sure that when you get this message, you quiesce everything that your application is doing and go ahead and return yes. Once you do that, the advertisement pops up.

And the user will interact with it, spend as much time as they desire, and when they're done, they'll eventually hit that close box or the home button and come back to your application, at which point we'll send the banner view action to finish message. Again, this is your opportunity now to start up all those activities you were doing before and get your app going so that the user can have as great a time as they were having before.

Now, finally, we want to talk a little bit more about that did fail to receive ad with error message. Now, as we said before, the absolute minimum thing that you need to do is hide the banner view. If you do nothing else, then you're golden. But while you're debugging your application, you might be interested in what the particular error you're getting back is and what it means to you. So these are all the possible errors that iAd can return to your application.

But we're going to focus on these four because they're the most important ones to you. This first one, inventory unavailable. It's an error, but it's not really an error. All it means is that we made a request on the iAd Network, but we couldn't get a banner. There isn't one available right now. And there's not going to be for a little moment. So we want you to just hide that banner view and do whatever else you're going to do. So just make sure that, as with all errors, We hide the banner view, and this is good.

The next one you might get is configuration error. That typically means that you forgot to go into iTunes Connect and actually enable iAd before submitting to the App Store. So if you get this error, and obviously if you're in production it's going to be a little hard to figure it out, but if you get this error, make sure you go back into iTunes Connect and you enable iAds and resubmit your application.

This next one basically means that you didn't hide the banner view when we asked you to. And so we're just going to keep sending this until you hide the banner view. So if you see this error, it means that some part of your logic in hiding the banner view isn't working. So correct that, and you won't see this error anymore.

Now this final one means that you're making too many requests too quickly. You've got too many banner views in your application. Now we recommend that you just use a single banner. Share it with all the view controllers that are going to display it and not have to worry about this error ever occurring. And to get you started with that, we're going to switch to a demo and show you how to share a banner view with all the view controllers of your application.

So right now, we have this simple little application. And all it's got is two tabs. Obviously that doesn't do a whole lot of work, but it does something. And the other one just shows a text view. And it supports all these orientations, so all that's good. But it's a very simple application, and we just want to add an iAd banner to it.

So let's go ahead and take a look at how to do that while sharing that same banner between both of these view controllers. So the first thing, of course, we want to do is add the iAd framework to our application. And we're going to use the application delegate to manage this banner view. And so it's going to be the AD Banner View delegate.

And finally, we're going to declare our own little protocol on top of it that's going to manage when a banner view shows and hides. Now we've got these two methods, the showBannerView and hideBannerView that we're going to send whenever the banner has content that we're ready for the user to see.

And similarly, we've got these couple of optional methods. So if we've got a view controller, like you saw that progress controller, that does work, and we want it to stop when the ad's coming up, we send these messages so that those controllers can stop what they're doing and restart what they're doing.

So to help with this, we're going to implement-- we're going to forward a few things. We're going to keep our own little banner view delegate method. And we're going to maintain a reference to whatever the current controller that we're showing is. So that tab bar has two view controllers in it.

And we're just going to say, this is a view controller that knows about the banner view container. And so we're just going to keep that reference so that whenever we have a message, we don't have to keep going back to the tab bar and doing a lot of type casts. And of course, we're going to synthesize those properties.

We're going to create the banner view. So as you see, we just go ahead and allocate an edit. And we're going to set the frame of the banner view so that it's sitting off the bottom of our UI. We do this because otherwise it'll be at the top, and when it animates in the first time, it won't look quite right. So we just want to make sure we place it at a location that when it does animate in, it does what we expect.

Finally, we're just going to make a reference of whatever the current control of the tab bar is referencing so that we can reference that later. Now the UI tab bar controller has a delegate protocol, and we're going to use a method on that-- tab bar controller did select view controller-- to know when the user taps on that tab bar to select a different view controller.

Now the first thing we have to be aware of is that the tab bar controller will send this message regardless of whether or not the view controller actually changes. So we're just going to check to see if the new view controller-- if it's the same as the one that we're already looking at, we're just going to return and not do anything additional.

But if the banner view is loaded and we're changing controllers, then we want the old controller to hide that banner view and the new controller to show it. And so we do that. And for the other methods we're going to implement, we go ahead and remember that view controller that we just switched to.

Next, we're going to implement our content notification methods. So we've got banner view will load ad. We aren't showing anything else in this simple example. So we're just going to note that this method was called by logging it. We've got banner view did load ad. So we know now that when we get this message, the banner view has loaded content and is ready for display. And so we're just going to tell the current controller to go ahead and show it to the user so we get that impression. And finally, this did fail to receive add with error method so that when we don't get an ad, we can hide it.

And finally, because the delegate's going to receive everything, we need to implement the action should begin and action did finish messages. Now in our protocol, those were optional, so we just make sure that the current controller actually responds to that. And if it does, we'll tell it the banner view began an action or the banner view action finished.

And so now, we just need to go ahead and go into our two view controllers and implement all of those delegate methods. So of course, we import our delegate, and we conform to the protocol that we created. And we're going to add some new forward declarations to the one that already exists. So in order to do the layout, if the user's interface orientation changes, we have to keep a reference to that banner view. So we do.

We go ahead and synthesize the property for that. Now, we already went and implemented this layout for current orientation method, but it doesn't need to do anything right now because all the content is being taken care of in Interface Builder using springs and struts. But now that we're adding a banner view, we need to actually be able to relay out content. So we're going to go ahead and add that method.

And it looks like a bit of code, but really all it's doing is it's saying, if we have a banner view, then we're going to figure out what's, we're going to set the current content size appropriately, and we're going to ask how tall is it. And if it's loaded a banner, then we're just going to make some room in our UI so that the banner can appear. And if it isn't loaded, we're going to animate that banner off. And then we just do our usual animation block to actually make it look like a banner. move the banner on or off screen.

And finally, we're going to implement those delegate methods that we already described. So when we get the show banner view message, we're going to remember the banner view we got, add it as a subview to the tab bar, and do layout so that the banner view will appear as appropriate. Similarly, for hide banner view, we're going to remove it from our view, forget the reference, and do layout again. So that's it for the TextView controller. And we're going to do something very similar for our Progress controller. Implement that. And add the forward declaration.

and do our layout. And this is the same layout code we had before. And the same methods for showing and hiding the banner. Now this particular view controller, however, also runs a timer that updates that progress bar. So what we want to make sure we do is when the user actually goes into an ad, we want to stop that timer, reduce our usage as much as possible.

And to do that, we're going to implement those optional methods we created to just stop and start the timer. So now that we've got all of this taken care of, let's go ahead and take a look at what that looks like. So we just loaded the ad, and we should be showing the ad.

There's the ad. And we go back here. And now if we click on it, watch the progress bar for a moment, and you'll see that it pauses right before the ad comes in. And when we close it, it starts up again afterwards. So that's what you want to make sure that your application does when the user enters and exits an ad, that you go ahead and stop all those activities that might take a little more CPU time, a little more memory, so that the user can have as great an experience in the ad as possible. And so with that, we'll go back to slides.

So now that you've seen how to share a banner view, let's go ahead and talk a little bit more about the other object that the iAd framework prevents, the interstitial ad. Now the interstitial ad is very simple to create too. You do the same thing, just allocate an edit and set the delegate.

Now, there are two different methods for displaying the interstitial, however, and this will really depend on what kind of application you have, what the UI of your application is. The first one we have is this inline presentation style, and that's intended for if you've got like a magazine or a book where you've got lots of other content that is also page-like, and the user will page through and go on, and they'll just keep swiping through, and they'll see an interstitial.

The other presentation style is what we call modal. And so that would be perhaps if you have a game or some other application where there's a break in whatever is going on, and you want to just show it interstitially, see about our sponsors type of page. And that presents as a view controller, takes over the UI, and will dismiss after the user is done with it.

So how do you do this? Well, we envision that in an inline presentation, you're going to want to display this interstitial as soon as you get it. So you implement the interstitial add to load message, and you use this present in view method on some view that you'll create to contain the interstitial.

You go ahead and you add that to your view hierarchy, and then as the user pages around in your content, They'll see the interstitial and they can go back to it. Remember, these are interst-- these are-- These are persistent banners. So they take over the full screen, but they last for a long time. So as the users go back and forth in your UI and they pass by it, they'll see the same interstitial again and again.

In the other presentation style, however, they're kind of more one shot. So you don't care about exactly when the interstitial loaded. You just want to know if it's actually been loaded or not. And so we've got this loaded property that you can check and say, OK, the interstitial is loaded. So I'm going to go ahead and present it from your view controller. It'll slide up, take over the UI, and when the user's done, they can dismiss it. Just like with the banner view, there's this actionShouldBegin method that is called before the full interstitials banner is shown.

After that method gets called, they go into the full ad unit, they do whatever they would do just like the banner view, And when they're done, you'll get this action to finish. All the same applies. A view controller is presented over your application. You should quiesce all that activity that you normally would do and just make sure and prepare that the user can have that great experience in the ad just like they've been having in your application. And with that, we'll show how to add an interstitial to a simple magazine app with the 80 Magazine sample.

All right. So just like going, just like when you're adding the banner view, you're going to want to import iAd. And whatever view controller is managing it becomes the interstitial delegate. This is a very simple app with a single view controller, so it can manage it. If you had a more complicated application, you might do the same thing we did with the shared banner view. And there are a few instance variables that we're going to add as well just so that we can manage that interstitial. And that's the interstitial add. Now just like before, we're going to declare a few methods that will manage the interstitial and do some work for us.

Let's go ahead and set up the interstitial. That cycle interstitial method that we just forward declared takes care of creating a new interstitial and releasing the previous one that we might have created earlier. And we just set this as a flag to know that we haven't actually inserted it yet.

We add this, and as we said before, all it does is it releases the old one and sets the delegate to nil. This way we won't get any more messages from that. And it creates a new one and similarly sets its delegate to self. Now, in order to actually add the interstitial to our UI, we implement this insertInterstitial method.

And it's a bit of code, but all it really is doing is making sure that we create a view that's the right size, and we add a page in our magazine to contain it, and then just insert that interstitial using the presentInView method into our application. And finally, We just want to implement that load method that we talked about, interstitial added load, and it's just going to insert an interstitial into our application. So let's see what happens now that we've got this implemented.

As you can see, it's just a simple application that pages through bunnies. And we now have loaded an interstitial. And you can page past it and page back to it. And if the user taps on it, they get the full interstitial iAd, just like with the banner view control, with the banner view. So that's interstitials. And we'll go back to slides.

So now that we've seen how to add a banner view or an interstitial ad to your application, let's get into a few best practices for when you're actually using iAd in your application. So the first thing is, you need to make sure that you manage memory warnings properly.

Because while an ad is up, it can use a considerable amount of memory. And you'll probably see memory warnings while it's happening. So if you don't implement these properly, you might get very strange interactions. And one of the most important things that you need to make sure you do is that you don't release those IADD objects. Remember, those are your connection to the framework. They're sending you those delegate messages that tell you when an ad is loaded, when an action's begun, when an action's finished.

If you release them while an ad is currently being displayed, you'll never get the finish call. And all those things you paused when the full ad unit popped up won't get resumed. So just make sure that you implement all these correctly so that your application will resume and pick up right after the user's finished looking at the ad.

Now, the next thing we've seen is that sometimes people do things that are not quite right with their view controllers. Well, in iOS 4, nesting view controllers just doesn't quite work right. There are a lot of kind of edge cases and gotchas that you might not expect. And one of them is, as we said, iAd's going to present a view controller over yours.

If you're pulling iAd from one view controller, but your UI is in another, then we're going to present over the view controller from iAd. And that might mean that when you come back out of the banner, that now suddenly the iAd is at the top of the screen.

Your entire screen is covered by some other view. It just doesn't look right. So iOS 4 doesn't really understand how to do that. So make sure that you do what UIKit expects, which is that a view controller represents the entire screen, and that you don't nest view controllers.

There are alternatives to doing so if you need to have reloadable content. But don't do that. So iOS 4 doesn't really understand how to do that. So iAd takes a view from some other view controller and add it to the view of one other view controller. Now, obviously on iOS 5, we introduced view controller containment. Unfortunately, that session was yesterday morning. So if you didn't manage to get it, when the videos come out, go ahead and take a look at it.

It offers some great new possibilities for working with view controllers. So I highly recommend the session. And if you follow the rules that UIKit outlines for view controller containment on iOS 5, then you can do a lot of things. So you can do that, and you can have a great experience both with iAd and view controller containment together. So in summary, what are your users really after? Well, your customers-- The advertisers are just creating some really, really awesome experiences in iAd. And your customers want those experiences. They want to see those iAds. They want to tap on those banners and engage with that content.

And that's really what they want. They want that great experience, but not just with those iAds. They want them with your applications as well. So if you can make a great experience in your application, then adding iAd means that you can see that great experience in your application, and they can get those great experiences from iAd, which means that you're going to make ad revenue. David Duncan So if you remember nothing else from this session, I just want to remember, if you create a really, really great application and you add iAd to it, then you've got that great experience plus the great experience that iAd offers.

For more information, our evangelist is Vicki Murley. And of course, we've got the human interface guidelines, which describe some more about how to place banners and interstitials in your application. And if you've got questions, we'll be here in the lab a little later. But we also invite you to come to the dev forums and ask questions on there for after the conference.

So again, that Improving the Stability of Your Apps session, that's tomorrow morning. The Implementing View Controller Containment was yesterday. And if you're interested in how all those ads, those iAd content gets built, there's the Building iAd Rich Media Ads with iiProducer session later today. Thank you all for coming, and have a great WWDC.