Ladies and gentlemen, please welcome Vice President, Development Technologies, Ted Goldstein. Thank you very much. Good afternoon. Let me hear you a little louder. Good afternoon. Thank you. Good afternoon. Hello. This is the Development Tools State of the Union, or as I like to think of it, The development-- no. This is the Hitchhiker's Guide to Xcode Tools.

Why the Hitchhiker's Guide to Xcode Tools? Well, it was a great movie, and it's a lot of fun. I think we're going to have a lot of fun with this presentation. But did anybody bring a towel? No? Thank you, thank you. Gotta have a towel. 'Cause you know, the Hitchhiker's Guide is all about, well, you know, essentially the end of the world and changing it to a new world, which is what we're really all about doing here.

So the first message, of course, is don't panic. Don't panic, right? It's not so bad. We're in pretty good shape, in fact, because really, Apple really has the tools you need to create the greatest application in the universe. Apple, we've been working on this for a number of years. And we've been thinking about the kinds of things you're likely to encounter should this day of a major transition come. So first, though, before we get into a lot of details about that, I want to recap essentially what Xcode is about and some of the other great tools in Tiger. Tiger, of course, we shipped it on April 29. And we also shipped Automator on April 29 as part of Tiger. And that was also the day, in fact, that the Hitchhiker's Guide to the Galaxy movie came out. Now, this is kind of a similarity here. In fact, we tend to think of this little man as Otto. And I think Otto can kick that little man, Marvin's, butt. It's a nice similarity. Marvin kind of depressed. Otto, he really wants to help you. Automator is a great application. It really is there to help expand what your applications can do. It has very little functionality of itself. In some sense, it is a modern Unix shell type thing with a graphical user interface.

We think that Automator is great for your app and to make your application automatable. It is very much a natural evolution of technologies that we think of in the past as developer tools such as Apple Script and Script Editor. These technologies, you had to learn syntax. Now, syntax is not a problem for anybody in this room. All of you, you're great at programming languages. You can pick up a new programming language in a few days. End users, that's the difference, right? They don't pick it up so fast. They need a user interface, check boxes and easy to manipulate buttons to do it. And Automator provides that. Essentially, what this does is it allows you to take the kind of scripting level, the object model of your application to the end user and to give them some of the same power and capabilities of scriptability for their purposes. It's another way for them to combine the object models from one application into another.

So one can take, say, preview and PDFs and combine it together with image processing, with Microsoft Word, with Photoshop applications, actions, and to really bring it all out to the end user in ways that you've never seen before. Almost every application, if you have something valuable and worthy of doing, it's probably interesting to turn it and expose the object model to the end user via a set of automated actions. The advantage to you is it will actually increase adoption. One of the big purposes here is that now your application can be part of a workflow where it becomes automated and involved and embedded into business processes. It's very easy to create actions, and you'll learn it here at the conference. We have a number of sessions to teach you how to do it. Also, it's a great idea at this point in time to make your app scriptable so that even the next level of AppleScript power users can get access to that same object model. Automator has been extremely popular.

In fact, when I wrote this slide, there were only 500. Now I understand there's over 550 third-party actions. There are several books coming out. There's an incredible web community. So Automator really has become extremely popular. I knew it was when I first saw it that, man, this was going to be one of the big hit features. And yet here it is. This is kind of a developer feature, but it's something we put on the end user part of the system because we think that it's accessible to many, many people. So this is Automator. Thank you. Now I want to talk about Xcode. And of course, start talking about Xcode 2.0.

Now, Xcode really is the fastest way to create Mac OS X applications. There's a number of wonderful features we put in it, code sense, predictive compilation, distributed builds. These are things which speed up compilation and the ability to get--to find and create the program that you're doing. Zero link essentially incrementally links your program as it's running. And fix and continue is a debugging feature so that when you make a--you can make a modification on the fly without quitting the program state, the compiler runs and dynamically links in the changed code into the application and so that you can continue along. Xcode 2.0 essentially is kind of a world, right? It's a whole environment, and this environment contains many important features that really help you develop application.

