Good afternoon. In the history of the Macintosh operating system, there are some defining moments. One of those moments was of course 1984, with the release of the first Macintosh. I'm sure everyone here is really fond of that little black and white screen. If you look carefully, you'll see all the sizes for folders expressed for disk sizes expressed in kilobytes. We've gone quite a ways over the last two decades. Now there's another moment that's very dear to my heart, which is 2001, when we released the first version of Mac OS X, version 10.0.

It already had all the elements you are now familiar with: the Aqua user interface and the strong Unix underpinnings. The reception has been fantastic, from our users and from you, who have brought thousands of applications to the platform. So we felt it was time, last year at the developers conference, to symbolically bury Mac OS 9.

and that meant that for development purposes, Mac OS X life was over. It was time to move on to X. And a few months after the developers conference last year, we released Jaguar, which was probably the most or one of the most successful OS releases Apple has ever had in its history. There were lots of features in Jaguar. Some were brand new, revolutionary features and some were just evolution. We're committed to constantly improving all our components. So now we're moving towards Panfer. So what's in store for Panfer?

Now, the basics of mobility, of course, is great portables. And we are happy because we have the best portables in the industry. We introduced at the beginning of the year the 12-inch, the 17-inch, fantastic portables. But of course, what you're interested in more is what's inside those things. So this is an X-ray. This is what's really inside one of those portables.

So if you notice at the top of that X-ray, there's kind of a funny-looking bent piece of metal. That's the antenna. We've been, of course, the leaders in wireless technology. First, with 802.11b, the airport, 11 megabits, of course. And more recently, at the beginning of the year, with 802.11g, which goes to 54 megabit. That's what we call export-- airport extreme.

We are also adding, for Panther, 802.11x. Now, the whole naming of those things is a little confusing, all those bizarre letters that are added after numbers. 802.11x is actually not just a wireless protocol. It's an authentication protocol that can be used for all networking. And this is where we put it in the system, at the place where it should be, so that all networking can leverage 802.11x.

Okay, so let's go back to that picture of the portable and let's focus on the modem port and the ethernet port and the antenna again. All those things together are networking ports. So networking is a big focus of what we do. There's a lot of resources that go into doing networking right. And that's really hard because networking is fundamentally very hard. There's a joke that networking is only one letter away from not working.

And that's really true. And when you do the rehearsals for this show and you have all kinds of networking problems, the routers that explode and all that stuff, you realize networking is really, really hard. So because it's so hard, we make it a system service so that if your application is a document centric application, it should not have any networking code. We do the networking code. So we have a number of new features in Panfers that your application can leverage.

We're adding IPv6, IPsec, and based on IPsec, we're adding VPN that I'm sure a lot of you who are in corporate environments will enjoy. 802NX, I already mentioned. And something that your application may actually want to use is what we call the advanced reachability API. Let's say your application depends on the server as a whole. And one way to make sure that the service you depend on is there is to ask every second, every minute.

You just poll and ask. This is terrible. This is polling. This is really bad for a number of reasons. So what we have provided is a reachability API where you can say, hey, I'm interested in this server. Call me back when the reachability change, whether the server becomes reachable or not reachable. And one thing which is fantastic is that we know exactly-- the reachability because we are working as a lowest layer here.

So I already mentioned that networking is hard, and this is BSD networking at the lowest level is very tricky. And so what we did is we put a layer on top of the raw BSD networking that we call CF network that abstracts some of the difficulty away. And it's an abstraction to support a number of protocols, sockets, DNS, all the common protocols that you use in your application. It's also a layer that really meshes well with your application because all the data types that you use in your application are the same data types that are provided by CF network.

So you have a bag of byte, you have a string, and also it meshes with the event loop, the run loop of your application. So the--all the events coming from CF network are just events that all get merged together in this run loop and that gets redistributed to-- wherever you want in your application.

We added some new functionality for CF Network in Panfer. We have a new host concept and that's where you can do DNS lookups all asynchronous and that's also where the reachability plugs in. So CF network is definitely easier. It's also fast. Now, why do I say fast? Well, we use it. We use it in key applications that are fast.

If you look, for example, at Safari, the speed derives from the rendering engine, of course, but also from very fast networking. All the networking in Safari is done with CF network. That's how we make sure that what we do is really good. And all the other applications presented here to use CF Network.

Okay, so let's go back to that picture and let's focus on another interesting rectangle down there and that's the hard drive. That's the storage for your computer. Now with mobility, you have new problems with your storage. The first problem that you have is disconnecting because let's say you access the server, an NFS server, an SMB server, an AFP server. Now you close the lid and move to another location, you may not have access to the servers. So what we are doing in Pantfa is putting some effort into file system mobility to facilitate disconnection and reconnection.

So the AFP is--the AFP client is now reconnecting when you move to another locale. Now in an industry first, our NFS also supports mobility. This is for all of you who have been using NFS, this is really industry first. I mean you--usually when you connect with NFS, you are stuck, okay. And you move to another location where that server is not accessible, you have the spinning wheel forever.

So another problem that you have with mobility and storage is that you're going to evolve the storage on your computer. You're going to work on a number of documents that you have locally. Now, at some point, you want to bring those documents back to the rest of the world. And so you have this thinking problem.

Now, this goes both ways. The rest of the world also evolves, and you may have some caches of the rest of the world or some documents from the rest of the world, and they are still, when you reconnect after your airplane travel. So that's why we have, over the last year, developed new syncing technologies to help this mobility story, to help the whole mobility problem area. So we started at the end of last year with addresses syncing, calendar information syncing.

We added just a few weeks ago bookmarks syncing for those of you who have .Mac and have several computers. Now, you can keep the bookmarks. So, you can keep the bookmarks on each computer the same. It's really a lifesaver for me. Now, new in Pantfor, and this was touched upon this morning, we're adding file syncing with the iDisk syncing that enables you to keep the iDisk the same on all your computers.

Okay, so let's go back to that picture and there's those bizarre cylinders down there. What are they? Well, those are all the weights that you carry when you carry your portable. That's where most of the mass is. We're in the land of physics here. That's your energy source. So there's an interesting equation. This is the biggest equation I have in the presentation, by the way. I won't go any further than that, which says that if you compute more, you consume more energy.

Any registered transfer that you do is going to eat a little bit of that battery. So the more you compute, the more battery you eat, the more energy you consume. The same thing goes with the frequencies. Actually, roughly the square of the frequency. So if you compute very fast, you are going to consume a lot more of the battery than if you compute slowly. So what can we do about that?

Well, if you look at that frequency term first, the first thing that we can do is slow down the OS when it's not needed to go very fast. And so we do that. Okay. We have this low power mode where we just don't consume too much energy and we slow down the processor. We power step back. Now let's look at the other term. That's the computation.

