Morning everybody! Welcome to session 401, What's New in Xcode 2.1. That was unexpected. That's the button. I'm Chris Espinosa. I'm the manager of developer tools productivity at Apple. And we're going to take you through some of the new features in Xcode 2.1. Now, it's available for download. We saw on the mailing list last night that a lot of you have already downloaded and installed it. That's terrific. A lot of you are already asking questions about it. It's also terrific. We'll have Q&A after this session, so you can find out a little bit more about it.

And it's really important, if you haven't done it already, and you're planning on coming to the session 4.02 right after this one, please download and install Xcode 2.1 on your machine. Also download the appearance sample updated sample code from DTS.apple.com. That's the sample program we'll be walking through in the hands-on this morning at 10:30.

So here's what you're going to learn in this session today. We're going to go on a quick recap of the features in Xcode 2.0. It was only released 12 weeks ago. A lot of you haven't even installed and updated to that. But when you go to 2.1, you're also going to have to understand what was in 2.0, because there were some big features there.

The key features of Xcode 2.1 that we just introduced: build configurations, the breakpoint actions, conditions, and watchpoints, both of those you saw yesterday in Ted's demo. Integrated unit testing you heard about. We're going to do a short demo today, a longer demo later in the week. And the project file format changes. I'll go into a little more detail about those. And of course, we're going to talk about Xcode support for universal binaries. The good news is that there's not much to learn. It's really great.

So let's talk about Xcode 2.1. We just introduced 2.0 12 weeks ago. Why did we turn around a .1 release so quickly? The answer: universal binary support. We couldn't ship that to you in Tiger because we hadn't made this announcement yet. We had to put it integrated into the UI, clean, so that you could use it right now.

And we also had to make some other major changes so that people could start upgrading, start migrating their non-Xcode 2.0. We're going to be moving from Xcode projects to Xcode and have a more productive development environment there. Xcode 2.1 replaces the 2.0 that's in Tiger. It runs on Tiger, it builds on Tiger, it builds for PowerPC and Intel, and it cross-develops all the way back to Mac OS 10.2. So you can upgrade to Xcode 2.1, run it on a developer transition system, run it on your current PowerBook or G5, and turn it on. And target the developer transition system, the G5s, or any machine back to 10.2.

It includes the Mac OS 10.4 Universal SDK. That is the key to the developer transition and targeting Intel. You need the SDK, whether you're running on the Intel machine or on the PowerPC. It includes features to support large project management. We really listened to our developers who were saying, Xcode doesn't scale. You need to make it easier to manage very large projects and trees of projects.

There are some new features to help with that. And it's got a lot of minor productivity enhancements. We've had this long list of things you've asked for over the years that we just never got to. We got to them this time. I think you're going to like what you see.

And then dozens and dozens of bug fixes. The good news is that we were just closing this project just as you were getting the Golden Master of 2.0, and we were ready to jump on anything you reported of new crashing bugs, corner cases, weird things that you found in 2.0. We didn't have to do a lot of that. 2.0 was a really solid release. We expect 2.1 to be just as solid.

The new project file format and the extension, I think, is going to be the change that affects you most, because 2.1 projects cannot be ported back to 2.0 or 1.5. It's a trapdoor migration from 2.0 to 2.1. To help with that, we've made a new project file format and extension. And so when you open a 2.0 project in 2.1, it saves it aside so you can maintain them side by side after that. It doesn't affect your old project. Upward but not backwards compatible with 2.0.

So let's just do a quick recap of what was in 2.0. You probably got the seeds for that. You got the Golden Master 12 weeks ago. Maybe you haven't really explored all of its new functionality. Let me take you through that pretty quickly. There are some new UI layouts. There are the design tools, a favorites bar where you can use your Xcode IDE as Safari-like to have quick reference to all the things you need. There are some new UI layouts. There are some new UI layouts. There are some new UI layouts.

All new documentation and dynamically downloaded documentation from the web and improved Apple scriptability. The layouts. You can use your preferred workflow now in Xcode. In the preferences, in the general preferences, there's a choice of three different layouts. The condensed layout is code warrior-like. One single window for your project and all other files, all other modes like debug or build results open in separate windows.

If you're migrating from code warrior, this is probably the one you'd prefer. The default layout, what you get if you just install Xcode raw, is the one that we've been using from Xcode 1.0, which is the three pane view. The groups and files, the detail view, and the embedded editor with the option to open separate editors and still your build, your find, your debug windows are all separate.

The all-in-one is for people who are accustomed to something like Visual Studio, where you always work just in one window. Your debug, your build results, your find results are in separate pages in the same window, rather than opening in separate windows. So wherever you're coming from, we have a working style that matches yours.

