Good afternoon everybody, I'm Chris Espinosa. I'm the Manager of the Xcode Core Tools team and welcome to Flight 314, Building and Distributing Your App with Xcode 4. Please place your luggage under the seat in front of you and during this short 1-hour flight, we are going to talk about 3 things.

First, I want to let you know that in Xcode 4, you can load and build and run the same projects you have in Xcode 3 and then take them back to Xcode 3. So even with this developer preview that you have today, you can try Xcode 4 now.

It installs right next to Xcode 3. You can open up your Xcode 3 projects and you can take them back to Xcode 3 safely. So we haven't changed the project file format, we haven't changed the build system, so you can try the new workflow out and new systems out safely.

The first thing we've tried to do with Xcode is to make the simple things more obvious, things like setting build settings or setting the deployment target of your application we're trying to put right up front so that things that you do commonly and you need to do regularly are right up there.

But we know projects get complex, so we've tried to make sure that complex things are now manageable, and you'll see through this presentation today how we've taken the complexity that is grown in Xcode and the complexity that grows in your projects and given you some great tools to manage that complexity.

The 2 most important ones that we're going to be going through today, you saw little of these in the State of the Union on Monday, you saw some of them in the introduction to Xcode 4 session yesterday, are schemes. Schemes help you simplify and cut through the matrix of your targets times your configurations times your executables times your architectures and just designated this is what I do, this is what I want to do all the time and have a one-click access to a small number of things that you do regularly, very powerful construct.

Second thing is workspaces: workspaces let you organize work in multiple projects and associate projects together on an ad hoc basis or on a team basis without having to change the project itself so you can have an archive project, you can throw it into a workspace, do all sorts of things, do it in the workspace and then it doesn't change the project.

That lets you experiment safely. It lets you share work among people and it lets you combine projects together in ways you couldn't do before. So what you are going to learn today is how to use the Xcode 4 user interface to construct and edit projects and targets. There are some new things we got for project management and target management in Xcode 4 we're going to take you through. We're going to learn how to construct schemes, to build, launch, and archive your applications, and how to build workspaces that relate multiple projects together and share schemes that you create in them with other people on your team. So, let's get started.

Before I go into what's new in Xcode 4, I have to give you some common grounding on what I'm talking about in Xcode 3, some of the core words and concepts, mainly projects. A project is simply a bag. It's a bag of references to source files and header files, some groups that are artificial constructs that organize the files in the user interface for you.

And then these things called targets, you never build a project, you build a target, OK? The target is the thing that contains the instruction for turning your sources into your application, and they are the heart of Xcode, and we're going to give you more and better access to targets in Xcode 4.

In a target, there are references to the source files in the project and the target contains build phases, and the build phases say first compile my code, second link it, third copy my nib files, fourth package it all together and then copy it on to disks. Targets are the same in Xcode 4 as they are in Xcode 3. They may seem to you to be buried a level deeper, but that's because some more powerful constructs are being layered on top of them.

Now, one of the things that goes across targets are things called build settings. Build settings control how each build phase operates, how code files are compiled, how resources are copied, and build settings are combined into these chunks called configurations. You have one configuration of build settings to debug and you have a different clump of build settings, a different configuration, for releasing your code.

And managing all of these, juggling all the acts, it is really difficult sometimes because you have your debug configuration, your release configuration, your application target, your framework target, your build all aggregate target. You have architectures for the Mac, you have architectures for the iPhone and the iPad and iOS. It gets really complicated, there are 2 big changes in the Xcode 4 user interface that let you manage that complexity, and we're going to show them to you.

First is that what used to be the groups and files tree has been split into several navigators and the main navigator is the project navigator, and that's the one where you get at dragging and dropping and moving all of your files among groups. The second one is that instead of having all these smart groups in that group in file tree, we've given project management and target management its own full-sized editor, a tabbed editor that shows you all of the expanse of all of your options in your project in the target in the full real estate of the editor instead of trying to cram it into a tiny little inspector. Or rather than talking about that, I think the best way to do it is show it to you, so here is Rick Ballard to take you through the first demo.

Rick Ballard: Hi, I'm Rick Ballard.

I'm an engineer on the Xcode team. Today, I'm going to demonstrate how easy it is to take your existing projects that you have been working with in Xcode 3 and dive right into working with them in Xcode 4. Today, I'm going to start with the popular open source project called Colloquy, which is an IRC client for the Mac. And this is the same project that they used to maintain their projects in Xcode 3.

I'm going to go ahead and just open it right up in Xcode 4, it will load and you can see the Colloquy project is represented in the upper left-hand corner with its groups and files underneath, just like in Xcode 3. Now you notice that this project has some cross-project references. I can zoom in on this.