And of course, you want to get rid of all unneeded power. So you can use the rich ability API to avoid that computation. Now, there's sometimes some computations that are needed. For example, polling to have that server to know whether that server is online or not. That's not needed. You can use a rich ability API to avoid that computation. So to summarize how to save that battery, you should minimize the computation, be even driven, and above all, no polling.

Okay, so there's a number of recipes here to be a great citizen for mobility. You should adopt all the system services that we provide as the lowest layer for system networking. You should use APIs like the reachability API if that applies. You can program at a higher level using CF network. You can performance tune by having things more synchronous, more even driven, more on demand.

You can use threading because we have a modern operating system that supports threading in the networking intrinsically. And you can be more even driven. If you do all that, you will reach the nirvana for mobility which for me is cafe computing. Okay, so that was mobility. Now, what are you going to do with all this mobility?

Reaching people is one of the activities that we do the most on our computers nowadays, which is fantastic. It's human-centric computing. So we added a key technology to reaching people, and that's Rendezvous. Rendezvous enables you to discover your neighbors. It's auto-discovery, it's brassibility of the people nearby in the networking sense. Now, Rendezvous is totally compatible with existing hardware and software. You don't need to change your routers or anything like that. It's all based on standard networking. It's all based on TCP IP and DNS. It's fundamentally a new way to use DNS and to build upon that.

Rendezvous, of course, is modern and supports human-readable names, not 8-character limit or anything like that. And it's a key to ad-hoc networking. When you don't have a sysadmin that's going to hook up everything just right and give all the IP addresses and put everything in control and all that stuff. When you just have totally ad-hoc, you just plug in like here in this conference. This is ad-hoc networking and Rendezvous is fantastic in those situations.

Now, what's very pleasing is that we released Rendezvous last year with Jaguar. We had adopted it in a number of applications. This year we are using Rendezvous even more. We enhance some of those applications to leverage even more Rendezvous and we're adding new applications into the mix. But beyond the adoption, one thing that is really making me happy is the innovation that has taken place with Rendezvous.

And that innovation comes from you. It comes in different forms. For example, you have printers that have adopted Rendezvous. You have games, multiplayer games that are using Rendezvous. You have some devices and you have some brand new way to do collaboration using Rendezvous. And that's very exciting to me.

So Rendezvous is fantastic to find out who your neighbors are or to communicate with your neighbors. But there are times where you want to reach someone who's not nearby. And that's when the address book comes handy. So the address book is an application we've invested a lot of effort to make it just right. And the address book, of course, manages all your addresses. Now, we have a number of applications that use the same addresses.

And as time goes, we put more and more applications that go to the same storage. Fundamentally, the address book is an application that uses a database that's underneath. And the key here is a database. The application is fantastic, but it's on top of the database. That database has a number of APIs that you can use for your application. We consider that the repository of addresses is a system service that we provide for all your applications.

We want this to become the hub for all the communication-centric applications. And we are doing a lot of refinements in Panfor. We are improving the API, adding some functionality that has been requested here and there. One of the functionalities that we add is what we call the action plugin.

So let me set this example. Let's say I want to call this person. I have his address card there. And now I need to reach the phone to call that person. The problem is that I don't have the phone. I know that my screen is over there. My phone is over there.

So I can just click at the right place. And now I can enlarge the phone. And now I can type the phone. So this is a functionality that we've added to the address book. And that functionality is using the action plugin. And it's available for all of you to specify for your data type how you want to have-- what action you want to have happen for that data type.

Another functionality we've added is what we call the People Picker, which enables you to filter the database of all addresses and select and let the user select which address they want to have. And then that selection is available through your API. Okay, so your application can definitely, in many cases, use those two fundamental technologies, Rendezvous and Address Book. And that's reaching people, one of the activities we do the most on our computers. Now let's change the beat.

So this is my techno session. That's really Unix that I want to talk about. So we have now Mac OS X totally based on Unix. This was a bold move and we wanted to let the world know about that so we ran this ad a year ago telling everyone, "Hey, we are Unix-based." Why would we choose Unix? For a number of obvious reasons. Unix is very, very solid. Unix is powering the internet. Most of the servers out there, the internet servers, are running Unix computers. So that's kind of a testimony of how solid it is.

It's very mainstream. There's no doubt that you hear talk about Unix every day nowadays. It's quite interesting. It was, for us, the fastest way to get to a number of features. No other place we could have gotten a networking stack that has thousands of engineering years put into it in terms of tuning, in terms of being standard compliant, all those things. In fact, networking is defined on Unix in general.

And this was also a way for us to attack new markets, markets where Apple traditionally had not been particularly strong and now that we can go towards. So with the great mobility that we have, we have now a dream machine for Unix folks. It's a portable that you can take on your conference calls. You can do presentation because you get all the standard software, all the productivity software.

You get PowerPoint but also now Keynote, of course. And you also have Word, you know, all those things that all of us use daily. And so some people are really liking it. And if you look carefully at that picture, that's James Gosling of JavaFame who, of course, is using a PowerBook.

So our Unix is very, very standard. We are a very good Unix citizen. In fact, if you work to a bookstore and you look at some titles, you will see titles like this that all apply to our platform. So is it perfect? Well, we always get a lot of feedback.

There's always kind of requests. And even though everyone is telling us, yes, it's really a good citizen, I mean, I was very surprised to find everything I would expect. So it's always the top of the list. And the top of the list for us was X11. So X11 is a toolbox, a windowing toolkit that is very ubiquitous in the Unix world.

I think X11 has been ported on all the machines, all the Unix machines in the world. And if you go to the scientific areas, you find applications that are programmed to X11, something for higher end. So we've integrated X11 right into Panfur. And by integration, I mean that rather than having one big window that has all your X11 applications kind of inside that window, now you can have X11 applications that have windows that mix with other windows from all the Cocoa apps, all the Carbon apps. So fully integrated with Quartz.

Another thing that was heavily invested is to have really, really fast X11. And especially for doing OpenGL functionality because a lot of the scientific apps do use OpenGL. And so those applications didn't want some insulation layer with OpenGL. They wanted to go down to the metal. And this is what we have done. When your application uses--your X11 application uses OpenGL, it's a native OpenGL.

Now let's talk about standards. So another request that we have constantly is to add things, to add little things here and there. And one of the top requests after X11 was to add a great XML parser. So we've looked around and we asked a lot of people what's the best XML parser that we could add. And pretty much the consensus that has formed is libxml2. So this is what we're adding in Pound4.

Another place where we had some requests was for locales, and we added ICU, the international components for Unicode. We're adding WTRT, which also was heavily requested to help you port applications to Mac OS X and a few others. And of course, there's a constant refresh. We are committed to constantly refresh all the Unix components that need to be refreshed.

