My name's Matthew Formica, I'm the Developer Tools Software Evangelist in Apple's Developer Relations Group and this session is Getting Started with Xcode. So as you may have seen in the previous session in this room, Xcode is the integrated development environment you'll use to write your code on Mac OS X and it's got a lot of advanced features; features you've probably seen demo'd yesterday in the state of the union.

But if you're new to Mac OS X Development with Xcode you may be wondering how do the standard every day features work. How do you use Xcode in a regular work flow and how do you get the fuller picture of what Xcode can do and that's what this session is for. How many of you were at the earlier session? Okay, a chunk of you. How many of you are relatively new to Mac OS X Development? Good, then this is the right session for you.

This is going to be a session for you if you are new to Xcode or to the Mac and if you're doing one of the two types of, two of the types of development that were talked about in the state of the union yesterday. Writing native code for the Mac or doing open source development on the Mac. What we're going to cover is the basics of Xcode 3.0, starting with first steps and first launch of Xcode all the way through the development cycle: editing, building and debugging your code. And you're going to see all of this in both slides and demos.

So let's jump right in. Xcode ships with Leopard when you install the development tools they'll live in /Developer by default, that's where you can find them on your hard drive. And I should make one note, which is that Xcode 2.4.1 is the current shipping version on Tiger our current GM release, but we're not going to be talking about that version in this session.

You can see when you open the developer folder that Xcode will be one of the icons in that folder in the applications directory inside of that folder. And when you double click it for the first time, you'll get a new user assistant that looks something like this. The assistant's going to help you with some basic configuration as you get set up.

The first thing it's going to ask you is where do you want to save intermediated files for your build and final results and products. And generally, the defaults are fine you can just click through that. The other thing it'll ask you is do you want your window configuration to be saved when you quit Xcode so that when you launch it again the next time all those windows will come back where they were. Some people like it, some people don't, it's your choice.

After setting up your initial configuration you'll be presented with the Xcode news panel and this will show up whenever you launch Xcode to give you up to the minute information about new updates to Xcode, documentation tips and tricks, links to sample code and so on. It's a great jumping off point to explore the documentation and find out about what's new with Xcode.

Typically as you get started on a project you won't actually be starting with a blank project. Instead you'll choose from one of the templates that we have that are preconfigured for building all kinds of things on Mac OS X. these templates give you prewritten source code and projects that are designed to help get you started whether you're trying to build basic Cocoa applications or screen saver plug ins, kernel extensions or whatever else you're trying to build on the platform.

Once you pick a template, give it a name, you'll be presented with the project window. And if you're coming over from Visual Studio I believe their word for this is solution, in Xcode we call them projects. It's basically the container where you'll do all of your development. And the project window has a variety of different components to it; first of all there's the tool bar with a variety of easy access buttons to do things like building and cleaning. Some of them have a little triangle on the edge, and if you click and hold you'll actually get a little pop down and it gives you extended choices for more things you can do.

On the left side of your project window is the groups and files list and this is where you're going to see all the source files in your project as well as any resources you may have associated with it. At the bottom there is actually additional other groups for special purposes. For example, your find results can show up there so you can easily jump back to previous finds that you did. You could also see for example all the symbols in your project by going to the right group.

The right hand side of the project window is the detail view and this will either show you a list of files in a particular folder in your project or it can actually show you the actual contents of a file. You could also double click source files to open them in a separate window.

Typically as you're working on code you'll want to bring up our full documentation viewer, this is what the window looks like. And it gives you nice documentation sets; grouping various APIs and functionality in Mac OS X. And you can actually subscribe to feeds for these different sets you get automatically notified when the documentation is updated. And when you're doing searches, you can search on specific strings in the documentation, on particular APIs or even titles of documents. So there's a lot of flexibility here for finding things in the documentation.

Okay, so you've got your basic project set up, you know where to find documentation. You'll probably spend most of the time in your development process in the code editor. So let's talk about that next. Xcode's code editor does what you would expect any powerful code editor to do.

It helps you write code quickly and easily with a smooth work flow via such features as syntax coloring, bookmarks, various pop ups and so on. Here's a screen shot of Xcode's code editor, you can see the syntax coloring, you can actually customize that. It also has a tool bar on top that gives you similar quick access as the project window did to things like building and cleaning.

Below the main toolbar is a little mini pop up bar that let's you quickly jump through things like all the headers that you have included in this particular source file, so you can easily navigate your code. And Xcode has code completion, there's two styles actually; one is the mail style complete and place and you can also have Xcode give you a full function pop up that gives you all the choices. Either way it's going to complete as you type and reduce the amount of typing you have to do.