In Xcode 3, cross-project references would let you set up target dependencies between the targets across multiple projects. But to do anything beyond that, you would have to open up each project separately in its own window, work with it pretty separately, and you couldn't search across them or really do much with them at the same time.

In Xcode 4, that's all changed. In Xcode 4, a cross-project reference gives you full access to the contents of every project you can reach and you can edit, build, and work with all of the contents of all your projects together just as easily as you can with the project that you will open.

That includes searching across all your projects. It includes filtering across all of your projects, very easy. Now in Xcode 3, if you want to work with the settings of your project or one of your targets, you'd open up an inspector on that project and work with its settings there. But in Xcode 4, we've got all the space. It's really easy, you just select your project and you get a full-sized editor for that project in all the targets that it contains, just like any other kind of editor.

This is the Project Info tab, and this is where you'll find some of the most common central settings for your project. You'll notice that we've added a slider here for the deployment target of your product that lets you easily set the minimum operating system version that your products will run on.

We've also got a configuration section here. Now, if you've ever worked with Xcode configuration settings files, you know that they can be incredibly useful for organizing and unifying build settings across multiple targets, configurations, projects, et cetera. But sometimes, managing which target or project has which configuration settings file set and which configuration can be a bit cumbersome and you can make a mistake and leave one off somewhere. So, we decided we should make this a lot easier in Xcode 4 and we give you central access to the configuration settings files of all the targets in your project for this project right in one place across all your configurations.

The Project Info tab is also where you'll find localizations now so you can easily see which localizations your project is set up to support, how many localized files you have for each localization, and you can easily add and remove new localizations that you want to support. So we think that you'll find that centralizing everything in a project editor gives us a lot more space and a lot more room to work. What about build settings? Well, let's take a look.

If you've worked with build settings much in Xcode 3 in the inspector, I think you'll find that our new build settings editor gives you a lot more power and makes it a lot easier to work with your settings. Having all this space makes a big difference. So you normally start out in basic mode up here. You can see that there's a basic in all toggles.

Basic shows you just the most commonly needed frequently accessed settings for your project. You can easily navigate by category just like you could in Xcode 3, and you can switch to see all build settings if you need to, or you can filter. And if you want to know more about a setting, you can select it, bring up Quick Help.

Or if you want to work with a bunch of settings quickly, you need to find out what everything is. You can open up the Inspectors and there's a Quick Help inspector that will also tell you about the setting that you're looking at. So in this case, we're looking at the compiler version, and it tells us what it is and what the underlying build setting reference, which shows up as an environment variable in your Run Script phases, is to refer to the setting.

Now you notice that just like in Xcode 3, we have build setting conditions. Here you can set a different value for this build setting for each architecture that this project supports, if you so choose. But you may also notice that in Xcode 3, we have this configuration pop-up for searching back and forth between release and debug, and that's nowhere to be seen here. Well, sometimes it was a pain when you had to switch back and forth to compare your build setting values and we decided, hey, configuration is just another type of conditional, so let's make it a conditional.

If I click the Plus button, I can see the values for both my configurations side by side at the same time without any switching.

And you notice if I change the value for one of these conditionals, it will go ahead and show me the value that will be used for each combination of conditions in my project.

So it makes it really easy to just glance over and see what's going to be used under what circumstances. Now we've got a lot of space here, in fact I can make it give me even more space by turning off the inspector navigator. What else could we do with that kind of space? Well, one thing that people like to do a lot is compare the settings across through different targets, try and keep things in sync, make sure they have the right things in the right places. So, you'll notice that if I just select multiple targets here, I actually get a column for each target and I can easily compare setting values right across all my targets.

I can make this even easier if I want.

You probably are used to switching back and forth between your project level settings and your target level settings and making sure you know what set where. We've got this new levels mode, you can toggle between combined and levels and we've been looking at combined so far. But if I switched to levels, it will show me the build setting values for all levels in my project side by side.

So in the right, I have the default settings that are inherited, then the project level settings, and then the settings for both of the targets that I have selected. You'll notice that there are these little green boxes or instance setting values. The green box tells you at what level the actual value that's going to be used for that setting came from so you can easily glance over and see where your setting values are currently set, where they should be updated, et cetera.

We think you'll find this much, much easier and a real big help when you're managing complex projects and lots of those settings. The project editor is also where you'll find your build rules and your build phases. So build phases are the ordered set of steps that will be executed when you build the target.

In Xcode 4, we moved your target dependencies into the build phases, so these are the targets that will be built first whenever you build this target, and then there are other phases like compiling the sources of this target, linking with the libraries that it links against, and in this case, a bunch of Copy Resources phases and Run Script phases. In Xcode 4, we've added the ability to filter across all your build phases. This can be really, really helpful. If you search for something, it will show you everywhere in a build phase that it finds a match.

