Good morning. Welcome to session 423. I'm Anders Bertelrud, the Xcode architect and I want to introduce you to the iPhone developer tools today and Michael Jurewitz who is the Developer Tools Evangelist who will be joining a little bit later on. So Michael and I want to show you the developer tools and as you've seen yesterday in Scott Forstall's presentation, there are over 50,000 applicatPions on the iPhone Developer-- iPhone App Store at this point and all of them have been developed using Apple's developer tool suite.

This is also the same tools suite that we used to develop the iPhone OS itself and as well as the Mac OS X Snow Leopard and previous Mac OS X releases. So we're hoping that when you see what we have to offer here with the tools and how easy it is to get started with iPhone development, you'll be inspired to add your own app to those 50,000. So, we'll be talking about Mac OS X and the iPhone 3.0 SDK. This session we focus on the iPhone SDK.

In the keynote and in other presentations, you've seen reference to both of these, Snow Leopard and the iPhone 3.0 SDK. One of the cool things about Apple's developer tools is instead of having two separate tool chains for the device versus the Mac even though both are fairly different devices, we actually have one set of tools, that's one IDE, one interface creation tool, one set of performance tools and the reason we have two releases in this case is that there is one shipping release, that's the SDK, iPhone SDK, the 3.0, and then there is a prerelease of Snow Leopard. So it's not two separate development environments.

It's actually just two versions of one development environment and we'll be showing the Snow Leopard developer tools today which will be giving you a taste of some of the things to come when Xcode 3.2 is released together with Snow Leopard later this year. What we're going to be showing applies to both versions of the developer tools When you ship your app, it's really important that you use the released version, the GM version of the tools to build your final version of your app and that's currently the iPhone SDK.

So at the conference here, there are two separate releases but there is one suite of tools and there are two different versions going on. So with that out of the way, let's go ahead and move on to iPhone development. So, we're going to talk about four major tools today. The first one of course, Xcode, you've seen at least some of all of these tools in the keynote and in some of the sessions yesterday.

Xcode is Apple's integrated development environment for Mac OS X and iPhone development and it has obviously project management, source code editor, built system and also some of the new tools like static analysis that you saw coming in the Snow Leopard version of Xcode. Interface Builder is Apple's interface creation and implementation-- prototyping and implementation tool.

So you can spec out your UI there and see if it's going to look right and work-- and it works again for both Mac OS X and iPhone. Different plugins for sure that show you different windows and different widgets obviously because the UIs are different but it's the same core tool.

Now, Instruments is Apple's performance analysis tool and it also lets you find memory allocation issues, lets you see where your code is spending time, look at file access patterns and all those things and Michael will be demoing that later on but it's a really quite a powerful tool and very flexible, works with Mac OS X, with the iPhone Simulator and with the iPhone however.

And the iPhone Simulator, this is a software implementation on the Mac side of the iPhone APIs. It is not a hardware emulator as we'll talk about a little bit later but it is-- it provides the same APIs on the Mac desktop within a little window as what you would have on the device and this can really help speed up the turnaround time. So, rather than just talking about Xcode, I want to show it to you.

Actually before I do that, I want to say one thing about Xcode again and just in case this isn't clear enough, Xcode is our IDE for Mac OS X apps, plugins, for UNIX command line development and for all kinds of open source development and it's actually, even though the iPhone SDK has only been available to the public for less than a year now I think, Scott Forstall said.

The Xcode IDE itself is many years older at this point and so it's a mature, stable, rich, feature-rich IDE. And the new thing of course, what we're here for, Xcode lets you create iPhone apps. With that, I'd like to show it to you. You probably all know where it is but for anybody who hasn't used it before, the Xcode application lives under the development folder at the top of my hard drive here under the applications and let's switch this to a slightly bigger view, Xcode. So I've launched Xcode.

I'm just going to go ahead and hide finder here. So this welcome panel is new in Xcode 3.2, that's the version that comes with Snow Leopard and is pre-released currently. There is a welcome screen also in the 3.1 so it may look slightly different depending on whether you run Xcode 3.1 or 3.2. In 3.2, we've greatly improved this panel and you have access to Apple development connection, various ways to really dive into iPhone development or you can simply create a new project. You can also access your recent projects here which can save you quite a bit of time.

I'm going to go ahead and create a new project and we see here that Xcode comes with a lot of iPhone app, types of iPhone apps already as templates. So for example, if I want to create a navigation based application that has these scroll lists that slide back and forth, I will start with this template. Open GLS application, that's great if you just want to take over the whole screen and do your own rendering like for a full screen game. Tab bars like the iTunes so the music application and there are various others.

For some of these applications, you'll see that there's actually an option now. This is new in the iPhone 3.0 SDK. You can actually use Core Data on the iPhone now and that was a much requested feature. One of the things I want to say about the templates is they provide you with a starting point. Depending on what kind of apps you want to start with here, you get a ready to run application that you can start customizing.

This doesn't-- the choice in this panel doesn't lock you in, it just gives you the default starting points. You could start with one of these and turn it into one of the others or do something else entirely but this is a really good way to dive into starting to work with it. So I'm going to ahead and create an app.

Oh let's see here. Let me go ahead and hit Choose and it will ask me to name my project. I'm just going to call it Demo App and I'm going to ahead and put it on the desktop. So we see here is Xcode's main window and I just want to give you a brief tour to this for those of you who haven't seen it before. On the left here, we have the contents of your project.

This is a fairly standard type of IDE concept, right. We have our source code in here, other resources. In this case, those are Interface Builder files so these icons here, probably a bit too small for you to see but they're actually user interface definition files and Michael will show you that a little bit later. We also have links to the frameworks to link against, et cetera.

In this case, that's a UIKit which is the user interface framework on the iPhone. Under targets down here we see the instructions for how to actually-- how Xcode should build something from your source files, in this case we just have the Demo App. We also have-- like in iTunes, we have a bunch of smart groups down here that will show you files with a certain characteristics like if I just want to look at my Interface Builder files, I'll select this here. Looks like my mouse is dying on me. Here we go. It's one of these battery operated ones. So in this case, we just see the interface files.

