Ladies and gentlemen, please welcome Senior Product Line Manager for Developer Products, Wiley Hodges. So I want to welcome everybody here today. Today, this Monday, marks the beginning of my 12th week back at Apple after a four and a half year absence. And what a 12th week! Geez. This is a really exciting time to be back at Apple. I was lured back to the company by the promise of something really great happening in developer tools. And hopefully this morning you got a taste of that with what Steve showed in the keynote, an Xcode.

I personally was flabbergasted by what was happening. I remember standing behind Steve Naroff's chair in his office and getting a demo of Xcode a few weeks ago, and just my jaw hitting the floor and thinking, "This is so fantastic. I'm so excited." And that excitement has just kept with me this whole time. And I want to share some of that with you today.

And we're going to start off by introducing the person who has overseen this effort and helped make this all possible. I am pleased to be able to introduce to you Mr. Ted Goldstein, the Vice President for Development Technologies at Apple. So thank you very much and welcome, Ted. And I want to shake Ted's hand. This is a great day. Thank you, Wiley. Thanks, Ted.

So I think this is going to be the first Nemo-free presentation. I like Nemo, but you know, got to talk about something else. So let's talk about a great legacy. I think developer tools on Macintosh have a great legacy in that we really do, are building on a number of truly excellent and incredible systems.

Developers have had extremely high expectations because many of these systems have been just really fabulous. First, maybe not so fabulous, but the Lisa development system, coming out in 1983 and '84, was soon followed very quickly by Lightspeed Pascal. And Lightspeed Pascal really changed the way people thought about programming because you could type a line of text and immediately see it executed. The designers and founders of Lightspeed really wanted that extremely interactive environment where you could interactively develop the code and really feel the application come into existence under your hand so that, in fact, almost the tool itself disappeared out from underneath you.

And that really is just what I think of as the most important property of a great tool. One reason why we use the hammer is you don't really think about the hammer. You don't know who the maker is. You just swing it and knock the nail in, and it disappears from your existence because your brain is focused on what you're building. Lightspeed Pascal was the first system that actually made that happen. And I think it's an important part of the legacy of development on the Macintosh. Because it was so well matched, so well matched to the interactive experience that the Macintosh offered in 1984.

The next system that I think was incredibly important and meaningful to Mac developers was the Macintosh Programmers Workshop. Fabulous system, yes. It brought the full Unix kind of command line sequence, but did it in a very interactive environment, and it provided scale. People who could start development in Lightspeed Pascal often found that they ran out of steam when the applications became a certain size. And MPW was really great because it allowed for small groups and teams to work together. But when it became larger teams and larger groups, MPW really didn't help all that much, and people found it falling down somewhat.

I think one of the greatest systems that brought the capabilities of the C language and such that people were using in MPW, but brought it to the interactive field was the Lightspeed C environment. Many, many applications were written using a combination, living in Lightspeed C for the development phase, but finally, they were able to run in Lightspeed C for the development phase, but finally, when you get to deploying, they switched back for shipping the application using MPWC. And those two environments really ran very nice and synergistically together.

Think Reference, an important system, provided great documentation, allowed for that interactive feel and capability of knowing, to be able to navigate through all the immense APIs that Apple was providing to you. I think one of the most important systems, and clearly one that stands to this day as the leader, is MetroWorks, C and C++.

And really sets the standard, and we respect that. Since for the last 10 years, MPW has really become the gold standard in development on the Macintosh, and it's really set the bar very high. And every time we look and compare ourselves, we, of course, compare ourselves to what MetroWorks and Code Warrior have done.

But Apple also wants to make sure that it's a player in this game. And we have, of course, when we introduced Mac OS X, we brought back the Unix environment. We wanted a Unix-focused set of tools with interactivity. And we have the Apple Project Builder environment that we came out with in 1999. These systems and these tools, Apple Project Builder, really harkens back in many ways to MPW and to that whole command-line-oriented interface with a wrapper of a very interactive feel on top of it.

But you could certainly tell that the interactive tools had a lot of different features. And the reason for that is that they're not necessarily the same as the other things. They're not necessarily the same as the other things. And so they're not necessarily the same as the other things. They're not necessarily the same as the other things.

So we were challenged by developers to do better. And last year we set a fairly high rigorous standard for us, ourselves, that to actually do far better in developing applications and to improve the program productivity than ever before. And I think it's critically important, critically important to say that today with Xcode we've made a tremendous step, I believe, in the right direction.

So, when we step back, we think, what's the basic mission of what we're trying to accomplish? And that is to improve programmer productivity. And we've actually decomposed the problem into four basic things. First, you need to be able to rapidly develop new ideas. Second, you need to be able to get to your code and then get out of that way. You want that transparency.

You want that tool to be an extension of your hands. You want it to, you know, not so that the tool itself is all that glorious, although we're very happy for it to be a beautiful and aesthetic thing, but we want you to be able to focus mostly on your applications, because it's your applications, frankly, that we depend upon for our success, and we recognize that. So, we want to take you to the places in your code that is most important and critical to making things happen.

The third is the XGUNry bugs. You need to be able to find your bugs and to fix the problems that occur, to be able to extend the code and to have that very interactive cycle that really goes all the way back to Lightspeed Pascal. We think that this is a critical, critical ingredient that you love about many of the development environments on the Macintosh, and we wanted to strive for that same type of experience with Xcode. You saw a taste of that in Chris Espinoza's demo this morning.

Finally, you need to be able to manage large projects. Many of the applications that you've written are in the millions of lines, in the tens of millions of lines of code. And applications that scale that have large teams, teams spread over multiple continents, and you need to be able to manage huge volumes of code and such altogether.

