Welcome to 307, Introducing Xcode 4. I'm Anders Bertelrud. I'm the Xcode Architect and I'll be joined later on, on the stage by Brooke Callahan, a dear colleague and Ron Lue-Sang also dear colleague from the same team. And together, we're going to give you a closer look at Xcode 4. So all of you, I presumed saw the State of the Union, Developers Tool State of the Union because there were no other sessions at the same time. So you've seen Developer Tools, the Xcode 4 developer preview introduced.

We're going to take a closer in this session. This is the first Xcode 4 specific session since the State of the Union. So, one of the big things in Xcode 4 is that we've improved the workflow by looking at what most of our developers do everyday and trying to take advantage of that in a better UI. We've of course also put Interface Builder inside the app. So that was one of the big request we got and actually let's us tie the tools together in a much better way. As you've seen a little bit of and you'll see more of here.

We have the Editor Assistant which in the State of the Union, you saw some examples of. One of my other colleagues, Matt, showed how to use Interface Builder documents or Core Data documents and have source code track that automatically. So we're pretty excited about those features. We're using the LLVM compiler. In this case, it's a lot of flexibility and power in terms of better indexing, the static analysis that you've already seen.

This also lets us do Fix-its where, well, if the compiler can tell you there's a missing semicolon, why can't it just put one there? Well, with LLVM, now we can. And the Version Editor where we can see our disk before we check them in, etc. There's a new Debugger of course.

So what specifically going to focus on in this session, we're going to talk about some of all of those. But I want to talk more about this concept of workspaces which is similar to the concept you see in some other IDs and other platforms but not exactly. So we'll talk about what a workspace means in the context of Xcode 4.

This was touched on just a little bit in the State of the Union but it's kind of important that you see how it fits together. So we'll spend a bit of time on that. We're going to talk more about the various ways to navigate inside of Xcode 4.

A lot of what we try to do here with the improved workflow is to ease the navigation to take advantage of the lengths between the various parts of your code, both those text based like source files and non-text based, like Core Data files, those kinds of things, so that you navigate between the various parts in a lot better way.

We'll talk about editing both as it relates to the related editors, the assistant. And also some of the specific file tech editors that have improved in Xcode 4. We'll talk more about the improved Organizer. Ron is going to show you some of that. The Version Editor, we'll talk little bit more about and again some of the Debugging.

We'll end up by talking some more about the theory of these new schemes word that we use to describe the future where you can set up little snippets and workflow, give them important names that are important to you as a developer and then run them at various points in your workflow. So we'll start off by Workspaces. And I just want to show what's-- where on the workspace window.

Actually at this time, I guess most of you or many of you have downloaded already the Xcode 4 developer preview and started using it maybe. That was something of course you hadn't seen yet in the city. Can I see how many people are actually using or have downloaded and tried out Xcode 4. Wow, cool. So some of this may be familiar too, but anyway, we'll-- hopefully, I can show you something new. Alright, so I'm going to start by launching Xcode and you see the welcome screen here where we can do all kinds of stuff.

We have a lot of new templates. They're improved compared to the ones in Xcode 3 but they were the basic same types that you've seen before. For example, you have here iPhone, the Mac OS X, the library icon here, static library, kind of looks a mausoleum and-- but I think it's a library actually.

[Laughter] So-- But it's-- I just want to show the various types of icons we have here and all of these represent various customized templates, some of them with options that you can have once you pick an application and you choose whether you use this Core Data, whether you have a document-based application, etc. I'm actually not going to create a new workspace or a new project right now. Rather, I'm going to create a new workspace. And what I get by default has been a blank workspace. I'm going to start out actually in the Documents folder and what I'm going to do here-- let's see, let me take my documents. There we go.

And let me go ahead and call this-- I'm going to call this Baffle. And what I'm-- hope I can spell. OK, there we go. So a couple of years ago when we introduce the iPhone SDK, one of the guys in our team wrote a little game called "Baffle" which was for the iOS SDK and what I want to show you here is creating a workspace using the Mac OS X version of that project and using Cocoa Touch version iOS project, putting them on the same workspace and working with them across the platforms in the same workspace.