One of those things on the list, on the refresh list, is UFS, and that brings me into file systems. We added journaling to the file system last year for the server. Now in Panther, it is a standard. All Panther systems, by default, will have a journaling file system. This is taking the high-end technology and making it available for everyone. We added NFS locking. Quite frankly, it was a shame that we didn't do locking. We fixed that.

We added mobility for the file systems, as I already mentioned, and we've had a lot of emphasis on performance. Performance of the remote file systems like SMB, NFS, and WebDAV, but also performance of UFS. Now for those of you who use UFS, you are pretty much at parity with HFS+, which is quite a feat.

Okay, so I'd like to digress a little bit and talk to you about architecture. I've been architecting systems or being involved with architecting systems for over two decades now. And I've realized over the last few years that I'm kind of part of the old school of design. So what do I mean by old school?

Oops. OK. So I started to realize a few years ago that that's kind of the old way to do design. Let's say you have like a subsystem to architect. The first thing in the old school that you do is really try to get to the essence of the problem.

And you create this wonderful engine that's going to just address the problems, you know, the core problems. So you design this engine and the API, of course, that you have on top of the engine for all the applications. And you spend a lot of design work there. Now, there's some books that says, hey, you should do top-down design, all that stuff. But we all know that it's both top-down and bottoms-up. You actually write some code along the way. And then you verify your assumptions are correct and all that stuff. But essentially, this is the design phase.

After that, you write a lot of code. And that can take months because it's brand new piece of code. And so we all know that every 10 lines or so, you make a mistake. And you have to debug, find that mistake. And even with something like Xcode, it can take a bit of time.

So then you have this system that's perfect. OK. You have it just perfectly integrated to your system. You are very happy with it. And you say, well, now I need to connect to the rest of the world. That's really ugly because the rest of the world has all those legacy systems. There's those standards you need to connect to. And that's where you need to write adapter code. This is tasteless. And you write all those adapter codes. And finally, you have the systems that works well for your system and that integrates with the rest of the world.

Now, I think there's a new way to do that. And the new way is open source. So how does that go with the new way? The first thing you do is you go shopping. This is very bizarre. You just go shopping. The problems that you are trying to solve probably has been solved by quite a lot of folks in the past. So you try to identify those bodies of code that solve the same problems that you are trying to solve. And you evaluate those bodies of code. You evaluate them looking at the speed of those bodies of code. You look at the standardness. Are they standard compliant?

And this is the most bizarre of all things. You look at the reputation. They're not the same reputation that they have on the net. This is really like shopping. So the next thing that you do is you write adapters to your system. So this is kind of the reverse of the previous picture. The piece of code that you have is totally standard. It totally fits with the rest of the world. Now you are trying to adapt it to your system. So maybe your system has a different UI. Maybe your system has an Aqua user interface.

That's where you will write some code to adapt it to your system. Now this is not necessarily a bad thing because you are actually going to add value. There are some examples that can come to mind there where you add value by making this fantastic user interface on top of this engine that was an open source engine. And the last step, which is very important, is to advocate your changes with the community. You don't want to be on a diverging branch of evolution because guess what?

The rest of the world will win, not you. And so you want to make sure you are all converged. And the best way to advocate your changes is to make sure that you have value in your changes. You don't want to do like crazy renaming of variables and changing everything. No, no, no. That won't work. You want to do the minimal amount of code that adds value.

So what are the advantages of this approach? Obviously, this is time to market. You no longer have the downtime of going away for a few months and writing all this new code. Also, it's a lot more reliable, which sometimes may be misunderstood, but the open source code is actually very reliable, and this has been proven in our experience.

We've done that with lots and lots of bodies of code, and typically, the open source code has way less bugs than the new code that we write, because the new code that we write is new. There's no secret here. It is also very secure, very important in this modern age. If the code is not open source, hey, it's closed. It's not secure. That's pretty much always true.

And there's a social aspect of this which I personally like, which is this two-way exchange with the community. You get some, you give some back. So we are using this strategy, of course, in Mac OS X. We've used that in Jaguar for a number of components. And we are doing that for more and more components.

I just listed a few here. One of the most noticeable in this list is, of course, KHTML, which is the rendering engine of Safari. But there's many more. In fact, you go to any group at Apple, and pretty much every group is incorporating open source one from another.

Okay, so in summary with your application and Unix, first, if your application has been running on Unix forever but not on Mac OS X, bring it. Join the party. This is the place where things happen. And it's easy to port your application to Mac OS X because Mac OS X is very, very standard.

We've got all the facilities that you want to help you port. Now conversely, if your application has been running on the Mac forever, now you have some new markets where you can expand. You can go to the scientific market. You can go to the higher ed, to the enterprise market. And the two sides can come in.

There's some technologies that are long time Mac OS technologies or technologies in your application and there's some technologies that come from the Unix world. There's new synergies to explore there. And think about incorporating open source. This can save us quite a lot of time and you end up with a better product in the end. So this was my techno section.

At this point I'd like to thank you to have come from all over the world to San Francisco. And one reason why you may have come here is that you went on the web and saw this enticing video saying "Come here to San Francisco!" And that video of course features Scott Forstal, my friend and colleague, that is going to take over at this point.

So now you know that I only have one nice shirt. This is not an intro for me, this is an intro for Aqua. So we believe Aqua is incredibly sexy and we've worked this year to make it even sexier and we've worked to improve the usability of Mac OS X as a whole. So let's get into it. We started with the open and save panel. Here's the open panel. here's the open down here there's the open now in jaguar A few people didn't think it was the greatest open panel they'd ever seen in the back row.

And we agree. The problem with this open panel is it wasn't user-centric. It wasn't human-centric. It was all about the computer. It was computer-centric. I mean, just to get to your home directory, you're four levels down, right? You're always scrolling back and forth trying to find things. So one thing we did this year is we have this brand new finder, right? A user-centric finder. And inspired by this, we have a brand new open panel as well.

So the open panel has the same left column you see in the finder. You can get to your documents folder, your pictures, anything in your home directory extremely easily. It's right there for you. You can also get to your devices. And really importantly, and I've been using this for a while and I love it, you can get to your removable media, right? So you throw a disk in or you mount a drive. It's right there in your open panel in your face.

Another request we have, which we have for Panther now, is we've added ListView. So-- This view is built in. We also have a path pop-up up there. We have back and forward buttons. So we think you're going to love it. Now we haven't forgotten about how you like to customize the open panel, right? You like to add your own widgets. So we have that as well in an accessory view at the bottom.

So we've done this in a binary compatible way. There's no new APIs you should have to worry about. Your application should just get this much improved open panel when you run it on Panther. Please install the seed you got this morning. Test it out. Let us know if there's any issues because we tried you lots of tricks for those of you who are doing crazy things in your open panels to get your controls in the right place. We think we've done it, but let us know. And of course, we didn't forget about the save panel. So again, we've made it user-centric. We've been asked a lot about that switcher thing. People say, hey, what about that switcher thing?