And we think that that has been, in some sense, a big place where Apple has previously put a lot of its effort, because so many great third party developers have put their effort in making that interactive experience. What we want to do is fuse all four of these directions into one tool, into one experience for you.

And so, we begin with a new user interface. And that new UI, in some sense, is inspired by the UIs that have worked for the Macintosh users. In fact, in many ways, you recognize, of course, kind of an iTunes-like feel about it. iTunes and your music collection may in fact be the largest corpus of data on your disk, right? Much larger, perhaps, even than the source code you manage. And yet you can sort it by group, by genre, by artist, by how frequently you've listened to it. It has this wonderful feel that you're just able to manipulate it.

You're not doing SQL queries to find the song, you're just clicking away and finding it. And it becomes a fabulous tool. And it was a great inspiration for us to use this metaphor, and it has so worked extremely well in many other of the new tools and applications coming from Apple, that we thought, gee, here we have a great place to begin a new user interface experience.

But then, of course, you're also used to speed. And this idea of rapid builds and zero link, this notion of eliminating the link phase or making it so minutely small that you don't care about it anymore, is of course a cornerstone of productivity. That feature of rapid cycle development and such is of course an essential ingredient and I think a hallmark of every Macintosh environment that needs to exist.

Now, how about finding the data? Of course, things like searching for information, just as it is in your music, just as it is in the finder, you have an enormous number of different ways of organizing and classifying information, and the metaphors that work extremely well for the applications work well here too.

CodeSense is this idea of the app that since it is an interactive tool, it knows something about your program. It has a built-in index of the symbols and information, and it's able to help you complete that on the fly. And then Smart Groups, this idea of being able to have meta information organized, both the lines of the code and the files and such, into categories that dynamically update themselves. And this is an area where we've only just begun. You'll see the first steps here, but this is an area where we're going to be looking at the next steps. we would love to get feedback. In fact, we want feedback on all the features from you.

Next major quadrant of features is in finding and fixing problems. Fix and continue, or the fix feature that you saw this morning, very important part of that dynamic interactive development field. And this notion of four matters, right, that you're able to tell us something about the way you want the data to be presented to you, so that you can take any of the types, both that are built into the system, or to extend it with your own data types, and show it in a short amount of information on the line, on the debugger information, both for standard types and for templated types.

The final convergence is how do you cope with a very large application? SCM, source code management systems, distributed builds, this idea of being able to form it out to a network of computers. And finally, you know, what's often the last phase, but in fact what we would like you to do is to be part of every part of development process of running performance tools, building and integrating it into the application as Scott talked about in the last session or to use it as part of the interactive development environment. We think all these these things need to be merged into one environment we call Xcode.

Now, many of these features are features that you've had before. What we intend to do is to essentially say, look, we need to meet your needs by providing you with a UI that you don't have to struggle to learn, that's fast, that works as you expect, and has the features that you've loved in other programming environments that have been done extremely well before us, and so that you're not sacrificing anything. We think it's critically, critically important that we build upon the past, and that we take that and use that to your advantage.

and other developers will be joining us in the next session. Thank you. My goal is that no build should ever take more than a minute, no matter how large the application. We're not there yet, but we're working on it and this is in fact I think the very first and most important step that we've set this important target to really make this tremendous and we'll show you some of that later today.

Fix and Continue, this idea of being able to dynamically patch the running application and insert new code, and to be able to try out multiple different ideas, to be able to fix bugs on the fly. And, of course, Zero Link, this idea of limiting the link phase, so that you think of linking as a kind of an optimization, an optimization that is applied after--or as you get towards the end of your project to make things even more tight. In fact, we will probably use the link phase time in the future to do additional optimizations, additional compilation technologies, so that we can actually do cross-module and intermodule optimizations that are more--that help you improve the execution time of your code.

So, our challenge then is to provide you with the fastest way to create Macintosh, Mac OS X applications. Applications that are fast to learn, fast to use, fast for debugging, and that the generated code is fast. We want to provide that to you, and we think Xcode is a tremendous leap in the direction of providing that.

So, you've seen some of this information. We hold MetroWorks as the gold standard, and this is on certain files we've picked out in Finder. And you can see that in Jaguar, we took a fairly lengthy 30 seconds of time. Back in the December '02 tools, we made good progress and reduced its sum. But I think in Xcode, we really cut it down to nine seconds.

And that's--that I think is really getting into the place where we're finally beating what Code Warrior has to offer. And then down to even three seconds where you have this very terrific process where almost the debugger ceases to exist and you're just modifying and changing the running application, and you saw that this morning.

On full build times, again, the time has been getting better and better, and now we're releasing with X-Codes in its distributed build mode. Fabulous, incredible time where we get it into the 100 second range, and even, I think today we're going to see even better than that of our benchmark application.

Let's talk about Carbon. Some people think Apple made tools to do Carbon programming. How many people thought that? Just curious. We do Carbon programming, we love Carbon. Xcode was designed from the ground up, focused on Carbon. And really to make the Carbon development cycle tremendously productive. And of course, that also means making C++ tremendously productive. As you saw in the Safari, we use a mixture of C++ and Objective-C, and they work extremely well together in a language dialect we call Objective-C++.

We've designed certain features in Xcode specifically for Carbon and C++. For example, you can now set breakpoints on exceptions. When a class raises a C++ exception, the debugger built into Xcode will catch it. We've provided a new feature we call the SDK, and this is the ability to live on one version of Mac OS X and target another. So you can actually live on Panther and target Jaguar. And in this developer release we're handing out to you today, live on Jaguar and target Panther. And as well, we also support Puma too.