The design tools. This was one of the big features in Xcode 2.0. There are two sides to them. One is the class diagram, where you can make a diagram of the class model of your application, either your entire project or even selected parts of it. You can manipulate the diagram and change it however you'd like, and even save it to use as documentation and navigate from the class diagram back to your source code very easily. Then the other side is that you can create a data model of the data in your application for use with the core data framework. There are some sessions on that later this week if you're interested in exploring those. This is a great, powerful feature of Xcode 2.0.

The code completion in Xcode 2.0 is greatly, greatly improved. It's much more responsive. It does not pop up automatically unless you specify it to, and then it only does so for method completion. Okay? So it stays out of your way rather than popping up when you didn't want it to or when you least expected it to.

We've also improved the heuristics for when it does a completion and what the priority of the completions are. And more often than not, it knows what you're about to type and offers you that completion first in the list. There's a little toggle in the list where you can have the completions alphabetical or by priority order. You'll find that very useful. There's a little more on that in session 4.0.3, which is coming up on Wednesday afternoon.

So those were the big features of Xcode 2.0. And like I said, we had a crash project once 2.0 was finished to turn around 2.1. Why did we do that? What was our motivation? First, we need to support the transition to universal binaries. And there are a couple different sides of that. One was to just support building universal binaries, but two was to support your transition if you hadn't come to Xcode yet.

Build configurations are a really important part of that, not just to help you manage multiple configurations and deploying for universal when you're building for native on the desktop, but also when it comes to coming to Xcode for the first time. Build styles were kind of alien. They worked in a counterintuitive way. We watched what was going on in the Xcode users list and saw that that was one of the major stumbling blocks, and we had to address it.

Unit testing. We know that when you build once and deploy on multiple times, you're going to have a harder time qualifying your product on multiple deployment platforms. You really need to make sure it's right. Building in unit testing helps to ensure that your code is correct before you deploy it. And by ensuring it's more correct before you deploy it, you have an easier time qualifying it when you have to deploy to multiple chip platforms.

And then the new project file format. People kept telling us that if I have multiple developers working on one project, when two people are making changes, more often than not, I get a conflict in my project file format. If I have to hand edit it, I can't understand what's going on, I have to throw it out and do it again.

We have made some improvements in the project file format to make it more readable, more diffable, more mergeable, to try to make it easier for multiple developers to work on the same project. Again, if you've got your PowerPC experts and your Intel experts working on the same project, that's more important now than it was before.

And we just wanted to improve livability. People who've moved to Xcode have sometimes done it with teeth gritted, and I know several developers, personal friends of mine, who drop a note to me every day on "Xcode should work this way" because there are some livability issues about it. We have addressed a ton of those in Xcode 2.1. We've improved the debugging and given you some features that you really, really need to get your job done, and gone a little beyond. We made a lot of UI changes to introduce familiar elements.

The biggest change, however, I think is from build styles to build configurations. How many of you are using build styles in Xcode 1.5 or 2.0 now? Okay, so you know what build styles are. That's great. Build styles are a way to reduce target proliferation. And for that, they actually work fairly well.

Because in some other environments like Code Warrior, you set up a target, you include all of your files in the target, you make all your target settings on that target, you build it, you get a build product, that's fine. But that's just for debugging. When you need to do a release version, or you need to do a version for beta seeding, you need to clone that target, change the settings, and then you can build it.

And then from then on, you need to maintain those targets in parallel. If you add a file to one target, you need to make sure to add it to the other. If you make a change to a target setting, you need to think, do I need to make that just to this target, or do I need to make it to all targets? And that's a maintenance headache.

Build styles help with that by giving you a set of settings that apply across targets. They're a product of the build style in the target. The target has its settings. The build styles have their settings, and at build time, they're combined. But build styles are imposed on the target rather than combined with them, and that's been counterintuitive to a lot of you.

The style settings override the target settings rather than are inherited by the target settings. So when you're looking at a target inspector, you don't see what you're going to get because you don't see the build styles that are imposed on them. So because the build style settings have obliterated the target settings, that has been confusing to a lot of people.

And that is especially true when you have projects with cross-project references or sub-projects. Because what we do with build styles is we take the build style from the master project and we apply it to all of the sub-projects, regardless of what their target settings or their own build styles are. And that means that if you have a sub-project, that the master, if you build the sub-project alone, it's built one way, but if you build it as a sub-project of a master project, it's built a different way. That's been very difficult to debug.

Build configurations work differently. And this is the most important change. I'm going to spend a lot of time on this now. Session 408 on Friday is going to spend a lot of time on this. This is the major thing to get in moving to Xcode 2.1. And we think that this is a very, very positive change.

But if you spend a long time wrenching your brain into how build styles work, you're going to have to wrench it back to build configurations. Build configurations is a matrix, not a product of settings. Each target owns its own settings for each configuration, and each... Target Configuration Setting Set is independent of the others.