You might want to do this if you have two related projects to share some code for example. So I'll start by saying, add files, I go ahead-- just go in here and pick the projects. I'll go ahead and say, "I'm going to add the Baffle Cocoa." There are quicker ways.

You can of course just drag in the icon from the disk but in demos, I like to use the menus to show people what they can do. So the other thing I'm going to though is drag in some non-source code content. In this case, I have a task file. So I'm going to ahead and add all this.

So from the left side now, we see the references to the projects into the task list. I can view it inline in the editor. And has it been mentioned, I think and we're going to talk about in this session, we actually can see anything that has a Quick Look preview installed for it where you can view it inside of Xcode.

So we have here a project. We have here another project. And I'm just going to navigate down to one of the source files here. And just again, give you an overview of what's on the left side here. On the left side, we have the navigation area. Here we show you the various aspects of the projects that are related to your workspace that you have added to you workspace and as you add more of them in here, the navigation area shows you more and more content.

So obviously here, you see the files and we have a heading row that shows you where the actual projects start. So you can group projects together also. If you have 40 plug-ins, you can put them all in the same group. You don't have to look at them all the time but they're still accessible from your workspace. We have several different navigators here.

We're looking at the project navigator. There is also the simple navigator and as we switch to that, it starts counting out the classes in here. We can actually navigate through what the class hierarchy is going to look like at runtime as a union of all the class hierarchies that are reachable from the project. There's the search navigator. We can find and replace from in here.

There was a demo of that in the State of the Union. The issue navigator here, it shows you a summary of the errors and warnings produced by the various types of compilers and translators that we use. And then we have the debugger navigator, the breakpoints and the log.

The log one is interesting. What we've done actually is to keep historical logs now in Xcode 4. In Xcode 3, when you quit your project or you quit Xcode and you started up your project or if you rebuild, you would lose the previous logs. Here we actually keep a history and that can be useful when you go back and you see well, what [background applause]-- OK, cool. This feature is for you.

[Laughter] Along the top, we have the scheme popup. We're going to get back to this but we have this concept of schemes which is configurations of running your various products. And on the right-hand side, we see the destinations that you can run them on. Obviously for an iPhone, there is iOS device and simulator, etc. The activity panel here, the activity viewer, it shows you any building that's going on, indexing, search and replace, that kind of thing. So, we'll show you right upfront-- and if there're errors or warnings that show up there as well.

We're looking at the standard editor right now which is the simple one where you just click on the file or navigate to it in some other way and just shows you the one file that you've chosen. As you've seen, we also have the Version Editor. I wanted to show a couple things here that may be wasn't apparent-- weren't apparent. You can change the split orientation which is sometimes very useful.

And there are other aspects that you can navigate too, the includes and the super classes and those things. In the Version Editor, we see the different versions that exist of the same file that are repository. And this was touched briefly on the State of the Union but not talked about.

You can actually scroll or just hover over here and you actually see the checking comments. And I find this very useful actually because I can be able to go to a particular version of repository. We're using a getRepository on this project here but it also works with some versions of course.

And finally, on the right side here, we have the inspector area and we have the library area. So before I switch-- that's a bit of a-- just an overview of what are actually the various pieces in the window here. I'm going to go ahead and run and build-- build and run and just show what this product is in case you don't remember from two years ago. And we have an error. Guys, what did you do? I gave the demo drive to you and you were going to check it out and make sure everything work, did you put an error in there? What is this? Test this thoroughly and remove before the demo.

Yeah, thank you Ron. OK. [Laughter] See I'm awake, alright. You might have noticed-- I can actually go to the issue navigator just by clicking on here. I find that kind of convenient whenever an error shows up. So we'll run again and we'll see if it works this time. Alright, OK. So I'll go back to slides. I do that myself actually.

Here we go. So what do we see? I mean, you saw the same thing in the State of Union but part of the point of this entry was to talk more about the concepts too. So I mentioned this concept of workspace. We've been hearing that. So workspace a place where you can put references to the source files that matters to you.