Each of these features we've designed as part and delivered with Exo 2.0 as part of Tiger to accelerate your development, to make it easier to develop, to widen your capabilities. One of the big thing improvements in Tiger was the transition from GCC 3.3 to 4.0. And we made improvements there on every point. We made improvements to make it both faster, better, and more powerful. We improved the front end, the middle end, and the back end. The front end, one of the most important things I'm sure you'll love, is that it's 20% to 30% faster compile times for C++ and Objective-C++. And we did this by writing a new C++ parser that's part of the Free Software Foundations community. We've added in, of course, Objective-C part of it to make it Objective-C++. And it's much better standards conforming. It gives you improved better errors and warning messages.

To the middle end, we made important changes in autovectorization. So if you don't want to write the vector code yourself, you don't have to. In fact, just with one switch, it can actually, in many cases, take floating point loops and generate the Altivec instructions. We've improved the integration of all the features. So between, for example, C++ and Objective-C. So now, for example, you can embed your C++ objects in your Objective C objects. But an extremely important technology that's a foundation there now that is going to continue paying dividends for many years to come is a new technology called TreeSSA. TreeSSA is essentially the single static assignment optimization technology that is the most powerful optimization technology that every high performance optimizing compiler uses. Using that, we're able to now do better loop optimization, loop unrolling, being able to-- the older vectorizer is driven off of this. And we will be adding in additional optimizations coming along. So if you have-- you can actually help, since GCC is, of course, from the free software foundation. You, too, can check out a copy of the source code, make modifications, and improve the optimization capabilities of the compiler. In the back end, another important feature is long doubles, giving you even more precision. And for the first time, we are now standardizing on a C++ ABI. This means that you no longer have to link in the lib standard C++ library into your application. So Hello World is only a few k bytes in size instead of several hundred k bytes. And of course, a great feature for G5 is 64-bit, being able to access greater than four gigabytes of virtual memory. Altogether, GCC 4.0 is a fabulous new platform and part of the new Universal Compiler that we'll be talking about in a few minutes.

Auto vectorization. So this is a piece of code extracted for doing image processing. And essentially, what we've seen in these kinds of very tight loop code, we're seeing anywhere between a 10% and 20% improvement. Because essentially, it's able to execute many of these instructions as a vector operation, being able to perform the operations in parallel. Here, too, again, we'll be adding in more vectorization types as we develop the Xcode and GCC4 further along.

Next major feature to talk about, of course, is the transition from 1.4 to 5.0. And this technology adds in generics and other features as part of it. Another part of Tiger is we've upgraded Shark from 3.8 to 4.1. 4.1 includes incredibly good data mining facilities. What that means is that now you can actually drill deep. You can actually have a performance graph, have this massive data, and isolate a segment of the graph and drill in to see what the stack traces are so that more and more of the information is exposed.

I think you'll find that the data mining really improves the coping with the complexity of a large application. We, of course, upgraded WebObjects for Tiger. And we introduced a major new feature inspired by WebObjects called Xcode Design Tools. And essentially what this is is bringing in the entity relationship class modeling so that now any C++, Java, Objective-C, Objective-C++ object model can be created and manipulated by the class model. This is also a very important technology, because this is the gateway technology to core data, which is, of course, laid on top of both SQLite and XML data files. The interesting thing here about the design tools is now you can actually-- this provides a fabulous interface to complex structures within your application.

Another gateway technology and tool is Quartz Composer. You saw that Quartz Composer essentially is a way to manipulate image units. Image units are the basic building block for filters. Much of the beautiful look we get out of Mac OS X applications is because we have this great engine underneath. Quartz Composer gives you the ability to prototype and pull these different filters together and get some idea of of what kind of visual effect they have. They can then be-- you then take the data file which describes the filter layering and can then embed it with your application to directly drive the image units.

We also introduced in Tiger, in Xcode 2.0, the ADC reference library. What this does is it downloads a copy of the reference library or of the web and keeps on monitoring for any updates. So you are always assured of having the freshest and most latest documentation for your system. This, I think, improves the whole usability and quality of the documentation interacting experience as well. Of course, what you really are dying to hear about is Intel and how it is that we're going to support. So it's time to broaden our horizons above just our home world. Let's go on a little trip.