You can make all of your changes at the target level now. If you want to, you can never leave the target inspector. You open the target inspector, you see your configurations listed in the pop-up, you make changes there, they take effect, what you see is what you get.

And we think that that's going to be very important, very intuitive, very clear at build time. So if I have three targets in my debug configuration, each target has its own debug configuration, each target has its own release configuration. What's more important is when we're dealing with sub-projects. If I have a target in my sub-project, it has its own corresponding set of configurations.

for debug and release. So when I build the parent project debug, I tell the subprojects to build with their debug configuration, not a set of settings that's passed down to them. It's an important distinction. If I build my subproject in its debug mode, and then I go to the parent project and build everything in its debug mode, I get the same thing. And that's going to be very helpful for you in debugging.

Now we put this in, we played with it, we used it, and we realized we made it clearer, we made it more intuitive, but there was still some power in build styles that we really, really wanted to have. And that was the ability to set it once and have it shared among all targets in my project. Now the way we were sharing it before was not right, it was imposing. When all of you thought, it was inheriting. So what did we do? We made project build configurations that are inherited by the targets.

So what if you want the same settings across multiple projects, targets in your project? How do you make sure that if you create a new target in your project, that it's got the right settings without having to set it all up manually? And how do you make target settings as concise as possible? A lot of you have complained that you go to the target inspector, you choose show all, and it's daunting. There are hundreds of settings.

How do you focus it out to see what's different? Well, the way to do it is by putting your common settings for your project in the project settings and have all of your targets inherit that by default and override it if necessary. It's a very simple model. If you've done object-oriented programming, it's dead obvious for you. It's just the right way. We've designed it the way you thought build styles worked, and it's going to work a lot better.

But we went one step further because a lot of big organizations told us that they're used to storing their settings in configuration files, checking them into their source code repositories, diffing them, managing them, using them repeatedly across multiple projects so that when you start a new project, you just pick the configuration file and add it to the project.

And then you get all of your settings right there rather than having to go in and check the same two dozen obscure, confusing check boxes in every target. So we added those. A configuration file is just a list of pairs. It's a .exe config file that's in your project. It's a list of setting equals value pairs.

You can prototype it, as I showed yesterday, by either cut and paste or drag and drop right from the inspector, so you don't have to learn a new syntax. You just cut it out and paste it in and drag and drop it. and you can share this file among multiple configurations, among multiple targets, and your project settings can be based on one set, your target settings can be based on another configuration file, and the same inheritance rules apply. We think this is going to be very, very powerful. So, to show you those, it's a lot to go through, but Scott Tooker is going to come up and he's going to walk you through our new build configuration features. Thanks, Scott.

So what I'm going to do is I'm just going to do a quick walkthrough. We're going to take the project I'm actually going to be doing a hands-on next session. We're going to take the final version of that and just play a little bit with build configurations. So the first thing I wanted to do was just show you the new target inspector.

And it's really not all that different. The big changes we had from 2.0 is that we've added this configuration popup at the top. And you'll notice here that it has the ability to show all configurations, which will show you basically a combined set of the values across all your configurations. It can track the active configuration. So for example, if I go and I change the active build configuration to testing in this case, these values actually change.

And then finally, we allow you to look at any specific configuration, for example, debug, release. So now what I want to do is just show you, the behavior is still the same. So for example, if I want to set something on, let's say, the release configuration for just this target, I can just go in. And let me search for, for example, dead code stripping. And so what I'm going to do here is just check this. And now what you'll notice is I've set this on my release, but I haven't set it on testing or debug.

Now, if I wanted to set this across all configurations, I can also just easily go up to all configurations. You'll see that it shows multiple value. I just click on this, and now it's set across all my configurations. And so when I go look at them, they're all there.

So it's really simple. And as Chris points out, you don't have to go any further than this. If all you want to do, you can just set everything at the target level, and that's fine. However, especially with projects with lots of targets, it becomes a bit of a maintenance headache, because, oh, did I set it in the third of my five targets? Did I remember to -- across all 20 targets, set a given setting? Especially in the case of things like warnings, for example, or things like dead code stripping or debugging settings, things that tend to be the same across all the targets in a given project, there's a much better way. And that's the project build configurations. So let's go ahead.

I'll bring that up. Now, one of the things we get a lot is this looks very similar to the build styles. Unfortunately, yes, it does. But it's -- I can't say this enough. It's very different. We do not have build styles anymore. Project build settings are a completely different beast. For one thing, as Chris said, they live underneath.

And also, they don't -- they only apply to your project. They don't apply to subprojects. But, for example, here, let's say I wanted to take dead code stripping and make it a project level setting. Well, what I can do here is say, you know what? Let me go ahead and cut this out here. And let's go over here into my release and paste it there.