It represents your workflow and so you might create one for when you're doing your feature development and you have references to spec files or to may be protocol definition files and PDF or what have you in file formats. You can have another one that you've configured for let's say performance tuning and it has a bunch of schemes in there that launch instruments in various interesting ways. So you can create these just as you like them.

They're loose collection of references to projects, folders and just PDF documents. They also contain schemes so you can create these schemes and as you may have heard about, we actually have two kinds of schemes. One is a launch scheme, that's pretty simple. At the end of it, it just launches your product. That could be GDB, LDB.

It could be in one of the instruments. It could be launching in a simulator or on the device, those kinds of things. Distribution schemes, they're a little bit different and that the end product of them is that you get a disk image or you get some other thing that you can actually deploy.

So I said that the workspace references the files. It doesn't contain any files. It doesn't contain any projects. This means you can have a single project which builds your application and contains all the source code for it and you can have multiple workspaces that all reference the same project. They just have different workflows associated with them.

And again, this is useful for development versus bug hunting versus testing and that kind of stuff. In every workspace, builds into its own built arena and it has its own index. And so if you have let's say, one workspace represents version 1.0 of your project and another one is 2.0, you can build them independently and even if they have the same name, you don't have to have the one share-- the one central share, the build folder, that you had in Xcode 3, just one per workspace.

So what they specifically contain are the references that I mentioned. They contain the actual definitions of the schemes and we'll talk a little bit about sharing those later. They contain breakpoint definitions. So you can choose to create breakpoint list or you can have symbolic breakpoints like NSLog and you can actually have those be either private to you or shared. And they contain the window layout. So every little disclosure triangle and split setting and all those things are persevered when you close the workspace.

The information sharing in a workspace is on an off to end basis. So the piece of information in the workspace like the schemes, you can choose for each one based on what it means to you to have it shared or not. And so if you have workspace that a team of 20 people share, you can have that one workspace and you can configure it and develop some schemes that you really put some effort into. The schemes can contain pre-launch actions and post-launch actions and pre-build actions and all those kind of things and you can put some effort into that. You can check that it's a repository and then every new user who checks that out will get those schemes by default.

Others you might want to make. So this is just for you because it just affects your workflow. So, there's a check box here in the scheme manager, shared or not, only for workspace basis. So not only can you choose to share an entire workspace but you can choose free scheme in the workspace whether you want to share it or private. And the sharing is through the normal means, right.

If it's important to you to share it, you check it into your SCM or you email or you include it in your source code distribution if you are open source. So you might have a workspace that you've really polished. You've worked on the scripts and it's really got this cool workflow for running instruments and some interesting ways with sample data, etc. So you want to check that as your repository that has value to you. You'll want to make edits to it overtime. There are other workspaces like the one I created on the demo machine here. I'm probably not going to be using that app for the demo here.

So that one is one that I just kind of roughly put together and it sort of a little bit more sketchy. And I'm not going to file it in an SCM. I'm going to file it somewhere. And so I can just throw it away when I'm done with it. So these workspaces could really be used in whatever way you want, right? You can just put one together for a specific bug and then just toss it afterwards.

What's cool though is that it works across all of the projects in the workspace. So as you add a new project in there, the symbol lookup gets updated, the documentation search, the index, and all gains knowledge of that project. So you may be working on debugging an app and you have some lower level framework you depend on. You might not have the sources for that handy because it might come from a different team or whatever.

But you might discover, you know there might be a bug in here. So you can just drag the source code for that project in if you have access to it and then you can step down through and the symbol updates itself, you know, index and all those things.

Find and replace works across the projects and that's of course very handy as well. The other thing that happens here is we have coordinated build so that a scheme that's in a workspace can work across all the different targets without the targets and the projects actually having to have any knowledge of each other. So you can add custom build actions with arbitrary dependencies that you define at the workspace level and custom scripts that aren't actually part of the projects.

And the implicit dependencies is a new feature in Xcode 4. So without two projects that know about each other, Xcode 4 will discover dependencies between them. So I may have a project here which has an application. I have another one that has a library. There's an application, the first one that links the library and the second one, without modifying either project, Xcode 4 will determine the dependency.