Welcome to the universe. And the universe consists of many processors. PowerPC and Intel, of course, are the ones we're focused on today, and really shipping an application that supports both is-- we have not underestimated that there was some challenge to this. We've really designed the tools in Xcode to support both environments. And with Xcode 2.1, we're introducing this idea of a universal interactive development environment, one that, of course, that can target and make it very easy to develop code for multiple processors simultaneously. And we think this is an extremely important and helpful to you.

In doing so, we've talked to you, heard your feedback, learned what you like about other programming environments, and what we've tried to do is take the best from Eclipse, from Code Warrior, from Visual Studio, and bring them into Xcode. So as part of Xcode 2.1, for example, we've improved the compile chain. We've improved the way the build system and project file management works. We've improved the way debugging and profiling infrastructure works.

We've improved other tools. So really there's improvements in every aspect of the system to really make Xcode so much more an enabler for your environment and for your system. And I think that you're going to like these changes. Thank you. So first, of course, is universal. We use this word to mean a variety of things, both at the binary level and at the application level, to enable your application for the different CPU architectures.

One of the most important parts of this is, of course, to-- we don't want to leave PowerPC behind. We don't-- at least not just yet. And we have to embrace Intel. Making it universal and making it so that all these different tools and capabilities can create and modify an application bundle. And applications such as Quartz Composer, such as Interface Builder, and Xcode, of course, itself, all modify and assist with this process.

You'll find that, in fact, that we have taken this approach of different kinds of components and resources that you manage and extend your application with, and really to be able to make it so that it's both easily internationalized to make it -- to make itself very successful. Being able to generate, of course, to multiple application processors is the -- is key.

As part of making it a universal IDE, we have this idea of that you can do, of course, host the target on the same machine, but of course, being able to do cross development is extremely important and you can work on either environment today. So for example, here at the conference, you'll be living on perhaps your PowerPC laptops, but you will be trying out your application code on the Intel systems in the labs. To enable this, the technology under the hood is this idea of a universal binary. A universal binary puts in one executable file, one A.out essentially, multiple segments. Each segment can have the Intel, the PowerPC, the PowerPC 64 code for each section.

And essentially, what each section contains within it, the load commands and the text and data sections, that that processor needs. Now this, of course, as you saw in Scott's talk, really simplifies how end users think about what an executable looks like. And also, I think you'll find that it simplifies your job. That you don't have to do this juggling back and forth. You can actually extract out the individual sections. But the entire experience of you as a developer really is focused around trying to do this and maintain a single file that is the universal binary for all the different sections. As we said, this is just one click makes it easy. We put this handy little checkbox in. And this is also, of course, the place where you can enter by hand other architectures as they come along, including support for things like PowerPC 64.

Now, in saying that GCC 4.0 is the universal compiler, Bertrand didn't overstate it. This compiler has been ported around to well over 100 architectures. And what we've done is we've updated it with the latest version from the Free Software Foundation. What's really nifty about this compiler is that, of course, it's widely used in the Linux community and other communities out there, as well, such as Solaris. So this compiler has already seen billions and billions of lines of code before we're delivering it to you. It has already gone through tremendous shakeout.

So you're not dealing with something that is going to be very buggy. In fact, we've had extremely good results. There are many tuning options to support the Intel architecture. And of course, we've added in auto vectorization support for SSE. You can also write intrinsics to get at the SSE MMX instructions natively.

Now, one of the features that people have commented to us that they've seen in other programming environments is to actually control the optimization level on a per-function basis. You may want to make different size space trade-offs. So for example, so what we've done is we now allow you to set the optimization level inside the code on a per-function basis using a pragma. Doing a reset essentially pops off the stack what the last optimization level was. So you can embed these optimization levels to really give fine-grained control. Simon talked a little bit about bit fields. We provided an additional mechanism, which essentially allows you to reverse the order of the bit fields. So that if you have data stored in a data file in one bit field order, but you, in fact, are in the opposite architecture, you can then surround this with if-defs to control that you're on the correct architecture.

So these kinds of features really, I think, help with making the system more conducive to being universal. person. Shared precompiled headers is another great feature we've seen in other programming environments. And essentially what it does is it allows you to take the PCH, the precompiled header file, and share it across multiple dial-ups, multiple targets or plug-ins in your project. This gives you the ability to have direct control over the state of creating the PCH, and it accelerates the compile time.