These formatters, which allow you to write in C++ directly, and that is invoked automatically by the environment to display your data. And of course, the fact that C++ does require an immense amount of cross-information in header files, we've provided this feature of distributed builds and PCH pre-compiled headers to make that easy and terrific. So with that, I want to invite up Steve Naroff to talk about the Xcode experience. Thanks, Ted.

We want to provide a fit and finish that's consistent with the Apple brand. From my perspective, that means four things primarily. It means the UI has to be responsive. That doesn't just mean a fast compiler, it means fast find, it means being able to get your job done in general in a very fast way. Number two, it means expressiveness.

We want a UI that can view your project data from many different perspectives, because there are many times during development where you're working on a project that you may or may not have created, and the way you want to view the data is significantly different based on what stage of development you're at. Number three, we want workflow that makes sense and that just gets out of your way. We want to make sure that you don't have to relearn a whole bunch of new concepts.

We want to make sure that you don't have to relearn a whole bunch of new concepts just to use the tool. We were inspired by many of the applications that Ted's mentioned. We were also inspired by many of the third-party applications that you've developed. We use them, and in fact, we look to them often with great pride.

We learn from you, we're inspired by our own apps as well. And harmonizing with Panther. When you look at what Panther's doing and you look at what we're doing, it seems like a unified whole. I think that's actually a breakthrough for us, to have the tools and the user environment have a very uniform look and feel and flow.

And the fourth thing, and this is very important, it needs to look sharp. It needs to be pixel perfect. In the past, we never collaborated with artists, design and production, and Steve Jobs was gracious enough to let us have the support of Apple's world-class design and production people. And it shows.

People who are expert at developing compilers and development tools are not artists. And some of the guys have developed icons over the years and we've gotten by, but it's really helped to have support from our world-class production people. So, with that said, I'm going to go through a demo.

So I have a project built. I have two projects we're going to look at today. One is appearance demo, and for those of you who have used Code Warrior and are familiar with Power Plant, this will look very familiar to you. What we've done is we've used our importer technology to import it into Xcode, and right now it's built, and I'm going to take you through some of the user interface now.

One thing, let's start at the top. We have these drop-down buttons at the top. If you click and hold, basically you get a list of buttons. The idea here is to save valuable toolbar real estate for operations that are fairly uncommon. So here we group build, clean all, and clean together.

Likewise over here, we have build and run, build and debug, run and debug. We have a stop button here. We have a little widget here to open an editor. I'm not going to do that right now. We have find, and we have an inspector. So you click here, you get the inspector. You click again, it goes away, just like many of the apps on the platform.

This morning you saw Chris Espinoza give a demo of some of the features here. If you want to look at all the header files or the resource files, you can see them likewise. So the search fields, very fast. Now what we're doing here is we're actually looking at the project group. If you can read the status message in the back, it says we have 359 files. One of the reasons we have 359 files is Power Plant is actually included in this.

Power Plant's typically statically linked into your application and there's no exception here. Let's now go through the table view here. If you click here, you can sort by kind. The application bubbles to the top, and the C++ files are all grouped together, and the header files are all grouped together. And then you have the resources towards the end.

Here, if we want to sort by file name, if you want to sort by code, you can see that the lwindow.cp is the largest object code we have here. And likewise, you could sort by warnings. So, there we have warnings, file name, kind. All very fast, right? So, let's see. Where do I want to go next? That is just a standard group, okay? So, you create these groups. In fact, if you click here, you can see that it has substructure, as you've probably seen in this project.

You can click here and you can go through with the arrow keys and see all the files that are there. So, even though hierarchy is something that I personally hate dealing with all the time, you can actually use this in a hybrid manner where you're using some of the hierarchy, however, you're still using what we call the detail view or the table view there. So, it's your preference. So, I'm going to go back here and we're going to sort by file name. And as you might expect, if you double click on a file here, you get an editor, okay? Fairly standard behavior.

Likewise, if we go over here, you can double click on the application group. If you double click on the application group, what we do is we actually fill a drawer with all the files. So, oh, a couple claps there. So the nice thing about this is you have the benefits of a standalone editor where you don't have to constantly go back to the project window to get to your other files. Right? And your groupings can be arbitrary. So for instance, I could close the groups, close the window, close my hierarchy, double click on my project, and here I actually have all of the groups.

Right? So you can double click on a file, get a separate window, you can double click on a group, get a drawer full of the files, or you can double click on the whole project. This depends on the size of your project, your work style. You can imagine having two editors up with two different groups. So you have a lot of flexibility that can adapt with your needs.

One of the things we hear a lot from you is, oh, well, I don't want to work in an embedded editor, and I don't want to work just in single window mode. I want to have a lot of control. And what's cool about this is you have control that, in fact, you control. You don't have to go to a preferences panel and set it all up and say single, many, all, or any of that stuff. It just works as you would expect. So, There's a little button here to get back to the project.

And why don't we now look at the first smart group. So here's a smart group called implementation files. And what it does is, it goes through and basically gets all your .cp or .c or Objective-C files out. So it's filtered. So if I was to add a file to my project, if it had a .cp extension, it would automatically be viewed when you clicked on the implementation file. So again, the analogy with smart playlists is it's based on a rule which you set up. And in this case, it's set up to do .cp files.

There's a project symbols group here that is very interesting. So right now we are looking at 8,000 symbols here, and if you click on the kind, you can see how fast that is. It doesn't hesitate. And this is a G4, just to be clear, not a G5. And in fact, you can go here and you can type, and it keeps up with you very nicely. In this case, we limited it from 8,000 to 630 symbols very quickly.

