Good afternoon. Welcome to session 906. I'm Anders Bertelrud. I'm an Xcode architect. And in this session, we're going to take another look at Xcode and some of the developer tools, but do it a little bit differently than what you may be seeing in the past. In the past few days, you've seen many examples and demos, introductions to Apple's developer tools.

Here, we're assuming you are the experienced developers. You come maybe from Visual Studio or Eclipse, have that kind of background. So here, we'll want to give you maybe a little bit of a broader overview of the toolbox we have, show how it fits together, especially how it relates to Visual Studio and Eclipse in particular. To do that, we'll be taking a look at a sample project that you've already seen, but we're going to take it a little bit further than you've seen in any of the previous sessions. And we'll do that in order to illustrate some of the differences.

And some of the things that are maybe the same with Visual Studio, Eclipse, vis-a-vis Apple's developer tools. The goal here is not to give you a tutorial, but to show you the tools, how they fit together, give you a taste of their capabilities, and help direct you to further resources like some of the great sessions we have coming up tomorrow and the rest of the week, and also in our documentation.

A new one I want to show that maybe you have not seen yet, this WWDC, is Quartz Composer, which allows you to edit rich media content and then connect that into your user interface and your code. So we'll be taking a look at that. And of course, Instruments, which is our central place to analyze your program to see how you can tune it. And it's a multi-track recording of your performance metrics for your program.

Under the Utilities folder, we have a bunch of other programmer tools that you may not have heard of. There's tools for comparing files and file hierarchies. There's a tool called Package Maker that we'll talk about today, which is for creating installer packages. Under the Graphics tools, we have OpenGL Shader Builder, which is great if you want to develop shaders, debug them, and other graphics tools for high DPI work, that kind of a thing, testing.

Under Performance Tools, we have Shark, which is a great tool for more instruction-level analysis of your code, and OpenGL Profiler or some other tools like that. That's the basics developer tools folder. Many of these icons are already familiar to you. Where do we begin? Well, Xcode. That's the center of the developer experience.

I just want to give you a demo rather than show you a bunch of slides. Let me show you some things. In particular, I want to highlight some things. It may be similar with Visual Studio or Eclipse, which you may be used to. Could we have Demo Machine 1, please? Thanks.

So let me start Xcode. And one of the first things you see is the Welcome panel. And many of you may just click to close this, but there's actually a lot of information here for you. Obviously, there's the iPhone Developer Center and the Mac Developer Center. Just lots of great introductions, not only to the APIs, but also to some things like the system concepts that may be different for you if you're coming from another environment. We have live Xcode news that goes out to Apple's web pages and fetches the latest updated samples, those kinds of things, mailing lists, and all kinds of stuff like that.

But to get started here, I want to show you, first of all, what you typically do is create new projects. We've all seen this at this point. Let me resize this. We have, obviously, both the Mac OS and the iPhone OS templates, as you've heard several times already, Xcode Interface Builder. and instruments are Apple's developer tools for both the Mac and iPhone.

What I'm going to do here though today is to show something a little bit more interesting maybe. We also have good SCM integration with subversion, CVS, and Perforce. And I showed you here how to configure the repositories. I just brought up the preference panel. I'm going to go ahead and browse the repositories. And I'm just accessing a local source code repository that I have on disk here. And let's take the demo app that Todd and Andreas showed in the State of the Union yesterday. I'm just going to drag this out into the desktop.

What I'm doing here is I'm looking at my repository. I can browse it. I can say I get info and look at the check-in history of any given file, all kinds of stuff like that. At this point, I've checked out a project from the repository just by dragging it to the desktop. I'm going to close the repository and just open up the project. So I'm doing this because I want to give an overview of what's in an Xcode project, specifically if you're coming from Studio or Eclipse. So at the top, of course, we have a toolbar. Whoops.

I wanted to create a nice little box like that. So we have a toolbar up at the top, fairly typical. And on then the right-hand side, sorry, the left-hand side, we have the contents of the project. So up at the very top, we have just plain hierarchy of references.

If you're coming from Visual Studio, a project is kind of like a solution. And then the projects underneath in Visual Studio correspond to Xcode's targets. If you're coming from Eclipse, this should also look fairly familiar. It's a hierarchy of references up in the left here. So all your source code is here.

The source code itself lives on disk. We don't try to have a database with all your code in it. We still want to keep things as flat files so you can use any tools you like on them, such as text editors. But we reference them from the project. By clicking on the project here, on the group here, I see my files that are in that group. And obviously clicking on one, I see the source code down here.

If the code here actually mattered, then this would have been too small of a font. But I just want to get the general picture across. Underneath the groups here, we have targets. And let me highlight that briefly. Targets are the individual instructions for building a project, building some code from your source code.

And then executables underneath that show how to launch a particular program with a set of flags. Let's say you want to launch it with a set of test documents, those kinds of things. . Underneath that down here, we have other smart groups. And this looks a lot like iTunes, right? You can click on a smart group and see, let's say, all the files that have errors in them, all the files that have find results or that have been touched in terms of SCM, those kinds of things, source code management. And you can define your own custom smart groups as well.