Not that switcher thing. Although we get asked a lot about that switcher thing also. That switcher thing right there. So we have this view switcher in the finder. And we've decided, you know, it really works well as a control in a number of different places. So we have it in the finder. You notice we have it in iPhoto as well.

We added it to the address book. So we had a lot of requests from people saying, hey, you know, you're using that. And we actually had implemented that ourselves in each of our apps. But it clearly was a nice standard control that you wanted. And so for Panther, it's built into both Carbon and Cocoa. You've got it.

We worked really hard this year to polish Aqua and make it even that much better. Here is Aqua in Jaguar which we thought was great but we knew we could do better and every release we try to refine it and make it even better. The first thing we looked at were those white corduroy lines.

We felt they were a little too strong. In some places, you'd look at a window and if there was text over it, it felt more like an interference pattern than it did like a nice texture. So we went through tons and tons of different background patterns trying to look for something better. I mean, sort of like Thomas Edison going through filaments for a light bulb. We threw each one out. We threw out different materials. We had a mock-up with gold.

And at the end we settled for something which is very, very subtle. You can see it better on your machine when you install it, but here it is. So here's Jaguar Panther. Jaguar Panther. What we've done is we've toned it back. It's very, very subtle. Your eye sort of notices that there's something, there's a texture there, there's something elegant, but it doesn't get in the way of readability of text or other elements. The next thing we looked at were the tabs.

So, you know, these tabs work fine, but the top felt a little bit clunky. And we love the switcher thing we've added to the tool kits. So we looked at that and said, we can start with that and then we can do better. We can make a tab out of that. You notice the tab here also, it's a sheet that sits sort of awkwardly on top of the window. We decided to etch it in. So there's the tabs on Jaguar, there's on Panther. So Jaguar Panther.

I think it's great and the most important thing for all of you is the mantra this year was "Save the same metrics." So this is the exact same metrics as the tab in Jaguar. The content region is the same, the control is the same. You don't need to do anything, you get it for free. The next thing we looked at was the toolbar.

So there's some apps that use the toolbar in a way where it's more of a view switcher. When you click on it, like in System Preferences, it takes you to a given pane. But there's no persistent state in the toolbar in Jaguar to show you where you are. Now there is. So here's Jaguar, here's Panther. Persistent state lets you know where you are. There's an API you can adopt for that if you use the toolbar in that way.

Next we looked at the title bars. The inactive title bar goes translucent. Nice use of quarts, bad use of UI. To find what windows are inactive, you have to sort of look around and say, well, what windows are translucent? And how do you know that? Well, it gets a different color depending on what the background is behind it. You look at the untitled there, and it's a little difficult to read. You get interference, especially if it's over another text document. So we said, okay, we're going to take and make the inactive title bar windows opaque now.

Once you do that, it becomes more difficult to tell what the active title bar is. So we took the active title bar, and we add a nice, simple gradient on top of it. And here it is. There's Jaguar, Panther. Jaguar, Panther. We think you're going to love it.

The next thing we do is panels. So in Jaguar, there's no way for you to tell if a panel is key. Meaning if you hit delete here, is it going to delete a font collection or is it going to delete characters in your text document? Right? There was absolutely no distinction. What we've done in Panther is there's now a key state for your panels.

So here's Jaguar, here's Panther. You can actually tell. And it turns out there's three distinct states now. There's the key state, and this in the panel is now key. There's the document it's acting on, which actually has a little bit of a gradient, but it's a very light gradient, and that's the main window.

And then there's the inactive window in the background. Now, you shouldn't have to worry about this as a developer. The toolkit should handle this for you automatically. Unless you're doing wacky stuff with the toolkits and windows, so you should pay attention to make sure you're not breaking our job of doing this automatically for you. So that's the third state. So here is Aqua in Jaguar, Aqua in Panther. Jaguar, Panther.

So we heard this year that size definitely does matter. And we've reacted to that. You see, we've had our standard controls. And the standard controls-- buttons, sliders, and everything-- work great almost everywhere. I mean, in most usage, you want to use the standard controls. But some places, you want to use small controls because you're creating a palette.

So you want to squeeze a little more into that palette. But we found that in some palettes or pro apps with lots and lots of palettes, you Even with these small controls, it feels a little bit cramped. And so we got requests to have even smaller controls. So new for Panther, we're adding mini controls.

So we still have our standard size controls, our small controls, and now this suite of mini controls. And if you look back at that palette again, here's the palette with the small controls, which looks pretty good. Here's the same palette with mini controls. You can really tighten it up and you save that much space. So if your app is the type that it's a pro app, you have lots of palettes, take advantage of the new mini controls in Panther.

So we're going to help you find what you're looking for in Panther. When we built iTunes, we found that one of the most important elements we added, one of the most important features we built in, was this. It's this great search field. There's three elements to this search field. It's fast, it's incremental, and it's readily accessible. It's right there in the main window.

As we built other applications, like mail, we found the exact same thing. We wanted to have a fast search field, incremental, and right there in the main window. Address book. Fast, incremental, right there in the main window. iCal has the same thing, as does the new Finder, right? It's one of the really important features of the new Finder.

The new font book. Great search field built right in. Even Xcode is really built around having great search built right in. We found this wasn't just an element for us to do. It's really more about the user experience of using most applications. If you can build great search right into your application, your application will feel better. It'll be a better experience for the user. So we're going to help you out in two ways this year. Number one, we're going to provide the UI. There's now a standard search widget built into both Cocoa and Carbon.

It looks like this. We're branding the rounded text fields to mean search. So if you use a rounded text field, that's a search field. Don't use it to mean anything else. It has an optional magnifying glass. You can use that to have a drop-down menu where you can scope your searches, where you can save older searches and someone can choose the older searches from there. So that's the optional magnifying glass.

It also has an X in there which clears the search once someone's typed it. So we're providing the UI in both Cocoa and Carbon for Panther. Next, we're providing the engine. So we're building in a new framework into Panther called Search Kit. Search Kit is a search engine you can all use for your applications.

We already use it for these applications, so for the finder, for the address book, mail, help. It works really well. So what is SearchKit? It's vTwin, but much evolved. So back in Mac OS 9, we had something called vTwin. It's a search engine. People really liked it, and we've been moving it forward, and we got it to the point now where we're ready to make it public in Mac OS X and fully support it going forward.

It supports a bunch of different kinds of searches. So prefix searches, like you'll see in address book in a lot of these apps, Boolean searches, natural language searches so you can ask a question, and even similar documents. So if you do a search and it comes back with a document, but that isn't the document you're looking for, but you know the document you're looking for is similar to that document, we'll actually do an analysis of that document, look at all the other documents you've indexed, and return the similar ones. And it's fully Unicode based.