And actually Xcode 4 uses Xcode 3 project format so you could just open two Xcode 3 projects in Xcode 4 and it will automatically figure out the dependencies between them and to you-- without changing the format of the projects, you get the benefit of 4.0 there. That was a bit about workspaces, sort of a theory behind them. For navigation, again, I showed this. I kind of want to just call out a couple of things here. The structure navigator and the whole navigation area is one of the primary ways in navigating.

There's a filter field that's often overlooked at the bottom there, especially on the big screen. You take a look at the bottom you can actually filter by content and by the file or path, but you can also filter semantic such as files that I have modified recently. The open quickly panel, that was part of Xcode 3 but in Xcode 4, it's been enhanced with the symbol information that we get from the LLVM compiler. So it does a much better job of actually finding you the places you're looking for. A couple of words about editing. So we showed before that Xcode automatically knows the related contents.

And again, I just wanted to emphasize this, we have the three different types of editing behavior. There's the Standard Editor what you use to from Xcode 3. The Assistant Editor is the one where the second review tracks the contents and the selection of the primary one. And then the Version Editor is the one that lets you look at your SCM system or look at other changes. So now to talk a little bit more about editing, I'd like to ask Brooke Callahan up on the stage please.

Thank you.

Thanks Anders. We've made a lot of improvements to the editing experience in Xcode 4 that I'm really excited to show you. There are several new ways to work with your files including improvements to the source code editing with the new LLVM Indexer. Interface Builder as you know is now built in the Xcode. And the Data Model interface has been streamlined for your most common tasks. In addition to that, we've added Hex and Preview for files that Xcode doesn't otherwise support.

We've also added new ways to work with your editors. Like the Jump Bar which makes it easy to navigate all the files in your project as well as inside those files. And the Assistant Editor which makes it easy to keep related content open next to the file that you're working on.

Also on the utilities, we have Inspectors and a Library of file templates, code snippets, objects, media. So let's see a demo. So my demo is in the sketch project. If anyone is not familiar with this, sketch is an example project we ship. It's useful for treating simple art with shapes and images. The sketch project has several classes for each of different types of shapes that it allows you to create. I'm going to create a new type of shape, an octagon. I call this SKT octagon.

And as I'm doing this, you can see that it's really easy for me to keep my .m open right next to my .h as I'm creating this new class. If I go somewhere else, when I come back, it's right there.

So I'm going to cheat a little here but here I've added what I wanted to add to my interface file and then I can just drag over my decoration and start having the implementation there.

So, here I've added my first pass at the init method. My init method takes an edge length so I can know how long each edge of the octagon is. And the-- I'm checking for the edge length to make sure that it's greater than zero. It wouldn't make sense to have an octagon with no size but that's not working. And here we see it-- I'll fix it again. It will work.

So Xcode has already noticed that I'm assigning to this variable instead of checking it. So I can just click fix and it will actually do the validation and return like I'd expect.

And that's what's new for source code editing in Xcode 4. Now let's take a look at an Interface Builder file.

As you see in the-- Interface Builder files have a canvass to work in. They also have a dock so you can see the top level objects. You can expand this into the outline view where you can browse through the objects or you can simply click on a jump bar and navigate down to the objects that you want to work with, like that.

We also have the library from Interface Builder so you can simply drag out objects into the canvass and work with them there. If I want to add an action or outlet for my button, I can simply control click and drag into the header and type the name here, or in this case, the button cell. So one--

So that's the outlet and here's an action.

Actually, one more thing that I want to show you was the code snippets. If you want to-- in the State of the Union, Mike might showed you using a code snippet but if you want to actually create a code snippet, you can simply select some texts like this method which maybe I want to reuse this text-- this method again, maybe I want to create some other class like an SKT triangle or whatever.

I'd drag that text into the code library and now I'd made my own code snippet. If I hover over this, I'll get an editing window. I can actually edit the code snippet from here. I can even give it a name and I can give it a shortcut. So let's try that out.