You'll notice too that whenever I go to add something like say I go to add a new library, I get a really handy-- give it one moment-- really handy sheet showing me all of my available frameworks and libraries in this case, and I can filter and easily find what I'm looking for and add it with a quick little button, very, very easy. Perhaps the most useful demonstration of why it's nice to have all these extra space now comes with Run Script phases.

In Xcode 3, you had to edit your scripts in a little inspector, but in Xcode 4 we give you a full-size source editor with syntax coloring and line numbers for editing your Run Script phases.

So we think you'll find this is all a big help when you're configuring your projects and we hope you like it. Back to you, Chris.

Thank you, Rick. We've taken great pains to try to improve some of the things that were suboptimal about working with Xcode 3 with multiple projects, with multiple targets, with multiple build configurations, and the matrix that those provide without really changing the underlying conceptual model, and we've got pretty far with that. But there is something else we need to do, because working with a single project or dependent projects was just far too cumbersome.

You had to go too many places and what people want is to make an overall program that declares what they want to do with all these projects rather than going in fiddling with all the projects themselves, and that's why we created schemes. The fundamental problem is that when you start a project, it seems so easy because you have one target that builds your application.

And then over time, you might add a library that that project uses. And then maybe you have a helper application or some other targets in your project, but it's still manageable. And of course, you usually just build the debug configuration, and then of course you have to build a release configuration that's optimized and has some special post processing in order to deploy it, and you're getting to get this proliferation and this is why you have so many different windows to go through in so many different modes.

Then of course, Apple invents another architecture to port to and then another architecture to port to and another architecture to port to, and all of a sudden we've got this unmanageable matrix of all of these combinations and then we go and give you a completely different platform that you have to port the whole mess to, and this is beyond control.

This was actually my feature slide last year, now it's my bug slide.

The feature we introduced last year was this thing called the overview pop-up that let you pick your overriding SDK, your architecture, your target, your executable, and your configuration all in the same pop-up. We thought that was a great idea. But what happened was that when you get so many of these things, it just goes off the end.

And frankly, the times when you're going to use any particular configuration, it approaches zero. There are 2 or 3 of those combinations that you're going to use all the time and the rest are either completely nonfunctional or dangerous to use. So we wanted to give you the control to just pick the things you need to do and put them in that menu.

What happens with schemes is that you pick a combination of targets and configurations and places you're going to run things, and you designate them as scheme to put in the Schemes menu. So for example, if my build and debug cycle means I need to build all of my targets for the i386 architecture in the debug configuration, I'll make one scheme for that.

And then when I need to ship it, if I just need to build my application target in my release configuration for all architectures, I'll make a second scheme for that. And then there are some variations on where I'm actually going to run it, but that's all I need. I don't need a separate entry in the matrix for every access and I don't need a separate entry for every combination.

And even better, your first scheme is free, we make it for you. When you open up an Xcode 3 project in Xcode 4, Xcode 4 scans your project and looks for targets that have executables associated with them or are not dependent, dependencies of other targets and they're therefore are top-level entities that need to be built themselves. And we looked at all the combinations and create schemes in the scheme menu for you. So we take each combination of a target and executable or a top-level standalone target, and we put them into the Scheme menu when you open the project in Xcode 4.

Then, we look at the base SDK, the deployment target, and the executables associated with it, and we create things called destinations. Destinations are the places that you build your product for and the places where you're going to launch to. So for Mac OS X applications for example, if you have i386 and x86 64 architectures, then we'll create separate destinations for all of your schemes for each one of those, and then you can just switch back and forth between Intel, Intel 64-bit and it will build and launch for that combination when you pick that scheme from the Scheme menu. Similarly, if you're building iOS applications, we look not only at the SDK and the architecture but we also look at whether you're building for the simulator or for which particular device that happens to be plugged in that you're building for.

So, in your Scheme menu, when you have devices configured, you may see some destinations for your scheme that are for the simulator, and you may see some destinations that are for a particular device that happens to be configured, provisioned, and connected. So the Scheme menu gives you all of the choices that all those 5 axis of base-- the override SDK, the architecture, the target, the configuration and the executable down to which device you're going to launch on, all in one short menu.

Now, as Anders went through yesterday there are three parts of every scheme: build, test, and launch. These are the three steps the scheme goes through when you pick it from the Run menu or the Build menu or the Test menu or the Archive menu. For the Archive menu, there's a special scheme called the Distribution Scheme, which instead of running your application, copies it of somewhere so that you can upload it, store, or save it off for future reference.

Now, in each part of the scheme, each part of the scheme does something different. The build part does what happens when you build a target in Xcode 3, it just goes through and performs all of the build phases of the targets associated with that scheme. There's a new test action, which will perform tests on your target. It's not fully fleshed out right now, but the intent is that you can have build, built-in test or build, test and run, or test and run as separate action.