Oops.

You'll notice that it also has dead code stripping set. And when I go through and I uncheck it, It goes away in both. So it's really easy. Now you have one place to set those things like warnings, debug levels, things that you're going to set once. And you want to have the same thing for all your targets. Well, that's great.

But what about those cases where maybe not across all your targets, but all your release applications, for example, you want to have a common set of settings? Let's say I wanted to set dead code stripping, and don't strip init's and terms, in just my release-- in my release applications, but not necessarily and they were released libraries.

Well, let's go ahead and click those. What we can do, I can set it here, but then I have to remember to do that across all my projects. And if I ever want to change what my release app is, that becomes a headache. Well, instead what I can do is I can just go ahead I'm going to create a configuration settings file. Let's just call it release app settings.

And so for example, this brings up a new XC config file, which is our configuration file. And I can just simply come over here. I will go ahead and cut the settings, paste them over here.

make a change, and it's instantly picked up. This is extremely powerful, especially for those of you that have lots of projects, lots of sub-projects, but you have standard policies about how you want to package your debug, your apps you give to testers, your release.

Before Xcode 2.1, you could at best put things in build settings. Now we have a lot of flexibility in this area to allow you to set things at the project level, and also outside in these XC config files that you can easily check in. And with that, I'll give it back to Chris. CHRIS BANES: Thanks, Scott.

If you want to standardize on a style of debugging or a style of release, if your company says that when you release code you must strip the symbols or you must put in these kinds of version strings, things like that, you can put that in the project settings per configuration.

If you want to characterize what a particular target is like, this shared library is this way, this application is this way, this tool is this way, And you're going to have multiple ones of those that are the same. If you have a lot of similar tools, a lot of similar plugins, you can put them in a configuration file that is shared among all targets of that type.

And if you want to distinguish among the debug and release flavors of a particular target, then you can put them in the target inspector for that target. It will inherit everything from the project config files, from the project settings, and from the target config file, and then you can specialize on top of that.

And then finally, if you want a special case, if a single file in a single target for a single configuration has to be built with a special optimization flag or a pragma or some sort of compiler-specific things, there are always per-file settings that you can go in and for a special case you can override them. So there's a nice, clean stack of inheritance all the way up from my company standards to the way this one file needs to be compiled.

We also have taken your feedback and we have changed the way that our build folders work, so that the build folders for both the intermediates and for the build products are segregated by configuration. So that if you're building your debug build and you switch over to release to build it, and then go back to your debug build, you don't have to rebuild your debug build from scratch.

You can also have your debug product and your release product have different names, or be in different places, because you can have those are in the per configuration settings. This is a pretty big change, and if you have complicated scripts, if you have post-processing scripts, if you have workflow processes that depend upon your build product being in a certain location, it will now be in a folder in that location, and you may need to adapt those. We do provide some build settings that tell you exactly where it is.

Anders Bertelrud will go over that in the project management mastery session on Friday afternoon. They're also mentioned in the build setting notes in Xcode 2.1. For most of you, though, this will be a change to be more intuitive. If I build my debug and I build my release, now I have two instead of one. Thank you.

So let's sum up build configuration. It's the biggest change in Xcode 2.1. It is, I think, the best example we have of our attempting to balance simplicity and clarity Power and versatility for what you need to do, and also backwards compatibility so that you don't have to make major transitions with your code. We have eliminated the number one frustration about build settings is, "Why can't I see this in the target inspector and set it here?" No more strikeout type. It's been removed from the product.

They have a more intuitive inheritance from the project level to the target level, so you can have the power of generalization and specialization without the confusion of where is that actually being set. They do the right thing with subprojects, it's what you expect, that when you build a subproject in its debug configuration it will build with its debug settings, not its parent project's debug settings. And the project configurations and the configuration files give you an expressive power that I don't think you've seen before in any Apple development environment. I think it's really going to help you.

The main thing though is that all of these were put into this version at this time so that you could set the right settings on the right configurations on the right targets to help you build universal binaries. You're going to really use, you're going to set the settings for universal architectures, the settings for per architecture settings in your configurations, in your target, or in your projects. That's where you're going to do it.

So that's configurations. The next main thing we've put in that I think is really going to affect your working style is breakpoints. Now a lot of this is old news to you if you've been using other environments where you've had conditional breakpoints and watchpoints and continuation and other styles of breakpoints and breakpoint actions for quite a while. We have conditions.

If you've used conditional breakpoints in other environments or at the GDB command line, they'll probably be utterly familiar to you. We have breakpoint actions. You have seen these in code where you can log something when you hit a breakpoint rather than stopping. If you do printf style debugging, you will love logging breakpoints because logging breakpoints are printfs you don't have to compile. It's really great.