So I'm going to take in the shortcut I made. I'm going to press Escape to bring up the shortcut and hit Enter and there it is.

Alright so that's source code and Interface Builder files. How about the data model? Here we see a list of entities of such requests and configuration for our sketch data model. It looks like I've got an entity for each of the classes I have for all my shapes.

So I'm going to make a new entity for my SKT octagon. Octagon. And I'm going to add in a tribute for that edge length you saw earlier. And it looks like I've got an error-- oh, I need to find a type for that, OK. So that's probably what we know.

One of the common things you do in data model files. But if I want to change any attributes on-- if I want to change any settings on my attribute, I can do that from the data model inspector. I can also change settings for the entity there. As you can see while I'm doing this, the jump bar is tracking my selection, just like in the Interface Builder file.

One more addition to the data model interface in Xcode 4 is this new support for find and replace. So if I decide that I want to change my SKT octagon to a square--

-- I can do that from here.

This is really nice when you have a large data model file because it can be really hard to find all the different classes and stuff in there and be able to make changes to them easily. In this case, this is the type of change I want to do across my whole workspace. So I'm going to use the search navigator for that instead.

So, here I'm going to type SKT octagon and here in the search navigator, I can see each of the places where I've-- each of the references to be octagon class in my project. And when I go to replace it, I can also see a preview and I can select or reject any of these that I want.

As I'm sure you're aware, this is really nice when doing find and replace with things like regular expressions where you have maybe lots of false positives, anyway moving on. Xcode traditionally hasn't had great support for opening files that don't go through the build system but Xcode 4 changes this.

We can see a preview through using Quick Look of any file in your project. And in addition to this, we can also, for any flat files you have, open them as hex and edit them.

Now what about documentation in the editor? The Quick Look-- oh sorry, Quick Help has been moved into an inspector and it works pretty much like you'd expect from Xcode 3.

But in addition to this, we've also added support for common task-- sorry, help result for common tasks that people do in the IDE. Now if I click this one, it's going to bring up this recipe in the organizer. Here you see the steps that I need to complete, the task, as well as a description of what the task is actually doing. And with that, I'm going to go back to the slides. So that's what's new [background applause] with editing in Xcode 4. [Applause] So now Ron is going to come up.

Cool. Thank you, Brooke.

There're a lot of people in here, cool. Everybody OK so far? You're enjoying the session? Yeah? Great. Very good. I'm always excited seeing all these stuff no matter how many times I see it. So, this is great for me too but-- so we're about halfway through our session.

I'm going to take the next 15 minutes or so and go through the next three major topics that being the Organizer, Version Editor, a little bit more info on the Version Editor, and finally some info about the UI we have for debugging in Xcode 4. And so I'm going to jump straight into demo here.

Pick up where Brooke left off. Don't save. OK. So on the organizer, Brooke left us in the organizer with the documentation tab up. Well, we see here that the organizers just a bunch of tabs with information on each tab, right. In the documentation tab, we have an easy way to not only browse all of our documentation, do lots-- do any searches we have where we want to find API or class information and we'll see the any sample code-- did I misspell image? No, there we go. We can find sample code, abstracts, API reference, everything. And once we find that piece of documentation we love the most, we can go ahead and bookmark it. So this is a great way to keep all of the documentation that we're using, that we're reading, well organized.

I think this is a great way to deal with documentation in Xcode 4 in its own tab and its own tab and its own window like this in the organizer. You'll also notice that we get the cool jump bar in the documentation view the same way that we get jump bar for our editors in the workspaces. So we can navigate around using the jump bar here as well. Alright, form documentation going to jump over to the iPhone tab. I'm expecting a lot of you guys are going to try out iPhone development if you have it already with Xcode 4.

So in Xcode 3 we had the organizer with iPhone support where you could see information about your developer profiles and everything. We have the same thing here. You can see your provisioning profiles, device logs, screen shots. We don't have anything interesting in this-- on this demo machine but at least we have the sexy Xcode 4 look and feel.

