And I think you'll find that we have had really just a fabulous time and really enjoy doing it, creating applications, creating the tools that you're going to use to create the next generation of wonderful Mac OS X applications. And to do that, I've been thinking about what makes a good metaphor? And we build on a great heritage, a wonderful heritage of terrific development tools, terrific development environments, going back to Smalltalk and Xerox PARC and Cedar and all kinds of really great programming languages and environments.

And really when I break it down, I break it down to about five columns, five pillars of development tools. The first one I think of is scalability. Do the tools scale to meet your needs. And then the second, productivity. Are you actually productive using the tools you get and feel that you're maximally that your time is well spent using these kinds of tools and environments?

The third one is performance. Thinking about the performance of your application, the performance of what you get out of the processor and out of all the other systems that go in to creating great applications. Performance is an ongoing thought process. And it starts at the architectural phase and continues right through to completion and finishing your product. And then interoperability. Does your application interoperate well? We provide many APIs and frameworks so that your application can play well with all the other applications. Your application exists in an ecosystem of many applications.

And the payoff is that your users, the customers, have many applications they are going to use to get their work done or enjoy what they do. And so you have to think about the interoperability, and the tools have a role to play there. The final one I'm going to hold for later, because it's keep it for the end.

So scalability. Scalability, well, two parts to that. Xcode scalability. Does Xcode scale for your needs? And let's take a look at where we've come from. And data scalability. And we've already spoken a bit about that. Let's jump right in. So last year when we met at WWDC 2005, we introduced Xcode 2.1, the universal IDE. And this was a development environment, of course, that could scale to two architectures, to PowerPC and the Intel CPUs. And these architectures and making it easy and simple to do was a big part of, of course, the mission there. And we've been working a number of years to create tools that made it simple, the whole universal architecture, universal binaries, all the other products and technologies that end to make that as convenient as possible.

We followed that up very quickly with Xcode 2.2, mostly bug fixes, but one new feature which you may not have noticed called Attach on Crash. What that does, of course, is when your program crashes and Xcode is running, it opens up the debugger and brings you very conveniently to make that happen.

We followed that up with a very important scalability feature, Xcode 2.3, called Dwarf Debug Format. And what that did was it shrunk the size of symbols so that it really could scale to the largest application so that debugging C++ and C and Objective-C and Objective-C++ applications really could scale to really be able to perform extremely well.

We also in Xcode 2.3, actually in previous versions of Xcode, we had distributed builds. Now, the primary purpose of distributed builds prior to Xcode 2.3 was to make use of ad hoc networks of computers that you might have around you and your colleagues around the local area network. We had a lot of requests for being able to use dedicated forms of machines. And really, this CC-based technologies that the distributed build mechanism was based on only scaled to about six machines. And after that, adding additional computers really didn't help. Well, we broke through that with Xcode 2.3 with a feature we called dedicated network builds. And it really more than doubled, even quadrupled. In fact, it really scales linearly. So there's no limit to the number of machines you can add. Really depends upon the scale and the amount of code you have.

And today, of course, we heard the count. And we're very pleased to say that there are over 3,000 universal applications. And I want to thank you for that. And it's really been a tremendous work you've done to make this possible. And so to thank you for that, I've got a surprise for you at the end of the presentation.

We also are releasing Xcode 2.4 with 64-bit tool support. And this, of course, completes for the Intel processor, completes and does it really just as we've done for Tiger last year to provide 64-bit support for the G5. We now provide it for Intel as well. I want to actually reflect how build times have improved since we started with Xcode. And we use Finder. It's a large C++ Carbon application, like a lot of large applications out there. And really what we've seen is a nice, steady shrink of the amount of time it takes to build. On laptops, for example, it went from 809 seconds to 113 seconds. And a lot of this is because Xcode is using an architecture that's really well designed for multiprocessors and scales extremely well. And of course, as you would expect, that works even better for quad processors. And so going from Xcode 1 to Xcode 2.4 today on the Mac Pro, really we've seen between a 7 and 8 load improvement. So it's been a wonderful experience in having the architecture and the hardware and the software really mate very well for it. And Xcode takes advantage of the processors, And much of, as I think, your applications need to be designed with the multiprocessor architectures in mind. Xcode has had that since the beginning.

So what's next? How do we follow this great run of technologies and services and applications that have come along? Well, of course, Leopard is next. Leopard is next. And with Leopard, of course, comes the fruition of a full, complete 64-bit stack. And we've designed a lot of the features into the next generation of Xcode, which we, of course, call Xcode 3. Xcode 3 is on the DVDs you have, and it's a really great technology and has so many important features. I'm only going to be able to... I only have time today to tell you about a few of them, but the sessions really will detail and go into great detail.

Of course, we give you the checkbox, so simple to build for 32-bit and 64-bit universal applications, and we provide you with all the languages to be 64-bit compatible, so that this is another great new capability for you to add to your applications. as you also have heard, all the frameworks. So really a big part of the data scalability that I think is extremely important that you need to use to make your applications take full advantage of the processor are going to be in these frameworks. And one I'd like to mention and call out that probably doesn't get a lot of attention is core data. Core data is extremely simple to use, and it scales to exabytes of data. It provides you with tremendous capabilities, both on 32-bit, but even better on 64-bit architectures.

One application, which since we brought Java up, it comes right up, and since Java is designed to use a portable bytecode, it doesn't encode any of the processes inside of it. Some applications that make use of a lot of data, like GeneSpring, which is a 64-bit application in Java that runs well in 32-bit as well, but in fact in Java, of course, we don't even think about the address size. It just came right up and works. I think you'll find that your Java applications will be able to make use of 64-bit right out of the box.

Now let's turn to productivity. Productivity. So productivity, of course, is a big part of why you're here, to hear about the productivity improvements in development environments. And really, we want to provide you with tools that streamline your workflow. Streamline your workflow. And I think a very important part of that is a really more productive programming language. And really, it means about solving problems faster. So it's the tools and the programming language together extremely well. And, of course, when we talk about a more productive programming language, you know what we have in mind. We face -- Apple faces Goliath competition. And in facing that Goliath competition, we really need to do that with a better technology. And the better technology is Objective-C.

Now, what is it about Objective-C that makes it so great? Partly it's dynamism. It's partly that it does interact extremely well with C and C++. And partly that it mates very well with tools because of the metadata model that is part of the class hierarchy and the structures, the fact that it has a runtime-type system, the fact that all these technologies mate extremely well together. It really does make Objective-C really into an incredibly powerful weapon. And it allows us to get work done to beat competition that's really an order of magnitude larger than us, and to do it by writing less code, writing less code, so that small teams can be extremely effective, extremely effective in getting the same amount of functionality, or in many cases, more functionality with fewer people. And that really is, of course, a big part of what technology is about. And so Objective-C really has served Apple extremely well. And so in thinking about it, right, There's a lot of capabilities here, which I believe that if you haven't used Objective-C yet, it's a great opportunity here at the conference to learn. And of course, we're improving this.