The visualization you saw a little bit of yesterday, it's a way to see where you are in a bird's eye view of your application, rather than just having to look at a stack crawl and see where you are there. Continuing after pause lets you set a large number of breakpoints and watch your program flow without having to click the continue button over and over again. And then watchpoints watch the value of a local variable.

So let's go through those one by one. Conditions. Pretty easy to set. When you hit a breakpoint, it shows in the pop-- in the tooltip what the condition is and what the situation is. You can go to the-- So right here I've set a breakpoint on this line, and I only break when the answer is above a certain threshold. So if you're trying to break in an iterative loop, and you don't want to have to step every time, you can just set a conditional breakpoint, and it will only stop at that particular condition.

The conditions can be any valid expression. You can evaluate things, you can even make function calls or method calls in the conditions. We warn you though, make them as simple as possible, make them have no side effects, and make them really reliable so they don't crash or stop your machine. Because those are going to be evaluated every time you pass that breakpoint, and it could severely affect performance or even the behavior of your application if you do untoward things in your breakpoint condition. Also, remember that you are in the debugger. You're not in the compiler.

So you don't have full access to everything you can type in your source code. You don't have a preprocessor available. So it just has to be a condition that can be understood at runtime. Breakpoint actions. Once you have a breakpoint, you have a number of actions that you can perform.

And you can perform more than one action in sequence. It looks kind of like the Automator interface. You can log and optionally speak a message, and there are a couple of value substitutions that we can put in the log message, including the hit count of that breakpoint. You can play a specified sound, anything in your sound files.

You can visualize the current class and method in that class in the class diagram, either one you've prepared already or one that's dynamically created by the visualizer. You can execute any shell command. So that's very powerful. You can go in and use anything at the Unix shell at breakpoint time. You can execute any Apple script.

One of the things I did for a demo right here was to go into the Unix shell and execute a shell command. So that's very powerful. You can go in and use anything at the Unix shell at breakpoint time. You can execute any Apple script. One of the things I did for a demo right here was to go into the Unix shell and execute a shell command. So that's very powerful. You can go in and use anything at the Unix shell at breakpoint time.

was to set my iChat status message when I hit a breakpoint. So if I've got something that needs to run for four or five hours, and then it hits an error condition, and I put a breakpoint on that error condition, I can set it up on a remote machine, log it into my iChat account, and then just watch it in my iChat status window, and when its status changes, I know it's hit its breakpoint, and I can go off to the lab and figure it out.

And of course, since GDB is our underlying debugger, you can execute any GDB command at breakpoint time. And that applies to remote debugging as well. The GDB command will be executed in the inferior on the remote machine rather than on your local machine. That's pretty important if you're doing two-machine debugging from a PowerPC machine to an Intel machine, for example.

The visualizer is, I think, the neatest part of it. We've just begun to scratch the surface on what you can do with this. It shows the method highlighted in the class of where you are when you hit the breakpoint. So if you're watching the flow of control, if you want to see whether, for example, you're doing something four or five times, or where something's getting called from, or how the flow of control is happening, it can show you that in a dynamic way. It is only for object-oriented code. It doesn't show you your path through C code. And it does show only your class inheritance hierarchy.

It doesn't show your instances. We're going to be moving this technology forward and doing everything we can to make it work. We're going to be doing other things with it in the future. So consider this just a first taste of what we intend to do with visual debugging.

Watchpoints. We use the GDB Watchpoint feature that's been in Mac OS X forever. We've improved its robustness and reliability a good bit, and we've made it accessible through the user interface. If you're familiar with Code Warriors Watchpoints, it works the same way. You stop in the debugger, you select a variable, you command-click it and pick watch from the context menu. It's just that simple. And then it will break whenever that value is changed. Now there are a couple of caveats for that. It uses the hardware paging system to watch changes.

Since we don't want to impede, so that impairs performance a little bit, and it also is not good for variables that are on the stack. So you really can't use Watchpoints to watch locals or registers, but you can use them to watch anything that, for example, you've malloc'd. That's really useful. This is considered something of last resort. If somebody is changing a value and you don't know who it is, this is the best way to do it. But it's only when tracing program flow has failed.

So breakpoints, much more like what you're used to. Some might consider this Xcode catching up. I'm not unproud of that. We have a lot of catching up to do with some environments that have been in the market for a longer time. But we do need to provide you this capability so you can be more productive. And we're also intending to not just catch up, but go beyond with more of the breakpoint actions and with the visualizer.