So, if you want to just build all the time during your build cycle and periodically decide the tests, you can do that by preconfiguring it in your scheme and then just picking what you want to do from the menu. And then finally, the launch action determines how you launch the executable, whether you launch it under the debugger, whether you want break points turned on or off, et cetera.

For distribution scheme, it's basically the same thing. Except instead of launching, what you get to do is to determine which build products to copy, how to copy them, and where to copy them to, to save them off for future reference. Now, if you want to create your own scheme, you get a lot of control over what goes in it. You get to look at all of those axes and pick individually.

So for example, if I got these configurations by those targets and I'm building a new scheme, first thing I need to do is figure out what I want to build. So I pick my configuration, and then I pick which targets I want to build and it'll build those targets and they'll build all the dependencies that need to be built first before it builds those. And then I can designate for each of these whether I want to make it build when I click Build or make it build when I click Build and Run, so I get my choice.

Similarly for test actions, I designate which configuration I want to build for my test-- my test product, which targets I want to build for my test product which usually involve like my unit test bundle for example, and then whether I want to build it all the time or just build it for building and testing.

Launch actions take the place of the Executables inspector in Xcode 3. They let you set what your executable is, whether it's a build product or some other application on your disk, which debugger you use, GDB or LLDB, whether or not you want to launch it using instruments, whether you want to have breakpoints on when you launch, what environment variables and command line arguments you want to use to launch it with, but a couple of extra things, and these are very powerful. I strongly suggest you go in and look at these. It lets you, with checkboxes, turn on certain memory management diagnostics like Guard Malloc to run automatically. You don't have to put in special environment variables anymore, you just check the boxes.

Second, it gives you--

Second, it gives you some advanced logging options for automatically logging things from AppKit or UIKit as they occur. Now for distribution schemes, instead of a launch action, you have an archive action. The archive action simply lets you designate what you're going to archive and choose whether you want to archive simply your application build product or a disk image with all of your build products from the build directory in the flat list.

Now, when each action runs, you get another chance to customize what goes on in the scheme by pre- and post-actions. Pre- and post-actions are basically two things. One, you can send an email message or two, you can execute a script. And these let you do things when you build, when you build and run, when you test, when you archive.

Some things you might want to do is before you build, you may have some frameworks that are in the ZIP file that you need to unzip before you build the first time. So, you might want to write a script for that. Or after you finish building, you may want to go through and script out your private headers and do that in a post-action on your build.

Before you launch, you may want to copy sample data into some arena for your application to use and then clean up afterwards so you can do repetitive test runs. These are the kinds of things you may want to do with pre- and post-actions. And to show you the power of schemes is Chris Hanson.

Chris Hanson: Thank you, Chris.

I'm Chris Hanson and I'm also a developer tools engineer working at Xcode and so aim to go over to our demo machine here. And let's take a look at schemes in Xcode 4. Now the very first thing I'm going to do is edit my active scheme and make sure that when I'm building, I'm building for development.

I think I'll also open up the navigator again and let's just select some code here. Now schemes let you build for a given purpose, but we first get just our top-level targets. As Chris explained, turned into schemes when we open an Xcode 3 project in Xcode 4. I'm just going to select the Colloquy application here from our project and build.

As you can see, I switched over to the log navigator already-- or to the issue navigator immediately-- and that's because in the preferences, we actually have a new alerts panel but lets you set some actions to take place when different events occur like a build starts. So here, I just have it set to show the issue navigator. Because usually, when I build something, I want to see immediately if I get any errors or warnings. Well, if I show the issues by file here in the navigator, you can see that-- even though my build succeeded I have a few issues in this code.

Now if I select one, of course the editor will take me right to that line of code and we get a message bubble here, describing exactly what goes on. We can also click add-on-- icon in the gutter, just like in Xcode 3, to hide the message bubble. But of course, that doesn't actually remove the issue it just hides it.

Now, we can also explore issues by type so if you want to handle all of the issues in your code of the same type at once, you can simply change how the navigator is filtered and go one issue after the other through your code even across multiple files. But we don't have to use the navigator for that.

Let's say we want to see just all of our code and not worry about this list of things in the navigator. I can hide the navigator and instead use this control up here, you zoom in on that, that we like to think of this a mini-navigator. We just click on it. We got a pop-up menu that shows the two warnings that are in this file.

I zoom out. We can switch between those warnings just by selecting them. But we also have a bunch of warnings in other files. Well, I can use these arrows here, to iterate through the warnings and then when I finished the warnings on one file it'll take me to the next file. You can see I've gone already from AGRegex.m to AsyncSocket.m. We can also bring back the navigator here and used its filtered field.