As we demo'd yesterday in the state of the union, Xcode has code folding and code focus. You can collapse chunks of code so you can get a better picture of the layout of your source file and the particular chunk of code you actually want to work on. And message bubbles are also imbedded in Xcode's code editor. This allows you to see errors and warnings for your code when you're building without having to jump to some other build results panel that might be obscuring the code that you just wrote.

So Xcode's editor goes beyond simple things like syntax coloring and indentation to providing you a rich environment for your complete work flow as you work on your application. And at this time I'd like to bring up Scott Tooker to do a demo of the editor.

So just to give a little overview here, the project we're looking at is sketch which you can actually find as one of the developer examples on your developer DVD.

Just a quick question, how many people here are coming from a Windows background? UNIX background? Okay. One thing I wanted to point out is I'm working here in what's called the grouped editor mode. We're going to be staying mostly in editor for this demo. The Xcode does allow you to have one window per file, but for the purposes of this demo we wanted to show off the group mode.

So I'm your tour guide and I'm going to start off by showing you the navigation bar part of the editor. This is this thin strip up here and everything in here is about getting, moving within your file or moving to different related files. And so the one part you'll use the most, probably over ninety percent of the time is the function pop up or symbol pop up.

So you notice here what I get is I get a layout of here, all the, here's all the symbolic information in this file kind of laid out as you'd find it moving through the file. So for example I can click on mouse down, it takes me to mouse down.

Now we also support, if you hold down option key, you can get an alphabetical listing. So in some cases depending on how the files laid out it's easier to go with alphabet, sometimes it's better to go with how the original author laid out the file. Some of the other ways we can get around files as Matt pointed out is bookmarks.

So, for example, right now I've got one in here, it says start here for the debugging demo. And you'll notice that just jumps me to a given selection in the code. You can also, for example, if I wanted to go to the top and be able to jump where my imports are, you can select a range and then go to edit, add to bookmarks, it's command D just like Safari. And by default we'll offer to label this with the line you started your selection on, but I can name if anything I want so for example, my My Imports.

And then this will show up in the little bookmark pop up here and I can just jump around my code. This is really useful when you're exploring code or when you're dealing with code you know intimately and you just want to have some metadata that allows you to quickly get to places but you don't necessarily want to or you may not be able to edit the file itself.

Some other things we provide and this is new to, this next one's new to Xcode 3.0 is we provide class navigation now. So for example you'll notice I popped on, I bring up the C here and I can see the super classes for this class, I can also see categories on it.

And so let's jump to NS View and so you can see here, here are the super classes of NS View itself, various subclasses and categories. And for those of you that have had experience with Objective-C, you know that categories sometimes can be especially interesting to find since they may end up in different files and so this is a convenient way to see all the potential categories on a class.

Now for those of you who aren't doing a lot of object oriented programming, maybe you're more C based, for example, or C++, we also provide an include pop up. And so here what we're showing you is what is included by this file and then which files include this and so this provides you a nice way to kind of move up and down in your include hierarchy.

Now you may notice that when I'm using either the include hierarchy or I'm using the class navigator, it takes you to the definitions of the classes or the headers. So, well, how do I get quickly back to my implementation. Well in this case we provide what's called the counterpart, so here I'm in SKTGraphicView.h, which is my definition. But I can just click this little button here to swap quickly to the implementation for that file. This is probably the second thing you'll use the most, next to the function pop up.

Okay, so now let's jump over to the left side. One thing you've been noticing is I've been opening these files because it's grouped they're showing up in the same window, well, what you can do if you, for example, want to get back to a separate file, you can actually just bring this file pop up here and we'll just let you jump back and forth. So for example I can go back to NS View. You'll also notice, although it's a little bit hard to see here on this screen that we actually do badge the files in the pop up to show you which ones are locked or not.

In addition, we can also use the go back and go forward arrows and these just let you step through the files that you've been looking at. And then I mentioned you know we badge files that are locked, well we also provide you the ability to control that. Over here at the very edge we have a lock icon and this actually maps for those of you with classic Mac OS experience or some Mac OS X experience, this maps to the Finders lock flag.

For those of you coming from UNIX, that's the unchangeable flag. And so you can go in here and just lock down a file if, for example, you want to make sure you don't make any changes to it, or if you're using something like Perforce, it's one way to make sure you can have a file to be unlocked so you can go ahead and edit it.