So let's talk about the third thing, which is unit testing. How many of you are using a unit testing discipline in your development? That is a surprisingly good number. That's great. Well, what we've done is we have taken some of the industry standard open source unit testing frameworks and we've integrated them into the Xcode build environment so you can create a new testing target in any project, populate it with test cases, and those test cases will be executed against your project and targets in it at build time. And the results will be reported in your errors and warnings window at build time. It's seamless, it's automatic, and it really helps you integrate unit testing, the unit testing discipline, right into your current projects.

It's an opt-in model of testing. We don't force you to write test cases before you can compile. You can start by doing your project normally, then you can add the unit test target and one or two tests and you can... beef up those tests over time. We don't force you to have tests for everything. You get to add tests just as you want to add tests. This is hard to describe in words. The best way to do it is a demo, so Chris Hanson will come up and demo the unit testing feature for you.

Thank you, Chris. Let me just close everything up here. And switch to my favorite layout for Xcode, which is the default layout. What I have here is just a simple project temperature converter that I've added some unit tests to. And I've also introduced a couple of subtle errors, so we can see just how unit testing and our other error reporting mechanisms are integrated in Xcode 2.1.

So, first thing I'm going to do is just try to build my project. You'll see that I'm not actually building the temperature converter application, instead I'm building the temperature converter test's target. This is a bundle containing all of my test cases, separate from my application. As part of the build process for this bundle, we'll actually launch the application, inject our tests into it, and run all the tests, and then report the results. So let's try building this.

Well, we're precompiling, we're compiling, and we get an error. So, I'll bring up the build results window, and we can see what that error was. Well, we have a parse error here, and it looks like we left out a colon. This is coming from the compiler, obviously. So let's just fix this and rebuild. Saving before building, of course. And now we link. Now we're building our tests.

We're running our tests. And somehow, ah, here we go. We got an error. So we have another error in our code. Now, if we click on this test failure here, which shows up right in our build results window, it takes us to the exact line of code that failed. Now, here we have an assertion that two values are equal. So we have one value here. Why don't I double click this, and I'll bring up the actual source code for our test. You can see that we're just iterating over a collection of conversions.

And we're performing conversion using our value transformer, and we're comparing it to a known good value. And we can see that one of those failed. And if we look in our build results window, since I can use a format string in my assertion, I can even tell which iteration failed.

So what I'm going to do is set a breakpoint on this line by control-clicking in the margin and choosing Add and Edit Breakpoint. And then, since I don't want to sit there and step through four iterations of my loop, I'm just going to put in the condition that failed. So that was iteration three.

And now, if we go back to our build results, We can see that even though we had an error, our build succeeded. This is because we actually did build the products that we wanted to. It's just running our tests that failed. This means that we do have products available that we can debug. So let's debug right into our unit tests. We'll load our program in GDB.

Chris Espinosa, Scott Tooker, Chris Hanson Our assertion. And we can even see that our condition is i equals 3 if I hover over the breakpoint. It says what our condition is. So let's just step into this code, and we're in our transformed value method. So let's just step a couple lines and see if anything looks suspicious. Let's step over here.

That looks fine. That looks fine. That looks fine. But what's this? We're assigning an integer value. to a double variable. What happens if we do this? Well, it says that-- Our centigrade interim value is -273, rather than -273.15. So that's probably where our error is. Let's terminate, change our code.

And let's just go back to the build window where we can build and build again. And this time, it succeeded. Bring up our build results. We have no errors. So we fixed our bug. That shows you how Xcode's integrated unit testing really is integrated into your development workflow. Back to Chris.

You're going to see a lot more on unit testing a couple more times this week. Come to Power Programming in Xcode, which has been moved from Tuesday evening to Wednesday evening to accommodate the porting lab tomorrow night. And Chris will give a longer demo and more complete explanation of how to set up unit tests in your application. Unit tests are a great development methodology and they're supported in Xcode 2.1 in the build system, in the wizards, makes it really easy to integrate testing into your software. Final major feature I want to cover is project file format changes.

The main things we've done are to improve readability by adding comments in the project file that tell you what's what, rather than having to grope your way around long hexadecimal UUIDs. We've added mergeability. We have taken things that are atomic, like file references, and put them all on one line.

So line-based differs and line-based mergers and line-based comparison routines can tell this whole file was added or this whole file was removed. Rather than by saying, "Oh, these two files, they look mostly alike, but they're only different in this respect, so that's the only difference." Well, that's inaccurate. So by combining things on one line, we've made merging project files work better with line-based diff and merge algorithms.

Similarly, things that are discrete, like project settings, we have busted out from single lines to multiple lines. So if you change one target setting in your version of the project, and she changes a different project setting in her version of the project, that a line-based merger can merge those together, rather than saying, "Oh, this whole line has changed in both places.

There's a conflict. I don't know what to do," and make you grope through it manually. And then writeability. We have improved the ability to machine-generate project files. The UUIDs that are there for Xcode's internal cross-references are optional, so you don't have to generate them. And the project file format is complete and definitive.