So at this point, I want to go back and explain some more of the concepts. I'm going to build and run the program just so you see which one I mentioned. It's the one that you saw probably in the State of the Union. I'm going to leave this running here for the next demo. And if we go back to slides, please.

Thanks. So what do we just do? Well, we create a project. And again, a project is a container for all the parts of your software. It's the source code and the instructions for building it, those kinds of things. And when you decide what to make a project, well, usually it corresponds to a software concept. It could be your whole program, it could be a project. Or you could have a project for each library that you use, that you work with, if you have a bunch of reusable code, and then an application that ties that together.

Again, it contains everything that's needed to build your product. So that's the file references. And again, the references, it's not the actual code itself. That's the same as in Studio and Eclipse, I think, just references. Groups, you can group the files, the references in arbitrary ways. You don't need to follow the structure on disk. You can actually group them by function in the IDE, different from what it's in the file system. There are targets, which are the instructions for how to build. And then launch context, which is simply the flags and those kinds of things for how to test your program.

Here are some new terms on this page. May or may not be familiar. Projects contain targets, and a target then has build phases, which is compile my files, copy my headers, those kinds of things, copy the resources, maybe compress the files, those sorts of things. Each individual file, the decision for what happens to that is determined by the build rules. So a build rule is what, for example, says that a .c file is converted to a .o file using a compiler, that kind of a thing. So you can configure the build rules to change what compiler you invoke for a source file.

Build settings, they are the knobs and switches that determine all the little things from what's the name of the thing that I'm going to produce on disk, what's the name of my app, to what are some of the optimization flags, to search paths, those kinds of things. This, again, is probably similar to what you're familiar with from Visual Studio or Eclipse, and even GNU Make uses dollar per n syntax for build settings.

A target can depend on other targets. This just means that the one target needs the other one to be built before it is built. Again, this is a fairly standard concept. It may look different in our UI. We have three targets. One depends on the two other targets. Not a big change, even though the icons may be different and those kinds of things.

Some more about the build settings. There are specific values of the tool options. When you look at the GCC manual page and terminal, for example, you see all kinds of switches. Well, a lot of those, the most important ones, in Xcode we expose those as build settings. And you see these in the inspector and you can set values for them, such as Boolean values or enumerations, those kinds of things.

They're organized into configurations, which are essentially just style sheets of build settings. So you can have one that you apply for a debug build, another one for a release build, and you can create your own as well. There's default values for everything, and they're arranged in a hierarchy. You can set settings at the project level, at the target level.

You can set the default values for the build settings, et cetera, and they'll override each other. There's a particular type of a file type called XC config, which is a text-based representation of build settings. And that's really nice because you can check it into your source code repository. You can do differences between those kinds of things. So you can see exactly what changes you might have made to your settings.

So we've talked a little bit about some Xcode concepts. What are some sort of behind some of the screenshots you've seen? Some of the system concepts may be new to you also. Mac OS X has this thing called a bundle. A bundle is just a directory hierarchy full of files and directories that are shown to the user as a single icon, as a single entity. So an application, for example, is a bundle. And it's got resources. It's got code. It's got all kinds of stuff in it.

And another type of bundle is a framework. And that's a term that may be new to you. That's simply a library that's bundled together with its resources and headers, stuff like that. So in Eclipse, for example, in the Java world, this would be similar to a jar. A bundle is essentially a jar. In Visual Studio, that would essentially be the same as an assembly, as a bunch of files and folders that are related, and then some metadata about that.

Bundles allow us to do localization because a bundle can contain multiple Lproj folders, what's called Lproj, and that's because the suffix is .lproj. The Lproj folder can contain not only string files with text, but also UI files, interface builder documents, as you'll see in a demo shortly, and also animations and splash screen art and those kinds of things as well. Very often what you'll do is you'll develop in a single language and then localizers will localize the content and maybe even adjust geometry of UI elements, that kind of thing. And then you can incorporate that into the bundle at a later time, shortly before you ship.

Another thing you may have heard about is the Maco file format. Maco is just the Mac OS X equivalent or analog to PE or ELF. It's a binary code format and very similar to what you might be used to from any other compiled platform. Universal binaries are a way to package multiple code files for multiple architectures into a single file. And the advantage of having it in a single file is that your code can still treat it as a single file.

So if you want to call a command line tool, you don't need to worry about are you going to call the 64-bit version or the 32-bit version or any of that. You just call the tool, and then the container format contains a header at the top and then an arbitrary number of architectures, each of which is a Mach-O file. So that's another concept that may be new to you.

To continue on, I would like to invite one of my colleagues up on stage, Chris Hanson, to talk to you about taking this project further. Thanks. Thank you, Anders. I'm Chris Hanson. I also work on developer tools at Apple, specifically on Xcode. One thing that Cocoa provides for you by default is and Andy . We have an about baffle panel in our demo application right off the bat that Cocoa provides automatically. It provides useful information. It shows our icon, name, version number, and if we put copyright strings and so on in there, it would also show those. But it is a little bit plain. So we would like to jazz it up a little bit.