Just like in other navigators, there's a filter filled and you can filter on the text of the warning, the file names and so on. If I zoom out and I just want to see all of the warnings involving semicolons, I can just start typing semicolon and I can see that there are a few semicolon warnings so I could go through and just fixed these if the other warnings might be a little bit more complex to handle. But really, if you just want to see you code, Xcode won't get in between you anymore.

I'm going to show the navigator again and we don't just show issues in the issue navigator. We also have a log navigator that lets you see all of the steps that have gone through-- that your build has gone through. Like the build window in Xcode 3. So this should be pretty familiar to people who have used Xcode 3. And you can see if we show the assistant, if we select a warning we're taken right there in the assistant editor in the bottom of the window.

But what happens if we highlight something that doesn't have-- oops, that doesn't have a file associated with it. Well, obviously, we don't have any assistant results but we can still see a transcript of the command that generated that warning so we can see what might have been happening.

We can also of course still filter using the buttons up here to see only errors, you know, in case we don't really care about warnings or if we really want to see all of the things that happened during the build, we can show all messages. And let me go back to the basic mode here so we can really see everything. And you can see that Colloquy is built it goes through a lot of steps.

But we only have one entry in this log, if I hit command B to build again, well, we switch back to the issue navigator because that's what I ask Xcode to do and then if I go back to the log navigator we have two entries for how we built. You can see that this is the build that I did first and now if I go to the second build I'm still showing all of the steps that Xcode went through and that's because I have All selected in the filter bar here.

If I just click Recent though, it will show that this particular build went through a lot fewer steps and those steps generated a lot fewer warnings, too. So we preserved these logs across multiple builds so you can see how your project is changing over time, not just in your own modifications to it but what Xcode is actually deciding to build.

As Chris was describing, you can customize Scheme menu to only show the schemes that you really want to use regularly. Now, Xcode has gone through and created some schemes for us based on top-level targets. But I don't necessarily want to see all of these. For example, I may not want to build the Ruby support plug-in directly. I may never really want to work with that. So, I can just open up the Managed Schemes sheet, click Show, and now it's no longer showing in the menu.

It hasn't-- the lead of the scheme know, I can still show that scheme and it also hasn't hidden it for all of the users of this project. That's only gone in my user data. So different users can show different set of schemes based on what they do with the project.

I'd also like to make sure that things are in the order that I care about, so I can just reorder these.

Let's see. I'm probably going to the regex testing first, so I'm going to, of course, keep the Colloquy application at the top of the menu. But the regex tests up above it and then show the Colloquy tests. And you can see the Scheme menu reflects the changes that I made there.

Now, if I actually want to make changes to the Colloquy applications scheme, I can just choose Edit Active Scheme from the scheme pop-up and I can see the stages that the scheme goes through and also I can switch between the various schemes that this project knows about and pick a destination for them that makes sense.

So here, in the build stage, we can see that we're building the development configuration and I've used the Plus button. Actually, if I just remove this, I can use the Plus button to add any of the targets that my project knows about whether in project itself or in projects that have references within it to the list of additional targets to build by the scheme.

Now the launch target would be built by the scheme and this is actually the target whose result is selected in the launch stage. But this other target here, well, I just want to build it for testing. So I have that choice now. So what I'm going to build with command B, this target isn't ever actually going to build, it's only when I chose test from the product menu that this target is going to build as well.

Now if I choose Test, my build succeeded pretty quickly, and if I look at the new build since I'm only showing recent changes, you see that it also built the regex test target.

If I go back to the Edit Active Scheme sheet, I can select the launch stage and here we have a choice of which debugger I want to use or which performance tool I want to use.

We can off course set the arguments to pass on launch and the environment variables to pass on launch. And we can use the diagnostics pane to turn on some memory and other logging and debugging diagnostics. For example, I've got Log dyld libraries turned on here, so I can see what libraries get loaded at launch time by MyApplication. If I just choose Run Without Building, you can see that we have the debugger here and my product-- my-- don't send, MyProject comes up.

And if I show the debug area again, there is a bunch of logging information from dyld saying exactly what libraries were reloaded. That means I didn't have to remember a cryptic dyld environment variable, and the syntax for putting that in my launch scheme, all I had to do was click a checkbox. But we're still in the log navigator and you can see that debugging actually got us a new entry in the log.

If I select it and zoom out, we can see all of the log data that was generated by that application. So not only do you get transient log data in the debugger area as your debugging, but it's also preserved right alongside your build results so you can go back and take a look at it later.

Now in addition to the launch schemes, we also have distribution schemes. So let's say I actually want to build this application, which is a Mac OS X application, package it up and post it on the web server. I would do that by creating a new scheme, selecting the primary target that I want to build, which in this case will be Colloquy application again.

I'm just going to name this scheme, build, and post, and then I'm going to make it a distribution scheme instead of a launch scheme. I click OK and go to Edit Active scheme and now you can see that the build stage is just like the build stage of my other scheme, although I think I want to build for release not development, because I'm going to send this out to people.