It's not like an XML import/export format that has a difference in fidelity from what the real thing is. The project model in memory is the project file on disk. So if you can generate a project file through mechanical means, when you read it into Xcode, that generates an identical project and will save the identical project file. We think this is really going to be a help in big organizations where you have to machine-generate a lot of identical project files for plugins, for standards, things like that.

We're going to continue to refine this. We reserve the right to completely change the project file in the future. But for now, to get your big projects up on Xcode, we think these changes are really going to help you. When you look at the project file, it's still somewhat cryptic. It's still got a lot of stuff in it, but it does look like an old-style plist with comments in it, in it, and it should be a lot easier to pick things out now.

OK, so those are the big hits in Xcode 2.1, the configurations, the breakpoints, the unit testing, and the project file change. But like I said at the beginning, there are a lot of little things we've done, too. We think these are really going to improve your productivity. In the user interface, we've added an unlock file widget right to the file editor. So if you open up and edit locked files and you want to save them, you can unlock them right from the editor. Small things, we know that bbedit had this when I was in short pants, but now it's there in Xcode.

We've added the touch feature to Xcode. When you click in the build column, it marks the file as touched or untouched. It flips its state so that if you need to rebuild a specific file, even though you haven't changed it, you don't have to open it up, type a space, and save it. You can touch it right there in the user interface.

We've added a target inspector for every file and every group so that you can see what targets a file belongs to, and you can change it right there in the inspector. You can even take a whole group of files and change their targets just by selecting the group, opening the inspector, and checking and unchecking the target membership. We've added a lot more drag and drop to the product. When you're setting up target membership and dependencies, you can drag and drop a dependent target right onto the target inspector. Okay, one clap. I thought it deserved more than just one.

And we've also added a lot more drag and drop for build styles and paths. So you can take any file proxy and drop it into any inspector that's expecting a string, a path, or whatever. And it takes the path to that and drops it right into the inspector.

In building, we've really improved the dependency checking and the reliability of it. This is going to speed up your development more than you'd think, because a lot of times you're either building files unnecessarily that don't really need to be rebuilt, or something that does need to be rebuilt wasn't being picked up and you had to do a full, clean rebuild in order to get everything right. We're looking at a lot more things now. We're looking at more build settings, we're looking at more internal dependencies, and we have much more reliable building when you click the build button, what needs to be rebuilt is rebuilt, and what doesn't need to be rebuilt isn't rebuilt.

We think that's going to be a lot more reliable. We're also helping you by being able to clean without removing your pre-compiled headers, so that if your pre-comps are good, when you do a clean, your pre-comps are safe. You're still around, and you don't have to rebuild them on the next build. And that's just a simple checkbox in the Clean dialog.

We've also added a capability to preprocess your Info.plist files. People who have .plc files in Code Warrior have been asking us for a long time for this. Rather than adopting the PLC language, which has a lot more to do with different language variations and localizations of your plist, which we handle in a completely different way, or inventing our own precompiler language, I mean, everybody wants to invent their own precompiler language, don't they? We just take your Info.plist and we pass it through GCC's precompiler.

You can have your own prefix file, you can include header files, you can have pound if conditionals, you can have macro substitution, all the things you want to share variables between your source code and your plist with the same GCC preprocessor. It's very simple to set up, just a couple of settings in the target inspector.

And finally, in debugging, we've added a lot more data viewers. String and OS types are now viewed properly, no matter what. You can view any long int as an OS type. We've added a string viewer for the STL string right in the preview window. And we've added completion in the GDB console. It's there from terminal. You have completion now in the GDB console within Xcode. And it's mapped to the same completion key that you use in the Xcode editor for code completion. So if you have your own preferred completion key, it works in both code and in GDB.

We have improved the SCM system a lot. We have automatic online/offline detection and a master switch. If you unplug your machine and go offline from your SCM system, it does not turn off the checkbox in every project, making you go back and turn it on again. It just sets it to offline. When you plug the cable back in, it's just like mail. It notices it's online and all of your projects come back online to their SCM systems.

We've also added support across all SCM systems for unwrapped package files, NIBs, class models, RTFDs, It's really basic right now. A lot of SEM systems don't particularly like handling unwrapped files, so a lot of the operations are not necessarily going to do what you want them to do, but the basic add, commit, checkout work. Things like moving and renaming may be a little more difficult in some systems, but at least you can check your nib into subversion now.

And we have some... We have some improvements to Subversion and Perforce, which does not have a hyphen in it, but the spell checker wanted it to have one. Thank you. Never sign off on the final review of your slides until you've read every word. In the Documentation Viewer, we've made some improvements both in the viewer itself and in the documentation that it views. We've added all of the standard C library calls to the Documentation Viewer, so when you look for malloc in the API view, it's there.