I can also look at project symbols and here I get a list of all the symbols. So that brings me to this view right here-- sorry, right here. This is kind of like the list of the songs in iTunes. It shows you the aggregate of all the things that are selected on the left.

So this will show me in this case all the symbols and of course if I select just the classes up on the left here, on the left side, I see just the classes. Now down here, we have the source code editor, full-featured standard editor with syntax coloring of course and things like code sense which lets you automatically complete against your symbols.

We also have very tight integration with documentation and they'll show you this in another session that follows this one, not in this room. We'll give a reference at the end of the talk here that goes more into detail about Xcode. So that's mostly what I wanted to show you today. I wanted to say actually also about the popup menu here, the overview popup. That's very important when we do phone development.

We've actually made it really easy to switch between development for the device and for the simulator and if you had let's say a foundation only framework that actually go for both the Mac and the phone and the simulator, you would use this popup here to switch between the ones you want to build it for right now. So as you could see here, I can switch to simulator device.

I'm going to switch to simulator right now. You can also choose to say debug versus release. These are called built configurations and they're simply sets of option for which your product should be built. So, you can for example turn on optimization, turn off optimization, set certain custom flags, those of kinds of things. So those options are called build settings. You can edit those. Under the Project menu here, we see Edit Active Target. We'll talk about this in detail in another session that goes more into Xcode itself.

We're going to talk about all the tools in this session. And so the configuration just switches between those. I'm just going to go ahead and build a run at this point and then just see that it comes up in the simulator. So, you've probably seen the simulator before but this is what you get by default from the template. You get an app that is content-free but it does have the structure that you chose and you can now go ahead and start customizing it.

So some of the definitions, I used a lot of words here you know, projects and targets and whatnot. So, one of the basic concepts of course in any IDE is files and in Xcode your files live on disks as separate files. This isn't some kind of source code database so you have access to them at any time but we do keep references to them and you put source code images even to-do lists and notes and that kind of stuff. Targets, in Xcode these are the instructions.

If you think of the files as parts like in a, let's say an airplane model kit, those will be the parts, right. And the instructions are the targets. That's what says-- what tells Xcode what to do with your files in order to build your particular product. And projects are a higher level grouping. Now typically for an iPhone app you'll only have one target for the project because typically you just ship that app.

If you have a Mac OS X application, you may have a dozen frameworks and maybe 50 pluginsstPylX and then one application, one DOC bundle, that kind of stuff. Again, further sessions will go more into detail about this but I wanted to explain these concepts a little bit here just so-- if you're not familiar with these terms. Build settings also fairly obvious perhaps. These are simply the options that control how you're product is built.

This could be optimization on or off, obviously, but also which compiler to use. If you've watched the Developer Tools State of the Union last-- yesterday, you saw that this is place where we can choose the compiler to use. Now for now, the GCC compiler is the one to use for iPhone development.

Clang is only available currently for the Mac. So, you typically don't need to touch a lot of the options for iPhone development. I should point out, values can be defined in terms of other settings there. Again, there is much more detail in further sessions today and later on in the week.

And build configurations are just groups of settings that you've given a convenient name like debug or release. We've provided many of them for you, also things like simulator versus device. Those are things that come ready to use out of the box. You probably won't have to modify but the power is there and the flexibility if you want to get into that a little bit later on. So, what does Xcode do with all this? Well, you have your project, you got your files in that project, maybe some interface files.

The targets, in this case three, but typically for an iPhone app there might be one or two. The targets take those files, produce your iPhone app and the options give you the control of exactly how that happens. Very brief introduction of Xcode 'cause a lot of the fun comes in some of the other tools, not that Xcode isn't fun. To talk about some of the other tools, I want to ask Michael Jurewitz to come on stage and to talk about Interface Builder.

Thank you, Michael.

Thank you Anders. All right, good morning everyone. Now let's talk about some of these fun tools here, so Interface Builder being the first one that to want to try to focus on. So Interface Builder is your premiere application on both Mac OS X and for iPhone development for graphically laying out your interfaces and being able to take that interface once you've actually put those elements in there and connect them directly to your code.

So that you know that as a user begins to interact with the buttons that you might have in your interface or the navigation controller that you've got that it's going to be calling through directly to the code that you've written in your project. So Interface Builder, one of the great things is that it lets you start off with the concept of what you'd like your interface to look like. Say, if you're working with a designer for example to figure out what is it that you really want to actualize in your app, what do you want to bring to your users.

And then because you can graphically lay out your interface in Interface Builder with these basic controls that are provided by UIKit, you can go ahead and transition from something like this, to having it well stubbed out in Interface Builder and understanding how you're going to be doing your work, everything from native controls like the search bar and the various elements in the toolbar to even including things like the map view that you've seen over the past couple of days.

And again, once you've actually designed this, you can take this interface and make sure that you connect it to your code so as your user begins to interact with it, you know exactly what's going to happen, you know how the flow is going to work in your application. And probably the most important and I think valuable part of using Interface Builder is that it's not code generation.

It's really important to know this. Although you're dragging these interfaces out and you're setting these, all of these elements in your interface to look just the way that you want and configuring them and connecting them to code, Interface Builder is not busy writing code under the covers for you.

You're actually as you're designing your interface, dragging out the real objects that are going to be getting loaded into your application at runtime and used. And all the Interface Builder is doing is providing you a convenient way to customize those objects and to work with them to make sure that they look and behave the way that you want.

So you don't need to worry about having a button and suddenly needing to double-click on it to you know, subclass it and do some sort of crazy work with it. You've got a much more intuitive way of dealing with things and you don't have to deal with the innards of the UIKit classes and let's say that's what you want to do. And one of the great things of course is when you're not writing code, you don't end up having to go through a bunch of variations to try to figure out just how to precisely place that control as you want in your interface.