CFString API is built right in so you can index any of your different languages. For Japanese, we actually do some really difficult work, which is we have to do linguistic analysis to figure out where the word boundaries are, because there aren't obvious word boundaries. We do that, all built right into search kit.

It supports these six document types right out of the box. So text, RTF, RTF with graphics, HTML, PDF, and even Word. But when your application adopts SearchKit, you can add on support for any type of application that your, or any type of document that your application knows how to parse.

So that's Aqua. We've taken the finder and made it very user centric instead of computer centric. We've taken the open and save panels and moved them right along with the finder. We've added that switcher thing as a standard widget. We've really refined Aqua and we think you're going to like it. We've really tried to polish every little thing. There's a lot of other things I didn't show you which we polished. We've added many controls and we encourage you to adopt search and we've provided both the search field and a framework to help you do the indexing itself.

I'm not going to moonwalk. So for text, we've done a bunch of things this year. Starting with text input for Japanese. We've really improved text input for Japanese. The first thing we did was simplify it. In Jaguar, you had to go to a bunch of different menus, different palettes to try to find the right input method. In Panther, there's a single menu for you to go to. It has everything you need and there's a standard single palette you can keep on your screen to switch between the different input modes.

So we've simplified the UI. The next thing we did is we improved the accuracy. We made it a better input method. There's two main ways we did this. We started off by using the latent semantic mapping technology from our speech team. Now, this is the same technology we use to do junk mail filtering. And what we've done is we've used the latent semantic We use it to predictively guess based on the characters you're typing what actual character you're going for. So based on the keystrokes you're typing, what character you're going for. And this actually improves our accuracy quite a bit.

The next thing we've done is we used the context in which you're typing to figure out what character you're looking for. So as you're typing along, rather than having to guess what character you're going for purely based on the keystrokes you've done, we look in the document, we look around in the document for other characters. So if the keystrokes you've typed could resolve in three different characters, and you've already typed one of those characters into your document, a line above, we'll guess that character.

So it helps the user, you know, get the better characters faster. Now the important thing here is you need to adopt this to help us out. So there's a protocol. You need to adopt this protocol, which will vend back the context of the document the person's typing in so it can pick the right characters.

We've also added a preference for all of those people who are coming from the dark side to the Mac and they still want to feel comfortable with elements of the old crack home and the new home. So you can use the same pipe, but it's now on the Mac, and it feels comfortable.

Font Support. We've really simplified dealing with fonts in Panther. The first thing is installing fonts is as easy as double clicking a font file. It comes up with this preview, you hit install, it goes right to the font book. So installation, incredibly easy. But the access for those fonts is in the font panel itself. So you should build the font panel and use the font panel in your applications.

That's where your users will get at the fonts, but they install it through the font panel, or through the font book. Next, the font book is for organization. So you can create new collections. You can populate these collections. And again, you access those collections, you access those fonts through the font panel in your application.

You can also activate and deactivate fonts. So take that font collection we just had, we deactivate, and you'll see it disappears from the font panel. So we really encourage you to use the font panel as the standard access method on the system for fonts. However, we know that some of you have very custom UIs for your fonts, and the font panel doesn't make sense for you. So for all of you, in Panther, we've added a new set of APIs to get directly at these collections, the activation and deactivation of those, you can use it directly. Text performance. There's one thing we heard loud and clear from you about our text performance in Jaguar.

I see that all the fish fans have perked up from making bongs out of their new cameras. They're the only fans where text feels almost too fast. So if you sample your application, you're going to find that a lot of time in your application is spent dealing with text. It's spent laying out the text, measuring the text, drawing it to the screen, redrawing it when there's a window resize. And that makes sense because a lot of what your application does is draw text. So this is how we've optimized it.

All text is drawn in Translucent in Panther. So we looked at that and we actually said, well, here's a great opportunity. Because anything we can do to improve the performance of text is going to improve the performance of every one of your applications and of the system as a whole. And so we looked at all this text we draw, and we spent a lot of time optimizing all of this for Panther. And I think you're going to be really pleased with what we have.

Let's look at the stages where we went through and optimized. We looked at the font system, so ATS and all the different pieces involved there. We looked at core graphics and how we get everything to the screen. ATSUI does a lot of the layout and the Carbon and Cocoa APIs. We had a concerted effort this year where we went through and we optimized every single layer of the tech system.

Then we stood back and we optimized holistically. We looked across different layers and said, "Are there places where ATSUI needs to leverage the font system directly? Is there an impedance mismatch and can we plug that up with some new APIs to make it faster? Are there places where Carbon should talk directly to Core Graphics?" And so we optimized across layers as well. What I'm pleased to say is the outcome of this is if you look at any of the text APIs, pretty much from the lowest level to the highest level, they're all more than twice as fast in Panther. So this is a great achievement.

There's some places where it's even much faster than that. So it's five or 10 times faster. Again, I absolutely encourage you, please install the new seed and see what performance improvements you get out of the text in Panther. We're continuing to optimize text and will do so until the final version of Panther is in the box.

So you still have time to let us know, are there any bottlenecks remaining? If so, we'll try to improve them before we go 10.3 with Panther. That's text. So we've improved the Japanese input. We've added great support for font maintenance and management, and most importantly, a lot of performance work.

So Carbon, we believe, is a gem, and we're treating it that way and continue to evolve it. A lot of what I've already talked about for things like the switcher thing and mini controls are features that we've added to Carbon this year. So I'm just going to talk about a few specifics for Carbon in this section.

This is the age of HIVU. Last year we introduced HIVU to you. We spent a lot of our time this year improving HIVU and sort of making it permeate throughout Carbon. Hiview is the future of the HIToolbox. So if you have a Carbon application, adopt Hiview. Most of you have already adopted Carbon Events, which is great. Hiview is the next step in this progress. We've added HITextView. So we took MLTE and it's now an Hiview.

We have HIView based menus, so it's much easier for you to extend menus, for you to add your own functionality. If you saw this morning, we have this action menu in the finder and allows you to set different colors for labels. That's all done through the use of the new HIView based menus.

And we've added great layout support. So we have springs and rods, but we also have very complex relationships. So you can look at different views, can sort of pay attention to each other, and when the window resizes, they can resize in very complex relationships whatever you need for your applications. And it's much faster, which is another theme of the HIToolbox this year: performance optimizations.

We have a complete set of Quartz theme APIs. So we used to use Quartz in our layer. Then we'd go through Quick Draw and we'd go back to Quartz. And it was a little slow. We now have top to bottom, a complete path, which is all Quartz. We encourage you to take advantage of it.

It's much, much faster. Data Browser. Data Browser, we heard from you, wasn't fast enough. We made it 25% faster to add new items, 80% faster to remove items, and if you have very large data sets, it is much, much, much faster. Much. And it now supports compositing mode as well. We've also really improved window resizing, so it's at least 30% faster. In most cases, if you have a fully composited window, it's even faster. So we encourage you to have your app be fully composited. It's Carbon.