It took our VP to insist that that happen, to make that happen. It's very surprising. And part of that is fallout of all of the man pages for man 3 and man 8, I believe, are now indexed in the documentation viewer. So all of the Unix man pages are there. for API. And we've added back forward buttons, just like in Safari, to the documentation viewer, so you can manage a lot of different documents in a back forward fashion.

And also, of course, we still have what's in Xcode 2.0, which is the union of on-disk and on-web documentation. We'll index everything and then show you the hits in the index, regardless of whether it's local or on the web. Automatically fetch the HTML page from the web if you want, and then when there is an updated set, we can download that from the web automatically and put it on your disk for quick reference.

And finally, we are continuing to beef up the AppleScript support. A lot of you use AppleScript to automate creation or management of projects in Xcode. We added a lot of support in 2.0. In 2.1, we extended it to much more target creation, SCM operations. The project upgrade from Xcode 2.0 to Xcode 2.1 is AppleScriptable.

There is a script up on DTS right now that's associated with this session and the next one, where you run that script and it will automatically walk a project tree and upgrade all dependent sub-projects and change their names and references in their master projects to refer to them. You can use that not only to upgrade your projects, but also to read to see how some of the new Xcode support works.

Build configurations, all of the Xcode support for build styles and so on. This has been removed, that's been moved over to build configurations and you can create targets now using AppleScript. Pretty much the only thing you can't do is create new projects from scratch in AppleScript. We've got almost everything else covered.

So, a lot of stuff, a lot of stuff to put in a dot release. We are really looking forward to your installing it, using it, giving us feedback on it. We're going to have a lot of time for questions today. Xcode 2.1, powerful and intuitive build settings management. We think we've removed your impediments to productivity and added the things you need to do to support building universal binaries.

Versatile debugging, not just with the breakpoints, the actions, and the watchpoints, but also the visualizer, a new way to look at your application in action. The UI features that you've been asking us for for years, they're there, they work. and David Satterthwaite. We expect that usage of Xcode 2.0 should drop off really precipitously starting today. There's almost no reason to continue to use 2.0 when you have 2.1 available.

For more information, everything is on the ADC website. We have a lot more sample code this year. We have a lot of sample projects that are .xcproj. They will only open in Xcode 2.1. They demonstrate a lot of the features of Xcode 2.1. We have sample code of projects with subprojects.

We have sample codes to build configurations. We have sample code for unit testings. Lots of sample code to show off the new features. It's all up on the website. There is an updated Xcode 2.1 reference guide. If you've seen the 2.0 guide, it's truly phenomenal. It's huge. It's thick. It's detailed. It's accurate. It's got everything you need in it. You can now RT-FM. Okay? I'm going to answer a lot more questions with that because the FM is fabulous. It's a fabulous manual.

Other resources? Us. There are some related sessions. Matt, are you supposed to be doing these slides? Okay, I'll finish. Best session to come to is to stay in your chair, get on Wi-Fi, download Xcode 2.1 and install it, download the appearance sample updated, get it on your PowerBook, and follow through for the next session in here, 10.30, Session 402, Adopting Xcode, hands-on. It's going to be an adventure. Power programming with Xcode has been moved from this afternoon to tomorrow afternoon. We're going to go through the user interface features of Xcode quite a bit in depth and detail.

Project management mastery with Xcode, Friday afternoon, Anders Bertelrud will tell you the whole truth about build configurations, how they set up, how they work, how build settings work, what's the relationship of the environment variables, what the stack is, all of the gory details of how to really, really get your arms around the power of Xcode.

And moving to GCC 4.0, Wednesday, 5 o'clock, if you're bringing code from GCC 4.0, you're going to be able to get your arms around the power of Xcode. And moving to GCC 3.3 to 4.0, there are a lot of changes in GCC 4.0, even for Xcode 2.0. The compiler is much more accurate in its adherence to the C++ standard, so especially if you have C++ code, you should come to that session.

Support, support labs, support labs, support labs. Tuesday, Wednesday, Thursday, come to the lab, bring your source code, we'll bring it in Xcode 2.1, we will move your build styles to build configurations, we'll help you set it up, we'll get you running, we'll check the checkbox and you will walk out of there with an Intel binary. We want you to do that. And then the feedback forum, if you want to talk to us, Friday, 5:00 PM. We know you'd rather be having margaritas. We'll be there answering your questions. Matt Formica, come on up. He's our man.

Develop Tools and Cocoa Evangelist. If you want to get to the team, we are on Xcode users at lists.apple.com. We answer your questions, we listen to your feedback, we want to hear what's going on, we want to hear how you're doing with the product. Please subscribe to that list, please tell us what you think, please ask questions rather than flailing around.