Okay, so before I jump, that's basically the navigator bar. As I said everything in the navigator bar is predominantly about getting around your files, getting around the file you're in, going to other files, getting you there quickly and easily. One final thing I wanted to talk about that's kind of in between the navigator bar and the actual editor view is our split view button. And so what I can do here is I can just click and get any number of splits that I want and I can also hold down option and I can get side by side splitting.

I should point out the one thing we don't do currently that we, it's a requested feature, is that we don't allow you to mix splits right now so you can do all horizontal, you can do all vertical but you can't do both currently. So let's move on to the main editor window. As you can see in Xcode 3.0 we have enhanced syntax coloring here and this is something actually that, not only do we provide a number of different languages, you can actually customize the syntax coloring to your liking. For example I'm using a custom set right now.

We found out really late that we were going to have a lot more room on the screen so I went ahead and bumped up the fonts right before the session. But there are a lot of different types of, a lot of control you have here so, for example, and you'll have to forgive the fonts getting smaller but we have the default look and then we have things like the basic look or bare which are very, very simple if you don't want a lot of information showing up. But we also allow you to control things like the background colors so you can even do things like midnight where we swap in a black background. So let's go back to my large fonts.

We also provide control for our indentation which uses the same syntactic information we're using for syntax coloring, we also provide good automatic indentation support and also we're using that same information when we do code sense. So let me go ahead, I'm going to jump to this align, we're going to spend a lot of time in align left I did yesterday. So let's jump there for right now and make this window a little larger.

Whoa, let me just give myself a little room here. So what I'm going to show you now is the code, we have two kind of basic styles of code sense. One is we can automatically, we can not automatically suggest and it's all user driven. You hold down a key, pops up a menu, you can choose from that. What I'm actually going to show you is a mode that's new to Xcode 3.0 which is automatically, we always suggest, it's much like mail's inline completion.

So for example what you'll notice is as I type Xcode's automatically completing what I want. Now I can just keep typing and it will change. I can type the entire word here and it never gets in your way, so you can have it on, it will give you suggestions, but you're never going to get in the situation where it will try to override what you're doing; you're in control.

So here I've got selection and so if we want to bring up something else. So now at this point I've got the first, I've got objected index here. Now there's two different things I can do here, I can, well many things, I can continue to type, I can hold down the escape key to pop up a menu and I go up and select something out of here.

But the other thing I can do is I can also use control period to actually cycle through and in this case, and you'll notice here it'll just let me cycle through the various choices directly there and in this case I want an observe value for key path. Not that I'm actually going to do anything with this beyond the code sense, but we wanted to actually also show off the fact that you'll see we have these placeholders here for example string key path, idObject, NS Dictionary.

If you use control slash we have this nice feature where you can just cycle right through and go straight to each one and fill it in. So that's just a really quick introduction to code sense. We'll be talking more about this in the New Workflow Xcode session. So let's go ahead and revert that.

So the other thing we did, you know code sense, it's a common feature of a lot of editors, we wanted to go a little bit further and so we have all this syntactic information and we understand the structure we code but what can we do with that. Well there's two things we did. The first was a little, it's something new and the second was just an outgrowth of that.

And the first things which was new, we introduced what we call code focus and so what this allows you to do is have a very graphical representation of where your scope, where your current scope is. So you'll notice right now, the current scope is in white and as I get further away it gets darker and darker. And this provides a really nice visual cue to understanding exactly what's in scope when you're writing. And this works not just when editing but also when debugging.

In addition, as a part of this, we also added the ability to collapse code. So, for example, we'll just put in a little glyph here and you can either come back to the focus ribbon here or you can just go ahead and double click on the glyph to open it.

Also, if you go under view in code folding we added some nice conveniences like, for example, if you want to fold all your methods and functions, you'll notice that even though it says fold all, what we were smart enough to know is that, oh, you are in this scope so we're going to leave this method open.

So it really allows you to zero in on what you're working on and not have the feature get in the way of your coding. We also have the same capabilities from, oops, from the contextual menu which you can either right click or control click to bring up and so I'm going to go ahead and unfold.

Now the last thing I wanted to touch on here was documentation. As Matt mentioned, we have a great documentation viewer, a lot of great features in Xcode 3.0, but how do you get to it? Well, there are two features that lead up to this and then one of them that's a very common thing that lots of people use is called command double clicking. And what this allows you to do is it uses the indexed information and so, for example, I'm going to command double click on objected index and when I do that I jump automatically to the definition in the header.