My test target is still only Colloquy. And now instead of a launch stage, we have an archive stage. And it's preset to generated a disk image. And you can select for a Mac OS X application which kind of archive you want to create, whether it's a disk image or just an application archive.

And you can see that we have a couple of checkboxes here for other options like including the dSYM files in your archive. That's if you want to save this out for symbolication later. One other thing that you might want to do with your archive scheme, your distribution scheme, is actually add a post-action. Let's say once you've built your application and had an archive generated, you want to actually copy that up using a CP to your web server.

Well, you can just use the new Run Script action button here, and you get an editor that has the full power of Xcode's text editor, including syntax coloring, for shell scripts and any other form of script. And after I post to MyWebServer-- let's just actually see what we're going to do here. Let's say I want to send email to my testers, and you can add as many run script stages as you want. You can reorder them and you can delete them.

And when you actually build an archive to your application, they'll show up in the organizer's Archives tab. Now, of course you don't have to do all of these through the Xcode user interface. You can set this up through the Xcode user interface and then we still support and have actually freely enhanced the Xcode Build command line tool so you can run your configure-- your continuous integration machine. Actually, I need to run the one that's in Xcode 4 user bin.

We install in Xcode 4 so as to not step on your currently installed dev tools. If I just show Help here, you can see that we've added workspace and scheme arguments to Xcode Build so you can tell Xcode Build to build a particular scheme and let it take all of its configuration from that scheme. And that workspace argument is something that Chris is going to tell you about next.

Thank you, Chris. Boy, that was a ton of stuff to cover. You've saw some powerful stuff there. But there were two really important things that you didn't emphasize that I want you to understand. I want to thank the Colloquy people for building a relatively robust, fairly complex Xcode 3 project that it didn't open and run the first time in Xcode 4. All we had to do is upgrade it 3 generations of compiler to build with LLVM 2.0 and it was great.

But that's basically all we did to the open source Colloquy project in order to get it opening, editing, building, and launching in Xcode 4. All we did was change the SDK in the compiler. A second thing is all of those changes Chris made to customize his working environment to narrow down the combinations to make pre- and post-actions on his launches to set up a special jig for testing. None of that touched that project.

Those were all his changes and if he wants to, he can just check the little shared box and share those changes with other people using Xcode 4 who have access to his workspace or that project. Those are two really, really powerful things. One is that we work with large, complex existing projects without changing and second is when you put Xcode 4 features in, that doesn't affect the Xcode 3 projects. Those-- that's really going to help adapt Xcode 4 in your organizations. Now notice I said workspace.

You saw a little of this before. Workspace are perhaps long term the most powerful thing we're adding to Xcode 4 and you're not going to see them by default because you just opened up a project and all you see is that project. But really, it opens in a window that we call the workspace. The workspace can be very simple or very complex.

So workspace is just the container. It can contain one file, multiple files, a project, or multiple projects. Workspaces have certain attributes. It imposes consistent cross-project standards on everything that's in it. For example, when you throw things into a workspace, the workspace is indexed as one. So all of your navigation can happen fluidly between things in that workspace and if multiple things that build there in that workspace they all build to the same location and that location is independent of other workspaces, even other workspaces that contain the same project.

And we've emphasized this a couple of times because a lot of people here use the trunk and branch methodology of development where you have an SVN repository or a repository for your trunk and then you fork off a branch and then load the project from that. In Xcode 3, if you're set up for a common build location, when you build trunk and then build branch, they're typically building into the same build folder and they step on each other and that's awkward and difficult.

With workspaces in Xcode 4, if you open each project in its own workspace, they have their own independent, self-contained build folders and they will not conflict with each other when you build the trunk and branch alternately.

Now what do you do to assemble the workspace? Like I said, the way you're going to build workspaces and you won't even know it is just by double-clicking your Xcode project, so it'll just open.

You can do it deliberately with a new menu and create a new workspace and you get a blank empty window and you can just drag and drop files right into it. You can use it as a standalone text editor if you want. Just close both sides, collapse the toolbar, drag a text file into it, there's your Xcode Text Editor right there. But if you want to drag and drop multiple project files, it's going to ask you the normal kinds of things that Xcode asks you for the reference style and whether to copy or not, and you can add new projects to it with the New Project button.

Once you get the workspace, the things you do in that workspace can be private or can be shared. And the sharing depends on whether you make your workspace available to other people either in a source code system or just by email or exporting it. So for example, if I've got a project in my workspace and that workspace is in a common repository, and Chris checks it out. All of my schemes are private to me and all of his schemes are private to him but I can go and designate some as being shared. And then he can see them.