I'm going to use that as an opportunity to show you some of the features of the Xcode editor and later some of the features of the interface builder tool and Quartz Composer. First, let's quit baffle. Because I'm going to show you the editor, I'm going to open up Xcode's preferences and change our fonts up a little bit so that they're nice and visible. So I'm just going to kick the font size up to about 18. Gotta make a copy, of course. Kick the font size up to 18.

There we are. So the first thing I'd like to point out is that while Xcode might look a lot like the editors and IDEs you're used to, there are some different features in its editor. For example, we don't have tabs across the top. Instead, we have this handy navigation bar here. So every editor you see is going to have a navigation bar that lets you get around both the code within the editor and around your project as a whole.

One of the controls in the navigation bar that lets you navigate around your entire project is the history popup. This lets you see all of the files that you have in your project that have been opened in that editor. So as we navigate around in our project, say within the views in this application, These are accumulated into our history. And we also have a back and forwards button right next to our history that let us go between all of the files we have open in this editor.

Of course, no code editor would be complete without a way to see the definitions in a file. If I go down to this view here that has a lot of pound defines, it has an implementation of a class, it has some functions and methods in it, we can navigate within the file just using this popup.

We also have a handy popup over here at the right that lets us see the class hierarchy that this class descends from. So we're in the scratchpad view, and we can see that it's a kind of NSView, which is a kind of NSResponder, which is a kind of NSObject.

And we can even select one of those to go immediately to the definition of that class. And if I just hit the back button, I get back to where I was. We even have a popup that shows you all of the files that you include, and if you look at a header file, you can even see what includes that header.

Now, rather than write a bunch of code for you, I'm just going to drag in some pre-baked code that we have here. is going to drop it on Baffle Cocoa. And I've added references to this code to our project. And the first bit of code that I've added is our About panel.

So what I'm going to show you in our about panel is how some of the features work when you're actually writing code. We have this all credits method that just returns a collection of credits for application. The things that we're giving credit to for making our application great. One of the features we've added new in Xcode 3.1 is something called edit all in scope. That lets me select this credits path local variable here. You can see in the other places in this method where it's used, it's gotten a faint underline.

That means I can either hover over it, or choose edit all in scope from the edit menu. And now all of the instances of it are highlighted. Once they're highlighted, I can just type and I've changed to every place in this method. and of course once I move my insertion point out of it, the highlight goes away.

Next, I'm going to retype this section of code just to show you how some of the code completion and research assistant features work in the Xcode editor. So, let's just insert a new line here. and I start typing path. You can see that it's completed faintly to the right of my insertion point in gray, right there in my code, rather than popping up a list of possible completions. To accept that, I just have to hit tab and it completes it for me.

I will type the next little bit of code here, which is NSBundle. You can see Xcode is proposing a completion, but I can also hit a keystroke, control, comma, we have a couple of different equivalents for this, to see a full list of possible completions that start with NSB. I can just navigate around this using the arrow keys and I can hit return or tab to accept that.

We also have a feature called Research Assistant in our help menu that shows you reference documentation about your code. So I can just resize this, I can move it around, I can put it in one place, and then I can go back to my editor and start typing.

So if I start typing, I get main bundle, and you can see that the Research Assistant has updated to give me documentation on the NSBundle classes main bundle method. And it's only the most relevant documentation. It's not a complete treatise on what that method does, but you can see that it's also been available since Mac OS X 10.0, that there are several other related API. and you can even see sample code that uses NSBundle's main bundle method.

Now I'll go back here and finish typing it. And then start typing the next bit of this method. Now, as I type path for resource, this is a method that takes two arguments. So because it takes arguments, Xcode proposes the completion of that method with what we call placeholder tokens. So if I complete this method by pressing tab, I immediately get one of these tokens highlighted and you can see that the next one to its right is faint and in blue.

We actually have keystroke navigation between these. So if I want to fill in the second one first, I can just hit control slash and go to it immediately. And I can just navigate between them. And of course, when we start typing, We replace the token. And because this is a token and not just text in our file, we can even do things like click the token and the entire thing is highlighted. That really cuts down on sort of the incidental editing that you have to do to write code.

and syntax highlighting. The highlighting there told me I had forgotten a double quote. and as I typed that final bracket, you can even see that we highlight our brackets and parentheses and so on for you. I'm just going to get rid of this. And go back to the slides.

So one thing that we didn't see in text editing was that we also have a great feature called Code Focus that lets you really sort of zoom in on only the code you're working on by letting that be in bright colors and fading everything around it out. So as you go in and out of different scopes, the scope that you're in is always distinct from all of the scopes around it. And of course, as a programming editor, we have code folding that lets you just get rid of parts of the code that you don't need to see right now. And as you saw, we have syntax and symbol-driven coloring in our editor.

and one thing that you may have seen, ah, the slide has been updated since I wrote it. If your fingers are used to Emacs, and that's not Emacs the Mac, but Emacs the text editor, they will really be pleasantly surprised as you're working in not just Xcode, but any Cocoa TextView.