You heard Batran talk this morning about garbage collection. There's two other important features I'm gonna talk about today, properties and iteration. Garbage collection though is a key factor. But of course, I don't think you should just hear it from me. I'd also like to invite up someone else to tell you about Objective-C and its virtues. This is Ken Case from the Omni Group. Please welcome. - Thank you, Ken.

Thank you, everyone. Small teams. It's amazing what you can accomplish with small teams when you give them the right tools. At the Omni Group, we have 12 developers, and we have six products. You may have heard of some of them-- OmniWeb, OmniOutliner, OmniGraffle. And this summer, we introduced two more-- OmniDazzle and our latest, OmniPlan. 12 developers and six products. That's easy math. We have two developers per product, and that's some pretty small teams. The only way we can accomplish that is through really great tools, and one of the best tools in our toolbox is Objective-C.

I first discovered Objective-C 17 years ago. And my first reaction is, well, what's going on with this language? What are all these brackets doing in here? What are these extra words in between my parameter lists? I just didn't quite get it. But as I started to use it, I discovered that this was a really powerful language that made me incredibly productive. I could work at the highest levels of abstraction with these nice object-oriented frameworks and with our own objects that we were creating. Or I could dive all the way down and do straight C code existing C code that's available for Unix. And it just made us incredibly productive. So Objective-C for the last 17 years has been really core to our development at Omni. 12 developers, six products. And they're not just tiny little products. They're actually serious productivity applications. So I'd like to take a moment and show you our latest Omni plan.

Demo screen, please. OmniPlan is a product that we wrote for ourselves, because even with small teams, software development is a complicated process. And so it takes a lot of organization. You start out by listing, of course, all of the tasks that you want to do. And we do that in an outline over on the left here. And then on the right, you'll see that we have-- a timeline that displays all of those same tasks and their relationships, their dependencies, in Gantt chart notation.

Good product plans, of course, need to be, first of all, easy to create in the first place, but also malleable and easy to change later. They need to be flexible because you can't just create a plan at the very beginning of a product cycle and hope that it will magically work out all the way to the end of the process. So let me show you what it's like to edit a project plan here.

Here we are at the end of our beta feedback cycle. And we've discovered that we have a few changes to make. Our beta testers have told us that we need to fix the memory leaks. We've got some memory tuning work to do. And we have some new features that we'd like to add. The beta testers thought of a killer feature that just hadn't occurred to us. And it wouldn't take very long to add. So let's put that in there. And of course, we have some bugs to fix.

So to integrate this into our process, we just hook them up. We connect them. And we level out the work, because we do have a small team. We can't do all those things at once. So there, as you can see, our final release is already adjusted. We can look at the split schedule here, see where the final release was, where the final release is now. And of course, our next step would be to then publish this to a web page and share it with the rest of the team so they can all see the task list, the project list, the resource list, and the Gantt chart itself. And from that web page, you can also download calendar files that have to-do lists and so on.

But let's take a deeper look at this extra time in here. We said four weeks spent doing this memory tuning, two weeks spent fixing memory leaks, and then two weeks fixing crashes. Why does that take so long? Well, first, to track down the memory leaks, you have to reproduce the conditions. You have to do it with some sort of tool like Omni Object Meter that sits there and tracks where all of your memory allocations are going and where you did all these retains and release and matches them up. And then once you've fixed your leaks, you have to go back around and fix the crashes that you've introduced because the leaks are masking them. So you have to go find all the zombies and fix those as well.

Wouldn't it be nice if-- I'm sure you can see where I'm going with this. Wouldn't it be nice if we didn't have to worry about doing all those memory leaks all the time? Now, when I saw Bertrand's talk there, his picture there just spoke to me. I was the person in the audience going like this when I first heard that Apple was considering doing garbage collection. I said, garbage collection is great for these scripting languages, but I don't really want it in our serious productivity apps. It's not going to work for us, is it? That's just-- that doesn't sound good to me. So my first piece of feedback to Apple was, well, that's great. You put it in Objective-C if you need to. Just make sure that we can opt out so we don't have to have it in our apps.

But then I think about these four weeks, and this isn't the first time we spent fixing memory leaks in this project. So four weeks is a lot of time. We could spend that time doing performance tuning in other places in the application. We could add some more killer features. We could fix bugs. Or we could just ship sooner, and that would be great. So-- The only question is, is Garbage Collection really fast enough to use in our application? And I have some great news to share with you.

This copy of Omni plan was actually built with Garbage Collection. And as you can see, it performs quite well. So I'm really looking forward to shipping garbage collecting applications on Leopard as soon as it's available, and enabling our small teams to do even more with even better tools. Thank you, Ken.

Garbage collection, essentially there are two issues. One, are you actually freeing up all the objects that you're no longer needing? And number two, have you accidentally deleted objects that you might still need? Without garbage collection, you have to worry about this. Bugs creep into your application without this. Now obviously, garbage collection is not every possible benefit from just simply removing bugs. But let's take a look. So this is a simple setter and getter implementation, kind of thing you write pretty frequently in all object-oriented languages. And one of the great things about garbage collection is we just make that go away, make away all the retain release count.

And it all just disappears, and the code becomes much more beautiful, really just the essential assignments and returns. And so GC really is going to simplify a big part of the retain count part of your programming. Now, you can still leave in retains and releases, but in a garbage collected application, they will be ignored, or in the application code. So you can remove them. So it's still very convenient to write frameworks that are both GC-enabled and GC-safe.

Of course, this code, since setters and getters are a typical part of what we do, let's make that easier. And so we've added properties to the language, and this retains the four object-oriented properties that you can override it, either the setter or the getter in the implementation. The compiler will generate the code for you to make that possible. One great thing about that is that with properties, we can now have the dot notation, typical dot notation. And it calls an object-oriented method call invocation still in objective C. And that works both on the left and the right-hand side of the assignment statement.

Now using that, what do we typically do? What do we typically do with this? So oftentimes, we write for iteration. And with iteration, we have to write an induction variable and count it along. But of course, again, since we have the built-in data types of NS enumeration and so on, we can, in fact, make that part of the language as well. So we've added in iteration into the language, and it has the very simple for loops.

These three features, these three features, I think are going to make Objective-C 2 on Leopard really terrific for you and really improve programmer productivity. the country. So if Objective-C is the rock, what's the sling? What's the sling there? And I think the sling, of course, is Xcode. And I could tell you about all the great features in Xcode, but I really think I just want to show you.