And then he can take some of his schemes and designate them in shared and I can see them. So that's a powerful way to share things among people but keeping your own workflow. For those of you who always wanted to take for example custom executables from Xcode projects and be able to export them and share them with other users, this is what you can do that with. You create a scheme, a launch scheme that tailors how you launch, and you click the Shared button and everybody else who uses that workspace can see that executable: similar for debugging, similar for testing.

And to show you workspaces is, again, Rick Ballard.

Rick Ballard: So I'm going to start out here and take you through a little bit of stuff that you've seen very briefly at first but then off to something new. So we've got an existing application project here. And if I opened it, as Chris said, you'd automatically get its own workspace for that project without even knowing it. But sometimes I want to be able to create a manually managed workspace for several reasons.

One of them is sharing, another one is this feature called implicit dependencies which I'm going to show you. So I'm going to go ahead and start out creating a new workspace and I can just do that from the new menu. Say new workspace and I choose why I want to save it and give it a name. And I've got a new workspace. It's not very interesting yet, so let's go ahead and add my application.

Now I've got my application in here. You will notice the first time you open the project or add it to a workspace. We automatically create a launch scheme for it. And I can go ahead and build and my application should build clean. Oh, it's got a warning, but it builds.

So one reason I might want to create this external workspace is I've got a couple of things that I want to work on together and they're not directly related so the projects don't actually reference each other. But when I'm working on one, I usually want to-- I at least look at and maybe work on the other one, too. So in this case I've got my application, but I also want to work on this new tool, so I can just say from the Plus button down here or from the new menu, New Project. And create my new command line tool project.

Choose where I want to save it on disk. I'll say this to my desktop and where in the workspace structure I want it to put it. So I'll put it at the top level. Now, I've got both my projects at the top level of my workspace and I can easily search across them and work with them both.

Now if my coworkers want to work on the same 2 projects, I might give them my workspace file or I might check it into STM or if it's just me that wants to work on these together then I might have my own personal workspace and maybe sometimes use another workspace that my team is sharing.

Now you'll notice that my application here links this framework called MyFramework. It's going to reference to it here and if I want to see the actual linkage, I can select the project, select the target, go to the build phases and look at that link binaries with libraries and yes, it links MyFramework. Well, MyFramework is this framework I've got installed on disk and most of the time I just want to use the installed version.

But occasionally, I have a problem with it and I have the source code to this framework so maybe I actually want to build it from source and run against my debug version of that framework now and then. Well, you notice right now I have no dependencies on this and in Xcode 3, the way I do this is add a reference to the MyFramework project and then set up a manual target dependency.

And then every time I build my application, MyFramework would also build. But then when I want to go back to just building against the installed version, I'd have to remove the target dependency, and every time I'm doing that, I'm editing the project. You know, I have to be careful not to check in that dependency if other people don't want to work with it. So we decided, hey, wouldn't it be great if you could take a workspace and instead of having to set up manual target dependencies for things like this, just if MyFramework, the project is available, use it, and if not, don't use it.

So that's what we did. If I go ahead and just drag in the MyFramework project and build my application again, you can see that it actually built the MyFramework target without any explicit dependency at all just because it was there. So that's implicit dependencies. When I'm done with MyFramework project then I want to go back to using it from disk, I can just delete it from the workspace and nobody will be any the wiser.

So you may be thinking to yourself that's great, it builds it automatically but surely when I go to run I'm going to have a problem because each project builds into its build directory and the linker won't find the framework at runtime; not in Xcode 4. In Xcode 4, every workspace automatically has its own per workspace shared among itself build directory. So the build products from all MyProjects and targets in this workspace go in one common location.

This is really useful because each copy of the workspace gets its own unique build directory and that means that say, I check at another copy of this workspace from a different source control branch and go back and forth building this one, now building that one maybe because I'm trying to track down a regression.

Since each automatically gets its own build directory, their build results won't conflict with each other and I don't have to clean and rebuild every time I go back and forth. I just build in one, build in the other, and it just works.

If you want control over exactly where your build products are going now, we definitely give that to you.

If you go to the File Menu, there's a Workspace Settings option or if you've open a project, it's called Project Settings. And when I bring this out, this brings me to a panel that tells me all about where my stuff is going to go. The first thing you see here is the derived data location.

Well your derived data from your workspace is the build products and intermediates you produced and any logs from your builds and debug sessions and your index. And by default, we store all the stuff in a folder underneath your home folder. But if you needed to go somewhere special you can do that, say because you need to have everything good with secure source image for security reasons. Beyond that, by default, every workspace gets its own unique build folder so that it doesn't conflict with another workspace. But if you want, you can set a custom subfolder to use instead.

If you set 2 workspaces to use the same custom subfolder, they'll share their build products because they'll be building into the same place. Finally, if you do need to build into the classic locations set by your build settings as in Xcode 3, you can choose builds going to locations specified by projects and instead of getting the new derived data directory location builds, your build settings will dictate exactly where your build products go. Now, if I click the arrow here, I can actually go take a look at my derived data directory.