So we think you'd be loco not to use Cocoa for a new application. All right, again, just like Carbon, we've added a lot of things to Cocoa this year, but I'm going to talk about just one. So stepping back, there's a standard developer paradigm called model view controller, right?

And so most of you probably know what this is, but you take your application, you separate out the UI piece, which is your view from the model piece, your data, and there's this controller layer in between, which pretty much is the glue that moves things back and forth.

So Cocoa has had a model in NSDocument, and it also had a view in NSView, but it hasn't had a controller layer. What this means is you've had to write a lot of glue in your applications to do that controller layer. I'm happy to say that for Panther, we're adding a controller layer. NSController.

So why should we do a controller layer? OK, this is up to 10,000 feet now. Our goal as a platform vendor is to make you The most efficient developer you possibly can be. We want you, when you have a new idea, to implement that idea on Mac OS X first and get it done the fastest possible. So that's our goal. We believe that Cocoa, that the shortest distance between a brand new idea and an app implementing that idea is Cocoa on Mac OS X. So what do we do to that end? Number one, we provide all the standard functionality.

So we provide views and controls and text views and collection classes and on and on and on. Cocoa is our advanced object-oriented framework and it provides all that standard functionality. The next thing we do is we continue to try to eliminate redundant code. So if we see that several applications are trying to do a certain thing with text, we add new APIs to the text system to help you out. But this year, we sat back and said, can we do more? And inspired by a couple technologies Apple's had, EOF and WebObjects, we've added a whole new layer which eliminates an entire class of glue code.

So we're getting rid of the glue code. So what is this glue code? You know when you're writing an application and a user updates a value in a text field and then you need to write this glue code which goes and updates your model based on it. You don't have to write that code anymore.

It's gone. The controller layer we provide does that automatically for you. When your model changes, you have to have glue code which then reflects that new value in the UI. You no longer have to write that code in Panther. The controller layer takes care of that for you.

You might have a couple UI elements or multiple UI elements all reflecting the same data value, the same model. And you have to write all this code where if it changes one place, you synchronize all the other ones so they don't get out of sync, so you see the same value everywhere. You no longer have to write any code for that. It's all done automatically in the controller layer.

And sometimes the user will click to change something. For instance, you have a table view, a big list of values with multiple columns. And depending on which column the user clicks on, you sort by that column. You've had to write all this glue code to do sorting for your table views. No longer. The controller layer now supports sorting out of the box for free.

and of course we didn't forget that if we're doing it we better integrate it into IB. So Interface Builder in the past has supported hooking up targets and actions meaning you could tie your UI directly to the controller layer you were writing. In Panther you tie your UI directly to your data, directly to your model. You don't have to write any of that controller glue in between. It's all provided by this new controller layer in Cocoa. That's the controller layer.

Alright, let's talk about the internet. We'll start off with Sherlock. So what is Sherlock? Sherlock is a web services host application. So you can write, quickly write, a web service, a client side of a web service as a Sherlock channel. It'll run inside of Sherlock and you'll get this great client side experience for that web service. So an XML feed or an HTML feed. You can get that right inside here. So here's an example of one of the ones we've written for our movie channel. It seems that we're required by our CEO to have everything be Nemo this year.

So, you know, this is a nice standard channel. What we found this year is that more of you have been writing channels. And so we needed a way to organize these channels. So we used the same library organization mechanism that we have in Safari and have brought it into Sherlock. So we now have that. The most important one of those collections on the left, though, is this one. This is a dynamic collection.

It's a dynamic collection of every channel which appears either on DMOZ, and DMOZ is an open directory, sort of the Yahoo of open directories. They collect things, they collect Sherlock channels. So if your channel appears on DMOZ, or you submit it directly to us, it'll appear in everyone's copy of Sherlock dynamically every time they launch it. So this is the way for you to get your channels out to everyone else. That's Sherlock.

Safari. When we built Safari, we had five main goals. The first two were performance-related. It had to be fast. It had to be fast. And it had to be small. So we've succeeded on these two goals, and Safari is the fastest browser on the Mac, as you know. Most of you probably use it.

And I get asked a lot, well, how did we succeed on it? How did we make it small and fast? What did we do? So let me take you through that just a little bit, because it wasn't magic. And I think this might help you understand what we did. So it'll help you make your applications fast as well.

Most importantly, we made performance the most important feature of the application. This is one of those things where for engineers to actually work on things, you have to make it a feature that they're going to measure it against or else they're going to sort of ignore it until the end.

So we made it the most important feature for everyone on the team. We started with a small code base. If you have a small code base, you're running less code. It also means you can get your head around all that code code, so you can optimize the entire thing.

And this is probably the one which is the most controversial. It's the first project I've seen actually that does this. We allowed no performance regressions from build to build. Period. So even when an engineer implemented some new feature and they checked that new feature into the code base and we built that and we measured it.

If our page load times got any slower at all, we checked that back out of the main trunk of the code. The engineer had to find a way to make it to implement it again without any performance regressions. Or they could be tricky and go optimize a different part of the system, a different part of the application and check it back in so it still didn't regress. That was the rule.

Now you can't tell people that up front because they put really slow stuff all over the place and the sleeps come out as they add features. So we measured constantly to know where we were also. This was really important. We hand-timed things, we sampled running processes, we built automated tests, and we created charts, charts all over the place, so we saw what was happening with our performance. So we were never surprised. You know, a chart would come out every day or every other day whenever there was a build, and if we saw there was a blip going the wrong direction, we'd check that code back out.

There's a lot of great tools in the system and we use them. So Sampler's a really good tool to find out where you're using CPU time. Malik Debug and Heap are great for memory usage. Quartz Debug, if you haven't run it, is fantastic for finding your drawing problems. If you're drawing a control two times, three times, four times, if you're drawing it multiple times, Quartz Debug will flash it right in your face and let you know that you're drawing something multiple times. FS Usage tells you how often you're touching the file system.

And the more you touch the file system, the more your application runs at the speed of the disk instead of the speed of the G5. And trust me, the G5 is faster than your disk. So run FS Usage and cut down the number of times you're touching the disk. And there's a lot of other tools. We ran all the tools.

This one I think is one of the most important. We built performance tests directly into the application. That means that anyone internally running Safari throughout the entire development cycle could run the performance tests. That means I could run them, and I did. Each time I got a new version of Safari, I would run the PLT, I would run the tests that were built right in, I would see what the speed was on my machine, I knew what it was supposed to be, I would know if it got any slower, and if it did, I'd call someone. So, building tests directly into your application is, I mean, I can't overstate this, if you look at applications where people have done this, those are generally fast applications. So what are the lessons we learned? Make performance a priority. If you do, your app will be fast.