So the big part about Xcode is we've streamlined the editing process, the building, and the debugging process, and really to make your workflow in using Xcode incredibly more productive so that you can write the greatest applications in the world. So I'd like to invite Andreas Venkerup, the Xcode ID manager, up to give us a demo. Thank you.

So good afternoon. Over the last couple of years, more and more of you have started using Xcode for the development, and we've been listening very carefully to your feedback. One of the things we've heard loud and clear is that you want a faster and better text editor. And I'm here to tell you today that we've been working very hard on that. And already in the leopard seat you hold in your hands, our text editor is up to five times faster than opening and scrolling through files.

Let me show that to you. To demonstrate it, I brought an open source project called Osiris. It has about 1,000 source files. And the largest file I could find in it is a C++ file. It's not quite a megabyte large, and it has about 20,000 lines of code. So let me open that up for you. Here it is. So as you can see, no more significant delay when opening files and scrolling through them.

Let me show you another one. This is an Objective-C class. It's about 400 kilobytes large, 12,000 lines of code, and again, no significant delay. Another thing you might notice while I scroll through the file here is that we've also made significant improvements to our syntax coloring. In Xcode 3, we've identified many more types of symbols, and we give you more options to color them.

Now let me close this project and go to another one, which I'm going to use for the rest of my demo. This is a variation of the core recipes application and a sample code for a core data. The next feature I want to show you is also very commonly requested, and it's code folding. Code folding is the ability to collapse blocks of your code together in the source editor so that you get a better overview of your source.

And so if you just concentrate on the pieces you're interested in, let me use a keyboard command to just collapse all the methods in this file. So as you can see, I now get a much better overview. And I can just decide to just look at the methods I'm currently interested in.

Now, some people like to use the keyboard, as I just did, and other people like to use the mouse. So let me show you a new preference we added to turn on the so-called code forwarding sidebar. The CodeFolding sidebar has two modes. The first one that you see right now, the default one, is just that it uses a color gradient to show you the depth of the nesting level you are in right now. So just by scrolling through the source file, you can kind of get an idea for where you are in the method bodies, how deep you are in them.

The other mode gets activated when you mouse over the sidebar. At this moment, the sidebar turns into what we call the code focus control. It allows you to collapse blocks of code with a mouse. And also, as you can see, when I scroll over it, it kind of gives you a very clear indication for where you are in your code and which block is going to be affected. So you can just go ahead and collapse that and open it up again.

The next thing we wanted to do is make documentation more easily accessible for you. For that purpose, we added the Research Assistant. You can activate it in the Help menu. And the Research Assistant is a small window that you can place on the side of your editor. And it will follow around your selection in the editor and show you relevant information about the methods you're working with right now. Most of you are probably familiar with the object and index methods. Let me just select that. And as you can see, the Research Assistant just follows me around and shows me information.

At the top of the window, you have just some links to take you to the header or to the documentation window. And below it, you find the information you would expect, the declaration and abstract description. But it also shows you more things like related APIs or related documents or even sample code if you have it available for these methods. So the Research Assistant gives you documentation right at your fingertips.

The next feature I want to show you is the feature that will become handy when you work with build errors and warnings. So far, Xcode displayed errors and warnings either in the build window or in the errors and warnings smart group. So let me start building my project. And as you can see in the status bar, it failed with an error. But wouldn't it be nice if it would show me this error right in context in my source code? Let me use the keyboard command to jump to the error.

Here it is. And now we can turn on what we call message bubbles for errors, warnings, and breakpoints. And then as you can see, we are embedding the information right here. So it's very easy for me, without switching context between different windows, to go through my errors and warnings, correct them, which in this case is very easy. Save and-- --and build again. And then the error is gone.

Now let's take a look at something beyond the source editor. Let me go to another header file. This is the header file for the recipe objects in my database. As you can see, it has instance variables for all the properties of a recipe, a name, and the number of servings, and things like that. But if you look closely, you might notice that I've had somewhat of a whimsical moment a while ago. And I actually called an instance variable yummies. Well, being here on stage, I'm kind of embarrassed by that. And I'd like to use a more professional name, like ingredients.

So typically, what I would do right now is go into the Find panel and start searching for all the occurrences of yummies, and then start replacing them one by one. And we all know that this is very tedious, time consuming, and it's also error prone because it's very easy to miss a spot. And wouldn't it be nice if the IDE would help me with these kind of mass changes? So there's a technology that is called refactoring. And I'm happy to announce that in Xcode 3, we are adding refactoring capabilities for Objective-C to the IDE.

Refactoring means that you can make structural changes to your source code without changing the behavior at all. And let me just show this to you. So I'm going to select my instance variable here, and I'm going to bring up the refactoring window. And this window just gives me a few options of-- gives me all the options that I can use to work on my instance variable right now. Just this pop-up here at the top. There are a few options to move up and down the instance variable in the class hierarchy. The most common one is the first one selected, the rename operation. So let me just go ahead and enter the new name.

And let me also point out this checkbox here at the end, the related KVC members. One of the great things about our refactoring engine is that we are building in specific knowledge about the Cocoa conventions. If you've ever worked with key value coding, you know that you have to keep a lot of method names in sync with your instance variable. And there's lots of stuff that is related to each other. And we are building in this knowledge right to the refactoring engine.

So once I end up all the parameters of my transformation, I can press the Preview button. And then Xcode goes and analyzes the project and will find all the files that need to be changed. and then comes back with a list of changes. Once it comes back with this list, I can go ahead and preview the changes just by clicking on it. And as you can see, we integrated fine merge-like functionality right here in Xcode in the workflow.

Now let's take a look at what we found. The first one you would kind of expect, because that's the instance variable where we started. But if you go down the list of changes, You can see that it found all the related methods, too, like the add and remove objects.

And this is now the implementation file. There's the instance variable again. And already here, you can start seeing that we not only find occurrences of the variable and the method names, we even find invocations through string that are done through indirect key value coding calls, like you can see here. Let me just go down, show you a few more of those.

And if you go on to the next file, you can see that we are also not limiting our changes to the source files. We're even going into your Nib files. We're going to keep actions, outlets, and binding names in your Nib files in sync with your code changes.

So in this case, for example, we found a binding name that was using yummies and now is using ingredients. So let me go ahead and apply this change. Just going to take a moment. And let me go and save all the files. And then let me show you another refactoring operation. A few minutes ago, you had Ted talking about the new features of Objective-C 2.0. And wouldn't it be nice if you could just start making use of these great new features without doing much work? For that purpose, we added a menu item to convert your code over to Objective-C 2.0.

So let me just go ahead and start previewing this. As you can see at the top of the window, we give you a few options for which features you want to start using, modernizing the for loops with the iterators, starting to use properties, et cetera. In this case, I just limited it to using the for loops, to using the new loop iterators. Before I show you the difference, I also want to show you this little checkbox up here, which is called Snapshot. Behind this checkbox, there hides another really great feature of Xcode 3, which we call Snapshotting. Snapshotting is the ability to capture and preserve the state of your entire project, to review how your project changed over time in comparing the snapshots and the current version of the project, and to also go back to a snapshot in case anything went wrong. So it's a very lightweight-- Thank you.