You also have the flexibility to go to the table view and say, you know, I don't really need the symbol type, and it gives you more room for your other data, right? Very nice capability. So, again, it adapts. And then you can pretty much go up to the symbol, and you can say, now let's look at draw, draw, and we go down here and you can see how nice it is to be able to basically cut through all the files and get to your data.

I've always wanted to have a great way to edit polymorphic methods, because polymorphism is a huge, it's just a great design tool that is underused, and in fact, when you have a tool that makes writing polymorphic methods this easy, in fact, I think it will encourage a different style of programming.

So, Go back here. Now I'd like to quickly demo the fine results. We go here, and right now you're looking at a sheet, obviously, that has a fine text field. It has a pop-up that says, do you want to do a textual search, regular expression, or the definition search? Right now we'll just stick with textual search. And we can look in the project, in the projects and frameworks, frameworks are all open files, and we can look in all the files and so on.

So right now I'm going to look for a string called the bar, and you can see it's right there. It's right there with me, and it's still looking over the entire project, and if you get the hits here, we can double click on it, and it takes you to the bar. So very nice, very convenient, very fast. So what I'd like to do now is show you a cool feature we call CodeSense.

If we go right here and we say "the" and hit escape, right now we're looking at everything that matches "the" in this context. So for instance, if I click "B" I used to have it sent to be case insensitive, but it's not set case insensitive anymore, so I have to type correctly now. But there is a feature in CodeSense to say, listen, you don't have to be so rigorous about case. So if I hit escape now, it will complete it, and then when I hit arrow, it will show me that.

All demos, yeah, you gotta love them. Okay, I think we'll go someplace else now and we'll... Okay, let's do something else right now. What I want to do now is actually build the app. But before I do it, let's look at an error and warning smart group. Now I'm going to show you the embedded editor here. What we have here is all the errors and warnings that are part of the build that we did last. So here I'm going through all the errors and warnings, and as you can see, we annotate the gutter with the warning right there.

And we can use the search field very nicely by saying unused and parameter if we want to see that. Here we limited it from actually over 200 errors to 6 errors, or warnings I should say. So it's very, very interesting to be able to manage your warnings this way, where if you're bringing over a large project, and in fact, as you can see, we compiled all of Power Plant here and there were 264 warnings.

Why is that? It's not necessarily because it's bad code, but because the GNU compiler has a different set of constraints that it places on code, to put it politely. And sometimes it finds errors, sometimes it doesn't. So I don't really know how many of these warnings are real, but the bottom line is when you port code from Code Warrior to Xcode, you will encounter this same phenomenon. So what I'm going to do now is I'm going to go to the inspector. Go to Build. I'm going to click something called "Inhibit All Warnings." Okay. And then what I'm going to do is click on the implementation files.

So what I'm going to do now is hit build and run. It's going to compile this right now. and what it's going to do is remove all the warnings for me and so you can see that All the warnings are going away. And it's really interesting because-- let me see, where I have the search field, thank you. There I go. So you can see it's shrinking. It's removing all the warnings and errors. So this is a really easy way for you to tell your manager, "Oh, we've cleaned up all 260 warnings." You just click that button and everything goes away.

Okay? Very nice. And so as you can see, we're compiling fairly fast now. This power plant builds in about 55 seconds, a little bit under a minute. And that we consider very respectable. We want to do better, but for right now it's 55 seconds for a full build of power plant, and it should run the application right now. So you've seen this application many times, I believe, most of you.

So, I'm going to go back to my drawer here. Go to one of the application files in here. What I'm going to do now is show you the nav bar. Here we have a symbol pop up, so if I want to go to listen to message, we can navigate down very conveniently. And if I create a syntax error and I hit save, and I hit build, You can see from the editor, we've basically annotated the gutter, and then when you click on it, you can see the error in the status.

The reason this is important is it gets back to this low distraction factor that we're trying to promote. We want to bring the information to you, so if you're in the editor and you make a syntax error and you hit build, you don't have to see some funky panel come up in your face and you get the error right there.

So right now, if I correct my error, and I hit build, you can see it goes away automatically. And it also gives you a sense for how fast things are, right? Because as soon as I hit save and as soon as I hit build, you saw it go away, which meant it had seen the source code and had corrected it. So, that's useful.

I'm going to show you briefly some neat support we have for searching the help system. So here we have a window which The Google Search Engine has the same search field as all the other Windows and you can, let's say, if you want to search for "retain." And it keeps up with you very nicely, and then if you click on it, it will take you to the HTML documentation very quickly. Okay? Very, very quick. So, right there. Thank you.

Likewise, you could focus on specific books, so to speak, with Carbon, Cocoa, Apple Script, Library, whatever you want. But it's so fast that often when you don't want to think too hard, again, you just go there and you get the information you need. And just like with the other user interface elements, you can basically remove these columns as you want. So that's that. Now I'd like to go back to my inspector.

So, let's... So one of the most interesting inspectors we have is the Target Inspector. Right now, what you're looking at is a native Target Inspector. We have a general pane that if you had a more complex project, you would see the various targets listed here. You have this build, and this is where you're going to spend most of your time when it comes to changing options. There's a little drawer here, and one of the things that's really cool is if you want to look at all of the options that we have, you can see I selected all the groups and 136 items turned up there.

So now if I go here and I say, "What about optimization flags?" It limits it from 136 to 6. So again, very useful way to find things just as you would expect from the other user interface elements we have. So current settings are the ones you've chosen. In this case, I have 29 items. Here are the common settings.