With Interface Builder, you simply drag an object from the library, place it in your interface, it gives you guides to show you where things go. You can go to the library and find the elements that you want and again, drag them out and know that you put them in the correct place the first time which is really great. You want to design once, you want to get that out of the way and you want to focus back on your code on getting your real job done and Interface Builder lets you do that.

Now we're going to be building a little sample application today that looks like this, just a really basic web browser, we got three buttons, we're going to go to various websites. You've noticed we've got a Back button, we've Back and Forward so we can navigate around. We're able to double-tap to zoom in, very simple, very straightforward and I'm going to show you how to build this application in about 15 minutes.

It's about all it takes, very quick. Now before we get started though, let's talk about two key concepts in UIKit that it is going to be good for you guys to have some familiarity with before we get started. So the first are ViewControllers, UIViewControllers. Now in UIKitViewController, you can think of its basic task in life is to maintain a connection to some view object and that view object is going to be-- what that ViewController's sort of sole purpose in life is to work with it, it wants to make sure that it gets that view onto the screen.

And similarly when that view has actions that it wants to do, say like a button being pressed, it's typically going to send those actions back to that ViewController and your ViewController is sort of your control-- youre controller level entry to the rest of your applications so it can mediate that interaction between the user with that view and the rest of your app. And as we begin to work with our application here, you notice when I-- when we pushed one of those buttons in that, in our demo app, we had an interface slide over.

So we're making use of a NavigationController with that and what NavigationControllers do is basically just maintain a stack of ViewControllers. So as you push that button, we load up a second ViewController with its view and it gets put on top and that causes that slide in effect to happen.

When you hit that, you can say if you click to some more detail, you have another ViewController get put on the stack and as you hit that Back button, that the topmost View Controller would get popped off the stack and you'd be back at the second view for example. So let's go ahead.

Let's just go straight to demo and let's start working with Interface Builders. You can see exactly how this works for your development. OK. So I'm going to go ahead, I'm going to bring up Xcode here, and I'm going to ahead and just create a new project and we're just going to do a navigation-based example just like we had before. In my case, I'm just going to call this Demo and cancel here, so we have one, how about that. Tell you what, we'll just go with the Demo App that's already up here. All right, so we've got our same basic view that you had before.

Anders took you through all the various parts of this.

And I'm going to go ahead and you'll notice that we've got the resources directory here. Anders already pointed these out to you earlier. And these resources directories, this is where you're Interface Builder files live. They end in .xib, we call them XIB files, and they're basically just an XML representation of your interface itself. So I'm going to go ahead and double-click on our main window.xib and we'll open up Interface Builder.

Let me go ahead and hide Xcode here just to clear things up. And by default when you come in to Interface Builder this is the kind of view that you're going to be presented with. Now on the left-hand side here, we've got your library. This is your large collection of various view objects and controls for you to work with throughout UIKit as you layout your interface and design the classes that you're going to be presenting to the user.

Below that we've got the Interface Builder Document Window, and this is where top level objects in your XIB file lives. So for example, you see we have the window for our application lives here. We've got the NavigationController which also lives here. This is again that control that's going to handle that sliding interface for us. We've got a few other elements up here. I'm going to talk about, about two of them specifically.

So the first is our Demo App Delegate. This is just our-- If we go back to Xcode here in a moment, you'll see a class called Demo App Delegate. That happens to be our application delegate as we begin doing our development and if you heard the Objective-C talk yesterday, we talked about a little bit about delegates and sort of the roll that they can play in helping you customize behavior in your class, in your application as you begin to work.

Now the important thing here is something called FilesOwner. Now FilesOwner you can think of is the actual class that loaded the NIB file. When we look at some other NIB files later on in this presentation you'll notice that they're called things like RootViewController.xib. In fact, let me go ahead and just show you that right now. We've got our RootViewController.xib. We've got also a RootViewController class. Well, it's this ViewController that is responsible for putting that XIB file, basically loading its interface and putting it on the screen.

And so FilesOwner is basically your way to talk to that ViewController, that class, whatever it was that happen to take that XIB file at runtime and load it up for yourself. So, you'll see some more of these in action in a moment. Now the first thing I'm going to do just in the flow of the demo here is actually just double-click directly in this Navigation bar that we've got.

And I'm going to type in Websites just to give this a title for our interface. I'm going to save that off and we're going to go back to Xcode to keep doing some work here. Now the first thing I'm going to do here is fix up our ViewController header file a little bit, add some code to it.

And I'm going to go ahead and go to our implementation file and do the same, save those off. And I'm going to open up our RootViewController.xib and rearrange things here a little bit. OK. So the first thing you notice here on our RootViewController.xib we've got that TableView. Remember when Anders did his demo we had a blank TableView just for us to go ahead and scroll into our interface.

But we don't plan on working with a TableView here so we're actually going to go ahead and just select this and delete it. And I'm going to use the library to search for a UIView, so just your basic ViewClass in UIKit. And I can grab this view and drag it directly to our document window, double-click. And now I've got a design surface to begin working with as I start laying out my application.

Now, one of the first things you can do over here on the right, in the Inspector, is to begin to set up the visual attributes of your view, to begin understanding sort of the space you have to work with and how youre application is going to look in the first place.

So for instance, I know that my application is going to have a status bar, so I'm going to want to go ahead and change these simulated interface elements to put one in. And all this does for me is to have Interface Builder basically take up the appropriate portion of the screen that that would occupy in my real app and draw it in there.

Just so I know what real spacing I have to work with, what the real constraints are in terms of the size. Now we also know that we are working with a navigation-based application and so our top bar we want to make sure is styled like a navigation bar.

Again, just purely so we can make sure that everything is in place. OK, so we've got that looking the way we want to, now we had that sort of wood grained image to the back of everything, so I'm going to go ahead and search for UIImage. I could also just search for image if I wanted and Interface Builder knows enough so you don't need to know the class name specifically. And if I drag this ImageView out here, you notice it resizes automatically to the size of that space, so I can just drop it in and be-- just keep on going with my life.

