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? Thank you, thank you. Got to have a towel. Of course, you know, the Hitchhiker's Guide is all about, 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. You know, 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 29th, and we also shipped Automator on April 29th 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-- We tend to think of this little man as Otto, and I think Otto can kick that little man, Marvin's butt.

It's, you know, a nice similarity. Marvin kind of depressed. Otto, you know, 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. So, user interface.

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--CodeSense, 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--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 Xcode 2.0 as part of Tiger to accelerate your development, to make it easier to develop, to widen your capabilities. One of the big 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 order vectorization. So if you don't want to write the vector code yourself, you don't have to. And in fact, just with one switch, it can actually, in many cases, take floating point loops and generate the AltaVec instructions. We've improved the integration of all the features. So between, for example, C++ and Objective-C. So now, for example, you can implement the C++ code. You can embed your Objective-C, 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 order 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 4 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% to 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 move--as we develop the application--Xcode in GCC4 further along.

Next major feature to talk about, of course, is the transition from 1.4 to 5.0. 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. 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--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. To be able to--Quartz Composer gives you the ability to prototype and pull these different filters together and get some idea 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 off 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--you know, we have not underestimated that there is some challenge to this. We've really designed the tools in Xcode to really 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--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 the debugging and profiling infrastructure works. And 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.

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. 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.

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. 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 been--gone through tremendous shakeout. So you're not dealing with something that is going to be very buggy. In fact, it's--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 is--allows you to reverse the order of the bit fields so that if your bit fields are--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.

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 Indian. It supports SSE vector processors and vector instructions and has a divide by zeros 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--of course, 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. And then we'll go into the process of creating the most complex and complex model that the CPU requires. The auto vectorization routine is a help. And then as sort of a last resort, handwrite the SSE intrinsics yourself.

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 you 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. We were either in sort of debug and development 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 were trying to both debug and use 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? Thanks, Ted.

Some of the settings would actually be crossed out in the user interface, and there'd be no tooltip 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.

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 in its 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 subprojects, 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.

Why don't you work on that example some while I talk a little bit. 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, .xcodeproj. 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 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.

Sometimes 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.

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-- visualizing 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 breakpoint, 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 breakpoints. 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.

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. Thank you, 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's 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 then 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 OS X and Intel using Xcode. It's really the way to go. I'm sold on it. Great. A couple other things. Okay. So, as you know, Hello World is sort of an early milestone as you're--as you're moving a compiler across. So we aren't quite ready to announce, you know, 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 technology, 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 will 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. Great. So we think Intel compilers will be a great enhancement to the tools that Apple's already providing in the Xcode environment. So... Great. Happy to have you on board Xcode.

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. 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've 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:00 AM. 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:00 AM 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.

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 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 [email protected] 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.