Simon went over this pretty well. I'll just simply reinforce Intel, of course, is a little-endian. It supports SSE vector processors and vector instructions, and Divide by Zero is handled differently. For the heat seekers, because you're going to go after each one, accelerate is the preferred way to do it. Because as we upgrade, as new architectures come along, we will always be tuning for the machine architecture. So it's best, because we always know what's coming down the pipe, we put in the work to do the most complicated and important algorithmic tuning that's necessary for vector operations, math, graphics, DSP routines that the CPU requires. The order vectorization routine is a help. And then as sort of a last resort, handwrite the SSE intrinsics yourself.

Now, since we're talking about Accelerate, Accelerate is one of this idea of an SDK. Software development kits are essentially the key to making great universal binaries. In the past, software development kits were a feature that was useful mostly if you were living on one operating system, but developing code for another version of the operating system. Now, SDKs take on an entirely new meaning. What SDKs are about is, of course, living on one architecture and targeting another architecture. So we've introduced this idea of a universal SDK. And really, essentially, what we're doing is compiling and linking with the headers that are extracted from one version of our operating system and packaged up. And it allows you to always live on the newest Xcode tools. So this means that you get to take advantage of the latest features, but still have confidence that the OS you're developing for is, in fact, the OS that your SDK is targeting. And essentially what we've done is we're making a commitment that the SDK is frozen in time, that the SDK is a set of standardized bits that will never change. Of course, you as a developer, you can change what SDK your project is targeting. But really, SDKs are much, much more important now than ever before. And we think that learning how to use SDKs is going to be very critical to helping you be great at developing universal binaries.

You need to install the SDK. In the past, you probably have ignored it. You just noticed cross development. Didn't even bother with the turn down triangle. But now we recommend that do open it up and do click on, certainly for this week, on your laptops. Please install the universal SDK. You will need it for most of the hands-on sessions that are going to be happening at the conference.

Another important feature is our build configurations. Now build configurations replace build styles. Gives you a much more intuitive user interface. No more strike through text. The big idea behind build configurations is essentially now you can manage and take parameters and store them separately. Each configuration essentially builds to a separate folder. In the past, in Xcode 2.0 and before, When we had build styles, which essentially was a big switch. You were either in sort of debug and development configure build style or release build style. And you threw a big switch, and that meant you had to throw away all the binaries, do a build clean, and then rebuild. If you wanted to switch back, you threw it away again. Of course, if you're trying to both debug and use the both configurations simultaneously, it wasn't easily supported. Now with configurations, each project, each configuration builds into a separate directory. And this means that you can actually change and manage the parameters per build independently. You can actually even store the settings in a file. I'd like to invite Chris Espinosa up to give a demo. Chris? CHRIS ESPINOSA: Thanks, Ted.

So I heard about the theme of your presentation, Hitchhiker's Guide, and so I started putting together a little demo application for you. I wanted to do a Hitchhiker's Guide to the Galaxy that I could deploy on Mac OS. I was actually targeting it to the tablet Mac that I read about in all the rumor sheets, but I think they had the message wrong a little bit. So I'm going to start out, and the first thing I do, the first thing I did when I created this application was what you do when you start creating anything. You create a project, and then you put a target in it. So I have a target here that's going to be my Hitchhiker's Guide target, and I put all of my source files and header files into that target. Now, in Xcode 2.0 and earlier, what I would inherit from the development environment is two build styles, development and deployment. And, you know, modulo the confusion of two things that are about this long and start with D, they would have set up everything for me. You know, the development build style sets up all of my debug time settings, and the deployment build style has everything that I need to make something that goes out to the general public. And that, I find, is a much nicer working style than, say, I have to create a target, populate it, run it, test it, and then I have to clone it for a different style of working, and then I have to maintain those two in parallel for all eternity. So I really like build styles that way. But there's one problem. When I looked at a target under a build style, some of the settings would actually be crossed out in the user interface.

And there'd be no tool tip or explanation as to why it would be crossed out. The biggest offender, of course, would be zero link. How many people have seen zero link crossed out in their target inspector and wondered what that meant? Most of you, that's right. Well, what that meant was that that setting was set in the build style for debug, and that that overrode what you're seeing in your target inspector, which was functional, but it was confusing.