So it's kind of a very lightweight-- it's not really an SCM system, but it's lightweight on the local disk. And you can use it in addition to the SCM system that you share with your coworkers. I'll show you a little more about snapshots in a moment. Let me now just preview the changes here for the modernized loops. So here, for example, we found a loop within enumerator. And we just replaced that with a new for each iterators. So let me also go ahead and apply this change.

And now let me bring up the snapshot window. So this is the snapshot window that just lists all the snapshots I took for this project over time. As you can see, it has a short description and a timestamp. And even better than that, I can expand the window to show me more details.

And here, as you can see, is the diff now of my project. And again, I can look at the differences in detail. You might remember that we just renamed yummies to ingredients. So here's my snapshot. So refactoring together the snapshot in vBelieve will allow you to become much more experimental and more playful with your code. Because first of all, you can make changes much more fast now. And also, you have a safety net in case anything goes wrong.

We talked about Nib files just a minute ago during the refactoring operation, so I think it's time for me to show you the new interface bit in Leopard. You might have already seen it in the previous session. Let me just go ahead and open it, a Nib file here.

Interface Builder in Leopard is a major refresh of Interface Builder. It has a fresh new workflow that is much more efficient. It also has a fresh architecture that makes it easier for you to extend Interface Builder with your own objects. I'm going to show you why in a moment. Let me start by walking you through the application. Here's a new file window of Interface Builder. As you can see, it has different views now, an icon view, an outline view, or a browser view. And then also we added a search field so that you can filter on the objects and more quickly reach the objects you want to work with. For example, you can find all the text fields very easily.

Let me open up a window here and start adding objects to my Nib file. For that, I bring up the library window. So the library window contains all the objects I can add to my Nib file. And it replaces the previous palette mechanism that we used with a more efficient and more flexible way.

First thing you will notice is that the library is organized in a hierarchy of groups. Right now I have the entire Cocoa group selected. Look at just the common controls, the controllers. I can select multiple groups at the same time to reach all the objects in both groups. The library window also allows you to create your own favorite groups. So if you want to just put the same-- if you commonly work with the same objects, you can create your own groups and just drag the objects in there and then bring up those groups. Let me add the text field to my new profile and just play around with it a little bit.

And of course, if I want to customize this text field, I will go into the inspector. So let me bring up the inspector. Here it is. If you've worked with Interface Builder before, you will immediately recognize this window again. It contains all the controls you need to customize the objects in your Nib file. For example, I could go ahead and change the alignment, or I can change the border type. Just the usual stuff.

Now, what you might notice is that the inspector is now organized by class hierarchy. It has individual slices for each of the classes in the class hierarchy. And that is one of the reasons why it's so much easier now to customize Interface Builder for your own purposes. In the past, when you added an object to Interface Builder, you had to replace the entire Inspector infrastructure with it. You couldn't reuse any of the work that we've done. Well, in the new Interface Builder, it's enough for you to just add a new slice, and you can reuse all the work that we've already done for the object classes. So it's going to be a lot faster for you to write your own Inspectors. Another thing our inspector can now do is inspect multiple objects at the same time.

So I just changed both objects at the same time. And even better than that, we can now handle selections of different types of objects. So this is another advantage of working with these slices because we can still show you all the common slices that apply to all selected objects. So for example, I can go and change the control size of all controls at the same moment.

Now, Interface Builder wouldn't be Interface Builder if I couldn't make connections between the objects. So like in the past, I can just Control-click an object, drag from the source to the destination. But now, instead of having to drop into the inspector to complete my operation, I get a little heads-up display right here in place. And I can just choose, for example, to set the next key view outlet. Even better than that, if I Control-click without dragging, I get another more extended version of this heads-up display that shows me more detail about all the incoming and outgoing connections at the same time. And again, I can start creating new connections. And as you can see, it nicely fades out so they can still reach objects.

So you can still reach and see objects right underneath the HUD. And as you can see, I just completed my connection here. So let me drop out of Interface Builder and go back into Xcode. And let me start building and running my project. Since we just refactored a few files, it's just taking a moment. And here it is.

So this application is a core data sample. It just has a little database of common recipes and has a window that I can double click on items to see more details. And I don't get any data. Actually, let me just give me a second to figure out what I just did. If it's possible, I'd like to switch over to the other machine. Yeah, this is where I invite you into the time machine. And we just go back in time.

Just one second. I just need to bring up the project again. But there's one more feature I really want to show you. And of course, now what I have to do is I have to go and refactor one more time, because otherwise my project won't work. But now you can see how fast it actually is. Just one more second. Now let me build and run. Just for you.

Yeah, it's not my fault. Anyway, let's just pretend there's some data in this window. So what I really wanted to show you is that there are some directions. And what I wanted to do is go and prepare my recipe in the kitchen. Of course, I have to step away from the computer for that. So to see it in more detail, I added an enlarge button to my window. Let me drop my window into the full screen mode. Unfortunately, it's empty right now.

This is, by the way, using one of the new Cocoa APIs to go into full screen mode. Now, what if I want to debug this? All right. That allows me to show you another feature that we use to streamline the workflow in Xcode. As you can see, when we launched the application, we added a small toolbar to the editor window. And this toolbar contains all the buttons that I need for most of the common operations.

For example, there's a button to just turn on breakpoints. And I've already set a breakpoint in my application that drops it into the full screen mode. So let me just go back to it and run it. And now, as you would expect, Xcode will go into the debugger. And here, I can use the toolbar to, for example, switch between the different threads. I can look at the stack trace. I can step over the different lines. And what I can also do in Xcode 3 now is I can just hover over the instance variables and get data tips.

And I can use these data tips right in line here in my editor to continue debugging. So with the toolbar and the data tips, you can now do most of the common debugging operations right in the editor without having to switch back and forth between the different windows.

So let me continue. And now, what if I want to debug the opposite scenario, where I drop out of the full screen mode? Well, I'm a little bit out of luck right now, because there's no way for me to reach Xcode unless I have a second screen. Well, there's a solution for that, too, in Xcode 3. Let me go back into the code, remove the old breakpoint.

and set a new one here, which is the place where it drops out of full screen mode. And let me also bring up the debugger heads-up display. So this is a little window that just have us here on the screen. And when I go back into my application, OK, well, I can't show you that. The idea behind the debugger hat here is that it hovers on top of your screen. And even when you're in full screen mode, you'll be able to debug scenarios because it's on top of your application without you having to drop back into the Xcode app. So it allows you to debug different scenarios that you wouldn't be able to debug before. And of course, I can't show that to you right now. Anyway.