We support many of the common Emacs key bindings, like control A to go to the beginning of a line, control E to go to the end of the line. And I found myself just naturally typing those because I'd been programming on Unix before I came to the Mac, and they just worked. It was great.

Of course, we saw the navigation bar and the function or definition pop up. We have features called jump to definition that lets you highlight a symbol and immediately go to where that symbol is defined. We have a class browser so you can navigate a class hierarchy and get documentation on the classes. And finally, we have a tool called open quickly that was shown in the last session.

In terms of code completion, our code completion is called CodeSense. It suggests completions in line as you type. It puts placeholder tokens in your code for arguments. And we have keyboard equivalents that let you write code fast, like control period for completing now or you can also hit tab. We have control comma for showing the completion list and we have control slash and control shift slash for showing the completion list. So you don't need to type the whole of anything essentially as you're writing code in Xcode.

We saw edit all in scope and how it lets you make simple common changes fast. We even have a keystroke equivalent for that so you don't need to take your hands off the keyboard to invoke it. As you're typing, if you need to rename a local variable, you can just hit command control T while it's highlighted and just start typing and it changes. Such a time saver.

Of course, as a modern IDE, we also have refactoring, and we support most common refactorings. And we don't just support refactoring of your source code. Mac OS X applications use resources to represent a lot of things. And those resources aren't actually code themselves. They're object archives and things like that. But we'll actually look into them and change occurrences of things like class names as you rename them in your code as well.

and the rest of the team. We have integration with developer documentation such as conceptual guides and framework references and our documentation, as I'm sure you found in the past day, is automatically updated. You can also create your own documentation sets that are available through the research assistant and through the documentation viewer right from Xcode.

We saw how Research Assistant gives you only the most important information that's specific to your current context while you're coding, and it stays wherever you put it, so you can always find it on screen. You don't have to hunt around for where is this documentation on what I'm typing right now. It's always where you expect it to be.

Of course, if your fingers have hardware keyboard equivalents for other editors, you can set up Xcode to behave like them. You can add keyboard equivalents for any editing command or any menu command. And if you have operations that you perform frequently that are represented in the toolbar,

and finally, we have text macros. These are really handy and they let you insert snippets of code into your code.

And we have a bunch of common text macros set up right at the end of the edit menu. For example, you can just type a few characters and hit the same code completion key that you would for code sense and you'll get a definition of a class. Complete with placeholder tokens that you can just rename and be done with.

We even support scripting within the IDE. This isn't an embedded scripting language. Instead, we allow you to write scripts for any of the scripting languages that are supported on Mac OS X, Python, Ruby, Pearl, Apple script and so on, right within Xcode, and then run those from keyboard equivalents or from menu commands. And these can actually be passed information from within Xcode, such as your current selection or the selected file, and operate on that and pass information back to Xcode.

So now that we've written some code, how do we design the rest of our application? We didn't really write a lot of code to put up our user interface, so how do we do that? Well, if we go back to the demo, First, let's see how our About panel actually works.

Well, we use Interface Builder on Mac OS X and on iPhone OS to build our application user interfaces. So I'm just gonna collapse a couple things here.

So here we see that the baffle main window is also defined in this main menu file. We'll just close that up because we're not going to edit that. And instead, we're going to open the main menu. And of course, we directly edit our menus in Mac OS X in sort of the same representation that you see on screen.

What's unique about this compared to the designers you might be used to from Visual Studio or Eclipse is that we're not generating any code as you do this. Instead, we're generating object archives that are just deserialized at runtime. So the objects you're working with in interface builder are in a sense the objects that you're actually going to work with once you run your application.

So this about baffle menu item, we can just control click on it or right click on it and see a list of connections for it. And one of its connections is a sent action. which it's hard to see here, but it says order front standard about panel and it's being sent to files owner. And you can see as I mouse over this, that files owner highlights in our interface builder document window in the lower left.

and this is a message that's actually going to be sent at runtime. And it's an Objective C message, but just double clicking this only lets us edit the text. It doesn't take us to the definition of that message, because that message is actually part of the Cocoa framework itself. It's not anything we've had to implement.

Well, what do we do if we want to implement our own About Panel? We've already defined some code for our About Panel in Xcode as About Panel Window Controller. I just dragged that in on the last demo. So let's go back to Interface Builder. And I just want to create an About Panel Window Controller.

So I'm going to look for an object in my Interface Builder library. And this handy search field, let me find that fast. I'm going to drag it and drop it straight into my main menu Interface Builder document. Of course, a generic object won't really do us much good. So I'm going to go to the identity inspector and tell interface builder that that should actually represent an about panel window controller.

Now, how do I actually tell my menu item that it should do something with my about panel window controller? Well, I can control click or right click on it to see its actions. And then instead of sending order front standard about panel to file's owner, I'm just going to drag that connection to my about panel. And Interface Builder pops up a list of possible actions that that panel can take, that object can take. I'm going to select show window. And that's it, I've changed this connection. No code is generated.