It wasn't Mac. It wasn't what you see is what you get. So what we've done in Xcode 2.1 is that we've replaced build styles with a concept called build configurations, which is that the groups of settings for each kind of deliverable are right there in your target. And we've actually changed the name to be debug and release by default. We hope you can keep that clear.

So when I look at my target inspector, what I get is a pop-up menu for configuration. And it has debug and release. And if I look at the debug settings, zero link is checked. And if I go to the release setting, zero link is not checked. So I get what you see is what you get right there in the inspector.

Now, what I'm going to do for my release configuration is that for release, one of the things I want to do is I want to do dead code stripping. So for release, I'm going to turn on dead code stripping. And you can see that that doesn't affect the debug configuration. And I can see which is which right away.

I can even have an A/B comparison very quickly between what's in one setting and what's in another setting. Now, this is going to be really, really useful for managing multiple sets of settings on a target. And each target in your project has the same set of configurations, but all of the settings are settable individually. So if you set a zero link in one target, you are not forced to use it in all of your other targets in that build configuration. That's a real big advantage of it. Now I'm going to take this application, and I'm going to have a third thing I want to do with it. I want to send it out to beta testers, okay? Now the version I want to send out, I certainly don't want to use zero link on because that has to stay on my machine, But I don't want it to be completely stripped of debug symbols because I want to get back traces from crashes should there be crashes. So I want to have a third configuration, and I've set it up, called test. And my test configuration, I also want dead code stripping on. Well, you know, I could go through this way, and it doesn't scale very well. I'd have to go through and set that in every configuration, and I've simply turned a cloning the target problem into cloning the configurations Well, we've got a solution for that. It's called configuration files. What I'll do is, from the file menu, I'll just say, "New file I could do for almost every file in Xcode." Scroll down and pick a configuration settings file, and I'll name it "external release."

And I get a new file that's just a text file with a certain suffix on it. Now what I'm going to do is I'm going to go back to my release configuration, select those settings that I had in release. I'm going to cut them out of the inspector. And I'm going to paste them into the text file. We save. And there are my settings.

So now I'll go back to the inspector, and now I have a pop-up menu for what this configuration is based on. And I'm going to pick that file I just created and saved external release. And there go my flags back. Now, of course, the whole point of this was I wanted test to share settings with release. So I go to Test, set it based on the same file, and it gets the same settings. So now when I go and change one of these settings in the text file and save it, watch the checkbox on don't dead strip and it's in terms, it turns off. I can take that text file, commit it to my CVS repository, check it out, modify it, share it among multiple targets, share it among multiple projects and sub-projects, so I can have one standard set of settings that all of my configurations inherit from. Now, this is a pretty big change. This is the most important change we've made in the Xcode build system in a while. Why did we put it in a dot release? The reason is that this is really going to help you manage creating universal binaries. Because one of the things you're really going to want to do is, in your configurations, you want to pick your architecture. And instead of building your release configurations for the native architecture, you're going to want to build them universal for PowerPC and Intel. And when you get that, you're going to want to put them into your configuration file. And then-- All of your release configurations will be built universal. We think this is really going to help you manage your universal binaries.

Thanks very much, Ted. Chris? Thank you. Why don't you work on that example some while I talk a little bit? So-- We've enhanced the project file format in addition to the configurations. And of course, many people work in teams. Imagine that. We've made it so that it's much more readable, it's diffable, and it's mergeable. You can actually make changes to the project file and merge it together.

It's also much more stable. But these two features come at some cost. So the new file format has a new file extension,.xcode proj. And this means that there's a one-step migration from Xcode 2.0 to Xcode 2.1 format. This new format, this migration is an unfortunate consequence, but it means then now that we can actually have both merge capability and configurations managed in this new structure.

Moving on, yes, unit testing. It's not enough, of course, to write the code. You've got to debug it. And you want to be able to make changes to your code with confidence that you haven't broken any of the invariants. Unit testing is one of the reasons why we ship Tiger on time. We wonder if Redmond has seen the book on this. It lowers the course because you're actually able then to incorporate much of the model creation and change as part of the build process.