I hope what you saw is that we are keeping up a very strong momentum in our tools. There are lots of new great features. And of course, we implement all that so that you can keep up a strong momentum in your own applications. So please start using Xcode 3. Thanks, Andreas.

Thank you, Andreas. I think that there's something wrong with the mirroring and the heads-up display. It's interesting how many bugs you discover here on stage that you never see in the development lab. So summary of some of the top features-- faster editor, code focus, message bubbles, snapshots. Really what we're trying to do here is create a fearless style of programming where you can try out different things and really debug them. Integrating file merge, a feature I heard a lot of applause for, and I knew you'd love it. All these things, I think, are going to make Xcode an incredibly, incredibly productive environment. One of the parts about how all this fits together, of course, is a lot of you, of course, are developing applications that you want to ship using Xcode 2 and Xcode 3 on Leopard. And so one of the things which we've been thinking about and gotten a bunch of feedback is that you want to use these two great tastes together. But of course, in the past, you can't. You can only have one installed at a time. So today, I'm going to make a commitment. And yes, we're going to, at Leopard GM, we will have Xcode 2 and Xcode 3 be able to coexist on your Leopard system. Thank you.

Now, let's switch gears and talk about performance. And performance is two great important parts. First part is a 64-bit compiler, and the second part is tools. You heard Simon talk about that 64-bit doesn't improve everything, so you need tools as well to understand when to use 64-bit and whether 64-bit is good for your application or not. But let's first focus on the compilers. Thank you. So of course, we give you GCC4, and GCC4 is already a 64-bit compiler.

We've measured and seen between 15% and 20% faster code generation on 64-bit Intel. And as well, we also see that Dwarf is giving us much faster build times just by switching from Stabs to Dwarf. So if you haven't switched, I highly recommend that you do. The better code generation, in part, is because of the registers and new addressing modes. And in fact, it doesn't affect every application equally. When we use spec just as kind of a benchmark comparing 32-bit and 64-bit performance, we see very different behavior. Some of the kernels degrade, but most improve. And in fact, some improve quite dramatically. If you have an application which uses 64-bit data types, it's going to love 64-bit, obviously. But really, even parsers and crunching applications the various compressions, Bzip and Gzip, both have significant improvement. So you have to understand whether or not your application is going to be able to take advantage of 64-bit if all you're doing is performance. Obviously, if you're going to want the scalability, you're going to move for that purpose alone. But for performance purposes, I think 64-bit can be a great improvement.

Now, how do you know whether or not 64-bit is good for you? Well, of course, you need great performance tools. And performance tools are a bit like being a juggler. One moment you start up Chud, another moment you're starting up an object Alec, and another moment you're in all the other performance tools. And it's kind of a problem, right? What do you do?

What do you do? You're never in the right tool because you want to look at one part and then another part is under investigation. And oftentimes, you're going to see, aha, we need to look at the multiple threads and the way it interacts across the system. And so in thinking about this, and of course the multi-core architectures we live in now, really we wanted to provide you with a new tool, something that brings all the functionality together.

And so to do that, we've created something called X-Ray. X-Ray is a new tool on the XO Tools DVD. And really, I believe that it's going to be a revolution, because it's a framework that brings together all the different kinds of tools and instruments into one place. And well, I could tell you more about it again, but really, better a demo is worth 1,000 words. Bring up Jeff Glasson, manager of performance tools. JEFF GLASSON: Thanks, Ted.

I hope you're having a great day. You've gotten a lot of information so far. I have the honor and privilege to be the first to introduce to you a brand new application called X-Ray. Now what X-Ray is, is it is a unified performance analysis tool. It allows you to analyze the behavior of your program and how it affects system performance and how it interacts with other things on the system. I think the best way to show you more about it is to actually show it to you.

Let's hope the demo gods are appeased. So the first thing you see when you launch X-Ray is you see actually kind of a somewhat familiar user interface. It is reminiscent of a garage band, and we have instruments, they have instruments. They're a little different. The top of the screen is the area where you can put your instruments. There is a master track. One thing that's very common between music and performance analysis is the concept of time, And I'll explain that a little bit more later. And down at the bottom, you've got a set of pre-built instruments that we supply. Probably by the time we ship this, there'll be a lot more in that. But this is what we have for you today. You also have the capability of creating your own instruments through customization and new instrumentation. So let's see how this works.

I'm going to drag a couple instruments up to the instrument bar, ObjectAlloc and NetworkTrafficMonitor. And actually, let's make some more room here. Make the window a little bigger. And also, let's put something else up there, File Activity Monitor. And now, I'm going to hit the Play button and select an application we use every day, which is Safari. And we're going to run it.

So as Safari comes up under X-Ray, you're going to see data starting to be collected and displayed in the graphical user interface up above. And instruments can display information in a number of different ways. Let's stop that. We have enough data to show you. The ObjectAlloc instrument is configured to show you a graph of memory being used by your program. The NetworkTraffic instrument is showing traffic for your network in and out. And the little blips are showing different file system events. And if you scroll, you can get detailed views with tooltips.

You can actually drop down here and see a very extended view. And you get stack traces whenever an event occurs. So you can use this-- a little bit of applause. So this is, I think, the first time Apple has given you a tool that shows you multiple different views of different aspects of the system. But what about that master track I mentioned earlier? So let me show you that. Create a new document.

Earlier in the day, you heard Steve mention accessibility. And one of the benefits, one of the other features of accessibility in making your apps accessible is this, because we tie into the same accessibility frameworks. All I need to do is click Record, and I'm going to launch an application that is actually a modified version of the AppKit TextEdit example that I've modified to use garbage collection. And I'm going to run it while I'm recording what I do. The app launches. I can open a file. Select some text. Open up the text menu. Change the color, and then stop. So what you see on the master track is an actual recording of all the user interface events that I did.

And there's actually a couple different ways to look at that also. This is just showing them strung together, but you can also look at them in time as seconds or minutes. And that's scalable, and you can see exactly when the event occurred in time. Now, we didn't stop there. We actually added the capability of saving these recordings as templates and integrated that into Xcode. So let me show you that.

I've actually saved a little bit longer script of a template. And so I'm going to open the TextEdit project in Xcode. And under the debug menu, I think those of you that have used Xcode before have seen the launch using performance tool. And you might see a few things you haven't seen before. File system monitor and below, those are all actual X-ray templates. And text edit is the one that I've created myself to help me monitor and performance tune text edit. So let me open that up. So I'm away from the keyboard. No tricks, nothing up my sleeve. It's actually going and running the workflow that I've created, doing a little bit more than I saved last time.