And you can see there are little icons to tell you whether it's a build setting or a language setting or in fact a warning. It's very useful to have that cue there. We have GCC settings here. You can click on all the language settings, code generation settings, warnings, pre-processing.

So there are many different ways to view the data from the categories we provide here to the searching that you've seen. And one of the things that we don't have in the pre-release that are being planned is you'll have user configurable groups. So let's say you're working at Adobe on Photoshop and the Photoshop team wants to have their own custom options. They could actually create their own group there, drag over the options, share them with other groups or people on the team so that you start to have basically a workflow where you don't have to think too hard about the options.

So you can see here that the first thing that we're going to do is we're going to create a group that's going to be called the compiler options group. And this is a very easy way to do that. So let's say you're working at Adobe on Photoshop and you want to create a group that's going to be called the compiler options group.

And you want to create a group that's going to be called the compiler options group. And you want to create a group that's going to be We have, and another thing to mention is these groups are extensible, so if you're a third party tool, you can add options here, which is very nice.

So the rules pane allows you to associate or change the compiler and associate files with the tools that build them. In this case, you could switch between GCC 3.3, 3.1, and so on, and there are lots of other ress in there as well. And then there's properties, very basic icon document types, that kind of stuff. So I think you'll find this very handy, very convenient, and we hope you like that.

One point is, we have this facility to pin the inspector. And what that will do is rather than track your selection as it was doing before, you could select all over the place and basically that inspector will stay put. Which again, since the target is one of the most common inspectors, that might be a popular feature for you. We're going to work on the user interface such that when you actually have it pinned and you hide that toolbar, it's more obvious what state it's in.

This gives you the best of both worlds where, as you know, in the finder there's a difference between inspectors that track your selection and info windows. So this gives you the same type of feature, however, it's more lazily evaluated. You don't have to select the type of inspector when you open it up. You can do it later on. So.

Another feature which I'll just mention briefly is we affectionately call it the Metro Morph, where you can double click on that widget and navigate your files and get back some screen real estate if you want. So in that case, some people may prefer that. So again, it's a case where, oh, the detail view is great, searching is great, but you might get into a groove where, in fact, that's the orientation you want. And you saw how easy it was, right? You double click on the widget and it does the right thing.

Here, it does the opposite. It'll push it out. It'll maximize the view. So, there are some cases when you want the detail view to take over the window, other cases where you want the outline view to take over the window. We support both. We have the next previous buttons here.

If you click and hold like Safari, you get the list. Very nice. Here you could just bop around between the files in the nav bar. This button is called the counterpart button, so if you're in a CP file and you want to get to the header file, you just click it. And this basically shows you the include files that you have.

And you can see the form factor is really nice. So if you want to maximize it that way, here's yet another way of working. You can go over here, click, and you have the full editor with your view here. So there's lots of different ways to work, and we think you'll find a lot of interesting ways to use the tool. Okay, so I'm going to now go to another demo, another project.

This project is built from a framework which is less commonly known to many of you, I believe. It's called the QT framework. QT was developed about 10 years ago by a Norwegian company, a very talented group of people. They developed it with a cross-platform flavor, so it runs on Windows, it runs on Linux, and so on. They're very strong advocates of the open source movement, so that's also in line with the Mac OS X strategy. So we're strong partners, and we want to support Power Plant and QT as first-class citizens in this Xcode development environment. So here I'm going to build and run this project.

Right now it's pre-compiling the Qt prefix, and then it will compile roughly a dozen files. It takes about five seconds to compile this guy. This is a little 3D application that ships with Qt, and that's just running it outside the debugger. What I'm going to do now is show you some fix and continue running it inside the debugger. But before I do that, I want you to see the stop button. When we weren't running anything, notice the stop button was grayed out.

Now it's running, and you can see that we composite the application that's running into the stop sign. Basically, that's the way you stop an application, and they stack. If you're running a long find, most of the finds are so quick that they never stack, but if you had a long find and you had a long build, that would basically stack with the most recent thing on the top. And so it's like a mini activity stop button. Let's now go to debug.

So, what I'm going to do is make this window a little smaller, put it off to the side. I'm going to make the debugger window a little bit smaller. And I'm going to hide it for now. What I'm going to do now is click on gear. So, right now I'm in the gear and I'm going to go to the draw method, use my symbol pop-up.

And I'm going to comment in a bunch of code that was previously commented out. So here's if 0. I'm going to move that down to gear 3. Okay? I'm going to hit save. I'm going to hit fix. And notice that it stops the application and adds the green gear. So, very similar to the demo you saw earlier today, the big difference is this is happening with a very large C++ framework named QT, and this is a GL application written in C++ using their APIs. What I'm going to do now is run another animation called landscape.

I'm going to move it over here. So now I'm going to comment in some other code. And look at the code. I mean, it's not just a constant, not just a variable. There's many functions that are being added. There's static data that's being added. I'm also going to go down to another method that has to do with the landscape. And I'm going to basically set smooth shaded. I'm going to hit Save, and I'm going to hit Fix. And it's going to build the application.

Okay, well my second fix is not happening today. Let's try it one more time.

Now let's set Smooth Shaded. There we go. Okay, so you'd see how the point here is we're running two animations, there's lots going on, and the responsiveness, even though there was a minor hiccup there, was very good. So the tools are not bothered by what was going on, and it didn't take any longer than just doing one of them.

So, that's fix and continue. So that's all I have for today. I think I'm going to bring up Director of Interactive Tools, Toni Trujillo-Vian. And I'd also like to thank the group for working so hard on this project and giving of themselves and supporting it so deeply. So thank you, Toni.