Well that's great, unfortunately a lot of times the headers can be a little bit terse in what they might be able to tell you about a given method. So you can also option click on any symbol and then will automatically bring up the documentation window and you'll notice here that now I have the information about objected index, I can read through it and if, let's expand this window out a little bit, you'll notice that I can also, it has other references and it's just a nice way to get straight into the documentation and learn more about the Mac OS X APIs.

So with that you can see, and I've just touched the surface here by the way, there's lost of stuff that I've either glossed over or have not covered about our editor, but I think this gives you a kind of good introduction to the layout of the editor and so that's it. Thanks Matt.

Thank you Scott.

So what did we see there. We saw that Xcode's editor gives you powerful workflow features to help speed your development. We saw things like code completion and both modes that it works in, we saw the code folding and code focus features, where we take advantage of the information Xcode has about your project allow you to easily collapse chunks of code that you're not interested in seeing right now. And Scott showed you the navigator bar where you can easily jump around to various chunks of your code and navigate around smoothly.

Scott also showed you a lot of key equivalents that you'll want to start learning as you use Xcode to become even more productive. And he showed you some of the key ones, some of the key, key equivalents for things like code completion where a tab completes and escape brings up a pop up menu and then control period actually let's you cycle through the different choices. He also showed you things like how to indent code and how to jump to definition; command double click, option double click.

And we could see from that in general in Xcode as with other Mac OS X apps, option action actually does a related behavior. So option double clicking brings you to the documentation, option clicking the split view control actually creates the split the other way. And as you may have already heard there's a whole session on Xcode's editor the New Development Workflow, that's tomorrow morning in Presidio.

Let's talk about the build system next. Xcode's build system architecture is fast, configurable and built on industry standards. And the industry standards we build on are things like the GCC Compiler. 4.0.1 is the default in Leopard, the ld linker and gdb for our debugging capabilities, but Xcode builds a lot of functionality on top of these industry standard components, enabling you to do more than you would be able to easily do with those tools. Let's talk about some of the terminology and concepts that allow Xcode to do this. Xcode has this concept of targets. The target explains how to build a particular product. You think of targets as the recipe and your source code and other graphical resources as the ingredients.

And the target tells Xcode how to put all those things together to make what you are trying to build. If you're coming from Visual Studio, I think the terminology they use is project, so we're a little cross purposes with them over terminology, but in Xcode it's called the target. And one project in Xcode can contain multiple targets. So you've got your project window you may be building both an application and a shared library it depends on and each of those would be its own target.

Xcode has a target inspector that allows you to configure both your project and your target and there's a variety of settings involved that allow you to tweak various aspects of your target. These settings are called build settings. So how do targets tell Xcode how to actually build your code. It's through these build settings. These build settings control all aspects of compilation and linking. And you can see a few examples of build settings. They're generally some setting name, some value name that tells Xcode what to do.

Now you can actually set up build settings and their values at either the project level or in specific targets. What happens is you set some settings in your project and some in your target. But your target values override whatever you've set at the project level. So settings flow down from the project, they could be overridden by the target, and eventually they are actually used to build your source code.

The basic rule that you'll want to use when trying to figure out where to put your particular build settings is you'll want to set general policy at your project level. For example, if you've got a set of warnings that you want all of your targets to use, set that build setting at the project level. On the other hand you can customize specific settings for your target. For example, what do you want your final executable to be named. You don't want to set that for all targets in a project, you want to set that on a per target basis.

One additional level of detail, you can actually have multiple sets of build settings for a given project and target. And these different sets of settings are called build configurations. We actually give you a couple of build configurations by default: debug and release. And you can see how these would be useful. You would use the debug build configuration when you want to have an optimizations off and you want to build for the native architecture of the machine you're actually on. And this is useful when you're doing your iterative development cycle on that actual machine.

You'll switch over to the release build configuration when you want to do final testing and preparation for release of your product and it might have optimizations on and build a universal binary for all of the different architectures for Mac OS X. And you can define your own build configurations for specific needs you may have Once Xcode and the targets know what build settings to apply the targets are going to follow a series of steps in a pipeline to actually build your product.

And these steps are called build phases. And there are some standard build phases that almost every target has. Things like compiling your sources and actually linking things together. But you can actually customize how Xcode builds things by adding some custom build phases. For example, you could add a copy files build phase that at a certain point in your build actually moves files from point A to point B. Or you could have shell script build phase and this allows you to basically do anything as a part of your build. Maybe it's update a given webpage, build a tar file for your final binary or whatever it is else that you want to do as a part of your build.