Interface Builder is always trying to help you out with very simple sort of task that it can expect like that. OK, so we've got our ImageView there. We'll be hooking that up in codes so we'll just leave that be for a moment. Now I also had three buttons in my interface, so let's go ahead and let's just search for button. And I'm going to go grab this round rect button here, pull this out, here we go.

I'm going to go ahead and resize it. You notice Interface Builder is already giving some basic information in terms of sizing in the left-hand corner right there, so I get this to be more or less of what I want. And as I begin dragging this button around you notice I get these style guides here. Interface Builder is trying to key me in to, you know, basically just key points in my interface.

And as I come up against elements both from the top, the left and the right here, this is Interface Builder actually helping to show you what the human interface guidelines actually say about what the spacing should be between elements on screen. So again, like really helping you to be productive and make sure that your applications look their best. And I just double-clicked here and I'm going to go ahead and give this thing a title so we're going to call this New York Times.

And I can go ahead and select this button and Copy and Paste just to get a new one, make sure that stays lined up. And I'm going to name this one CNN, paste again. Oops, got the wrong one there. That's OK. It makes it easy to place it back. And I'm going to go ahead and call this one down here Mercury News.

Okay, so all three of these buttons are placed but they need to actually do something, right. We need a user to be able to press them and have something happen in our interface. So in Interface Builder, the way that you basically capture that sort of action is by holding down control and dragging from the element that's taking the user input, say the button in this case, to the item that we want to actually connect it to, in this case it's our FilesOwner which is our RootViewController. And when I let go you'll notice that I've got these three events that pop up. We've got Show CNN, Show Mercury News, Show New York Times.

So I'm going to go ahead and hook up the show New York Times method right here, and now when that button gets pressed it's going to call that method in our RootViewController class. I'm going to go fix up the rest of these right here, Show CNN, and Show Mercury News, and hit Save. Now how did Interface Builder know that it should do this in the first place? Well let's go back and take a look at the code that we have.

And in our RootViewController header you'll notice that I've got three methods defined here that have a return type of IBAction. So IBAction is just, is just void. You can just think of it as the same thing as void. And all this does is tell Interface Builder as it's staying in sync with Xcode, hey these are methods that I'm going to want to be available to me when I'm working with my interface. So please make sure that, say when you do that gesture that Control + Drag from the button to the controller but those things get hooked up. So that's pretty simple.

You notice they all take a single parameter and to type ID, so it's any object type, and we just call it Sender. In this case this is the actual interface element that sent that method. So a lot of times you'll have controls where you might want to turn right back around and ask the sender hey, what's your state, are you on, are you off, you know, what did the user just do exactly. For a button, in this case, it's always just going to be that the user clicked.

But there's other interface elements where being able to call back out can be very, very important. So now you'll also notice up here we've got this-- our UIImageView declaration and it begins with IBOutlet. So what an IBOutlet let's you do when you adorn it on an instance variable like this is be able to say all right well I'm declaring this instance variable.

And what I really want to happen is when this class is loaded and it loads up this interface file, I want to make sure that this instance variable is connected to that ImageView in my interface. And this will automatically be done for you if when we go back to Interface Builder, when we Control + Drag from FilesOwner to our ImageView, we set that ImageView outlet.

And now when that NIB file gets loaded, that instance variable will get set for us, and we can go ahead and we can do things like set the content for that ImageView and say hey, I want you to use this wood grain image for example. Now since we changed the view that we want the ViewController to actually display, I need to make sure I Control + Drag from FilesOwner to that view and hook up that outlet as well.

Remember we had deleted that TableView. Okay, so we've got our three buttons, we've got connections going down to our application, we've got connections going back out to the actual interface itself, but we still need to have that WebView, right. We still want to show this web-based content to the user in the first place.

So we're going to back to Xcode here and I'm going to go ahead and create a new file and we'll call this new file-- first of all, we want this new file to be another ViewController, right, 'cause we want to push another ViewController on top of the stack that's being managed by the NavigationController.

And Xcode is kind enough to actually offer to create the interface file for this ViewController for me as well, so make sure that option is selected and I'm going to hit Next, and I'm going to call this myWebViewController And we'll go ahead and hit Finish and this will add this directly to our project. And then just for organizational purposes here, I'm going to drag this XIB file down to our resources directory. Okay, so what's happening in our ViewController? Well, nothing terribly interesting at the moment.

So let's go ahead and let's change that, add in some code here, same thing in our implementation file, save both of these and then let's start designing an interface. So we'll double click on myWebViewController. I'm going to close our WebViewController down just so we can focus on this. And again, we've got this blank slate, this blank view to work with.

So really quickly, I'm just going to make sure, we've already got the status bar, but I'm going to make sure I put that top bar in there, and let's start designing our WebView. So the first thing we want to do here, you notice we had a toolbar at the bottom of our WebView so the user can go back and forward.

So I'm going to go ahead and search in the library for toolbar, and I'll spell it right this time. And if I just click and drag this out, you notice Interface Builder shows us exactly what that element is, and we can place it precisely where we want in our interface.

We've got a single button right here we can work with called Item. It's somewhat interesting. Let's go ahead and I'm going to select it, hold down Option, just click and drag to duplicate it, and we'll use some ASCII art here. We'll make this one Back and this one Forward.

But it's kind of lame to have them both at the same side of the interface. And Interface Builder will let us see things like what happens when our interface rotates. So if we rotate that interface, we see, oh, they're staying on that side, that's not too fun. So what I really want to do is I really want us to find some way to push these things to opposite sides of the interface so that one is always on the left and one is always on the right.

And you do that Interface Builder using a flexible space for the toolbar. So I'm going to type in "flexible" here. Let me see, we've got a flexible Spacebar Button Item and if I drag this down and put this directly between these-- those two buttons, it will push them apart. And when I rotate the interface, they'll stay pushed apart.

So just that easy, really quick and easy to see. OK. Now what I want to do is grab that WebView that I was going to be showing to you, so let's go ahead and search for Web and we see we've got WebView as one of the built-in controls that we can work with. And I'm going to click and drag and just bring this directly into my interface.