And we've adopted industry standards, of course, of C unit and OC unit, J unit and such, into the project. The methodology that we're espousing here is a test-first, test-as-you-develop approach. And it means that every time you make changes to your code, just as a natural part of building the project, you're able to have the test run.

One of the great things here is that you need to evolve the test case as you are evolving the code base itself. And so in doing so, you'll have greater confidence that the changes are incorporated. We've included templates. We've included the tools. And errors and warnings are reported in the build window and in the smart groups just the way compiler errors are. So there's a very good chance that programmers will notice this.

So imagine you do find a bug. Well, clearly being able to live on your PowerPC machine and do remote debugging across to your Intel architecture is supported. We've also added some important features that you found in other programming environments, things like conditional breakpoints, being able to set a Boolean condition that controls whether or not the breakpoint is stopped. We've also added breakpoint actions, which give you the ability to put behavior on the breakpoint. This means breakpoint actions can be many things. Of course, it can be AppleScript commands, shell commands, sound, and can be GDB's own native debugger language.

It can also set a watch point on a variable. Altogether, we've unified this into a very nice user interface that is reminiscent of the automator user interface. So it's a very convenient way to track and manage each of the different kinds of actions is when an event happens, all the events, all the actions are fired off. You find that this kind of event approach really is extremely high productive for debugging purposes. Breakpoints, of course, can also be copied and pasted and stored in a file as well and managed like you would the configuration file in the source code management system. This kind of direction I think is extremely helpful.

We didn't want to just stop there. One thing about whenever you hit a breakpoint, you get a few lines of code. And you're kind of just looking at a very small part of the program, a few lines, just a little bit of state of what's on the stack. Where you are in the rest of the program is sometimes a bit of a mystery. And this is a bit like looking at the world through a keyhole.

You're really trying to understand the state of your program as a whole, not just the spot and location that you stored it. So the metaphor I like to have here is really you want to have and see a more perfect world. You want to see the entire landscape in front of you. And to do that, we've invented a technology of software visualization. These ideas have been floating around in the research community for a number of years, and we've adopted this now to mainstream IDE and Xcode. Chris, can you give us a demo of actions and visualization?

Sure, Ted, thanks. I've been working on this application, as you asked me to. I've added a few classes to it. These are just template Objective-C classes with just nothing much more than an init method, but no time like the present to test what I've written to see whether it works, because each of these classes forms a tree of inheritance, and each class calls it super init, so I want to make sure that all of those init methods are being called in the right order before I go through the trouble of writing much more code.

So I'm going to start by going into my main here, and go down, and the first thing I'm going to do is just set a regular old breakpoint, and I do that the conventional way by clicking in the margin next to a line of code. But that's just a plain old breakpoint that stops when I hit it. By control-clicking on the breakpoint, I can pick a number of different styles of breakpoint. I can log it, I can make sound, I can print self and auto-continue, or I'm going to make this a speakable breakpoint so that when it hits the breakpoint, it speaks and continues. And actually, what I'm going to do is edit that breakpoint. By choosing reveal in breakpoint, I go to the breakpoints window. And it's a log breakpoint. I'm just going to change the text here and say, figuring out the answer.

I could add a condition here in the condition box, and I can make it continue or not continue. For now, I'm going to make it stop when it hits that breakpoint. I can also add multiple actions, and all of the actions will happen in the sequence that they appear in the breakpoints window. So now that that's done-- I can close that window, and I can debug the application.

And it'll load up. Figuring out the answer. And I've hit my first breakpoint, and I'm sitting there. Now, that's great. I can use speakable breakpoints for long algorithms or things that are hit very infrequently, or especially for points where I really don't want to stop, but I just want to continue. But in this case, that was just making sure that I got into main. What I really want to do is I want to watch that program flow of my init methods.