Once you actually click build and it starts executing all these build phases you'll see errors and warnings in message bubbles right in line in your code editor. And in general this is what you want because you just wrote usually this chunk of code, why should you have to go somewhere else to see what's wrong with it.

Sometimes however, you actually are going to want to bring up the build results window, particularly if you are doing a clean build of your entire project and want to see errors and warnings across your entire source base. And Command B will bring up the build results window or when you have errors and warnings, the bottom right hand corner of the editor window will actually allow you to click there and bring up the build results window.

And you'll see all the errors and warnings you may have and you can actually select them and see them right in line in your code to fix the problem right there. So we allow you to work either way. When you're working on a chunk of code you just wrote, you can see message bubbles right in line to fix things, when you're doing a complete clean build of a large project, you might want to bring up the build results window. I'd like to bring up Scott Tooker again to show you a demo of the build system.

So one of the interesting things I've demo'd the build system a lot and the thing I've learned is that demoing actual building is boring so I went ahead and built while Matt was talking so that we could get to the interesting stuff. So you'll notice here I've built and of course my tendency to make typos has bit me because I have some warnings and errors.

So you notice what we do is we provide warning and error information right in line and so, for example, you get the same, this is the same message you would get in a normal build log and it's local, sorry, it is local to where the warning or error occurred. We can go ahead and we can hide these if we want and they will just flow with the code. Now this is great and most of time this is exactly what you want, you don't want to have to jump to a separate window.

However there are times when you want to see the bigger picture so you'll notice down here in the corner where it says failed, we also have these little icons of warnings and errors. Now you can click on any of these little images and that'll bring up the build results window.

So this is how the build results window comes up by default. You'll notice up top I have an outline view here that lists my warnings and errors and it groups them by which file is being compiled. You'll notice that in this mode we're only showing you files that had warnings and errors. And then below if I go ahead and select the warnings and errors that they'll actually jump to the proper place in the file.

Well, that's great. And sometimes for example, I don't care about warnings, especially if I'm bringing over a new project I may have a bunch of warnings, I just want to get it to build. So we also provide you the easy ability here with the warning icon button to just go ahead and hide those warnings for now and we won't show them to you.

However, sometimes you want more information. You want to know exactly what happened. So we kind of have two stages of this; in addition to showing you the warnings, we can actually show you all the build steps. And so if I click the check mark here now we get to see everything, including stuff that just succeeded and went well. And so you can see exactly what happened. Well, not exactly, because you can see these are all summary lines, but what if you want more detail. Well, we also provide the build transcript. So let me go ahead and hide the editor window for a second.

And here's the build transcript and you'll notice as I click on these steps we actually highlight the actual commands that Xcode used to send to GCC or the underlying tools or to the shell. And so for example if I go and look at my warning, I can even look at, for example, the compile line and you can do for example comparisons of, oh, let me look at this compile that succeeded, let me look at this compile that failed. We give you all the information right there. The text in this window you can select it, you can copy/ paste it to other people and you can even take the lines and it's a full complete line so you can use it with GCC.

So that's the build results window, it's there for you. One, for those of you who are used to having a separate window we definitely provide it, it's fully functional. It's also a place to go when you need an overview. But as I said earlier, most of the time this is just overkill. It's a separate window; it's got you out of your flow.

Instead you can do most of what you need to do just simply right in the window itself. So for example in this case, I see where my warnings and errors are, I can just, and this is why we do sacrifices to demo gods?

Come on.

Okay, we're going to move on to the next part of the demo. The next part of the demo is the fun part of the demo where I get to talk to you about something that I used to be responsible for which is the target inspector. So Matt talked a little bit about the target inspector and talked about projects and targets and so I'm just going to give you a little guided tour of looking at build settings for the target.

So what you'll notice is, sorry I did that a little quickly, what you can do is go into the project window here and you can open, just close targets over here and you can double click on targets to bring up the window. You can also say edit active target, to go ahead and bring up this get info window for the target. The tab we're going to look at today is the build tab. This shows all the build settings and right now we're showing everything. We're saying okay from my bug defiguration show me all the settings.

