And we've been working very hard to make Mac OS X worthy for your creativity and your innovation. 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 into 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? Do 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. 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? 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 to 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. And the whole universal architecture, universal binaries, all the other products and technologies. to make that as convenient as possible.

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.

But 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 call 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. It really depends upon the scale and the amount of code. you have.

and today, 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 a very, 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 a lot of data. It's a 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, and 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 the very important part of that is really a more productive programming language. And really, it means about solving problems faster.

So it's the tools and the programming language together. Working 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? It 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, there's a lot of tech-- 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 Bertrand talk this morning about garbage collection. There's two other important features I'm going to 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, Ted. Hi, there.

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 6 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 with all the 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, 6 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. Thank you. 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 some 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 on the 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, right? 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've 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. 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 for just simply removing bugs. But let's take a look. So this is a simple setter and getter. Implementation, the kind of thing you write pretty frequently in object-oriented languages. And one of the great things about garbage collection is we just make that go away, make away all the retained 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 retained count part of your programming. Now, you can still leave in the retains and releases, but in the end, you're going to have to do a lot more. 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, so that, and it calls the methods 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. 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 Wendker up, the Xcode ID manager, up to give us a demo.

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's 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, 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.

Thank you. 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 code folding 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 a 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 failure 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, you found a loop with an 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 snapshotting, we believe, 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 with NLeopard. 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. You can look at just the common controls, the controllers. Or 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 yeah, 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 that I can still reach objects.

So as you can see, I 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 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. Um, actually, what did I do? Let me just give me a second to just 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.

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 so the new one here, which is the place that 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, Okay, 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 won'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 in 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, right, 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 kind of a bunch of feedback is that you want to use these two tastes.

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.

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, you're going to see a lot of different behavior. It's going to love 64-bit, obviously. But really, even parsers and crunching applications like 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 is going to be the best. 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?

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

It's a new tool that's been released 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, a better demo is worth a thousand words. I'll bring up Jeff Glasson, manager of performance tools. Thanks, Ted. Thank you.

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 XRay. Now what XRay 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. Object ALEC and network traffic monitor. And actually, let's make some more room here. Make the window a little bigger. Oops. 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 object instrument is configured to show you a graph of memory being used by your program.

The network traffic 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 tool tips. 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 TextEdit is the one that I've created myself to help me monitor and performance tune TextEdit. 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 D-Trace 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 this is going 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 independently.

They're all 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. 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 is great.

Here it is. If you can make your app accessible, all these kinds of applications, and another one you'll see in a minute, become part of the interoperability of your app. 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 released Automator.

And Automator, very powerful, wonderful feature. Let's talk about Automator. This little guy has been a big success. 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. We've been thinking about, now, how can we improve this? 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 Automator 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. 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 continue 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 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 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 and workflow. This is for developers so you can embed Automator in your application, a framework that's accessible. And workflow view and workflow controller and 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 Apple Script, very straightforward, and you simply tell app iTunes to get the name of the current track. It's that simple.

Now, learning Apple Script, 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 Apple Script. And it's just that easy to do. But this is not very popular. And one of the big reasons why it's not very popular is now you have to know both Apple Script 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 Apple Script 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 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 Scripting Bridge. 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 in ourselves. We're 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 we've been working on this for a long time. And we're working on this for a long time. And we're working on this for a long time. And we're working on this for a long time. And we're working on this for a long time. And we're working on this for a long time. And we're working on this for a long time.

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. And 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 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. 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 up to give us a demo. Thanks, Ted.

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

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.

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. The search will actually be performed on--

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 source code 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 Xcode that ships with Leopard. Thank you.

So spotlight integration, Doxygen, really working to improve the speed and fidelity and capabilities really of Xcode 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 Dashcode. And I want to demo for you now. Dashcode 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.

And I think it's going to be a great tool for you to use in no time at all. It has some great templates, as Scott said, a visual designer, a 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 Dashcode.

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

Now you say, OK, Ted, that's great. You know, wonderful that you can build widgets pre-canned. What can you do that doesn't look like it? So let's modify things. Clean 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. Okay, 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.

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. and David Davis. Just so that you can see some pretty colors because nobody likes to see a gray dial. Go, stop, run. Ha ha. No, 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.

Mac is better. So you can see very simple, straightforward way, lots of capabilities. Bugger very powerful and lots of great stuff. So that's Xcode. I think you're going to love it. It's great to build widgets and I think other interesting things. Let's go back to 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."

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

♪ I said you might have some Indian reservations over network of byte order ♪

Your code could give up the ghosts without them network 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 .macdiv. Well, you dealt with your Andean reservations. All the byte swapping, flip-flopping permutations. Fixed every goof, made your code bulletproof.