and I haven't had to write any additional code to wire this up. Now let's actually lay out this window. Well, we're going to create a new interface builder document for that, which just contains a plain window. We already have our window here, but let's change its name to something more appropriate, like AboutBaffle. and just to be on the safe side, I'm going to save it immediately. As always, save early and often. I'm not expecting Interface Builder to crash. That's not why I'm saving. I just like to save for my own security.

I'm going to navigate to where we put our baffle project and add this to baffle Cocoa. I'm going to call it about panel. and save it. Interface builder will ask me if I want to add it to an open project in Xcode. This is because our tools are integrated. Even though we have special purpose tools, they do talk to each other and learn about each other. So I'm not just going to tell interface builder to add this to my project. I'm also going to tell it to add it to the baffle Cocoa target.

and you can see that it now knows about the bafflecoco project. And that means I can tell it that its owner isn't just a generic object, but is actually going to be and about panel window controller. So what is this file zoner thing? Well, it represents the object that owns this interface builder document. Because an interface builder document is really only part of an object graph.

There has to be some way to hook it in to the rest of your application. And that's file zoner. So this file zoner object here is really a proxy to this about panel window controller right here. Of course, I need to tell that about the window itself, so I'm just going to drag from its window connection to the window.

I'm going to put a view in the window for our Fancy About panel. I'm going to use Quartz Composer for that view. Let's type Quartz into the search field. We got our Quartz Composer view as the first hit. I'm just going to resize this so it fills the entire window. And I'm going to set its sizing through our springs and struts mechanism.

So it stays the same size as the window. And finally, because our fancy about panel is going to push data to this view, I'm just going to drag from this credits view to this view. Connection on FileZoner, straight to the view itself. That means our About Panel Window Controller doesn't just know about the window that it's managing, but it also knows about a view inside it.

So we didn't have to look up that view by ID in code or anything like that. We can just use that as an instance variable. Now I can save this and close and close. And if I build and go, and show my about panel, we get our new fancy about panel. I'm just going to put this over here and go back to slides and talk a little bit about what we've done.

So Interface Builder, like I said, is our human interface design tool for Mac OS X and iPhone OS. And it edits a live object graph that gets serialized to an archive. So your code and your interface are wired together at runtime as you load these. And that wiring together takes place automatically through Cocoa. It's not a code generator. It's not generating reams of Objective C or C code to build that interface with comments around it saying don't edit this.

At the same time, it's also not doing anything that you can't do in code with a bit more work. So if you want to instantiate a button dynamically, you can. You don't have to create an interface builder document just to contain that button. And it's really a tool for everyone.

Because it isn't a code generator, because it doesn't follow bad patterns, experienced professional Cocoa developers have been using interface builder throughout Cocoa's existence. It's not a newbie tool. And you can also give it to your designers. Because Cocoa follows a model view controller architecture, you can put together sort of a prototype interface, hand it over to designers who understand interface builder and how to work with it.

And as long as they preserve all of your connections, they can make the interface as slick as they want it to be using features like core animation. And it'll still just hook up to your code. And this is also how you do localization. You hand over your interface builder documents to your localizers.

They can open them up, and change the text and change the metrics so that you get a pixel perfect localization even in other languages. For example, German text is typically about 30% larger than English text to say the same thing and you won't just want to automatically expand every control by 30%. Sometimes you might want to move things to a separate line. Sometimes you might want what is one line in English to be two lines in German and so on. Interface Builder gives you the flexibility to have tweaked localizations for every language and locale that you're delivering in.

Now, one thing I didn't show is Quartz Composer. I showed you the result of Quartz Composer, but it actually works a lot like Interface Builder. You create objects and you wire them together in a graph called a composition. And just like Interface Builder, it doesn't generate code. It just generates a graph of objects that you can load and connect your code to at runtime. But again, it doesn't do anything that you can't do in code if you want to invest a little bit more work in it. If you have a completely dynamic system that you want to generate a composition for, you can do that.

Quartz Composer is a designer-specific tool. Fortunately, thanks to Model View Controller, you can create a basic placeholder composition, decide what inputs it needs, what inputs that you're going to hook to from your code, and then toss it over the wall to your designers. They can spend the effort on making it slick and they can apply their unique experience and they can hand you back a version that you can just drop into your code and that will just work.

Now, we talked about designing your application and editing your code, but what about your data? Well, we do have data design tools, too, and we have a framework for managing your data in Mac OS X called Core Data. I'm not going to talk too much about this because we have several sessions tomorrow on it, but it lets you do entity relationship modeling of your data and manage its persistence from within Xcode. And it really implements the model-in-model-view controller.

One of the features that this gets you if you're doing Mac OS X application development is seamless, effortless undo and redo. And again, it's not a code generator, but if you do want to create models at runtime and use those with Core Data, you can do it. It just requires writing a little code.

So there's one thing that I showed in the demo, and that's this kind of undulating blue, but there was nothing on it. Well, we were gonna give credit to the technologies that we're using in our demo. Joar is going to help us debug why we weren't seeing that.