And as you can see there are a lot of settings. In fact there are a lot that you'll never care about and so one of the things we wanted to provide was quick ways for you to get the settings you might care about. So what I'm going to look for is I want to look for my prefix header because I want to make sure that I'm precompiling it. So what I can do is type into the field here and type prefix and you'll notice that you're automatically filtering while still keeping things grouped in an outline view.

You'll also notice, well here's my prefix header and it is being pre compiled, but the prefix header's in bold, what's that about? Well, because you can set things at multiple levels most notably the project and the target, we needed a way to show you that you've set this for the target in this case. And so that's what the bold means; it means this was set at this level.

And we've also provided a convenient short cut in the show pop up here to say well I can look at all settings defined at this level. And then I can see this is the only one with prefix, I can remove the search filter and then I get to see well here's all the things I define in my target. And as you can see they're all things specific to just this target; the prefix header, the product name, what extension it might use.

And just to give a quick look in comparison, to kind of give a concrete example of what Matt was talking about. If we bring up the project settings which we can bring up in a similar way, double clicking on the project brings up a get info window. You can notice that if I look at the settings I define for the project, they tend to be more generic things. What SDK I want to use, how do I want to debug, what formats do I want to use.

And what we are strongly encouraging people think about it this way, anything that can be shared across targets should move up to the project. Because what we want to do is make it so it's real easy for you to go one place. Change it there and then not worry about, oh, did I remember in my fifteenth target to change that setting.

So as you can see, oh and oh sorry, there's one final thing, one last thing I wanted to show off was the research assistant and how it integrates in the build settings. So one thing you may notice is this is great, you're giving me titles, you're giving me values but I'm new to the Mac, I'm new to the Xcode, I don't know what any of these things mean how can I find out more information. Well in most cases this is as easy as just selecting one of the build settings and just clicking this little button down here to show the research assistant.

Hey, let's move this over here. And so you'll notice what the research assistant does is it tells me the localized name, which we show and then it also gives me just as a convenience the actual raw build setting name. This is useful sometimes if you want to reference these build settings and shell scripts or from the command line. But the meat of it here is this abstract. So this is a bunch of help text, it tells you what the function's for, how it works and gives you additional information.

And so I can have this research assistant open and I can basically kind of browse through my different settings and see what these different settings mean. And so it provides a really nice way to get to learn more about your project easier. And once again this is just a brief kind of snapshot of what the build system is about.

There's a lot that we haven't talked about here like build phases and other things. I'd encourage people that are interested in the build system, there's a talk later on Wednesday evening about the build system in depth, it is very good to go to. Matt.

Thank you Scott.

So what you saw was that the build system allows you to easily see errors and warnings in lining your codes, you can fix them right next to the line of code you just wrote. And when you need more contexts you can build up, bring up the build results panel and Scott showed how you can get a lot of additional information out of the build results panel, including the complete GCC build transcript which is sometimes helpful.

And finally we touched on customizing your build with the target inspector and build settings and you could go into a lot more depth on that. We actually, oops, not that slide yet, as he said, we actually have a session on the build system tomorrow evening at 5:00 I believe.

So there's a couple other concepts that I just wanted to touch on briefly that you should know about relating to the build system and these will require further exploration on your part because they can be fairly complex but they're important for you to know these are there and start getting familiar with them.

The first is the concept of SDKs. Now these are, we have Mac OS X SDKs that we provide with Xcode and these are specialized SDKs. They're a little different than the SDK concept you may be familiar with on other platforms. Basically what we mean by SDK is a set of all the headers and libraries that originally shipped on that version of Mac OS X, so that you can easily target that version of Mac OS X by building against those headers and libraries to avoid API pollution.

By doing this you make sure that for example if 10.4 Tiger is your minimum system requirement that you don't accidentally use a 10.5 only API. So we ship several SDKs with Xcode for 10.3, 10.4 and 10.5, and you essentially decide what your minimum system version's going to be and then pick that SDK to make sure you don't accidentally leak over.

The other thing that you may need once you build up more complex projects is Xcode configuration files. And these are basically text files with the .xcconfig extension that contain lists of build settings and values. And the great thing about them is you can actually reuse them across targets and projects.

You can tell a particular target or project, get your settings from this config file. And so you could have dozens of targets in several projects across your whole hard drive, all referring back to the same Xcode configuration file, which would enable you to make a change to a build setting in one file in one place and instantly have it be picked up across all of your projects and targets. So it's great if you're dealing with a very large build environment with a lot of locking pieces.