That's the end. And this time, the template that I created actually contained a couple instruments to monitor the garbage collector running. The top graph is actually showing bytes of memory in use. And you can, again, go through the detail view and scroll and see events. And then down here, these are actual times when a garbage collection event occurs, and you can see the bytes collected. So what you can do with this is you can create a saved workflow. You can then run it over and over again as you change your application and watch how it changes the performance.

So I've only scratched the surface of this tool. In fact, we're actually not quite sure the real uses of this tool is so powerful. And that's up to you guys. And if you really want to learn more about this, there's a whole hour dedicated to X-Ray on Thursday afternoon. I believe it's at 2 o'clock. And I hope you guys are all there. Thanks, Ted. Thanks, Jeff.

I think this is an incredible new tool. It pulls together a number of different technologies, and instrumentation has its own plug-in interface. And as well, it uses the DTrace scripting language, event monitoring language, to be able to monitor and very rapidly create ad hoc instruments as well. So we think this is a tool with an incredible amount of potential. And given that so many performance problems sometimes are the interactions of many systems, databases, web servers, and applications, we really believe to be a very powerful tool in your toolbox to understand and do things, and to really help figure out how to make use of all that compute power, all those CPUs and network capabilities and other frameworks that we provide. Of course, it captures the events you need, the instruments operate in parallel, and very importantly, this concept of a master track to record the events for repeatable debugging runs so that you can actually inject a little bit of science into performance tuning. And I think that's going to be a big help to you. So that's X-Ray.

What's next? Interoperability. So, interoperability. Well, now you've heard Jeff and Steve talk to you about the importance of making your app accessible. Well, it doesn't stop there. We also want you to make your app scriptable and automatable. I know it's a lot of work. But the payoff, the payoff is great, right? Here it is. If you can make your app accessible, all these kinds of applications, and another one you'll you'll see in a minute, become part of the interoperability story of your application. Making it scriptable, of course, has been a great, great benefit of Mac OS X for many years. And of course, with Tiger, we leased Automator, and Automator, very powerful, wonderful feature. Let's talk about Automator. This little guy has been a big success, right? People love him.

He's kind of cute. And on top of that, it really is part of the way people use a desktop productivity system to use it in this ecosystem of many applications. There are thousands of actions now. And your end users can use that to combine together to create functionality that has better lock-in. And so, really, I believe that Automator is a way to extend the functionality and capabilities of your applications so that it is part of a very rich system of great applications. And, of course, we're not going to stop there, right? We've been thinking about, now, how can we improve this? How can we improve on what has been already a fabulous run? And we're thinking about Automator 2.

And so Automator 2 is going to be easier to use, using accessibility, and more efficient to make it even more powerful and faster, and everywhere. We're going to give you the capability to take automated functionality and embed it in your application. Big feature request that you've asked for. So let's give you a show and show you what that looks like. I'm going to invite Todd Fernandez up. Todd. Automation Tools Manager, give us a demo.

Thank you, Ted. Good afternoon, developers. Now, Ted has just called upon you to make your applications accessible, scriptable, and automatable. So to demonstrate how important we really think that is, I'd like to show you what we've done with Xcode, both as an example of the benefits that we think you'll see by doing so, What's that?.

So Xcode is scriptable in its initial release, and we've continued to expand and improve upon its scripting interface in subsequent releases. Automator also has a number of Automator actions, so it's already automatable. But we wanted to make it even easier for developers like you to take advantage of workflow automation. So as Ted has said, we've integrated Automator right into Xcode. But before I show you what we've done, I want to set the stage a little bit. Can I have the demo machine, please? So let's imagine that you've been hard at work all weekend adding a new feature to your application. In my case here, the ubiquitous text edit.

And you really want to make it look nice when you send it out for some wider testing, and maybe to your boss so that he knows how hard you were working all weekend. But there's no easy way within Xcode to create a package and maybe add it to a disk image so it's easy to distribute or send out as an email. This cries out for a workflow. So let me show you what we've done.

We've added a Workflows menu to Xcode's Application menu. As we can see, the first option-- is the workflow that I've described. I want to create a package and add it to a disk image so I can distribute my great new version of TextEdit. Now, this is within Xcode. And the three AM workflow model view controller classes we used to create it have been added to the Automator framework so that you can use them within your own applications to do the same integration. Now, those of you with good eyes may be able to determine another great new Automator 2 feature, workflow variables.

Those blue tokens in the text fields in both actions are, in fact, workflow variables. Variables are an efficient way to avoid repetitive data entry and pass information into and between actions outside of the normal data flow. And they're even more powerful when combined with application integration, as they are here, because the two variables I'm using, product name and product version, are defined and set by Xcode based on information that it possesses about my project. So I don't need to reconfigure this workflow when I want to run it against some other great application I'm writing.

And in fact, your applications can define new variables that make sense within your application so that your users can create more powerful workflows. And what we've found is when you make it easier for customers to integrate your application into automation, you've made loyal customers. They will not want to go back to doing things by hand. So let me show you how this works. Well, in fact, I think my title in my package should really have the product version as well. So I can use type completion to add it into my title.

And let's go ahead and run it. So we'll see the workflow run. And if all goes well and the demo gods are with me, the package and the disk image appear on my desktop. And the disk image is mounted. So let's go ahead and open that disk image up. And as you can see, all the name and version information are on my package and disk image. And when I open my package up in installer, I see that the name and version are there as well. So the combination of application integration and variables give me a powerful solution to make my boss aware of all my hard work.

Let me clean this up a bit before moving on. So far I've talked about variables making your workflows more efficient. And I've talked about the new AM workflow classes making it possible to have Automator everywhere. But I haven't talked about making workflows easier. Well, I'm glad that you liked what Jeff showed you in X-Ray's master track in terms of UI recording, because we think it's great. We agree with that. We thought it was so cool that we wanted to build it into Automator as well. So let me show you what that looks like.

you might be able to see the new record button in Automator's toolbar. And when I click that button, Automator will begin recording my interactions with the OS and its applications and encapsulating them in a new Automator action called Watch Me Do. And I'd love to show it to you. So let me just make a simple recording using our friend Xcode. I'm going to switch the build configuration. Build and go, text edit.

type something in and then quit and dismiss the dialogue and then stop my recording. Let me zoom in so you can see that a little bit better. You can see within Watch Me Do, each event is recorded separately in a nicely graphical way so that you'll be able to tell what the heck this recording is six months later when you look at it again.

And let me show you the playback. Let me reset our state here just so I can also do my no hands on the keyboard. So I've already talked about scriptability and automatability, but I haven't talked about accessibility any further. And as has already been mentioned today, as Steve's Leopard feature number seven, the new universal access features, as well as the spotlight within your application to find and help users find what they're looking for to control your application. X-Ray's Master Track and Watch Me Do all depend on your applications being thoroughly accessible. There's now a huge payoff beyond the obvious benefits for making your application thoroughly accessible.