Hi, my name is Joar Wingfor, I'm also a developer on the Xcode team. As Chris pointed out, we expected to have a list of names showing up in the about panel, every name showing up for a couple of seconds to then be replaced by the next name in the list. And to do that, we had set up a recurring timer in our code, and every time the timer fires, it would invoke a callback method in our code. So to debug that, I'm going to drop down into the debugger by setting a breakpoint in that callback method.

I'm going to expand the window a bit. Now, as you've seen in earlier sessions, we can actually get most of our debugging work done right here in the editor. There are three basic things to debugging. You want to be able to set breakpoints. You want to be able to step through your code. And you want to be able to view your memory.

And you can get all of that done right here in the editor. So to the left of the editor window, we have the editor gutter where you can set and manage your breakpoint. On top of the editor, right above the navigation bar that Chris introduced to you earlier, we have the debugger strip that we have seen before.

Going through the debugger strip from left to right, We have a popup showing all the threads running in this application. Next to that we have a bunch of stepper controls that allows you to step through your code. And to the right of the rightmost in the debugger strip, we have a popup that shows you the call stack of the selected thread.

To view memory, we have data tips that you might have probably seen in other sessions. Data tips shows you data structures and objects that you have in scope. And in the data tip you have, from left to right, you have the type of the variable, the name of the variable, and the value of the variable. So for an object, that would be the address of the variable. You can also drill down into the data tip.

In case of an object, drilling down would allow you to see the instance variables of that object and the instance variables of the superclass. If you want to get to more advanced functionality or get a better overview over your debugging, we also have a dedicated debugger window.

The debugger window probably looks a lot more like what you're used to from other environments.

In top left, we have a threads list that allows you to select threads and show the call stacks of the selected thread. And next to that, we have the variables list showing arguments to functions, local and global variables, and even registers. And below that, we have a source editor.

You can also open the console window. The console window serves two basic purposes. First, it shows textual output from your application, typically debug log statements, but it also allows you to interact directly with a debugger using debugger commands. The underlying debugger technology for Xcode is GDB, the open source debugger. So if you know GDB or if you want to look up the commands in the man page, you can use all of them in the Xcode console.

We also have a number of components to the Xcode debugger that I'm not showing here. We have a disassembly view that shows you the raw instructions of your program. We have a memory browser where you can view the raw memory of your application. And we have a dedicated breakpoints window where you can add and modify and manage all of your breakpoints in your project in one place.

For this demo, I'm going to do the debugging back in the editor. So I'm closing this debugger window now. This is the callback method where I'm supposed to update the name in the about panel. We will do that on this last line of code here. And the next name to be updated is this next credited variable.

And as you can see from the data tip, the value is nil. You can also see that the name is red here, meaning that this variable was updated on the last step of execution. Whenever you see a red value in the debugger in Xcode, that means that that value was just updated.

I'm scanning through this method. Nothing really sticks out as wrong. I will have to step through this. To do that, I can grab the program counter over here. That's the red arrow. I can just drag that back up to the top of the method to start over and step through the code.

So the first line of code here is called to a method called allCredits that you find right above the method that I'm in. So if I hit the step into button, I'm stepping into that method, stepping over the first line of code, and then inspecting that variable, we see that, well, that's nil, too. So we seem to have the problem already here in the first line of this method.

And just by inspection, I can see that I'm trying to look for the path of a file called credit. But if you check over here, you see that the file is actually called credits. So, it's a -- we have typed the wrong name. So, just by correcting that, I should be able to fix this problem. So, I'm going to hit build and go.

Launching the application, opening the About panel. Since I left the breakpoint around, the breakpoint hit again. And using data tips, I can now inspect and see that this time I do have the values that I expected. And if I disable the breakpoint and continue execution, You can see that the bound panel now works as we intended from the beginning. So if I could go back to slides, please.

As you might expect, in Xcode, you can use breakpoints to simply stop on a symbol or a line of code. For every breakpoint, you can assign a condition, and this condition would need to be satisfied for the debugger to stop on the breakpoint. You can also assign one or more actions, and these actions would be executed as the debugger stops on the breakpoint.

There are several different types of actions to choose from, but the two most useful types of actions would either be a log statement, where you provide a printf style format string to the debugger that can reference this data in scope. So you can output data to the debugger console much like you would do with a debug log statement. The other useful type of debugger action, the other useful type of breakpoint action would be to execute any type of debugger command. One of the more commonly used debugger commands for breakpoint actions would probably be to print the backtrace of where you have stopped execution.

Thirdly, you can also set your breakpoints to automatically continue after having executed your breakpoint actions. And this would typically be used for, for example, if you have a breakpoint set up with a logging action. So you would have your breakpoint log something and then just automatically continue. You could also often see breakpoints being set up to log the backtrace and then automatically continue. Very useful.

Finally, as you create new breakpoints in your project, the breakpoints are associated with that project and persisted with that project. But you often have code shared between several projects and you might want to have the same breakpoint set in all of the projects where you use that code. And in these cases, you can change your breakpoints from being project scope breakpoints to be global breakpoints. Meaning that whenever you open a project in Xcode, you will have access to that breakpoint. It's a very convenient way of sharing breakpoints between projects.