And inside you'll notice that each of my copies of my workspaces got their own folder. Inside that you'll see there's a build folder, an index folder for my index, a folder for my logs. This file here called Info.text, which just gives the path to the workspace that this folder corresponds to, which can be useful if you're trying to work backwards. And inside the build folder, you'll notice that we now separate your build intermediates from your precompiled headers from your products cleanly. So this should make it easier to work with your build products when you actually have to do that.

Now as Chris mentioned, there is another kind of sharing that we support in Xcode 4, and that's scheme sharing. And I want to show you just a little bit about that. If I go to the Managed Scheme sheet, I'm given several options. First of all, I see all the schemes in my workspace and I have a Shared checkbox.

Well, by default, every scheme I create belongs just to me and nobody else can see it so I'm not cluttering up their workspace and when I change settings, I'm not affecting anyone else. But when I set up a scheme that everyone on my team wants to use or I've got some setting that other people are going to want to use, I can just click the Shared checkbox and now it will show up for everybody, everybody will co-own it, they can all edit it, it's just a shared scheme at that point.

Well what happens if my team adds a whole bunch of shared shames and they're cluttering up my menu and I don't really care about these things that most of my team members care about. Well, the Show checkbox that Chris showed earlier let me easily say, hey, I want to leave the scheme alone at shared but don't show it to me.

And that Show checkbox is per user so I'm not affecting anyone else when I say not to show it.

The last thing you'll notice here is the container column and that lets me control exactly where each scheme is saved. These schemes are saved off in their own files.

So changing your executable settings no longer affects some big file that you're managing at resource control. Instead, each scheme gets its own file easy to manage in source control and I can control whether I want a scheme to be saved in, say, the project that it's associated with or the workspace.

When I do that, that controls whether well, if I share the workspace with somebody else, do they get my schemes? If I share just the projects but I'm keeping the workspace for myself, do they get those schemes? I have full control over that with the Container pop-up. There is one more way to share this which is very useful which is in the Gear menu there is Import and Export options.

I can go ahead and export one of this and just save the scheme file directly to disk. I'll save this one to my desktop. I could email that to a colleague and he could turn around and say Import. Choose the scheme, import it, and it shows right up in his project.

So we think that sharing is a lot easier in Xcode 4 and we hope that you find this stuff very, very useful.

That's terrific. Thank you very much, Rick. Well, we are now approaching our destination. Thank you for attending. I want to sum up a couple of things for you. You saw a lot today. Come down to the lab tomorrow morning if you need a recap of what this all means or to see some of these things in real life.

Download the product from the hardwire connections in the labs or in any of the public areas. I hope that when you download Xcode 4 and install it and open up your projects, you're going to start seeing 3 or 4 things. First is that your Xcode projects that you have already open up in Xcode 4 and you can edit and build them just like in Xcode 3.

And then take those projects back to Xcode 3 if you needed to. That you have a lot more room and clarity to edit those projects in their build settings because we show you all of the configurations at once and all of the targets and project at once instead of making you go to a lot of modal little inspectors to figure out what's happening where. I'm hoping that what I personally get out of this is that I never have to ask people are you looking at the target settings inspector or are you looking at the project settings inspector, and then explain what I mean by that question.

And its sister question is, do you have all configurations chosen or just one configuration chosen? Both of those problems go away. Third thing is that schemes are a really powerful way to organize your work personally and to organize the work in your organization and share it in your organization.

And you can control how you build with schemes without having to make all of these edits in your project file that create trash in source code system and create angst because I don't want to see those new aggregate targets you created for your test jig and they make my menu too long. Those problems go away with Xcode 4. And finally, the free form association of product projects, the way that projects will implicitly build implicitly depend on each other. The ability to search across multiple projects all the time and get to the right answer in the right project.

The ability to index and jump and navigate across projects. The ability to edit the build settings or the targets of all of your projects you're working with in one window instead of having to open 7 project windows on your desktop. You'll find that those tremendously improve your productivity when you're working with Xcode 4. For more information, Michael Jurewitz is our evangelist. He's here the rest of the week, which is not very long.

Apple Developer Forums, there is a specific developer forum for the Xcode 4 developer preview. It's all already quite active, get on it, ask questions, read the questions and answers other people have answered, read the release notes. There are 11 pages of release notes for this release. Go ahead. There's a lot of stuff there and there's great documentation. There are only a couple of sessions left talking about Xcode 4.

Using Interface Builder with Xcode 4, in this room immediately after, stay in your seats, it's going to be great, tons of great stuff. Tomorrow morning, Debugging with Xcode 4 and LLDB, the great new things in our LLDB debugger. Thank you all very much for coming.