So I'd like to talk to you about our new native build system. Our native build system is actually the core of Xcode. You no longer have to use a separate command line tool like make or ant because Xcode actually does all of its own dependency analysis for you. What this allows us to do is maintain your build state at all time, so the benefit of that is we can now give you feedback directly through the UI when your files become out of sync. It also allows us to deliver faster single file compilation.

What we wanted to do is take it one step further. We've introduced a new technology called Predictive Compile. Normally when you go to compile an application, you do your debugging, you save your file, and then you wait. And sometimes you wait a little longer. But with Predictive Compile turned on, the experience you're going to have is Xcode is going to go out there in the background and start to compile your headers while you're doing the editing. So we're taking care of about 80% of the time that it takes to compile for you while you're still working.

So then when you go to hit the save button now, you're not going to do the waiting game anymore. What's going to happen is you're going to have a really great user experience and the file will be back in time for you. Maintaining your build state also allows us to deliver features like parallel and distributed builds.

Xcode also supports multiple target types. We're introducing a new target called Native Targets. This gives you a lot of flexibility. What you can do now with Xcode is mix and match the different target types within a given project. So you can migrate one target at a time independently.

So this allows you to manage your own process of migration. We want to encourage you to migrate over to Native Targets because then you'll be able to take advantage of all the new great features that we're showing you inside of Xcode. We also are introducing extensible rules with native targets. What this allows you to do is modify the built-in rules that we ship with Xcode.

So you can actually pick which compiler you want to use, which res tool you want to use, and do any other mapping that you may choose. So now you can solve both simple and complex problems by modifying these rules. Xcode also supports Project Builder targets and custom built targets like Make, Jam, and Ant and other command line tools.

Now you've heard a bit about distributed builds already today. This is a really great feature. What we're doing with distributed builds is we're taking some open source code called DiskCC and also taking advantage of the Rendezvous technology. So you're all familiar with your normal developer work environment, but with distributed builds, what we're encouraging you to do is to take advantage of the entire unused computing power across your work group.

So if you have a larger project, you can, you know, if someone's surfing the web or reading email, take advantage of the computing power that they're not using. So what you've created is a work fleet across your work group. If you have larger projects, you can take You can also distribute your builds across a build fleet, kind of like the one we have over here, this XServe rack. I'd like to invite Stan Jirman on stage to give you a demo of distributed builds.

Thank you, Toni. So as Toni already pointed out, we have a small build fleet here because we don't have any engineers who would be surfing the web or reading email. All of our engineers are happily working on the great code so that we can make CDs for you.

On my machine here, I have Definder front end sources from Panther running on Panther. And as Steve pointed out earlier today in the keynote, as you have seen, that's over 100,000 C++ lines and 1,500 files or something like that. So this machine is connected to the rack of XSERPs, and I'm just going to press build, and if somebody has a stopwatch or a cell phone with a feature like that, it should be fairly quick.

So if you direct your attention to the rack of XSERPs, at least the part of people sitting here, you will see a lot of nice blinky lights. We should have a view up there. And we're building Finder now. The whole stack of 1,500 files. and it should take just about a minute. Steve was talking in the keynote of 90 seconds on four or five machines. We're using a few more here, but you will find that actually this is overkill. You probably don't have a rack of how many Xers at home.

This is a demo of the Finder demo machine. The servers are idle and sitting pretty. We see that Finder has succeeded and we can actually run it. This is not an optimized build. It's using the ZeroLink technology. As was pointed out earlier, it will take a little bit longer to launch, but you've got the Finder here and it's fully functional and fully built. Now, what we can do is to show you why we actually have a big fleet up here. I'm going to clean it.

And I actually have two machines here to build the Finder. Let me build this one as well. We don't have it. I think I triggered a Steve Jobs kind of slow-mo thing. Looks funny, but... So I'm going to kick off that build of Finder and let me actually restart this one as well.

We're launching Xcode. And so if you have a stopwatch, how long is it going to take when we're building two finders at the same time using that build fleet? Well, you will find out it's actually not so much more. It will be a little bit over one minute, because the machines before, they were sitting more or less idle, and now when you look at the speed as it's flicking through, we're building somebody do a count of how many source files at the same time. The sweet spot lies with less than those machines that we have here. You will actually find out that with four or six machines, you really reach almost full speed already.

What was the last time you saw this many Xers on stage? It also shows you don't have to go buy a full 42 unit rack. and a few more will be doing. Now we're done compiling here. The last file is compiling, linking and The other computer is already done because I clicked it earlier, and now we build two finders in this time. So, with that, back to you Toni.

Thank you, Stan. So what we're really doing here is taking something that used to take hours to do and doing it in as little time as it takes to take a coffee break. So the power of distributed builds. So I'd like to shift gears for a minute. In addition to being the director of Xcode, I'm also the director of WebObjects.

And over the past year or so, a good number of you have come up and asked me, "What about EOF? Can you put it back into the operating system?" So we're taking a step in that direction, and we've come up with a new technology, a new binding technology that we've added to Cocoa. And it is created with the analogy of EOF's interface layer inside of WebObjects.

So what's really neat about this is it's completely integrated with Interface Builder, so you can take advantage of this new Cocoa binding without writing any code. And the benefit of this is that you can write your applications a lot faster and a lot easier. And I believe if you attended the session in this room prior to this one, it was also demoed for you.

If you're interested in this technology, there's a couple of sessions dedicated to it, the first one being session 412 on Wednesday, so I suggest that you attend that. It's a great technology. I also wanted to thank the WebObjects engineering team for working so hard to get this technology into Panther for you. With that, I'd like to turn it back over to Ted.