So Otto is jumping for joy. The workflow is completed. And also to remind me that there's one more cool thing about Watch Me Do, if I select all my events, I can copy and paste these into Script Editor or simply drag them out into Automator and translate them into the equivalent GUI scripting code.

I'm glad you like it. So then you can configure them further to your heart's content. So now that I've motivated you to make your applications accessible, scriptable, and automatable, I hope to see all of you in the sessions later this week that will help you do just that with your applications. Thanks very much. Thanks, Todd.

Automator 2. Watch me do. Make it easier. Anyone now can use Automator. Workflow variables for the more professional, more experienced users. AM Workflow. This is for developers, so you can embed Automator in your application, a framework that's accessible. AM Workflow View, AM Workflow Controller, AM Workflow Model. Nice Cocoa Apps.

Scriptability. We've talked a lot about scriptability. And one of the big parts here is how can we make it easier for you to use all these capabilities? Obviously, you could write Apple Script, but can you actually use scripts from other applications, applications like FrontRow, for example, use scriptability? And so we've developed a feature we call Scripting Bridge to make it even easier to develop applications that drive other applications. So what's the model here. Well, here it is, your application, and you want to talk to iTunes and get the current song.

Well, you could write AppleScript, very straightforward, and you simply tell app iTunes to get the name of the current track. It's that simple. Now, learning AppleScript, of course, yeah, well, it looks a little weird. It doesn't look like a programming language. It's supposed to be kind of English-like, and it is. And it's very simple. You can actually take this code and you can embed it into your application using Common Class and as AppleScript. And it's just that easy to do. But this is not very popular. One of the big reasons why it's not very popular is now you have to know both AppleScript and Objective-C to do it. And as well, it's kind of slow. It's kind of slow. It takes about a second for the AppleScript interpreter to start up and for that machinery to work. Now, there is a faster way. Very experienced people know about this. And it's called NSApple Event Descriptor.

And it's kind of hard and ugly to use, because you have to know all the four character codes, and you write them like that. And people actually do this because it's faster. But you're generating the raw Apple events. And that's a straightforward way to do it. But even though this is faster, people don't often do it because it's kind of, well, obvious reasons.

There is a third way, and we call it Scripting Bridge. And what Scripting Bridge is, we're going to give you a tool to simply run it against any Apple Script dictionary, against any application that has an Apple Script capabilities. And it's going to generate for you a set of Cocoa classes, and it's just that. That's the code there to get the current song from iTunes. It's that simple, those two lines.

But the best part is the performance. It's not just simple. It's also extremely performant. It's 80 times faster than Apple Script. That's ScriptingBridge. I think you're going to love it, and I really encourage you to use this. I think it makes every application that's scriptable into part of a service that you can use, and I think you're going to really like it. Switching gears slightly, let's talk about a couple of open-source projects and a little bit of things that we've been doing on the horizon.

And many people have heard about this technology we're working on in-house called LLVM. It's a compiler framework. It's a new back-end for GCC. It uses the same front-end as GCC. And we're using it ourselves. exploring different capabilities of it. It has a just-in-time compiler, kind of like Java does, but for the C class of languages, C-flavored languages. And we've used this with OpenGL. It's part of the OpenGL pipeline that's in Leopard, and it's been extremely wonderful to use. Essentially, as part of the pipeline, for a given scene that pulls together a number of different functions and raster operations and vector operations and so on, they get specialized dynamically on the fly. What that means is, so for example, if there's a feature like fog, right, fog, that your image doesn't use, that is often a very computationally intensive. And there's a lot of places in the pipeline code where that would be executed, where the scene generation and utility actually would leverage that. And what LLVM does is it takes the bytecodes that assemble, this compiler representation intermediate form, at runtime and optimizes it away. So essentially, we're making a bit of the compiler part of the runtime. We're going to be exploring different uses of this technology. So that's LLVM, and it's available as well for you to explore on the website at LLVM.org, a bit of an interesting open source technology.

Another technology that I know you're going to love, well, another bit of interesting technology, Spotlight. Now, there are many programming languages, not just the ones that Apple supports. And we provide you with a number of importers for Spotlight, but not for every language. And we've been looking around for some better indexing technology to use with Xcode. So we've been looking around, and we found one.

It's called Doxygen. And Doxygen is an open source indexing package. And we found a number of incredible and important benefits to it, which I think the best way to look at it is just for a demo again, to see the Spotlight integration. So I'd like to invite Brent Shank to give us a demo. Brent Shank: Thanks, Ed.

As Ted said, we're using Doxygen to power the new Spotlight source code importer that will ship with Leopard GM and Xcode 3.0. Why are we using Doxygen? Well, we're using it because it supports all your favorite languages. It supports C++, Objective-C, and your favorite scripting languages too, like Perl and Ruby. And we've been working really closely with the Doxygen developer to get this feature off the ground, so we'd like to thank him for all his help. So what benefit does this give you as a user of Xcode? Well, I'll be happy to show you right now.

I'm going to launch Xcode, and I'm going to open Osiris. Andreas showed you this project before. It's a large open source project. It has thousands of source files. I'll show you it has over 700 CC files. if I have the right thing selected. It has a number of Objective-C files.

So this is a fairly big project. And if I were to perform a full text search in XCAD, it would probably take longer than I wanted to. And I'd go get a cup of coffee, which is OK, because I love coffee. But you'll notice there's a fourth search option here. It's called Spotlight Symbol Find. And I'm going to enter a search string here.

Hit return. And before I can even tell you that it's going to search the spotlight index and give me a list of results, it searched every single source file in this project and returned 126 hits. And you can see-- I click on the search results. They look just like search results from doing a full text search do. They take me right to the place in the source file where that symbol exists. I can search for some other things. And again, it's a super fast search. As we like to say, searching for symbols in Xcode now is not just going to be fast, it's going to be spotlight fast. We think you're really going to love it.

So I'll show you one more thing this enables us to do. So in Xcode, you can define your own find set. And you usually do this if you have some source files that are outside of the directory of the current project you're working in. A lot of developers do this if they have big header search paths that point to directories with lots of header files. So you open the batch find options window in Xcode, and you can define your own set, point it to a directory. And then when you go back into the Find panel, the search will actually be performed on-- the source files that are outside of your project. So all these hits are outside of the scope of the current project. Thank you.

So what I'm showing you now is not on the Leopard seed that you got today, but it's something we're going to ship with Leopard GM. There's one more thing, one surprise that's also not on the Developer Seed, but we know you're going to love it. I'd like to show it to you now.

And we call it Workspace. And what this is, this is a really-- I'll close my project here-- this is a really lightweight way to use Xcode. So when you don't want all the complexity of an Xcode project, and you want to organize arbitrary kinds of files, this is a really great feature. So I'm going to add the drag and drop outline view example, since I've been doing a lot with outline views. And you can see it shows me all the source files in the project.