Use the right API for the job. This is one of those things where it should be obvious, but we have lots of APIs on our system. And some of them are generic and do a good job of a large amount of functionality. For instance, we have APIs that are meant for a large editable text view and it's meant to handle bidirectional Unicode text. Right? So this is great, but it's not great if you're drawing a label. So we've added optimized APIs for certain smaller pieces of functionality.

So when you're going through and you find an API that solves the need you want, keep reading through that header file to see if there's anything else we've added just for your usage. Use the right API for the job and you'll get better performance. Measure, measure, measure. Measure to find where your bottlenecks are.

Measure to find if the new API you're using is going to be a good one. Measure to find if the new API you're using is going to be a good one. Measure to find if the new API you're using is going to be a good one. Measure to find if the new API you're using is going to be a good one. Measure to find if the new API you're using is going to be a good one.

Measure to find if the new API you're using is going to be a good one. Measure to find if the new API you're using is going to be a good one. Measure to find if the new API you're using is going to be a good one. Measure to find if the new API you're using is better for the job and measure to prove to yourself after you've made the optimization that it actually made your application faster.

and never regress. Again, this was controversial, but it really helped us nail it. Instead of trying to optimize at the end, we were optimizing the entire time, so we made architectural changes that would make the app fast. Alright, let's get back to the goals. The next goal, we want it to be native, so we want it to be a great Mac OS X citizen, leverage all the features we have on the system like CF Network, We wanted it to be real world standards compliant.

So of course we wanted to support all the standard buzzwords, all the standard, you know, the standard standards. But if you go to eBay and, you know, I don't know if anyone's here from eBay. If you go to eBay and it doesn't render for you, even if it's not following a standard, it, you want it to render, you don't care. And so we made sure that all the sites out there would render. We wanted real world standards compliance.

But most important for you, one of our main goals from the moment we started this project was that it be embeddable. Our goal was to be able to open this up and have you embed everything about the guts of Safari into your applications. So let's look at that.

Here's Safari. Here's the way we built it. Safari itself is just a thin layer on the top of this stack. Everything else are public APIs. So we start with the standard BSD sockets. CF Network is where we implement most of our protocols, and Bertrand talked about that earlier. Foundation URL APIs. So Foundation has been greatly enhanced in Panther. It has fantastic URL loading. It's much enhanced from Jaguar. It has automatic content caching.

It supports standard authentication schemes. It has extensible streams. So we now have a stream object. You can subclass it. You can extend it. We provide all the standard protocols, but you can extend that with custom protocols. And we support cookies. C is for cookie, that's good enough for me.

I've got a four year old. Alright, WebKit. Let's look inside WebKit. This is Safari. This is WebKit. WebKit is that content region of Safari. You can build it into your applications. We built it directly into Mail, so Mail now has much better HTML rendering, but this is WebKit.

Most important for you, you can build it into your application. So WebKit is that content region and more of Safari. We support standards, so here's all the buzzwords that HTML4, XML, I'm not going to read to you, but we support all the standards. And we are a member of the W3C and are actively working on new standards which we'll support as the W3C decides on them.

That's WebKit. Let's look inside it for a moment. There's two main pieces inside of WebKit. It's WebCore and JavaScript Core. So WebCore is the open source KHTML library. We encourage you to become members of the open source community, contribute to this the same way we're contributing to it, and it will benefit all of us. JavaScript Core is KJS, again the open source version of the library. We encourage you to support it.

Now one thing we've been telling you for the last few years is if you're building a brand new application, you should go find some open source code that's great and then if it's a brand new application, build a beautiful Cocoa UI on top of it. It's the fastest way for you to get your application out the door. It's exactly what we did here.

KJS is C++, WebCore is C++, both open source. We used Objective C++ and WebKit to marry the whole thing together and build this beautiful UI called Safari. But the important thing for you is WebCore and JavaScript Core are pieces and implementation details of WebKit, but for you, the API to use on Mac OS X is WebKit itself.

So this is WebKit, and that is where it falls in the stack. We've taken and built Safari in such a way that you can take advantage of almost all of the APIs directly in your application. And to show that, I'd like to bring Richard Williamson, engineer extraordinaire, up on stage to blow you away with how easy it is to use WebKit.

Hi. So I'm going to give you a demo of WebKit. And what better way to do that than to build a web browser? So let's get started. I'm going to launch Interface Builder and start a new application. And you'll notice that Interface Builder has a new palette. The WebKit palette. This palette has a single class on it. It's called the WebView. Let's add a WebView to our window. Resize it.

Set some resize flags on the web view itself. Now, how do I load a URL into this web view? I'll use a text field. Drag out a text field, place it in the window, and using the normal target action mechanism, connect it to the web view. Now I'd like to add a few more... This is good, but I'd like to add a few more features. Maybe a back and a forward button.

So let's drag out a back button, place it in the window, and a forward button. Give these buttons labels-- back, Forward. And again, using target action, connect them to the web view. And finally, I'm going to set the resize flags on these widgets. That's it. I haven't written any code. Nothing's compiled. Let's go ahead and test this. How about checking out Apple's site?

So Scott's going to sign for one of these G5s, I hope. So back and forward, these buttons work. You'll notice, though, a few things aren't quite right. The URL in the text field doesn't update as I navigate. And the back/forward buttons don't disable and enable as I'd expect. Now we all know this point, to really make an application work, you write lots of glue code. Glue code be gone.

So I'm going to add these features, enable and disable the back/forward button, update the URL in the text field, and also show a progress indicator without writing any code. And I'm going to do this using the new controller technology. So the first thing we'll do is create a controller.

Now going back to the text field, what I'd like to do is share the same underlying URL for the web view and for the text field. As I navigate, I'd like to update that in the text field. So we're going to bind the URL to both the web view and the text field. But first let me disconnect the target action.

Then I'm going to go to the new bindings inspector. And this lets me bind properties to the various elements that are selected. In this case, I'm going to bind the value of the text field to the mainframe URL. Now for the back and forward buttons, I'm going to associate their enabled state with properties on the web view that tell me whether or not I can go back or forward.

And then finally, I'd like to add a progress indicator so I know when the page is loading. And we'll make this progress indicator determinant. Its value will go from 0 to 1. And let's bind it. Its value again will come from the web view controller, estimated progress. We set the resize flags. Now we have another browser. Again, no glue code, nothing compiled. Let's test it. This time, I'm going to go to the mandatory Pixar site. And let me emphasize, the content you see here is exactly the same content you would see in Safari. Let's check out a trailer.

So the back and forward buttons enable and disable as we expect and as I navigate the URL is correctly reflected in the text field. That's the WebKit and the controller technology. Thank you. There are more in-depth sessions on both of these areas, so I encourage you strongly to go out and check out the more in-depth sessions. Thanks, Scott. Thanks, Richard. All right. So that's the architecture. The web kit is available to both Carbon and Cocoa.