So, suppose you have a game like in this case and you wanted to run full screen. If when you're running your application full screen, you can't interact with the standard debugger UI at the same time. So, one way of solving that problem would be to use remote debugging from a separate machine. You can also in many cases use the Xcode mini debugger.

Even if you're not running full screen, it is sometimes a bit too intrusive to have to switch back and forth between your application and Xcode. In these cases, you can also use the Xcode Mini Debugger. The Xcode Mini Debugger looks like this. It's a small window that floats on top of your application. It starts out small like this, but as you pause execution or as you hit the breakpoint, it expands to show you the familiar in-editor debugger UI with the data strips, with the breakpoints, and with data tips to show you memory.

Finally, we have these four separate ways for you to interact with the Xcode debugger. There is the rich, traditional debugger UI provided by the debugger window. There is the debugger strip that allows you to stay focused on your code and get most of your debugging done right there in the editor. For full screen applications and less intrusive debugging, we have the mini debugger. And for textual output and for direct access to the debugger command line, we have the debugger console.

and moving on, this is my second part. I'm going to talk to you a little bit about performance tools. Performance Performance analysis is very important, and the ability to troubleshoot performance problems is very important. For that reason, we have a great set of performance tools available on Mac OS X. and the rest of the team. Too many to talk to here, but I'm going to give you a bit of an overview over our flagship performance tool, being instruments.

In this case, I, well, so, if I launch instruments, It will create a new document for me. This document will be used to collect performance data from my application. Before I can do that, though, I need to let instruments know what type of performance data that I'm interested in at this moment.

A very convenient way of doing that is to pick one of the predefined

Typically, when you are using instruments, you have some sort of idea of what type of performance problems that you are looking for. And then you would pick the appropriate template. For this demo, I'm going to pick the blank template and instead I'm going to manually pick the types of instrumentation that I'm interested in.

So, in order for you to get an overview over the different types of instrumentation available in instruments, you would open the library window. In the library window, you will find all of the different types of instrumentation that you can perform in your application. And you can pick and choose from this list.

For this demo, I'm going to look at file IO using the file activity instrument. I'm going to look at memory leaks using the leaks instrument and finally,

Since I already have my application up and running here in the background, I can simply attach to that application from instruments by selecting it from the popup and hitting record.

Instrument attaches to the application and starts to collect performance data. The instrument window has a couple of different parts. So the topmost part here is the timeline view. The timeline view is designed to give you a high-level representation of the data as it is collected by instruments.

It's also designed to give you, to make it easy for you to immediately pick out any performance problems that you have in your code. Below the timeline, you find a detail view. The detail view shows all of the performance data collected. It allows you to filter that data and to drill down into that data and look at it in detail.

So I can stop here. And so for the CPU sampler here, there are basically no peaks. CPU-wise, we seem to do fine. There is one peak here for memory leaks that we might want to take a look at. But for this demo, I'm going to focus on the fact that we have this recurring file I.O. operations here. Doesn't seem quite right. And this is probably too small for you to see, but here in the detail view, you can see that all of them are accessing the same file, our credits file, where we have these names that we display in the about panel.

By selecting one of these entries here in the detail view and opening the extended detail, I can also see the backtrace to this file IO event. And if I find my code here in this backtrace, I know that this is probably something that I could do something about.

The backtrace is color coded by library. So you can easily pick out the system libraries and separate them from your code. So in this case, I have my code down here. And I can double click on the last frame in my code, go back to baffle, and see that, well, we have this accessor method here where we request to have this list of credits where we pick out the next name from the list to show in the panel. And we actually reread this This would be a problem that we would want to fix. And I'd like to go back to slides, please.

Instruments is this umbrella type application that provides many, many different types of instrumentation. You can select several of these different types of instrumentation and run them side by side, have them collect data at the same time and present them to you in a way that makes a lot of sense.

We have these many great data mining and visualization tools that makes it very easy for you to correlate the data and to pick out the performance problems. Instruments also provides very nice Xcode integration. You can launch instruments from Xcode and you can also get back to Xcode from instruments.

There are a number of other tools that have been mentioned earlier already at the conference. So instruments, if you're new to the Mac, new to Apple, instruments should be your first choice. But if you're really into performance tools, there are a lot of other very interesting tools for you to take a look at, in particular, perhaps Sharks and Sharkenquartz debug. Most of the tools come with command line utilities. Being able to access the functionality provided by these tools at the command line is very useful when you need to do remote performance troubleshooting or if you want to automate your performance analysis and call these tools from scripts.

A very important underlying technology for instruments, a technology unfortunately not available on the phone or on the iPod touch, but available to you if you run your phone application. In the simulator is Dtrace. Dtrace is an open source technology created by Sun and made part of Mac OS X. It's very interesting and I would encourage you to take a look at that. And with that, I'd like to hand the stage back to Anders.

Thanks, Joar. All right. So you've designed and edited and built, debugged and tuned your application. What do you want to do? You want to ship it. So let's talk briefly about deployment. You might burn a disk and, you know, cut down trees to build a package and all that.