Alright, yes. [Applause] The next tab, I'm going to take a look at the repository tab. So here we can take and look at all of the repositories that are related to the projects we're working on whether they're SVN or get, whether they're on the same workspace, separate work spaces, we can use this as a way to view where all of our source comes from.

We can take a look at the repository information. We can look at the repository history, browse through the individual directories. Let's see. And-- So like I was saying [laughter] in the Xcode 4 developer preview

So if we're interested in picking up some extra repository, we have some URL to get hub that we want to pull source from the kit, add a new repository reference right here.

Or if we have something that's already checked out, we can go in and check "Add working copy", browse to whatever we have checked out. And Xcode will sniff the directory and figure out, well, this was checked out using get and configure the repository entry here automatically. Pretty neat. So that's iPhone repositories. The next tab here, projects.

Well, this is all the project and workspaces that we've opened in Xcode 4. This is just a great way of seeing what you've had, what you've been working on, when the last time you worked on it was, and where all the drive sources like the index and log files ended up.

The next tab is archives. I'm going to come back to this. It will make more sense near the end of my session, OK? So just remind me if I happen to forget. It could happen. Alright, I'm going to bring up our Baffle workspace again. So we finished talking about the organizer, the next thing remember I want to talk about was the Version Editor again.

And this really goes back to the amount of integration with the SCM system that we've put into the Xcode workspace here. Being able to see, OK, sure you can make edits and see immediately in the project navigator that the edit-- normally see that the edit happens. We would update the status of the file. Be able to filter the navigator based on what files have SCM status. But using the Version Editor, you can also see the Continue button [laughter] and you can also watch me walk over to my next machine.

You know, the main thing is that we get to work really closely with how the SCM bubbles up to the user, making the user experience that much better. So here again, making any changes. I thought I would try it again. Let's see. So now switching to Version Editor again, you'd be able to see any changes that we've made in the local copy compared to what's in the repository or comparing, you know, different versions that are both in the repository. And that's just using the comparison view. Now with the log view, you can see the history of the entire file going backwards in SCM.

And then everybody's favorite, of course, the-- is Blame View where you can actually see what people have done and how recently. So you could imagine that we could have figured out at this point using Blame View what happens under this demo earlier potentially pointing to Brooke the-- to Brooke at someone-- the finger at Brooke.

The history view, the log view-- oh, that doesn't look anything I changed. I'm not worried about it. So that's the versions editor again. And the last thing that I wanted to talk about briefly was debugging. So with the debugging UI, let's just build and run our application. We don't have breakpoints turned on here, all we have to do at any point is turn on breakpoints using the toggle here, right. On, off. On, off.

Let's go in and set a breakpoint in one of our views. Let's try highlighting, sure. So breakpoints are on now. We set a breakpoint there. Start a new game. I like this game actually. So at the point that we-- let's set another breakpoint over here, actually. I like this one better.

Oh, you know what? I'm looking in the wrong project. Let's try this one. This one looks like a winner, placing bets? Yes, OK. [Background applause] Thank you. I'll be all week. No, seriously I'll be here all week. [Laughter] So Xcode has stopped on our breakpoint and we're here in the debug navigator.

You can see all of the threads that are running for the application. And this is something that Dave demoed skillfully in the State of the Union session on Monday. You know, being able to filter out the stacks and the frames in thread in the stacks that aren't interesting here because we don't have source code, being able to hide the threads that aren't interesting because they don't have any frames that aren't interesting, and being able to switch, seeing everything by thread, switching over to seeing them by queue.

So one thing that I like to do though is if I'm really, really into the source code at this point, stepping through trying to figure something out, I'll sometimes hide the navigator. And navigate just using the debug jump bar here. So this is a great way of navigating through all the threads and stacks in the running application.

And there I'm right next to the variables view where I can see all the values and names and variables that are in scope, and of course next to my debug console. So that's how-- that's what I wanted talk about for debugging for right now. We're going to run back to slides, cool.