So the summary for the build system, we've got familiar underlying compilers and tools with Xcode. If you're familiar with GCC or other similar open source tools and other platforms, you're getting the same tools on Mac OS X. Xcode puts a flexible architecture on top of those tools allowing you to insert custom build steps, customize settings and easily make changes across all your projects in one fell swoop.

And we give you a seamless work flow to actually fix the errors and warnings in your project. You can do it either in the code editor or in the build results window. And at the bottom of the slide there's the details on the session we've been referring to tomorrow.

Next, the debugger. How many of you write perfect code the first time every time? Right. Hello World's a killer isn't it.

Under the hood Xcode uses gdb. So if you prefer that, if you're familiar with that Xcode can give you access to that, but we think you'll prefer the much richer functionality that the rest of Xcode's debugger provides.

Here's Xcode's debugger window so when you do find that rare bug you may have inserted in your code, you can go in and debug it and you can bring up Xcode's debugger window and this is going to provide a very similar functionality to what you are perhaps familiar with in other platforms. So you can stop at a breakpoint, you can continue, you can step into, you can customize breakpoints, and so on.

But as we're fixing errors and warnings, we think there's a better way. You can actually do a lot of your debugging right in the code editor. And this makes sense if you just wrote this chunk of code and you just fixed the bugs in it, why should you have to go to some other window to actually go in and debug it. And so that's what the editor let's you do. You can actually customize breakpoints right in the editor, you get the little mini debugger toolbar across the top that allows you to step over, step into and so on, just like you could in the full debugger window.

For those cases when you want to see what's inside a variable, you can simply hover over that variable with your mouse and Xcode will give you the contents of it. So it's very easy, very intuitive to just start mousing around and hover over things and find out what the values are.

Now whether you prefer working in Xcode's dedicated debugger window or in the code editor, either way you're going to get a rich set of functionality. You'll be able to customize breakpoints, set watch points and view expressions, view variables and collections and data tips and even customize variable formatting. You can decide if you would prefer for results for a particular variable to always be presented a certain way. One of Xcode 3.0s most powerful features is its seamless run/debug/run workflow.

And what this means is you can run your application not in the debugger, it'll launch quickly, you'll see it right there. When you reach a point in your app where you actually want to set a breakpoint and start debugging, simply add the breakpoint. And Xcode will automatically attach the debugger to that running application, there's no need to stop your app relaunch it on the debugger and keep going. So things are very smooth, Xcode automatically attaches the debugger, you fix the problem when you remove the breakpoint, the debugger detaches and you just keep working. So it's a very seamless flow back and forth between running and debugging.

Xcode also saves you time by allowing you to restart, which means, run your application again the same way you did last time. And that could mean running it again under the debugger, it could mean running it again with a performance tool, see you don't have to reselect the same options over and over again, Xcode remembers what you did and lets you easily do that again. And to show you this, I'd like to bring up Scott Tooker again to give you a demo.

Okay, so I'm here in align left edges and I want to go ahead and let's just build and go. And you can see here's sketch and it's all loaded, let's create some circles. And what I've done, I've selected them all and now I'm going to go ahead and align them and I want a break.

Oh, that's right I need to set a breakpoint. So as you can see I'm just running here. In the past what we've had to do is actually as Matt says, you have to quit out, set up your debugger again and go. Now what we do is just set a breakpoint, let me go back here, let me go ahead and just reselect that align call and boom right into debugger.

So?

And you'll also notice I've kept, I've stayed in my editor window, haven't brought up a new window yet. I've added now this debugger bar up along top that has all the common functionality I'd need. But let's take a short detour; I want to show off the main debugger window, especially since a lot of you coming from Windows, probably more familiar with an interface that looks more similar to this. You'll see on the left I have my stack frame list, I have a thread pop up, over I have variables and then down at the bottom I've got my source code.

And so I can go ahead and as Matt said I can do step over, I can step into, I can continue from here. But with Xcode 3, we actually wanted to have something that was more tied to the editor. There's no reason I should have to come to this other window for most of my debugging needs. So we introduced some new things called data tips and step controls. And I'm just going to show them here to you just briefly.

So first off we have data tips. And so for example here, let me go ahead and step a little bit, in fact, and so you can go here and okay now this has been evaluated and I can see that C is equal to 8. Well, that's great, I could hit this step next and look at things as they evaluate or I could just, I really want to get down to this bottom part here where I'm actually setting up some bounds.

So another thing we added were step controls and so for this case, I can just click on the step control, what is going on, okay well normally I could, let me try something, yeah I know, I'm going to go ahead, I'm going to try that one more time.