So I've set some other breakpoints in my breakpoint window. And notice all of these init line 8s in all of the classes. Those are visualization breakpoints on the init method of every class. So if I continue from here, I'm going to hit the first one. And what it's done is it's built a dynamic class diagram of the class I'm in and its superclass in relation to all the other classes in the diagram and highlighted the method that I happen to be in, which is the init method. I'm going to make this a little smaller because I'm going to be doing-- I'm going to be generating a lot of these. And I'm just going to change this breakpoint to a-- visualize an auto continue after one second. That is really the only interface that you need to it. You can customize it, but just Control-click on your break point, pick the visualization, and continue. And that's the way you do it. It's really cool. So now when I continue, I'm going to hit all of those other visualization break points. And as it hits every init method in every class, it dynamically adds that class to the diagram.

And you can watch the bars move down the initialization chain as all of the supers are getting called. Now, of course, when it gets to the end, I put another breakpoint because I'm calculating the answer while I'm doing all of this. And we're going to hope this has actually worked.

It didn't take 240 million years last time, but it was actually pretty quick. When I get to the last class that's added, it's going to give me the final answer to the ultimate-- - The answer is 42. - And that's correct. There we go. Thank you, Ted. - Thank you, Chris.

So that's Actions and Visualization demo feature. Events are triggered to perform many important things. You can use this to modify the behavior of your program. You can change and capture the state, run external commands, shell scripts, Apple scripts, and of course, visualization. The visualization feature, I believe, really is the first of a whole new class of great debugger features that we're planning on to allow you to understand the large scale behavior of the way your program works? And of course, the answer is 42.

Speaking of 4.2, in Chud, we have a new developer preview. It's not on your DVDs, but it will be available for download later this week. And it, of course, supports Intel-based Macs, includes Monster, a new feature that is directly integrated into Chud, and includes all the wonderful features you've had for PowerPC, such as time profiles, disassembly for architecture, the ability to have Intel-specific optimization tips and be able to visualize all the system traits that are unique to the Intel processor. Java native code is also supported in this release.

And of course, thanks for all the fish. Speaking of Java and 42-- boy, that number just keeps on coming back there, doesn't it? Java 1.4.2 is on the system. And Java 5.0 preview is online, I believe. Is that correct? Yes, it is available for download. So no waiting for Java 5.0. The preview is available and includes auto-boxing, generics. And one of the first for Apple Computer is we are releasing both the C1 interactive client compiler and the C2 server compiler. If you're not into Java, this isn't meaningful to you. But if you are, C2, of course, is a much more high performance version of Java, great for long running server-based applications and scientific computing, great optimization technologies. In Xcode, we have enhancements that support breakpoint actions and code visualization. Actually, we have that as well for AppleScript as well, supporting breakpoint actions. So no second class languages here. WebObjects is now being bundled. The tools are now included in Xcode 2.1.

And there's a development license with every copy. We have a new emphasis on Mac OS X, really trying to make it extremely fresh. One of the things that you'll see in this release is EOF modeling support is now integrated into the Xcode design tools. APPLAUSE So Xcode is the home for many languages on Mac OS X. Java, AppleScript, C, C++, Objective-C, Objective-C++. But there's one language we're missing. What about Fortran? What about Fortran? So coming soon, ICF, coming as the Mac OS X latest this year. So ICF is not from Apple though. Like to invite Kevin Smith from Intel up on the stage. Hello Kevin. Hi, Ted.

Good to see you. Yeah, at Intel, we've been working on compilers for a number of years. And I'm really excited to be able to know that Mac OS X is finally going to be on Intel. So this is really an exciting time for us. We're going to take our C++ and Fortran compilers, and we're going to take those products and put them on Mac OS X, on Intel, and we're going to have that as soon as we can. How is that going?

It's going pretty well. So far we have Hello World working. Excellent. First step. As you know, Hello World is sort of an early milestone to see if the compiler is living and breathing. And as we were porting it across, we started setting up this cross-development environment where we'd be hosted on some other operating system and cross-target.

And we said, oh, what the heck, let's take the code, use Xcode, and self-host the compiler. And it really just, you know, worked just about right out of the box. It was very little effort at all. There really is an easy way to port to OF10 and Intel using Xcode. It's really the way to go. I'm sold on it.