You notice again Interface Builder sized it precisely into the space that I had left so I can begin working with it, and there we go. So now this toolbar though, I don't really want this to be blue. Let's say we want it to be different color. Let's say we want to make it black.

So I'll select the toolbar and then the Inspector here on the right, I can actually change this to, say, black opaque. As I click away, you'll notice that it's even changed the colors of the buttons. The buttons themselves are blue to begin with. But Interface Builders are smart enough to notice this change we've made and has tried to help us maintain consistency as we're designing our interface, so pretty handy.

Now, for these buttons we initially typed in some text but now it looks, you know, not so great. We could do something a little better here. And it turns out as you're working with toolbars and et cetera in UIKit, you can make-- take advantage of a Bar Button Items identifier.

And what this gives you is a certain amounts of standard artwork from UIKit for common user actions. So if you wanted, for example, an Add button or perhaps a Cancel button or maybe you even wanted a button for composing a message, for example, the standard motif for doing that, these are all provided for you.

As it turns out, we're going to cheat a little bit here and I figured that-- I figure rewind is more or less okay for back. You should definitely do your own Back button if you were doing something like this but we're just going to be quick and easy here.

So we've got Rewind and we've got Forward for our forward and back. And now, these buttons are here but they're not doing anything currently. So we need to actually have them tell the WebView to go back or go forward depending on what the user clicks. So what I'm going to do is hold down Control and click and drag from this button to the WebView, and you'll notice we've got a set of actions already that we can work with.

As it turns out, UIWebView actually publishes a set of IBActions that it expects that you'll probably want to use as you're working with it. So go back and go forward are already things that we can make use of, so that's pretty great so we'll just hit Control + Drag, do the same thing, and hook up, go forward for the Forward button.

All right. So that being the case here, let's go ahead and let's go back to Xcode here, and we need to fix up one thing here 'cause we're using our Demo App so I need to make sure-- oh, it's-- that is all good. I'm going to hit Build and Run and, hopefully, we'll be okay.

We've got one Build there. What happened here? We've got our Demo App Delegate-- oh, but we've got Demo App App is actually the name of the file in this case. So let's go ahead. We just corrected that, you know, as Xcode showed us directly on our line where the error was. Hit Built and Go. We've got our interface.

We don't have our-- we don't have that wood graphic. So what happened here? Well, we've got our wood graphic sitting over here on the desktop but we haven't added it to our project. Interface Builder didn't-- or Xcode didn't know to include it in our application. So I'm going to go ahead and just drag this wood graphic into our resources, make sure it gets copied in. And now, if you actually go down to your target, and this is one of the neat things about targets. I think Anders talked about them, serve as a bit of a recipe, if you will.

The ingredients are all your source files and all your interface files and the targets tell you sort of what to do with them. But you'll notice there's a Copy Bundle Resources phase and we see it's copying in all of our interface files and now it's copying in that graphic as well.

So now, when I go ahead and hit Build and Run, we'll get our application with the wood grain just as we wanted it. And I can go ahead and I can start clicking on these things and we'll load up the New York Times here, assuming that-- assuming we have the wonderful powers of the internet helping us out. Perhaps not. All right, well, sometimes you can't rely on the internet in these situations. Well, rest assured we'd actually be loading these resources here.

I'll go back to New York Times to see if we can unstick it. All right, oh, well, rest assured, we'll leave this off to the side just in case it happens to catch up with itself here. Let me just double check the-- double check that everything got set up appropriately for us and that looks good and as does that, so probably just a matter of slow internet at the moment.

Such is the life of onstage demos. All right, so, but you see we've built the application. We've got the interface to go back and forth. Our back and forth buttons work seamlessly and, you know, we've spent probably about 15 minutes to build the entire application itself. So pretty straightforward, you know, and it's a fully functioning interface, really quite awesome. Now, one of the great things you can do is, say, as you're using your interface, is let's say that I wanted to set a breakpoint in my Xcode project here. And I'm going to go ahead and hit Build and Debug in the simulator. We'll load up.

And when I hit one of these buttons, notice I'm stopped directly on this Show URL with Title which is the method we were using to actually create this in the first place. And in Xcode I can actually do some pretty cool stuff like mouse over a variable directly in the source code to see exactly what its values are live as we go through the-- as we are going to the execution of our program.

So even if I go and step over this line right here where I'm setting the location for our WebView, I can get that all taken care of and see that this is indeed getting set up in our app. You see we now have the New York Times being the address that we had clicked. So, pretty powerful, pretty great. Go ahead and pull that breakpoint out and quit that.

All right, so let's head back to slides here. So as Interface Builders, you got a sense for how Interface Builder really does lets you quickly and easily construct these graphical user interfaces. And sort of the back and forth display that you have as you go between creating your interface and connecting it to your code and having that be part of what the, you know, when the user interacts with your app, having it-- knowing exactly where it's going to be calling through to your application.

OK, so we showed you Interface Builder. Let's talk a bit about our next application in this week. Let's talk about Instruments. So Instruments is our flagship performance tool on both Mac and iPhone, for performance and memory analysis. It's a really versatile tool and you get a powerful wide range of things you can actually look at in your application. And the great part about Instruments is that it really brings context to your analysis.

Because usually, when you're doing performance profiling, you end up in a situation where maybe you're just looking at the timing of your application so you're just saying, "Hey, how am I spending in some method?" And so you're looking at this one thing and you've got only a single set of data, you know, a few points to say like, "Oh, that method is a little slow and I can improve that." But you really don't have any other context in your app to know sort of what was happening with memory, what happening with video, what was this play actually happening throughout the various subsystems on the device, whether it's a Mac or whether it's your iPhone.

And what Instruments let's you do is bring this other elements in where your application is performing and understand them in context. So you can see, oh, that timing related issue. Well, it turns out I was doing a lot of File IO and then-- and I was having to malic [phonetic] a whole bunch of memory. That's why it was taking a long time, you know.

Oh, I see that, you know, some other operation took a while. Well, again, maybe I was thrashing memory at the same time, things that if you were just looking at timing alone, wouldn't be sufficient to know exactly why you were taking so long. Alright, so, let's just go back to demo. I like showing off the tools just to have a chance to see what it's actually like to work with them.