So, that covers the organizer in Xcode 4, the Version Editor, as well as some basics about debugging, the new debugging UI in Xcode 4. If you want to learn more about the organizer and the versions editor, check out the session that's coming immediately after this one, session 308. They'll go into more detail about building-- working in Xcode 4, building your application, and they'll touch more on those topics. And on Friday morning, there's going to be a debugging with Xcode 4 session as well.

So the last part of my talk, I'm going to talk a little bit about schemes. And this is something that Anders brought up earlier, you know, Xcode 4 schemes. It's a new topic in Xcode 4, a new concept. So I just want to take a few minutes through slides to discuss what a scheme is and some of the motivation behind having schemes in general.

I'm going to start off with the definition. You know, this is the dictionary definition. The dictionary I have at least for a scheme. And the part I want to concentrate on is that a scheme is a plan for obtaining a particular object, right? A plan for getting a result.

And so, that's all the scheme is in Xcode 4, it's a plan for taking everything that's in your workspace, the project contents, your targets and producing something whether it be build results, some built product, test results or just your application actually running, that's the result, right? So that's what a scheme is. It's just a plan for Xcode to produce a result from your projects and contents of your workspace.

Unlike any good scheme, Xcode 4 schemes come with three phases. The first phase is the build phase. So this is where we take all of the targets that you specify and build the built product for those targets. So the build phase ends up producing your build results. In the test phase, we'll run all of your unit test or performance test. We'll do your testing and then the third phase, profit, right? Launch, the launch phase is where we'll actually take your built application. Those built during the build phase and launch it.

So that's what the scheme is in Xcode 4. It's just a plan for building and testing and launching your application and why this is really useful for developers, well, this can be really useful for your workflow, is that you can use these schemes as presets for the different development scenarios that you might have. If you could imagine, if you have a small team working on some project, you know, we have our two-person team with Jill working hard on implementing new features.

You know, during the feature development phase, you might be thinking of just building your application in any related libraries in your workspace. Building them all, using the debug configuration for their targets and then when it comes time to run the unit tests, we would only run Jill's unit test related to the new features that she's working on.

And if you were to hit the Run button in the work space, we would want to launch the application in the launch phase and launch with the debugger. But this is a different mentality. This is a different mind set than if we have Jill's coworker, Jack, hammering a way trying to fix some bugs and we might want to build the application and libraries in the debug configuration as well but there may not be any testing really to do. There may not be anything in the test phase.

But it's the launch phase where we have the application launched in the debugger with some debug parameter set like turning on MallocStackLogging, or something. So that'd be a different mindset. And the third hypothetical, if we had another scheme besides feature development or bug fixing, we might have a third scheme for performance tuning. You know, at this point, we would build our application for release using the release configuration in the build phase.

In the test phase, we would run all of our unit test related to performance testing, not the entire regression test suite maybe. And you could hypothetically-- you could imagine we'd want to run the application instead of in the debugger, actually launch with instruments so that you could do some performance tuning, profiling, so that'd be a third scenario that we'd be able to switch quickly between different schemes to adjust to a particular scenario. Now these three hypothetical schemes that I've outlined here, this fall under the heading of what we call launch schemes and we already mentioned that there are two kinds of schemes, right? There are launch schemes and there are also distributions schemes.

The main difference is that launch schemes have a launch phase and distribution schemes have an archive phase. So it might be easier to see if we take a concrete example. You know, again, we're working along and we want to share what we have so far with friends or, you know, it's ready to ship, put it up on our MobileMe site as a disk image.

So we might create a scheme where we create-- we build the application for release, we run all of our unit test just one last time to make sure everything still works and in the archive phase, we might decide to create a disk image out of the built products, out of our application. Instead of a launch phase here, we have the archive phase.

So that's really what the schemes are for. They're a plan that tells Xcode how to create something out of all the projects in your workspace and attain a result either test results or some built products. And launching the application or creating an archive of the application. So with that, I'm going to-- So, here's where we would switch between the different schemes, right? This is the example that Anders showed us earlier. And actually, I think it'll be easier to show how this all works if I switch over to the demo again.