Eric Schmidt: Great. Hope -- Eric Schmidt: A couple other things. Eric Schmidt: Okay. moving a compiler across. So we aren't quite ready to announce when the product's available. We will be announcing that at Intel's developer conference in August. We'll give you specific product details, when the beta starts, when the product will be ready, et cetera. We've been working on compiler technology for Intel processors for quite a while. We really have a state of the art compiler. It's all ready to go. and it really maximizes performance on Intel architecture. It'll be a little bit before it's ready. In the meantime, really get started on the port now.

Use Xcode. Get over there. It's really easy to use. Everything works. And then later, the Intel compilers will just kind of seamlessly slip into the build environment, and you'll be able to use them also. So we think Intel compilers will be a great enhancement to the tools that Apple's already providing in the Xcode environment. Great. Happy to have you on board Xcode. Okay.

Thank you. This is really good. Well, welcome to Mac OS X. Just as, I guess, we're welcome now to the Intel CPU. So it really is amazing, because we are getting one of the great compilers in the world on the Mac OS X. And we think that it's important that you have choices.

Apple, though we believe that we are the principal provider, We have the tools you need to create the greatest applications in the universe. And really, of course, what this is about is you. This is about you creating the greatest universal applications. So I want to actually invite Matt Formica up and tell us a little bit about the rest of the conference. MATT FORMECKER: Thank you, Ted.

Thanks. So looking out at the audience here, I actually recognize a lot of you. As the developer tools evangelist for Apple, I've toured the country and even parts of the world over the past year telling you all about Xcode, as well as getting your feedback. You guys are the pros, and you have high requirements from your developer tools, and you've given us a lot of good feedback. Features like build configurations, the updated project file format, and per function optimization pragmas really are there in part because of the feedback you've given us.

So for those of you who are already using Xcode, you can really just step in and enjoy Xcode 2.1. And I'm so proud of the engineering team at Apple for the features that they built into this version. For those of you not yet using Xcode, really the time to move to Xcode is now. Xcode gives you the power to keep up with the platform to build universal applications. It also includes these powerful new productivity features that we've told you about today that allow you to go even further with your development. So how do you get there? Well, the Xcode engineering team, as well as developer relations, are really here to help you with this, both this week and often to the future.

Here at the conference, we have a variety of labs where we will actually sit down with you and help you on your code. We also have a variety of informative sessions where we'll give you the information you need and answer your questions. You can test your code on the developer transition systems here at the show. Ask us questions, and we'll try and help you.

These are a few of the Xcode support labs that are scheduled through the week on Tuesday, Wednesday, and Thursday. I encourage you to stop by. In addition, there are some important sessions you should go see. Perhaps the most important session of the rest of the show is tomorrow morning at 9 a.m.

It's not in your show guide, because Xcode 2.1 wasn't announced yet when the show guide was handed to you and printed. But 9 a.m. tomorrow morning is What's New in Xcode 2.1. Following that session is Adopting Xcode. That's a hands-on session, especially for those of you new to Xcode. You'll want to make sure you've got your Xcode 2.1 installed when you come to that session and download the associated sample code off of the WWDC website so that you can follow along with that session. The WebObjects overview session is also tomorrow morning, where you can find out more about the details of how we've bundled those into Xcode. So that's what we're doing here at WWDC. What about beyond WWDC?

After the conference, there are a variety of resources you can take advantage of. The Xcode users' email mailing list is a great resource. It's really a great community of people that are eager to help answer your questions about using Xcode. If you get stuck on one particular point, you can contact Developer Technical Support, where they will bring in engineers from Apple's Xcode team to help you work through any issues as you build universal applications. If you do happen to find any bugs, and we think we've nailed most of them, you can file those at bugreporter.apple.com. We take your bugs very seriously and read each and every one.

But as -- so those previous things are available to you whatever level of member you are of the Apple Developer Connection. But if you're a selector Premier developer, there are even more benefits. And as has been talked about earlier today, you can get the developer transition kit. You can actually get one of the systems with Intel inside today or actually within the next few weeks and start experiencing the future now. You can work your -- bring your code over and actually test and debug your code on those systems.

If you've got feedback on the Xcode tools, you can reach me at mformica at apple.com or just flag me down in the halls. I'd love to get your input, both on what you love about Xcode, and there's a lot to love there, or what we could do to tweak things, make them even better. So thank you all very much. Enjoy Xcode 2.1 and enjoy WWDC. Thank you.