Alright, so we click and open Instruments here down the dock. This is what we're presented with initially which is a series of templates for you to use as you're working with your application. And this is really quite powerful because you've got a whole bunch of stuff that you can look at. You'll notice we've got an iPhone category as well as a category for the iPhone Simulator. So we actually have different templates set up that are especially tuned to what you can do in either environment.

And Anders will talk about sort of what's appropriate when we discuss the simulator here in a moment. So if you look at all the templates for iPhone development, you'll notice that if we're looking at the device directly, we've got a lot of stuff that we can choose to do. We can track object allocations so we can better understand the memory usage on our phone itself and how our application is actually working with that memory.

We can use Leaks, which is going to allow us to detect, say, if we're leaking memory in our application. And so basically, runs a statistical analysis of our app's memory heap roughly every 10 seconds and determines, alright, what's still alive but nothing else is currently pointing to it.

Oops, well, that's probably something that you leak and didn't realize. And on iPhone stamping that out is going to be extremely important. Activity monitor will give us a sense for the overall usage on this system, say, of all the different processes and the memory they might be using.

And you've got a slew of others, everything from CPU sampler for timing to OpenGL ES if you're a game developer and want to get in to the very low levels of how the graphics card is actually being utilized. And Core Animation as well for if you're doing UIKit drawing.

You can see basically how efficiently you're doing that. So I'm going to go ahead and I'm just going to open up ObjectAllocations here and just give you a tour of the interface. Alright, so you'll notice this if you've say, Garage Bamboo 4. So probably fairly similar interface this thing that you're used to. On the left hand side here we have individual instrument that you're working with.

In this case, we're working with the object alloc instrument. And our Info button here is going to let us configure various aspects to it. So, most instruments have different options you can turn on and off depending on the type of profiling you can do and you can reach them all through this Info button. Now, on the right here is your actual track view. This is where you're going to see live data come in as you begin to profile your application. And down below, you've got your detail view.

This is going to show you exactly the detailed information that's been collected on your application. And again, over here on the left hand side, you've got further options that you can use usually to hone down that data that the specifics that you care about. And the great part about Instruments is that once you've already jumped in to a template, you still got a library of different instrumentation that you can take advantage of and drag back into your interface. So one of the things you can do is you just pull down the library just to go straight to the iPhone section and you've got all the different iPhone instruments that you might want to pull in and begin to use as you're examining your application.

Now, another one of the powerful things that again Anders will talk about when we deal with the iPhone Simulator is on the iPhone Simulator you can use-- you can often use Mac instrumentation to actually understand greater detail about your application. So if you are working with core data, for example, you could use any of the core data instruments to understand the various performance characteristics of your core data faults and fetches and your saves, et cetera, so really quite powerful. So I'm going to go back Xcode here and we're still on the simulator as we see.

And if I go to the Run menu, I can actually go to Run With performance tool. And what I'm going to do is go ahead and run with performance tool and let's do a-- let's go ahead and do Leaks to begin with. I told you those were important. We'll drag this off to the side and let me go ahead and hide the library so you can still see the simulator here. An ObjectAlloc is showing us some basic memory usage.

I'm going to go ahead and interact with the simulator here. We don't have any content to load, unfortunately, with the internet connection. We can go back and go forward. But you'll see that Leaks is already picking up on a couple leaks that we've got. We see both the leaks that have been discovered as well as the total leak bytes that have actually happened in our application. So I'm going to hit Stop here.

And what you can do, already you see an ObjectAlloc. This is actually really, really pretty excellent if you've ever needed to do some fine grained analysis in your application. You'll notice that we're seeing every single allocation that our application has made. And if we dig deeply into these things, we can even see where exactly they came from. So in this case you've got a lot of stuff that's come from UIKit. Not too surprising 'cause we were setting up a whole lot of just basic framework code here. But if you got your own objects here, you can actually search for them and find them yourselves.

And so that's really the power in being able to-- in being able to see these things. You see, we can even search for roots down here at the bottom and sure enough, there's our root view controller. As you would expect, it was created and we're able to see that But we leaked some memory, which as I said again it's the thing that you're always going to make sure that you're trying to avoid doing on iPhone.

So I'm going to hold down the Option key and just drag around this region right here. And what it's done, it's gone ahead and narrow the scope of this data to only include this region. And we'll see that we've got a couple things that have come from our demo app in this responsible library that are being leaked.

In this case, we've got a couple UI images. So let's go ahead and let's take a peak at this. So for the first thing we can do we'll go to our View menu and select the Extended Detail View, and what this lets you see for every one of these objects is the call stack that actually was responsible for allocating that object in the first place so you can know exactly where that object came from and really the-- as the sort of the first line of checking, you want to make sure that if there's any part of this that is your code, that you're doing the right thing.

So if we take a look through here, we notice that we've got this RootViewController ViewWillAppearshowing up and this is, obviously, our code so we might wait. We might want to do something with this. You see, we can even see a path to the actual file itself. And if I double-click on that, Instruments actually opens up directly to the line in our source to show us the object that it was leaked. And in this case, the view will appear. I'm doing something kind of silly.

I'm allocing this UI image view and I actually don't later release it anywhere So I alloc this image view. I set this image as-- so alloc this image. I set the image to our image view. In this case, this is the wood background and I don't later release it. So we're leaking this memory every time this ViewWillAppear method gets called, which in fact, is every time that we come back to the view.

Not a good thing. So really, if we wanted to fix this, we should be taking just the loading of this individual image, making sure that we release it and we really should just be doing this in ViewDidLoad, it's called once. It's going to be your place to set up initial state and that's where that work should predominantly be happening. But again, you'll notice Instrument is honed in on the line on our source.

It's shown us the amount of memory that's actually been leaked. In this case it says 32 bytes. For UIImages, they are also backed by CG layers on iPhone, and so most of the memory that they are actually using is in the separate object. So it's actually more than 32 bytes. It's even worse than we would have figured.