It's available on both Jaguar and Panther, and it's available today. You can download the SDK, the 1.0 SDK for Jaguar today and ship your apps on it. So what we've done is we've taken Safari and we've opened up the engine and given it to you to embed in your applications. With that, I'd like to turn it back to Bertrand. Thanks. Thanks Scott. So we are running a little late and there's so much in Pantfer, so I thought I'd take a few things and put them together in the Pantfer Parade. So ladies and gentlemen, the Pantfer Parade!

Okay, enough of that. So the first technology I chose is ColorSync. ColorSync is about color correct images. And it's really a shame if you go to a real life safari in Africa, take this picture of this lion, and you open it with several apps and it doesn't look the same in the different apps.

So it's really a shame because we have this great technology, ColorSync, and we've made it really fast over the last few years. So that there's no excuse for not using ColorSync. Now, I know that many of you have not used ColorSync because it was a little too hard because by default, ColorSync was off. We've changed the default. Now ColorSync is on.

And so you automatically get the benefits of ColorSync and you can--if you have a color-specific application, turn it off with a little more code now. And QuickTime Graphics Importer supports that philosophy as well. Another long-time technology we've had is AppleScript. AppleScript is a blessed technology for our end users who want to automate certain workflows. We also use that in a lot of the publishing space. So there's two sides to AppleScript. There's a supplier side providing scriptability and there's the consumer side using scriptability.

For the supplier side, obviously you need to make your application Apple Scriptable. And that's not too much work, but you have to go do that. Now for the consumer side, what's really beautiful is that you can use and leverage the other applications that are Apple Scriptable. And we've made more and more applications Apple Scriptable. We've enhanced the terminology in all those applications. We also added a facility to do UI scripting so that even if you haven't made your application Scriptable, it will work with Apple Script.

Other technology, Veclib. Veclib is fast math. It's really, really super fast math. It's used in all kinds of contexts. It's used for linear algebra, so of course something like Mathematica uses that. But something that's not obvious is that even our little junk mail filter in mail uses linear algebra.

It's used for signal processing, all those FFTs for audio, big nums for crypto. And what we've done in Panfer, we've optimized Veclib for the G5. Now we added another technology that we called V-Image, which is now fast math, but for 2D arrays. This is for graphics, of course.

It's for doing convolution operations, morphology operations, all those things that I don't know what they really, really mean. Or I don't understand the math underneath them. But what I can say is that it's really, really fast math. What I can show you is some pictures. This is an example of blur. Hopefully you can see it's blurred. An example of embossing.

Another technology that we have is DVD. We have had the DVD player for a while. We've made that DVD player functionality available to your application. So if you want to embed usage of a DVD in your application, for example, for training or whatever, now you can do it by using those APIs.

Another technology is, of course, QuickTime. We've seen a notary shot. And QuickTime is embedded in Mac OS X. We embed the latest QuickTime. We have focused for this release a lot on infrastructure. A lot of you have asked to have threat-safe QuickTime. And now in Panther, QuickTime will be threat-safe for static images and for playing movies. We have full support for Unicode.

And we've gutted the audio infrastructure underneath QuickTime to replace that with Core Audio. Now that brings me to Core Audio. Core Audio has been a wonderful technology on Mac OS X. One reason is that it has been conceived from the ground up to be a great X citizen. Now we're adding features to Core Audio. We're adding surround support. And we're enhancing the real-time effects and want to encourage all of you to bring new audio units, which is real-time effects, to the platform. Thank you.

We are supporting new formats. And we make it really, really, really fast. It has very small latency. And it also consumes very little CPU to play. And, for example, on Gigahertz PowerBook, you can play AAC, which is what we use for the Apple Music Store, of course, with less than a percent of the CPU. So that means you have 99% of the CPU for the rest of your application.

Another technology that we have is a window manager, Quartz Extreme. The vision behind Quartz and Quartz Extreme is to have Hollywood effects right on everyone's desktop. And we are really moving in that direction. And some of the features that you saw demo this morning, like Exposé, totally leverage this kind of facility.

Now, what we've done, Core Graphics is the API to Quartz, and we have rounded it a little more. We've added a lot of the functions that you've been requesting. So, little functions here and there to do shadowing, to screen scrap, you know, all those things. Now, we also added some brand new areas of API, notably the PostScript to PDF converter, and some APIs to deal with PDF. Both PDF in terms of the document structure. We've all those nodes, the document tree, and with PDF in terms of what gets drawn, the pages. So, you can access the pages that are getting drawn.

Another technology in the graphics land is OpenGL. Now, OpenGL is, of course, hardware accelerated. It's 3D imaging, and it's used for games. I mean, most of the common games use OpenGL. But one thing that I'd like you to think about is that OpenGL is not just for games. You can use OpenGL to your advantage for your application. You can use OpenGL to get to the next level of great user interface. And my favorite application, of course, is Keynote that totally leverages OpenGL.

Now the last technology that I have is world readiness. Now we've had an effort since the inception of Mac OS X to be a great global citizen. We have devised this technology that we call app packaging, which is really fundamentally an object-oriented concept. All the languages supported by your application go along the application.

We use that for all kinds of plugins. Our frameworks are packaged that way. And I am very pleased that all of you have adopted that packaging in your applications. So our users out there in the world really enjoy that. We are doing just more of it with more support for locales, languages, and font. It's easy to internationalize on 10. So this is a very, very quick panther parade. Ladies and gentlemen, thank you for going along that panther parade.

And now I'm going to conclude. So we've gone through a tour of a lot of the developer features of panther. And the transition from nine is over for all of us for development purposes. Thank you. Thank you for bringing thousands of applications onto the planet and onto the platform. Now we have some next challenges. What are the next challenges?

What are the next challenges for all of us? It's to strive for excellence. What do I mean striving for excellence? The number one thing that I mean is performance. We should all make all our applications more performings. There's always some extra speed to gain there. And the key to do that is to think 10, not 9.

A lot of the codes that we have originated on 9 and was moved from 9. We need to think, get rid of all the dependencies on 9, all the conceptual dependencies on 9 and think 10, 10, 10. We have great performance tools that should be used and that can be used to address the performance issues. And performance does make a difference. Safari has a great streamlined UI.

It has snapback and all those things. But fundamentally, it's fast, fast, fast. That's what users love. Now fast is not everything. Of course, there's functionality. And one of the keys to add value, of course, to differentiate your application from your competitors. And one way to do that is to adopt and integrate the basic system services, the basic system frameworks.

They give you an extra bit of lift, OK, to your application. And you can focus on the higher level of your application, the higher level functionality rather than having to reinvent the wheel. It's more value with less code. I hope you will enjoy our pre-release of Manfr. We've worked hard for it. Thank you.