But Internet delivery is becoming more and more popular and fairly common. That said, first impressions are still important. So you might want to have logos. You might want to have basically virtual box art that shows up. How can you do that? Well, first of all, how do you install the application on the user's system? There's two basic options.

There's drag and drop, which you've probably all seen for a Macintosh application. You just have a single icon that the user can drag and drop onto their desktop or onto their applications folder, more likely. Or you can have an installer package. Mac OS X does have a built-in installer. Let's take a look at that. Keeping in mind simplicity, drag and drop is the preferred way when you can do it.

Because of the bundled technology, you can put the code, the resources, any kind of plug-ins that you need, help pages, documentation, all those sorts of things. You can actually put that into a single bundle. iWork, for example, puts even the templates, localized templates inside of the bundle. So you can have a single drag and drop application. And that's fairly easy for users to understand.

They can also drag it to the trash if they don't want it, those kinds of things. So for simplicity, robustness reasons and flexibility, do drag and drop install if you can at all do it. And one way to do drag and drop and still have a nice experience is to use a disk image. You can create a disk image and put your application in the disk image.

You can add customized compositions and custom artwork in the background that, for example, says, you know, drag this icon to the application folder with your branding, that kind of thing. The contents are compressed and users can mount the disk image on the desktop and access the contents without decompressing it.

Disk images are also great for Internet travel because they don't have resource forks or metadata or any of that kind of stuff that tends to disappear out in the ether. So they're just a flat file and all the goodies are contained inside of the contents of it. This may be a new concept. Well, it's a fairly familiar concept on Windows World, too. I think there's ISO, some other formats. But on Mac, it's typically called a DMG, disk image format. There's something interesting also called Internet-enabled disk images.

So you can have disk images that can contain, for example, a license agreement. And when the user goes to access the contents of the disk image, the license agreement is shown and they can agree or disagree. And, of course, it only opens up if they agree to the license. So that might be a good way if you want to have some kind of open source license or a commercial license on the disk image.

There's also automatic -- optional automatic extract and discard a disk image for maybe novice users who don't even know what a disk image is but just want to know what it is. So you can have disk images that are just a little bit more complex and you just want the icon to show up on the screen.

So how do you create one? Well, there's disk utility. That's a graphical utility that's on the Mac OS, not even the developer tools. That's actually installed with Mac OS by default. But there's also command line utility, and that's extra interesting from Xcode. I mentioned targets earlier. One thing I didn't mention is, besides building an application or a plug-in or a framework, a target could be set up to just invoke a shell script, and that shell script, or indeed any script, Ruby script, Python script, could do anything. So you could set up an Xcode target to invoke this HDI utility. You'll find lots of documentation about that in the developer pages. And then you could that way create a disk image automatically as part of your build. So that's a great way to do that.

If you don't want to create a disk image, you don't want to sort of go branding maybe isn't that important, you can just simply zip up your built application. Just create a zip file from it, select and finder, say compress, and then distribute that. That's also compressed and it's about as standard as it gets. Most people have heard of that.

There are times when it's appropriate to use the installer, and if you need to use it, by all means do. If drag and drop doesn't work for you, for example, you need to install a kernel extension, spelled correctly with an S, actually, but extension, launch daemons, other kinds of things. You may want to install specialized things in the file system. In that case, go ahead and use an installer package. There's a great tool that's called Package Maker, and that's in the utilities folder of the developer folder.

And that lets you build up the whole workflow for where you see the welcome screen to the license screen, maybe options for installing optional features, those kinds of things. It's a great tool. There's a command line equivalent of that, and that's called PKG Util, and that, again, can be invoked from a shell script within Xcode.

I mentioned these things, shell scripts being invoked from Xcode. There are some great sessions on Xcode introducing you to how to create complex projects and how to really take advantage of the build system, and I encourage you to go to that to see more about how to evoke these kinds of things from the build system.

So in summary, Mac OS X and iPhone OS, they provide a lot of functionality. And if you're coming from Eclipse or Visual Studio, you're not only used to a different IDE, but you're also used to a different set of libraries and frameworks, maybe a whole different way of structuring your program. So hopefully we've introduced in this session some of the differences and also some of the similarities. In some cases, the difference is only terminology. For example, we use the term bundle on Mac OS X.

Well, it's kind of like a jar file or it's kind of like an assembly. It just packages up all the stuff that is needed for, let's say, an application to access its resources and those kinds of things. So some of the concepts are different. We have lots of good documentation. There's also good sessions.

We'll provide some links to that. And sometimes the only difference is the terminology. OS X overview. There's an Xcode overview and a Mac OS X as well as iPhone OS overview. So there's a lot of good reviews that are really good. Xcode's welcome panel. I showed that. There's a lot of good information accessible right off of that, as well as many sessions here at WWDC.

I should say, here are some of the related sessions. I'll leave the slide up for a few moments. I'd like to bring up Michael Jurvets on stage at this point. We're going to go to Q&A here. We're going to have just a short time for Q&A, but come see us in the lab for more questions. We wanted to make sure we gave a complete overview here.