And if we wanted to make some changes of this code, we could just click this Xcode button and jump directly to that line of source in our Xcode project itself, so really quite powerful. Now, all of this is great but you really want to be running your application on the device, right.

So, Anders already showed you this overview menu and it turns out we can just select this device, 3.0. And I'm going to go ahead and hit Build and Debug.

And this is going to build our application, it's going to install it on our development phone which is over here, and this should automatically come up here in a moment and we'll launch our application and here we are we have it to work with. And again unfortunately, we don't have service at the moment but we can tap on our application. We see it loads in.

We can navigate through it. And we've got this fully functioning application here on the phone just by switching that pop down and going here. But the really cool thing is that you can still debug and do performance analysis on your phone itself. So I'm going to go ahead and in our Xcode project here. I'm going to take our RootViewcontroller and go to this, show URL with title and drop that same breakpoint in that I had before.

And if I go to the phone and hit our New York Times button, we see it lights up and we go back to Xcode, we see we're paused on that line itself and same thing before. I can mouse over these values directly and get their actual values where they are in memory, all of their state and talk to them. And it's all happening right here on your phone, really powerful, really, really powerful.

So I'm going to go ahead and I will drag this breakpoint out. We'll hit Continue. I'm going to go and stop this but you can even run with performance tool against the phone itself. So let's say that I wanted to-- wanted to start this up with object allocations and do it on the phone.

We have a new template that would start up here. And on this case, that's actually-- I'm mean don't say that, over the best trends [phonetic] again here. We've already got the application on the phone. So I'm going to go ahead and select object allocations of the template. And if I do Launch Executable from this menu, I can actually choose the application that I want launched.

In this case, I'm going to select our demo app And if I hit Record, we'll see we start up, if we got the phone here, we see our application has come up. I can begin interacting with it, things are a little bit slower when you're actually using object alloc on the phone itself because the iPhone is recording an enormous amount of data about the allocations of your objects, which is still quite usable and go back and forth.

And when we go back to our demo machine here, we see an object alloc that we've got a live view of the actual objects in our application recorded and most of them here with full pointer histories. So we can go on and see all of our CF arrays that were created in any for a given pointer I can see all of the individual malics and freeze on that pointer itself.

So if you ever end up in a situation where you're overwriting memory or you're smashing memory and you need to figure where did that come from, you can even hone down on the pointer level and understand the exact activity that has happened there to get to the source of the problem. It's a really, really fantastic set of tools for you using youre development. Alright, so that's Instruments.

So we showed you how to you collect data from multiple sources both in terms of using things like object alloc but also leaks which analyzing your data to understand where it's coming in from and there's all sorts of other instrumentation you can make use of everything from taking advantage of network profiling to CPU activity, et cetera. Instruments provide a rich set of data mining.

So we only scratch the surface here. Yesterday, in that helper's [phonetic] tool, state of the union, you probably saw a really rich set of features for doing things like charging calls to different callees. And we've got some great sessions on Instruments later on in the week that is going to go in this wonderful detail there. And really Instruments again helps you better understand the context of what's happening in your application, again, really, really awesome application. All right so that's Instruments and with that I'd like to go ahead and hand it back on to Anders to talk to you about the iPhone Simulator.

Alright. So we've seen the Simulator a couple of times already today. It sort of just comes up and looks exactly like a phone right. So one of the things to know about-- well, why use it at all? Obviously, faster edit, build test integration. So for iterating on some logic, maybe a button click isn't quite working right or even for working on some OpenGL ES graphics.

It can be a lot faster if you just build and run, get the simulator. If nothing else, you don't have to shift your focus to look at the device. There are more analysis tools available as Michael mentioned, because the simulator is actually an Mac OS X app and your app inside of it is one.

You can analyze it using some more tools than what we have on the device and I'll talk a little bit more about that. It's also easier to test exceptional conditions. The Simulator lets you show what the UI will look like if a call comes in while your app is being used, for example.

And you can also simulate a low memory condition which will then cause some special code in your app to get it run to try to free of some memory. And obviously you can do it without having a device connected. You can just set and program it on your computer and you can actually write a full-featured app just using the simulator and then when you connect it to a device for the first time, you'll be very far long.

So one of the big reasons edit-complied-debug cycle, another thing is Dtrace. I mentioned there were some technologies that were available to Mac OS X. Dtrace is an open source technology that we provide on Mac OS X. It lets you add probes to your code and lets you instrument code without modifying the code at all and without recompiling it.

So as you saw with Instruments, we can attach to an application and without adding a whole bunch of profiling points or anything like that, it gets dynamically instrumented and that's what-- one of the technologies that Instruments uses under the hood to sample-- to insert little probes to sample your program and figure out what's going on.

And on a retained release, malic-free kind of a memory architecture like the phone, there's always the opportunity, the risk of lost objects, right. This is dangling pointers that you have somehow released an object and you still have a pointer to it and we call those objects "zombies." They're kind of this half-life, half-dead state.

The memory has actually been deallocated but you still have a pointer to it. And one of the things that you can do on the Mac is to turn on this feature called "zombies" and then instead of actually deallocating the memory for your object, it will turn them into a zombie but remember what they used to be.

And you saw this in the state of union yesterday where Steve Lullan [phonetic] showed that the instruments connection flagged this automatically for you. Now one of the reasons this is available on the Mac and not on the phone is it can use up a lot of memories. You're going to keep around all the allocated objects just in case they get message. So this is one reason that this is tricky to do on phone.

So that's another advantage of using the simulator. So it looks just like hardware, right. It looks exactly like a phone with the bezel [inaudible] those sorts of things. But it is important to remember that the simulator is not an instruction level emulator. It doesn't emulate the chips that inside of the phone. It doesn't emulate any of the hardware on the phone.

Rather, it is the Mac OS X implementation of the iPhone SDKs. So all of the same APIs are available but complied for Intel and obviously, their implementation on the Mac from Apple's side is different because the hardware is different. So any drawing you do goes through a window on the Mac screen as you've seen. So this has some implications.