I can load them over here. And now I get all the benefits of Xcode's full-featured editor, but without the overhead and complexity of a project. And I can also display and edit other types of files, too. So this is another feature that we're really excited to provide to you in the GM version of Excavator that ships with Leopard. Thank you.

So Spotlight integration, Doxygen, really working to improve the speed and fidelity and capabilities, really, of Xcode even in a project-less session. I've been holding out on you, the fifth column here. What is that fifth column? And that fifth column is fun, right? So how can we have fun? I mean, programming isn't just about improving our productivity, but it's also about enjoying what we do. And you saw a demo-- you saw a quick-- Scott introduced it this morning, a great new tool we call Dash Code, and I want to demo it for you now. Dash Code is Apple's own complete widget development environment. It really is an incredible, fun way, I think, to introduce people to programming, but as well to get interesting things done in no time at all. It has some great templates, as Scott said, a visual designer, reusable parts library, a code editor, and a JavaScript debugger. And I think you're going to really enjoy it. So let's give you a demo of-- Is it this one? Yeah. So this is a little demo I cooked up this morning.

So as you can see, there's a number of templates. Wish I had time to show them all to you today. Maybe to create RSS widgets is what I'm going to show you right now. But you can create a countdown timer and use photo casts. Great way to link into Quartz Composer and so on. So let's just do that right now. And what you see here is a visual designer. On the left-hand side is the document object model. Expand that down. Different attributes.

The lower left here are little guides just to walk you through. And what it's telling me is to provide an RSS feed. So let's start up Safari. I'm just going to drag it over. And really, no typing. Vice presidents can't be expected to type. Bam, I've got myself a little RSS feed widget. It's that simple.

And you say, OK, Ted, that's great. Wonderful that you can build widgets pre-canned. What can you do that doesn't look like it? So let's modify things. things up a little bit. And I'm going to throw away some of these nice components. And just leave up the image and content area.

Now I'm going to select and open up in the inspector and just tell it to hide the content. So now I've got a kind of an empty canvas here. Make it a little bit bigger and bring up my parts library. And... And let's scroll down and see all the familiar kinds of components. And I'm going to pick a gauge up and just drop it there. And now let's resize the gauge out.

Nice and big, so everybody can see it even in the back of the room. Now, let's decorate it a little bit. And we have a bit of a competition always at Apple about which is bigger today, iPod or Mac. Well, Mac is bigger image, but let's just scale it to size. Now I'm going to show you the source code editor. And here it is, kind of Xcode-like, simple pop-up of all the functions. And now let's look up and move that.

And I'm going to drop a few lines of code, something that just searches through the different RSS entries, looking for the words iPod and Mac, and counting. Let's run it, see what happens. And it hit an exception, a null value. Let's take a look at the run log. And it brings me, of course, right to the error line.

And I noticed that, in fact, document get there. There's no document get. It's document get element. So let's go. And I don't want to type. Type the one letter E. Element by ID. Complete that. Let's stop and run it again. Did I lose my network feed? Oh, pod, Mac.

Well, you know what, I'm going to hard code in which one's better today. Since demo gods don't love me. Yes. Just so that you can see some pretty colors, because nobody likes to see a gray dial. Stop. Run. Ha ha. No, it still doesn't love me. View. Run log. I'm going to debug this right on the fly. It's going to make everybody necessary. Ha ha ha ha. I notice. Oh.

Mac is better. So you can see very simple, straightforward way, lots of capabilities, debugger very powerful, and lots of great stuff. So that's Dashcode. I think you're gonna love it. It's a great to build widgets and I think other interesting things. Let's go back to the slides. So, all the tools you need, scalability, productivity, interoperability, performance, and to have fun, all the way from Xcode, interface builder, automator, X-ray, dash code. Lots and lots of other capabilities I've barely begun to scratch the surface on. And really, I think the innovation that the Mac OS X developers and developer teams has really is unique and really pushing the envelope of what I think the capabilities are. And I think you're going to love it. So that's our developer tool lineup for Positron. And as they're setting up, what's our surprise? What's our surprise?

So given how heroic you've all been in these difficult-- making the Intel transition and creating all these wonderful applications, we thought we would thank you. And of course, the best way to thank a hero is with a song. So I'd like to invite up James Dempsey and the Breakpoints Up.

Thank you, Ted. So in the past, I've done a song or two at WWDC. And this year, I brought along some reinforcements. So I'd like to introduce to you the breakpoints on guitar is Mr. Gordy Friedman. And as always, on keyboard, Mr. Victor Alexander. So over the past year, there's been an amazing transition to universal binaries. And I was thinking a little bit about some of the technical nuances involved. I wrote a little song that I hope you all enjoy. It's a little tune called "Indian Reservations." Hit it.

Well, you might have some Indian reservations over bit flipping, head tripping, complications. Getting it right, however everybody's interpreted. ♪ 'Cause if your processor changed ♪ ♪ You might not keep things arranged ♪ ♪ Like the last one did ♪ ♪ Well, eight bits make up a byte ♪ ♪ Each bit is active or it slumbers ♪ ♪ But eight is not enough to represent the larger numbers ♪ ♪ So bytes are strung together now ♪ ♪ In twos and fours and eights ♪ ♪ Each byte contains a portion ♪ ♪ Of the represented state ♪ ♪ The rights is insignificant ♪ ♪ But some also than others ♪ ♪ Each is more or less significant ♪ ♪ Than its sisters and brothers ♪ ♪ So do you star them least to most ♪ ♪ Or range them most to least ♪ ♪ It's this order and conundrum ♪ ♪ That's the nature of the beast ♪ ♪ I said you might have some Indian reservations ♪ ♪ Over network of by and order ♪ situations, what can transpire, pulling bits off the wire, as you will at ease.

Your code could give up the ghosts without them networked to host-type utilities. ♪ Oh, my processor says potato ♪ ♪ Yours says potato ♪ ♪ Oh, two different patterns represent the same data ♪ ♪ One puts significance first ♪ ♪ The other saves it for later ♪ ♪ The most annoying switcheroo since Anakin became Vader ♪ ♪ Well, you might have some Indian reservations over file or format specifications. What is the risk dealing with files on disk is what you want to know.

The file header should mention, or it's simply convention, how the bytes should go. Well, do you have to break this code or has someone else cracked it? You can use an API that's already abstracted. Your development schedule won't be greatly impacted. Then you can blog about it like some guy on.mac did.

Well, you dealt with your Andy Young reservations, all the bite swapping, flip flopping permutations, fixed every goof, made your coat bulletproof, ♪ And so forever it bites ♪ you had to reverse and for any late night that made you muttering curse we'd like to thank you for making your app universally available and that's all thank you And thank you. Have a great conference.