So back here, we have our application Baffle Cocoa. Now, you'll notice that when Anders created his throw-away workspace initially, all he had to do is add those projects to the workspace and he got two launch schemes. So, every executable that was in the targets he add-- in the projects that he added resulted in a new launch scheme. So you don't have to do a lot of fiddling if all you're going to do is add a couple of projects and try and run a target. Try and run an executable out of one of the targets.

What I'm going to do here though is click on the Manage Scheme's button. Here you can see the UI we have for choosing whether or not to share an individual scheme. And down here, we can ahead and create a new scheme. So I'll add a scheme-based on the Baffle Cocoa target in our workspace and I'll make it a distribution scheme.

Go ahead, hit OK and we'll edit the scheme. So here, we can-- here's what the editor for schemes looks like. So we can see all the build phases, all the info on the build phase, the test phase. And here, instead of the launch phase, we have our archive phase.

And we can choose to create and archive as a disk image or just the application. And this is what populates the contents of the organizer that I showed you earlier for the archive's tab. So every time we-- if we were to create an application archive type, every time we hit the Play button here, we would end up creating a new archive and it would show up in the archive's tab in the organizer. It's pretty simple. Makes sense? OK. And with that, I'd like to ask Anders to come back up on stage. That ends my part of the session. Thanks to everybody. [Background applause] Anders is going to close out the session.

Thanks Ron. So what we covered in this introduction to Xcode 4 session, talked a little bit about workspaces, in particular some of the-- let's say theory behind them that wasn't apparent at the State of the Union. So in the motivation for them and some of the uses of them both as an integral part of your source code and maybe as something you'll create as a throw-away collection of projects and temporary schemes. Some of the navigation, hopefully, you've learned a little bit more about some of the ways you can navigate between the various parts of your projects in the session and there are sessions coming out that will get even more into depth about that.

For the editing of course, we've been talking about the assistant editor quite a bit and we also saw some of the more specific editors. In terms of the organizer, this is again where you will go to manage your device if you're doing embedded development. It's where you can access all the repositories that Xcode 4 knows about because of the projects you've been working with. You can also access information about the projects there as well as documentation.

The Version Editor again, we support some version and get. And the Version Editor was a great way to see what exactly you will be checking in to see who did what. You might have caught it up there. But actually, there was a check-in from some account called "Demo Monkey" which said, "Let's see how Anders handles this one." So that must have been the one that added the error.

But I'd-- somebody went under a pseudonym there. So I'm not quite sure who he was. For debugging, of course, we have some of the good features like the automatic filtering of the local variables. What we're showing you just the locals and ivars and those kinds of things that are relevant to where these cursor where the program counter is at the moment.

You'll see more about that in the debugging session. And of course, schemes which is something new to Xcode 4 and these ways of attaining a goal as Ron said, which could either be to launch your app in the configuration for performance tuning or launch your app with specific debug checks, of course, for debugging or to hunt down a particular problem or to produce an archive or disk image.

I wanted to invite you to join us on online at the Developer Forums. Xcode 4 is a developer preview. Of course didn't-- nothing crashed at all on stage. I'm happy about that. So by the time we ship, we intend to be as polished and solid as marble. So we're hoping that you guys are going to provide good bug fixes and bug reports.

We'll do the fixes. You provide the bug reports with lots of-- sorry, lots of info about how to reproduce. And also, we would very much welcome your feedback about the direction we're going, about what you think about suggestions for how we can improve the workflow. This is really about making the product a better IDE for you guys to develop really cool Mac OS X and iOS apps.

And so, we want to try to do what we can to make you more productive realizing that there's a wide variety of development modes out there. There are a couple more sessions that are going to be talking about Xcode 4. One is following immediately in this room. There's the Developing Your App With Xcode 4. So if you stay here for that that starts in about 20 minutes.

And they're-- there'd be more in depth about some of the topics we talked about here. There's a specific session of Building and Distributing Your App and-- With Xcode 4. Pacific Heights tomorrow in the afternoon also at 3:15. And then another session in Pacific Heights following that immediately which is Using Interface Builder in Xcode 4. That will of course focus mostly on the Interface Builder editor that's now embedded inside of Xcode 4.