You're actually compiling your code for a different chip set than you do when you build it for the actual device and some of the differences here, the implications are you can use eitherthe device or the simulator for things like logic testing, for leak checking, those kinds of things.

As I mentioned, zombies are great to-- that's a great way to check your memory usage and lost object problems on the Simulator and you'll know that that's going to be the same logic that will run on the device. There are other things that are not so interchangeable. The simulator again, it's better for very fast rapid edit build debug cycles just because you don't have to send your app through that USB cable. And of course, Simulator can also simulates as it were exceptional conditions like pretend that there is a little memory warning issued by the system and see how your app reacts.

Typically, you're supposed to then deallocate any resources that aren't being used at the moment. Some things you can only really do on the device. Performance analysis in terms of, you know, sampling to see where I am spending most of the time, those kinds of things. That's obviously something you want to do on the phone because if you do that on an eight-way very fast Mac Pro you're not going to get meaningful results typically. So something that runs plenty fast in the simulator maybe too slow on the device and of course, hardware accessories.

iPhone SDK 3.0 lets you talk to your own hardware devices, that's not being simulated in the simulator, not even accelerometer those kinds of things either.

You can take advantage of the difference too though. Because the Simulator is just a Macintosh Application and when you build your iPhone app for the Simulator, you get a Macintosh Application. You have access to things like the file system. So this path here shows where and this also available in the documentation of course.

It shows where in your home directory the simulator view of the phone file system is stored. So this means that if your application writes some application-- writes some files, you can actually just go out and look at them in the file system on your Mac and that's a lot easier than pulling them back from the device and then looking at them in some other way, although you can do that too. You can go to one of the Xcode sessions for more information about that. They'll get into more detail about how to talk to a device through Xcode. One of the other things you can do, you can take advantage of that power in the Mac Pro.

And let's say you have an application that does some data processing, you can add records, remove records, you have some code that updates the database of some kind. For database you probably use Core Data but then you have some other structures internally. One of the things you can do is if you have some exhausted-- some code that does some exhaustive tests, integrity check of this data structure, you can actually run that after every event.

Let's say, the user goes to reorder two items, you could run that in an exhaustive test on your whole-- integrity of your whole memory collection. You could do that on the Mac because you have the horsepower to do it but on the phone, of course that would be too slow.

So this is one of the ways in which you can take advantage of the simulator. You can run with full assertions enabled and that can help you to find problems faster. If you do want to have separate code for the phone and for the simulator, there is a macro that is provided whenever you build against the iPhone SDK, and it's simply target iPhone simulator.

So you can check for this and you can have simulator specific code versus the device specific code. This slide is just a bit of a summary of some of the things you do and you don't want to do on the simulator versus device. It works really what is best for.

The fastest turnaround for most cases is going to be the simulator, simply because the app does not have to go on to the device. Debugging as you saw you can do on either. You can stop on breakpoints, you can set conditional breakpoints, breakpoint actions, you can expect your memory, all of those things work just as well on either of the device or in the simulator. Performance tuning is something obviously you want to do on the device.

It doesn't help to know that some operation takes half a second on a simulator because it's being run on your beefy desktop machine and who knows how long it's going to take on the device, so that you really need to do on the hardware. Memory tuning and leak checking, you can do on either because if you lose an object or leak an object on one set of logic on the simulator, you probably going to do the same thing on the device.

Unless of course, you have a lot of codes that's different between the device and the simulator so you want to keep that to minimum. File access, you can also check that. One of the things Michael didn't have time to show is in addition to the leak checking and memory checking, you can add another instrument there which is, OK, show me file access. And in this case it would have shown that that image was getting loaded multiple times from disk.

So if you see that together with a memory leak, that's a good indication that you're a loading a resource and not leaking it. That can be done on both. Things like hardware accessories, accelerometer, the magnetometer those kinds of things, the camera, obviously there are somethings you want to test on the device itself.

So that summarizes the iPhone Simulator. And that kind of brings to conclusion, our brief tour of the four most important tools I'd say for iPhone development. As you've seen, we've talked a little bit about each of these. There are plenty of sessions that go into these in a lot of detail.

Xcode is/are integrated IDE with project managements, source code control, integration with various source code control systems, subversion, CVS, those kinds of things. And obviously, a powerful editor and also as you've seen in some of the new Snow Leopard features, static analysis and a lot of good stuff in there.

Interface Builder is/are-- is Apple's interface prototyping and implementation tool for both the Mac and the phone. And again, one of the most important things to remember about it, is that it doesn't generate the tons of codes that you going to have to maintain. It actually lets you edit the objects that are actually going to be loaded at runtime whether on the Mac or on the phone. It lets you edit those, modify them and then you go back to edit your user interface, you're just changing attributes of those objects.

You're not regenerating code or any of that kind of thing. Instruments is our flagship performance analysis tool and it's really powerful and especially because it let's you hook up an arbitrary number of instruments to your process and see what it's really doing, what system calls are being issued, whether zombies are being triggered because you have dangling pointers and those kinds of things. And it works again for the Mac OS X.

If you're doing Mac OS X development, works for simulator for the device. And finally, if the iPhone Simulator, most of the time just kind of shows up and does its work obscurely in the background but it also has some unique features to it like being able to simulate what an incoming call looks like and being able to simulate low memory conditions, those kinds of things. And actually, we did not mention it but it actually supports Multi-Touch by using option click and those kinds of things, it supports pinch gestures and push and those kinds of things.

You can actually do all those things in the simulator as well. For more information, please contact Michael Jurewitz, Developer Tools Evangelist who has also been on stage. We have a lot of great documentation for iPhone development and for the tools in general. And actually in Xcode 3.2 which is-- what you get as a prereleasewith the Snow Leopard, the documentation integration in Xcode has been greatly improved.

So I encourage you to take a look at that. I encourage you to run the prerelease tools and provide feedback about those. Remember when it comes time to ship your app, you need to build that using a released tool set and currently that's the one you get with the iPhone 3 SDK, that's Xcode 3.1.