Come on?

You'll also notice along the side here, that we have summary information. And this is a feature of Xcode we call data formatters. We provided it; there are two ways we provide it. This is a very simple, in this case we're just using a very simple kind of mark up language so you can just say I want to see x equals y equals and so on. We also provide for those of you that have more complex custom types, you can actually write plug ins to the debugger so you can just display information about your custom code.

Now in addition to that, we also, as you notice here as I move around, I'm just kind of using the syntactic information we already have to say, oh, current bounds that's a symbol, I know that and we can go look up the information. However, we can do more than that, we can also, for example, notice that when we're looking at structures, we can drill down into that structure automatically so for example here I can look at the origin which is a point or I can move over and just look at x in that point.

We can also do evaluation. So just to be clear here, what I've done is I've actually selected curGraphic bounds and then asked the debugger to evaluate it right now and then show me the information and so you see here, oops let's bring that back up, that I'm actually looking at the structure and that I've got live information about the data. And it goes even further than that because actually if I go down to curbounds here, which is the current bounds of the graphic I'm about to set, I can select that.

Actually I don't need to evaluate it. I can select that, I can for example go down into the size and just inline? ( Sigh ) Inline. I can go ahead and change it right there. And so when I decide to go ahead and say continue, and bring back up sketch you'll notice that I've actually had an affect directly on the program while it was running.

So there's actually a lot more to the debugger experience. We're going to be covering a lot more of this in the Xcode New Workflow, especially issues about being able to quickly jump in and out of functions, but this is just a brief overview that hopefully shows you the power of the debugger. Matt.

Thank you Scott.

So what did you just see? You saw that you could actually get a lot of your common everyday debugging tasks done right in the code editor. Now you can control breakpoints and message bubbles, you can view variables and data tips in line and so really a lot of your day will be spent right in the code editor.

Writing code, building code, debugging it and it's a very seamless flow and experience as Andreas talked about yesterday. Sometimes if you want to do a broader investigation you might want to bring up the debugger window, it's there if you need it. But we think that the seamless run/debug/run experience of Xcode will be much appreciated as you develop applications.

So edit, build, debug, those are kind of the core things that an integrated environment does. But there's actually more things to your project that you need to keep track of that you'd like for the project to be able to handle for you and we don't have time to go into these aspects and detail in this session. But I just wanted to touch on three of them briefly so that you know that Xcode can do these things and you can find which sessions you should go to to find out more. First of all, Xcode's source code management system.

We actually support three systems Subversion, Perforce and CVS, and where the underlying SCM system supports it will actually give you a nice browser for you to easily browse through your repository, find the project you want and then check it out. So you configure it and then you can handle most of your common SCM operations right from Xcode, check code back in and so on.

We also support refactoring in Xcode and you saw this demo'd yesterday in the state of the union. Refactoring basically allows you to quickly, safely and broadly upgrade or change your code, either to make it more maintainable or make it easier to add new features to your code, such as new Leopard features.

And you could use find and replace, very manual thing to do to try and accomplish this, but it's going to be much more error prone. And why do all that when you have tools to do this for you? And that's what refactoring is about and there's a session on that on Thursday in The Presidio.

And finally the Organizer; this was demo'd yesterday and there are two key ways you'll probably find yourself using the Organizer, first as a way to manage and view all of your projects. So if you're doing particularly native developing from Mac OS X, Cocoa applications for example, you'll be using projects primarily and you can drag those projects into the Organizer easily get to them, open them up, build them right from the Organizer.

If you are more of an open source kind of guy and you don't want to use a full Xcode project for your development you can actually still use the Organizer, simply drag in folders of code, we've go build in support from Make, AutoConf and Ant and you can actually customize actions as well. The Organizer gives you easy access to your projects, a free form development workflow and the ability to extend it based on your needs and we have a whole session on the Organizer on Thursday, it's called Project Free Xcode, Mixed Language Development.

So, what have we seen in this session? We've seen that Xcode's intuitive workflow helps accelerate your development by giving you a very editor centric focus; you don't have to keep bringing up other windows to get your work done. Xcode's build system gives you the power based on industry standard tools and also the ability to customize the build system based on your needs.

And finally we've seen that Xcode makes development more fun by handling common tasks for you, like SCM operations, refactoring and helping organize your code. For more information you can email me with feedback, [email protected], I'm the Software Evangelist. There's also a variety of chunks of documentation for Xcode I encourage you to read.