Thank you, Toni. So this is really great. Did I mention this was a developer preview? So there are, I think one of the things that though isn't developer preview is the GCC 3.3 that is on your disks both on the Panther and the Jaguar versions of Xcode. The compiler itself is GM, and so you can ship applications with it. The tools themselves clearly, you know, where this is the first time we're handing out to you, but the compiler itself is GM. Obviously, what we're trying to do here is to compile both smarter and faster.

And we've built upon technologies that were built into GCC of pre-compiled headers, and we've improved it. We've tuned the memory management system, we've tuned the algorithms, we've added in the predictive compiler for very fast interactive response, we've added in distributed builds for large full build response. And this is really, I think, a fabulous platform for all of us to work together. And I think it's a really, really good platform and foundation for what we're trying for making and improving program of productivity. And this is the compiler's part of it.

But GCC is also extremely critically important at providing you the performance for your application itself. It's not enough for it to simply execute fast, it also has to generate great code. And so we've also put a tremendous amount of time on increasing and improving the optimization technology. A big part of that has been spec, Mark, and you heard this morning it helps us compare one system to another.

One of the big important parts about the G5 is that the G5 has unique and important architectural features that the GCC compiler is designed to generate code for. So the big word in CPU design is ILP, Instruction Level Parallelism. And essentially what a CPU does is it processes through a very long pipeline of instructions and tries to execute through multiple functional units at the same time.

So really this idea of a program counter really is something that is this notion is not that it's executing one instruction, it's executing multiple instructions in flight. You heard this morning, 215 instructions in flight. Well essentially part of what the compiler is doing is it's scheduling and interleaving multiple operations, multiple statements of your program to be executed simultaneously. And that's a hard thing to do. And GCC is doing this a tremendous and terrific job for doing that.

And as well, because we have so much in flight, the CPU is also capable of doing that. It's also capable of prefetching both the instructions and the data. And because of that, there are these incredible I/O channels that is pulling data both out of memory and paging in off of disk to make things, to keep the functional units fed. GCC performance is designed to take advantage of these features and to create these incredibly good performance numbers that we're talking about.

So when we look at where we've come from GCC 3.1 to 3.3, we actually see benchmark performance improvement of anywhere from 10 to 30% on individual benchmarks. My favorite one, in fact, is Eon, one of the GCC spec benchmarks, and we improved that by 50%. Eon is a C++ benchmark with over 200, 250 or so virtual functions. So one of the things is that the G5 is, in fact, it's about, it's 150% of the Intel Pentium's benchmark performance.

150%. So in fact, the G5 is the best machine for object-oriented code. This is a really terrific device, and I think for your applications that use virtual functions or Objective-C polymorphic message sends, this is the device that you're going to be using. So this is a really great device for you. We've seen many applications improve by 40% from just migrating from one compiler to another.

And even extremely well-tuned apps, apps that we've focused the performance tools on, we've seen performance improvements of 5% by just improving the alignment flags. If you read the release notes in with the GCC compiler, you'll see those flags. Your mileage, of course, may vary. So it's not all about flags. It's also about performance tuning and using the tools, which we'll talk about in a minute. few minutes.

So, very quick run-through again of the spec benchmarks. The ones you saw this morning, the formal names are SpecIntBase2000, SpecFPBase2000, the multi-process benchmarks SpecIntRateBase2000, SpecFPRateBase2000. These are the benchmarks that really mainframe computers have been comparing each other over the years, and which today your G5 is one of them. We used, because we ourselves from Apple do not provide a Fortran, we used a terrific Fortran implementation from Numeric Algorithmics Group, their Fortran 95 implementation.

And it's a terrific Fortran that front-ends the GCC compiler. We hired this company called Veritest. Veritest used to be the old ZD Labs used in the ZD magazines and to perform the CPU 2000. That's the name that SPEC gives the overall suite. And of course, these are the machines we compared against.

So, and then of course on spec CPU comparing against the Pentium 4, again, they eke us out, edge us out on integer, but we edge them out on floating point. And I believe that word processing is about as fast as it needs to be. But I think in the floating point domain, where we have all this user interface and graphics, image processing, scientific processing, the G5 is the hands down winner. So with that, if flags aren't enough to make your application great, then you need to accelerate your applications. And so I want to invite Dave Payne up, Performance Tools Manager, to talk a little bit about the other things you can do. Dave.

Thank you, Ted. So, you've seen how we can enable you to quickly build applications with Xcode and how the code generation is better with GCC now, but what if you need more? How can Xcode help you make your applications even faster? Ted Goldstein, Steve Naroff, Toni Trujillo-Vian, Stan Jirman, Dave Payne Well, what we've done is we've directly tied Xcode to several of the major performance tools that we ship with Mac OS X. You can launch the performance tool directly from Xcode, almost as if it's a debugger, with your executable as the target application from there.

And then as you're navigating through the data from the performance tool, if you find hotspots in your code, we highlight that code and you can double-click on it and get directly back to the source code in your application. So, this lets you look at a variety of performance aspects. If your application is too slow, for example, you can look at application-level profiling with our statistical profiling application sampler.

If you're using too much memory, or leaking memory, which is a bad thing because that might end up causing paging, you can use malloc debug to look at that. To study your object allocation and deallocation patterns, perhaps you're creating too many short-lived objects too much. Object alloc is great for that. And to really let you take advantage of the raw CPU processing power that you've got here, there's a lower-level machine profiling tool called Shark, which is part of the Chud tools that I'll mention here briefly.

We've also enhanced some of the tools to give you some new ways of studying application behavior. Hi, in the Sampler Profiling Tool, basically what it does is it takes a call stack at specific time and intervals, and we build up a tree of those call stacks. Previously it just showed you a browser view, we've added an outline view for that.

We've added a new ability to look at dynamic behavior of your application with event tracing. So, what we can do is show you for every, let's say that you stop on malloc and dealloc calls, for every time it hits, we'll show you a table of the call stack for each specific hit.

Then we show a graph with the height of the stack at that instant. What that lets you do is see patterns of calling in your code, and you can click on the graph at that point and see, "Wow, what is going on?" "What is going on here that I'm repeating this certain activity over and over again?" We also, how many of you have seen this spinning rainbow wheel come up a little too often in your application? That's not a good thing. We've added an ability to automatically catch when that happens with an application called Spin Control. Just have that application running, and when that little cursor comes up, it automatically samples in the background and you can go see what was going on during that period of time.

Now I mentioned the Shark profiling tool. That's part of a package of tools that's been upgraded for this release. It's called the CHUD tools, for Computer Hardware Understanding Developer Tools. What these do is really give you access to the performance monitor counters built into the processor and the memory controller.

These tools have a lot of deep knowledge of the architecture built in, so they really understand the pro--they've got models of the processors for both the G4 and the G5, and can show you specific optimization tips at specific lines of source code or assembly code. Are certain things causing cache misses right here, for example? So Shark is great for seeing these kinds of things, both within a specific application and across the system as a whole.

Because it takes advantage of kernel extension that lets you look at what's going on in real time in your application and the entire system. Monster is a spreadsheet for performance events, and there's a number of additional tools as well. In the interest of time, we're going to skip over the demo here. You can come to the performance tool sessions on Wednesday to see that. So we've hope--we've excited you with a lot of the cool technology that we've been putting into Xcode here.

We want to make it easy for you to adopt this and remove barriers that might get in your way in your environment of getting here. So we put a lot of work into the importer so we can import projects from Code Warrior into Xcode very easily. What we do is we Apple script out to Code Warrior and ask it to export the project into XML in the format we want it.

We then read it in, create all the targets in the order you specified, populate them all the way through the code, map all your Code Warrior compiler settings over to GCC compiler settings, build up your info p list. One thing that we don't have yet in this developer preview will be there for Panther final is cross project references, which has been very heavily requested. If you have references out to other projects, we'll automatically import those as well, and the build system will understand that.

Once your project is in, it won't necessarily fully compile, but we've made some additional changes to enhance that. We've added Code Warrior style assembly syntax to GCC, that's a higher level, a bit easier to program. And we've had a lot of requests for wide character support, so we've added that in as well. It's built into the system libraries in Panther, and there's a third-party solution from Dinkumware for Jaguar.

SDKs we've touched on before. We ship header files and stub libraries for Mac OS 10.1, Mac OS 10.2, and now for Panther. So from X.2 you could develop for any of these OSes. Gives you a lot more flexibility in your environment. And in talking to a lot of our large developers and listening to you in feedback forums, we've heard that Perforce is a very heavily used source code control mechanism. So we've worked with that team, a company from Alameda, to integrate that into Xcode, as well as the open source standard CVS.

So, we've quickly seen here some of the ways that we make it help you develop fast applications, in addition to developing them quickly, and our efforts to make it easy to adopt Xcode. So, if you want to give it a try, we've got people in labs throughout the week, and come more to the Developing Carbon Applications with Apple Tools session on Thursday morning to see the import process in detail. Thank you, Dave.

So, what we have is a terrific architecture. What we plan for GM is to make it faster yet. We'll be adding in Java and WebObjects support, and we'll be working on some of those bugs. We want to hear your bug reports. We want to hear your feedback, what you like, what you don't like, how--missing features and so on.

I think the workflow is a tremendous, tremendous improvement from any tool Apple has ever shipped, and I believe that, in fact, we have the basis for something that's extremely scalable. Techniques like smart groups, for example, you can clearly see how we can add in with many features to help people better understand programs, to help people refactor and understand things. Beyond this release, we'll be shipping pretty much concurrently with Win Panther ships.

We'll be adding in, into the compiler, into module feedback-directed optimization and enterprise application development in future releases. These are important technologies that we have already well under development. The enterprise application development tools that you've seen in tools like WebObjects will be working in so that they're very nicely, tightly integrated and so on and such.

So remember, it's a developer preview. There are, you know, we, there certainly will find at least one bug per person. But, you know, it's not bad. I think that the, we've been living on it for some time now, and we think that this is, it's certainly of quality that you can release.

So, developer.apple.com/bugreporter. Send feedback to xcode-feedback. I promise to read every message and I'll probably respond to most of them. And really want to help you create better tools and better applications. So to wrap up, speed has been the primary focus. Removing obstacles has been a big focus, has been very supportive. We are integrating in Apple script, Web objects, Java, C, Objective C, performance tools into one umbrella. And Xcode, I think, represents a new dimension in creating applications for Mac OS X.

You'll hear more. Please join me at the Java State of the Union immediately following this session downstairs. Tomorrow, we have the WebObjects State of the Union and even detail to introduction to Apple DevTools given by Stan tomorrow. GCC In-Depth on Wednesday, knowing how to use the Cocoa Bindings mechanism on Wednesday afternoon.

And Steve will be giving a talk about the user interface and how it was put together and some of the thought processes behind it. Godfrey DeGiorgi will be up here afterwards to answer additional questions. There'll be mailing lists created on list.apple.com. And again, [email protected]. Thank you very much and have a good evening.