Ladies and gentlemen, please welcome Vice President of Platform Technologies, Bertrand Serlet. Good afternoon. It's a pleasure to be here again. I think I've been here five times before, and I think you will agree with me. We've come quite a long way in all those years. So what I thought I would do is to kind of draw an analogy with the path we've been going on, is to take an example from Psychology 101, for those of you who've gone to a psychology class.

So there was this scientist, last century, Abraham Maslow, who found a very interesting way to put in perspective the human needs. And he had this diagram, which was kind of a pyramid or a ladder. And the basic concept is that in order to get to the next level of needs, you have to first have satisfied the previous level. So it worked something like this. We've had the lowest level, the physiological level. And we've got the highest level, which is the level of human needs. And going up to safety and belonging to a group, self-esteem, and finally, the ultimate in enlightenment, self-actualization.

So Apple kind of started a little low and we had a number of challenges and the first one was to define the software strategy. As you know we've worked on that for a number of years and defining a strategy was just the first layer and the strategy that makes sense and that was Mac OS X, Mac OS X strategy. But the hardest step was maybe the next one to finally shape a product and we shaped Mac OS X about a year ago on March 24th of last year and that was a lot of hard work went into that.

Now that was a year and a couple months ago and exactly a year ago we had the developers conference, this conference and our main goal there was to explain what was Mac OS X because Mac OS X is a very complex software. But many of you had not been running Mac OS X for a very long time and so we wanted to have a lot of sessions covering what is Mac OS X.

Now we also had an agenda. In order to be successful for everyone we needed application. The operating system without application is nothing and applications you need an operating system underneath. So last year the conference, one of the goals was a call for action. We need apps. Thank you. A year after, we have over 3,000 apps. So I would like to have a round of applause for all of you for bringing all those great apps to the platform.

We worked hard too. Six months and a few days after shipping Mac OS X version 10.0, we shipped Mac OS X version 10.1. That's six months, including vacation days for the team because we were pretty tired after 10.0. And so that was a pretty major achievement for a major OS release that had much greater performance, but also lots of features added.

Now, after working on 10.1, we forked our development. On one side, we had the next generation and that will be Jaguar and we'll be, of course, talking about that today. And on the other side, we started working on software updates, 10.1.1 all the way to 10.1.4. And those software updates have shipped over 800 fixes, bug fixes, lots of little things we cleared up in the software updates. We also shipped new applications, 10-only applications like iPhoto and some security updates unavailable in our days. So after having all those applications and after having shipped such updates, we felt compelled to flick the big switch, which was the default on all new Macs, was Mac OS X.

We decided to flick the switch. In January, and that was definitely a milestone, at least for us, because from that point on, you know that the usership of Mac OS X will just go linearly as we sell new platforms, new CPUs. So it's fair to say that we climbed the next two steps in that ladder over the last year. Now, what's next? Well, there's two things. There's, of course, innovation. That's the most glamorous of what we do.

But there's also continual improvement, continual evolution. And we are trying to strike a balance between those two focuses. Now, this is the focus, of course, of this presentation. And this is the agenda that I'm going to talk, cover today. First, evolution, what we do in that incremental improvement.

tendency and what we do in terms of revolution and then we'll take two areas the unix area and the Frameworks and show how those things combine So first let's talk about evolution Now when you think of evolution you may think of something like this When I think about evolution, this is more what I think about now why? Well because I think fundamentally software is like wine you need to age it a little bit now There's one conditions where you need to start with really good grapes Otherwise if you start with vinegar you're not going to get great wine So we are committed to maturing Mac OS X over the years We are spending a lot of resources maturing Mac OS X and we are doing that in a number of areas We are doing that in UI architecture API security and overall functionality. So let's look at UI There is this myth that the way you do great UI, you start with a brilliant idea. And once you have that idea, you have a big show to announce it.

Now, it doesn't work at all that way. In fact, we look at what's broken. We take the feedback. And the feedback in terms of UI is always very, very strong. And usually it's negative feedback. I mean, there's some positive feedback. There's a lot of positive feedback on our innovation.

But what people really feel strongly is something that's this little need that's wrong. So we take all this feedback and we look at it and explore directions. And there's a lot of hard work. We explore a lot of dead ends. And we iterate constantly. And finally, at some point, we say, oh, finally, we've solved this problem. And that's when we put that in the product.

So let's take an example. In 10.1, we wanted the DVD player experience to be very, very smooth, something like a consumer would expect. So you put the DVD, the media itself, okay, in the computer, and of course the DVD player plays. Now at the same time, we wanted to have some options because you may not want the DVD player to play. You may want to burn media. You may want to use another app on your DVD. And so we wanted to generalize that a little bit.

We had the same problem when the iPod came in. And that's why if you run 10.1, you have these little applications that you may have seen, the iPod helper. And again, we wanted to have some control UI so that you can customize the user experience. that you need. So for Jaguar, we added a whole row in the system preferences, and that's the digital hub set of preferences of pref panes.

Now, what's there? Well, of course, you have the customization UI. And we've generalized for a number of devices to have this general mechanism of when something happens on a certain event, try to do a certain action, which typically is launch an application. Now, we, of course, put in the UI and preferences, but we also had to architect how it works, the engine for that. We wanted everything to be event-driven. Obviously, on Mac OS X, polling is not an option. That's not how you should write those things. So you want to have a little daemon that watches for events.

Now, every time you have a daemon, you need to think, OK, what is the performance impact of having one more daemon? And if you can use, reuse an existing daemon, in many cases that makes sense, especially if the functionality matches. It turns out we had just the right daemon for that. This thing called the System UI Server, that's what puts up the menu bar, the right-hand side of the menu bar. And so we generalized this little daemon to also support the digital hub refpans.

So you can see how from a UI problem we moved into architecture. And this is not a major overhaul of how the system works. It's enhancement of the architecture. The general philosophy is to start by solving a real need. You don't want to over-architecture something, which is to essentially not solve real needs. You want to just be right on, using Occam's Razor to focus on the problem you need to solve.

You don't want to rush into a hack, you know, just put together a solution. You want to really think, to put the right piece of functionality at the right place of the system. That's how you get a great system over time, by always moving the pieces upwards or downwards, depending on what it should be, what is the right place.

Your design and of course you implement. Hopefully the implementation once you have a design should be fun and easy. And then once you have the design in place you propagate. Usually you can rationalize the system by simplifying things once you have this more general mechanism in place. Once you are happy you start thinking about how to publish the API. Hopefully you have devised an internal SPI, a system programming interface, something that's private. And now you can think of exposing that for everyone.

So we're moving into API land. So there's a general kind of philosophy about APIs. And APIs are totally central to what we do. They're central to the conference. What we provide to you are APIs. Now, at the same time, every time there's publishing an API that comes up, there needs to be a warning signal for us, which is, are those the right APIs? Because if we publish the wrong API, we are limiting our capacity to innovate because we will be binary compatible from release to release.

And that imposes a very tight constraint on us. So in many ways, it is better to not have an API than having the wrong API. So I know sometimes you'll get frustrated because you don't have the APIs that you'd like. And in many cases, it's because we haven't come out yet with just the right API, something that we believe we can support over time.

We are developing internally a culture of high quality API. The ideal life cycle for an API starts with having this private API, using it in a number of places, having more than one client. That's very important to get great APIs. You need to have several clients. You need to iterate at every step.

Then once you are happy, you have an internal review, a design meeting or some email review. Integrate the feedback, iterate again, and finally present the API to you, for example at this conference, and get your feedback. That's how we want to develop APIs. That's the ideal path. I've gone over a number of reasons to essentially not have APIs, but be reassured we have lots of new APIs in Jaguar. Lots and lots. We'll cover that after.

Security is another interesting topic. We are not talking very much about security. Fundamentally, we want to keep a low profile on security for obvious reasons. But we are very sure that we are very aware of all the things that go on in that space. We are constantly scanning distribution lists, search advisories, the web to find potential vulnerabilities. And of course, we are addressing those vulnerabilities in software updates.

Now, that was kind of the vulnerability side. Now we also have some new APIs for security. That's an area where we've added quite a bit of API for Jaguar. We have API to deal with certificate and of course you have Kerberos support and that comes with APIs so that once you log in with Kerberos using your Kerberos signing in login window, you can keep that session key and pass that token all the way to the applications that needs it. For example, Mel may use that token and connect to your Kerberos server.

We have a number of APIs like Keychain and the authorization API that were not very used in 10.1, not used as much as we would have liked. So we are adopting internally those APIs for a lot of the applications and we hope that you will adopt those APIs as well because all those APIs make for a much more secure system fundamentally. As well as a very nice user experience that you get with Keychain.

Encrypted disk image is also a very little-known feature. I've seen quite a number of portables in the hallway. In fact, the vast majority of you seem to have a portable, and you may have some sources. I strongly recommend, if you have some sources on your portable, that you encrypt them using the encrypted disk image. Now, the feature is a little hidden. You have to start the disk copy application to get to that feature, but it works great. It's a safe way to put your sources in the case, hopefully, that will never happen where your portable disappears.

We also added support for smart cars, and that will be in Jaguar. And we have firewall support. Now, let's talk a second about firewall. We actually have shipped a firewall since 10.0. It was there right from day one. However, there was no UI for it, so something without a UI, we don't call that a feature. So, finally, we have added a UI for that. It starts with the sharing pane of preferences, and there you have a new tab, which is the firewall tab, and then you can protect individually each port.

Security is a set of frameworks. We have non-UI frameworks and UI frameworks. What's underneath all that is CDSA. CDSA stands for the Common Data Security Architecture and is a very extensive set of functionality for providing all the basics of security, all kinds of encryption and algorithms. The key thing about CDSA is that it's open source. It's an open group standard and you can download the source for CDSA.

This is essential. If you have a piece of code that is open source, you can go see and you have lots of people who will go see and find out all the potential security vulnerabilities. If it's not open source, you should probably not trust that code. Fundamentally, open source brings the highest level of security. Thank you.

Now let's talk about functionality. Of course, we added a lot more user functionality pretty much across board. Now we have a challenge when we do that is to increase the breadth of the functionality without making things more complex. We also want to add all these functionalities so that fundamentally your applications have less code because some of the code has moved downwards to the system.

So we use a number of techniques to do those things. We again iterate and think about the user model and simplify that. We also use a lot the progressive discovery technique in terms of the UI where you start with something that's very simple and then you have a way to get to more functionality. And for simplifying the development on the platform we have great frameworks and we have lots of features added in those frameworks.

So again, across board, we are doing incremental improvements. We are continuing constantly to improve performance, to improve polish, those little nits that are sometimes just too small to even think about them, but that just are annoying. So we constantly iterate and try to improve on that. Same thing goes with the API additions, adding this one convenience function that will save this whole page of code. And your feedback is critical for iteration and for continual improvement. So we've talked about evolution, now let's talk about revolution. Now when you think of revolution, you may be thinking about the French Revolution.

Now, when I think about revolution, I'm thinking about something that's a little less violent. I'm thinking of the fall of the Berlin Wall. It was, you know, a moment in time, but it was also the result of deep trends. Communism, the fall of communism, all those world events that you are very well aware of.

I'm not going to go too much into all those world events, and I'm going to talk on a smaller scale on some of the big trends that I see in the industry and at Apple. Apple is at the leading edge of the industry in many ways, and I'd like to just present a few trends. One of the trends, of course, is the digital hub.

We are getting more and more surrounded by electronic gadgets everywhere, like this thing I'm dealing with. And lots of those things are surrounding us and are part of this digital hub. Now, I'm not going to talk about the marketing side of those things, but what are the technology implications of those things? You need a whole new set of technologies to deal well with all those gadgets. You need to have, like, a great OS that does, you know, multi-threading right at the base.

You need to have event-driven applications. And I mean much more than, you know, the wait-next-event kind of thing. I really mean, like, when something happens, okay, over the rendezvous network, it propagates, okay, and something happens in terms of launching an app or something like that. It needs to be all event-driven.

I/O Kit, which enables you to write very fast, great drivers, is critical. Lots of those devices have a driver, a software driver corresponding to that. You need rich networking in all forms, NAT, multi-homing, all those things. You need things like Bluetooth. All those are the basement level technologies. Now you need higher level technologies. You need optimized signal processing. That's the kind of thing you can get with a library like Veclib, which is the IT Vec libraries that we offer.

At the lowest level you need to be able to deal with Unicode strings everywhere. That's the concept that you have in Core Foundation along with many other concepts. Networking, QuickTime, Multimedia is very present on many of those devices, so you need to have also a great library to do multimedia. And you need to be able to put together applications very quickly, and that's where Cocoa and Rapid Development come in handy.

Another trend that's very dear to my heart is cafe computing. I spend a lot of time processing my email or whatever with a cup of cappuccino in my hand. I know a lot of you do that because there's a lot of internet cafes, especially in the Bay Area, and portables have been exploding over the last few years. Many, many folks have a portable, take their portable everywhere. Along with the portables have gone some technologies like wireless technologies. The airport is again exploding. Mobility is great in Mac OS X as well as power management. We've really worked hard on those technologies.

Now, very often you have networking in place and you have a system administrator that organizes the whole network. But at times you're in a cafe and you would like just to exchange a file with your neighbor and there's no one who manages the network at this point. So this is the world of ad hoc networking.

How to connect two computers without system administration. And this is a problem because you need to discover your neighbors. You need to have readable names so that it works in every locale. And you need to do all that on top of existing low-level networking, whether it's airport, IP, or whatever. And so this is, is the solution Apple Talk? No.

We know that. Apple Talk is game over. Apple Talk has been rejected because it's non-standard. The solution is, of course, rendezvous. We will, in that conference, use several nicknames to talk about Rendezvous. We'll use "ZeroConfig" or "ZeroConf," but that's the same. Those are synonyms. Now, rendezvous fundamentally is dynamic discovery over TCP/IP. It enables you to brass the network and find all the rendezvous clients that can talk to you.

It is done on top of existing protocols. It's done on top of TCP/IP. It's using DNS in a new way to provide that functionality. And it's compatible with existing clients. You don't need to have the whole network switched at once. You can switch one machine at a time.

And it's a standard that's in progress. Now, how does it work? Well, you say, "Look up the printers nearby." And one printer who's nearby says, "Hey, I'm Stuart's printer here." And another printer says, "I'm Brett's printer here." So you collect all those names over a period of time. It's definitely an asynchronous activity.

You have to have a list of names that are nearby. Then you look up again using the same mechanism. Okay, so Stuart's printer, what's the IP address? And Stuart's printer answers and says, "I'm 123.45." And so finally, you have resolved the set of printers down to IP. That's why it's on top of IP.

Now we have defined a number of conventions and policies on how to use ZeroConf Rendezvous. We also have defined several APIs. We have at the lowest level the system framework, the Unix level kind of API that any Unix application can use. And then we've built on top of that a layer which is at the level of core foundation to use Rendezvous. And for those who use Cocoa, we have a layer at the Cocoa level to make it easier to talk to Rendezvous machines. And you've seen this morning we have been using that for iTunes.

We will be using that for file system and for printing. And so a lot of subsystems are going to participate in this Rendezvous network. But the most important is to have your applications play in that world and use Rendezvous to do things that frankly we are not even thinking about. So your creativity I'm sure will generate something fantastic with this technology.

Now, another trend maybe is B2B, C2B, P2P. There's a lot of acronyms out there, so maybe there's a trend out of that. And I think there is. For me, the key trend is P2P. Now, when I say P2P, what I really mean is people to people. A lot of what we do every day is about communication, about communication with other people.

I spend a lot of time, and I'm sure you do, using mail. You've seen this morning a lot of the new features that we have in mail. We are putting a lot of effort in getting really great mail systems that scale all the way from the novice to the professional who depends on mail a lot.

This morning again you saw iChat. Instant messaging is another form of communication that is widely used. Maybe it's the most widely used form of communication in the world. Again, we're putting a lot of energy into this. And what's underneath all those things is dealing with addresses, dealing with people, managing contacts. So we've done a little more than just develop an application. We have developed a database to manage contacts. And all those applications I mentioned are using the database. It's really the hub for all communication applications.

So we have a number of big trends that are industry trends, but that are also things that we espouse very deeply. So digital hub, cafe computing, ad hoc networking, and P2P. All those thrusts are leveraging our strength in many ways. Because we do the whole system, all the way from hardware to software, we can really integrate them nicely and make them easy to use. We have a great platform to start with, with lots of great technologies.

And we all share the same vision of bringing those great technologies to everyone. And when I say we all share the same vision, I know that my colleagues share the same vision, but also you in the overall Apple community. So I think by reusing all of us, reusing all those technologies, we can have something which is really fantastic.

So I've been talking about evolution and revolution. I'd like to take one area, which is Unix, and talk for a second on how those things kind of come to play for Unix. Now I don't know how many of you saw this ad: "Send over Unix boxes to /dev/null". It's quite a departure from the other ads that Apple has had over the years, which are very, very consumer-centric. This one is definitely not for consumers. Very few consumers know what "dev/null" means. It's very Unix-y. Now, I think it's fair to say that adopting Unix was in many ways a revolution. Apple OS is now Unix-based. I think this is something that very few out there realize.

Now, it has been somewhat well documented why we've done that move. That was in fact very logical when you think of it. Unix is a very mature, solid, proven foundation and we wanted to go mainstream and adopt a whole bunch of standards, standard technologies. What is maybe less known is that for us that was the fastest way to many features.

Let's take networking for example. The Unix networking stacks have been iterated over several decades and they've had like several hundred developers at a minimum participating in the development. There is no way we could have replicated these thousands of person years of development by just us, by just a few of us just trying to develop a competing stack.

Now another thing of course with Unix is that we can address now new markets. We can go towards the scientific computing, the higher ed, the enterprise markets. So these two last points are less obvious and another thing about those is that all these things apply for you. You can come along with us, attack new markets. And rather than reinvent the wheel, you can have a higher level application that uses some of the features that are built in in Unix.

Now I'd like to give you my personal view on what explains the Unix longevity and strength. There are some reasons that are technological reasons and some other reasons that are less technological. So let's look at the technology reasons first. In many ways, Unix has write low-level abstraction. You know, open, read, write. That's write API for dealing with a low-level file. And there's many examples of those technologies just done right with Unix. The whole piping concept, you know, all those things, just is great.

There's a very clear separation between what's at the kernel layer and what's in user space. And that's a very tight boundary that in many cases is like, you know, a little hard when you come from a world where you can have a driver that suddenly puts up a UI and says, ask a question to the user.

So that's a source of tightness, but that's also what makes Unix great in terms of robustness, having a very well-defined boundary for things like Cisco. In terms of UI and non-UI, again, there's been a very clear separation. Some of the UIs have come and gone on Unix. They were not that great. But that was a source of weakness, but also a source of strength, because it meant that the separation between what's UI and what's non-UI has maintained very well, and the APIs are very clear there.

Unix also has this philosophy of small blocks. To program in Unix you take these little tools, you plug them together using the shell, and build something greater. In fact, loose integration via scripting, shell scripting, has been really the way people have gotten their work done on Unix. And if you look at most of the scripting languages, you know, Python, Perl, the CGIB, all those things started on Unix. And there's a good reason for that. That's part of the philosophy of Unix.

Now there's also some less technological reasons. Because there was not much room to grow on the desktop, some companies have turned to the server. Some Unix companies turned to the server. And from that server focus there's been a much greater reliability and scalability. Unix is a way to get a reliable server, of course.

Also, there's been this Darwinian evolution that took place in the 80s when there was a Unix world, different flavors of Unix, and out of all that, a refinement has occurred. Now, for the last few years, Linux and FreeBSD have started passions, and that's associated with the open source movement, which is both a technical and political and sociological kind of movement. and that we're definitely embracing.

Finally, when we want to hire, it used to be that we had to look for kids out of school that had this Mac Toolbox experience, and that was really hard to find. Nowadays, we can look for people coming out of school that have the Unix experience, and I'm sure you can do the same when you hire. That's quite different in numbers.

Now, what is the relationship of Mac OS X and Unix? Obviously, we are adding a lot of stuff onto Unix. I mean, after all, we have a Unix bug that can run Microsoft Office. That's fairly rare. So clearly, we all together are adding value on top of the best Unix.

But let me reassure you that we want to preserve Unix's strength and its philosophy the way it is. So we will add value on top. We will also, at times, change Unix itself. We will improve the best. We will add, you know, mobility support, power management, drivers. I mean, we'll do a certain number of modifications because we have a business need to do so. But we will only do that where we add value.

Another thing that we will do is clean up the APIs. Unix has not been designed to be binary compatible from release to release. And of course, we have to. And so that's another place where we'll clean up the header of Unix over time. So again, we will only deviate if we have a very good justification to do so.

Now, all that's kind of the philosophy, now what are we doing for Jaguar? Some of that was partially covered this morning, but I'll reiterate it. We have refreshed a lot of the stacks that we got from the open source world. We have refreshed the POSIX APIs, we have the latest APIs in many dimensions.

We have refreshed our networking stack, IPv6, IPsec. We've updated a number of commands like Emacs that maybe some of you may use. Libraries like Curses, LibC, Shell, Bash. We also added PAMS, that's the Plugable Authentication Module, which are very important to connect to other systems that don't use the same authentication. Of course, GCC3, that has been talked about. And Terminal, we have done quite a lot of improvements in Terminal. The most notable is the UTF-8 support, which means that, for example, Japanese finance will finally display right, double byte languages.

We are also adding a lot to Unix. We have added Samba both for the client and for the server, both client side and server side. Python. We've decided to replace our printing backend, the spooling architecture, with CUPS, which was in some ways a bold move, which does not disrupt any of the applications, of course, because the API remains the same, but which brings us another kind of additional reliability. Thank you. We're integrating VPN, PPTP, LDAP, both in terms of having the client be a great client for non-Mac servers and vice versa. Integrating to non-Mac clients.

Open Directory is the name for the directory service adoption. We are going through this layer that enables us again to redirect. In computer science, one direction buys you a lot. Open Directory is this direction that enables you to redirect to different directory services. So UNIX. UNIX is about power. UNIX was a revolutionary move and now we are evolving it. So now what I'd like to do is to ask Scott Forstall to come back again on stage and talk about frameworks.

Alright, let's talk frameworks. So Bertrand said, you know, we've been evolving for revolution. This last year we've been evolving the frameworks as quickly as possible to allow you to create these revolutionary applications on Mac OS X. So let me tell you, Jaguar is one involved cat. What have we done this year? We've done a bunch of networking improvements. I'll talk about all these in a minute. We've added web services client support.

The address book APIs we talked about a little bit this morning and I'll get into a little more. We've improved upon our already outstanding international support. We've added really good universal access support. And we've made improvements to both Cocoa and Carbon. And very interestingly, we've added some integration support. So stay tuned. All right, let's talk about networking.

So let's say you've got a URL. What do you do with it? You want the data back. Well, the high level APIs are if you're a Carbon application, you use URL access. If you're a Cocoa application, you use NSURL and NSURL handle. And these are nice, very simple high level APIs. You pass it a URL, it hands you back the data. You don't care what the schema is. Everything just happens for you. But what if you want to control a transaction? Or what if you want really, really fast speed? Simple, right? You drop down to sockets.

Sockets, you can go as fast as you possibly can. But this is like dropping from the 20th floor to the cellar. You've got to rebuild everything. You have to write your own HTTP engine. You have to do all your own networking code. But you can use the sockets piece.

What we've done this year is we've filled that gap and we added something called CF Network. So CF Network has more power than sockets, a lot more functionality, but it's much more configurable than the high level APIs. So CF Network, it really gives you power, it gives you control, and it gives you speed. Let's talk about the power.

It has a full 1.1 HTTP engine built in. That means now with CF Network you have digest authentication, you have persistent pipeline connections. It's great. Full HTTP 1.1. Security's built in, and it has rendezvous or net service APIs built in as well. So if you want to use zero conf, go straight to CF Network.

That also gives you control. So you can manipulate the transaction directly. That means if you want to add headers, remove headers, you want to control when bytes are read or written, you can do all of this from CF Network. And you get to choose the threading model as well.

But probably most importantly, even with all of that, it gives you speed. It's very, very fast. If a network packet leaves your machine to go out to the network at all, then CF Network is as fast as raw sockets. So it's very, very fast. Gives you a very small footprint, and even if you have a non-UI daemon, you can link against this. So even for low-level to high-level things, you can use CF Network.

We use it throughout. Where we're doing networking code, you know, Sherlock uses it. In fact, when we moved Sherlock on to CF Network, we got almost an order of magnitude speed improvement. iPhoto uses it for uploading photos to the web, so we use it all over the place. So we encourage you to as well. Networking. We're really improving our networking support. What's next? Web services.

The great thing about having a good networking base like CF Network is we can build on it. And that's exactly what we're doing. We're building web services on top of CF Network. So what the heck is web service, or a web service? You know, is it MS web services? Web services, let's start with some examples. So Google has a web service. And the web service for Google, not surprisingly, is you pass it a string and it responds with a search query or a search result.

Okay, that's their web service. It's not a web page, it's a web service. Babelfish, you pass it some text, does a translation, and it, you know, responds with the translated text. So again, there are many, many different services, and the difference is they're not web pages, they're APIs. So let's define a web service.

Let's just look at the two words, web and service, and we'll start with service. So a web service, it's a service, it's a set of APIs, it's a set of functionality which is presented as that set of APIs. But the web part's really important, too. These APIs are callable over the web. So really a web service is just a remote method call, a remote function call over the web.

Now here's where you get into all these acronyms, right? There's, it's generally packaged as a SOAP package. Use XML to construct your parameters. Sometimes it goes as XML RPC. Use HTTP as the transport layer, generally. I mean, there's all these different acronyms, but very simply, we have a set of APIs that are callable over the web. So what have we done? Number one, we're supporting standards. We're just supporting the standards. We're not going to pelt you over the head with a hailstorm of proprietary protocols.

We are supporting just the standards that everyone out there has been using, XML, XMLRPC, SOAP, all built in. Now, in X.1, we actually added some web support, web services support. We made the Apple Event Manager web service aware, which means that since X.1, our Apple Script customers, and Apple Script is built on Apple Events, have been able to use web services. What we're doing for Jaguar is taking that whole layer and moving it down a level. So there's going to be a C API callable by any of your applications to do so XML RPC to do web services. That's web services.

And I really encourage you, you know, write web services, take advantage of them, and let's just use the standards. Address Book APIs. If you look at almost anyone's machine today, there are many, many databases of different bits of information about people. So some of these databases, if you look at, for email, for PIMS, it'll be a really large database with, you know, people's names and phone numbers and fax numbers, lots of information.

But if you look at some of these other apps, you might be surprised that I put them up there, like a web browser. Well, it turns out that a lot of web browsers allow you, when you're shopping on the web, to do an auto form fill of, say, the shipping address. Right? So they have a little database of your shipping address that they fill in.

What we're doing in Jaguar is providing a central database and a central set of APIs for every one of these apps to use. So instead of recreating your own database and having the user enter it every single time and synchronize it between applications, there is one API. Now, the API is really powerful.

The API, you know, you can set, you know, name and phone number and address and all these different types of things. You can put tags and labels on them. You can have international addresses, so it'll look at the different, you know, an address. You can have an English address, a Japanese address, have it formatted.

But one of the really strong concept in here is the concept of me, of the user. And so you can ask, okay, for the user who's currently running the system, what is their shipping address? What is their name? What is their phone number? So I really encourage you, if you have any-- an app which uses anything about people, about, you know, their shipping address, or about phone numbers or e-mails or, you know, AIM or iChat IDs, go ahead and take advantage of this API.

There's the address book, so. Let's talk about our international story. Mac OS X is truly an international OS. We feel very strongly about supporting this throughout the world. When we shipped, we had a single installation and we continue to have a single installation. Now we have a single installation for 15 different languages. What that means is on a single machine, I can log in in English. When I log out, Bertrand can log in and everything appears as French.

Single machine. You have a server and we're pointing at the same server and he runs an application off the server, it runs in French. I run an application off the server, it runs in English. One reason for this, of course, is just money. Half of our revenue comes from outside the US, and, you know, we like to make money.

From the time we shipped, we've been supporting the Unicode standard. And we support this really from top to bottom of the system. All the way down to the file system. So you don't go to a web page and get garbled text, right? We support Unicode throughout. One thing we did this year to better support international customers is we added spell checking support for these languages. So there's-- Absolutely.

But we also added this really clever thing, which is a multilingual setting. And this actually tries to figure out what language you're typing at the time, and then use the spell checker for that language. So, again, a personal example, Bertrand sends me mail, and sometimes it's in English, and sometimes it's in French, and sometimes it's in Franglais. And he doesn't want it as he's typing English to say everything's misspelled just because he's running the system in French. And so this will figure out when he's typing in English and use the English spell checker for that.

We've also greatly improved the spelling algorithm. It wasn't hard. It used to be just a dictionary lookup. Now it's actually does sort of language analysis. So it looks at, you know, plurals and apostrophes and other elements of the language to really expand and figure out what is spelled correctly.

On top of that, we increased the size of the English dictionary part even before this algorithm is applied by 33%. So here's a sentence that I used to write all the time: "Talentless, simple-minded, cockamamie filmmakers prioritize clunky skateboarders. Surreal." You run this in Puma, you run it in 10.1, it'll say every one of those words is misspelled, but it correctly recognizes those in Jaguar.

Another thing we've done is added more access to the fonts we're shipping. So we've been shipping these fonts that have just tons and tons of characters and glyphs, but you've only been able to get to a subset of them through our APIs. We've added Unicode 3.2 support. That increased it some set. And then we added surrogate support. So you now have access to over a million glyphs in all the fonts we're shipping.

We added a Japanese, a better Japanese input method to take advantage of surrogates. So if you're typing in Japanese, you can get to all these surrogates. And I know you're all, you know, trying to find that little pointing finger dingbat, and you can't figure out the key combination. We now have a character palette. You can just see it and pick it.

We've also enabled a bunch more languages in Mac OS X. A number of more languages. But we haven't localized into these yet, but just by putting down a language package on your system, you can now run in these languages. So Cyrillic, Arabic, Hebrew, Thai, and a bunch of languages I can't even pronounce the name. But, you know, probably most importantly, we have finally broken into the lucrative Hawaiian market.

That's right, if you speak Hawaiian, you can now put a Hawaiian localization on your system and it'll work just fine. Number one request. You'll notice we have two languages on here that are right to left. So of course to support those we've added BiDi support to both Cocoa and Carbon.

Alright, let's talk about the file system for a minute. So here's what it looks like when you're running text edit in English with a save sheet down. All looks good? Here's what it looks like when you're running it in Japanese. The menus are in Japanese, the buttons are all in Japanese, but the file system is still in English.

So a Japanese user, when they've just downloaded the MP3, legally, they still have to know... Don't steal music. They still have to know to put that MP3 in this folder called Music, which is in English. So it's really been hard for people in different languages to get around the system. For Jaguar, we give a localized view of the file system.

So we had a number of goals that we wanted to solve when we did this localized view. The first is the same way that our OS is a single installation, and you can have different people run in different languages. We wanted the file system to do the same way.

So when Bertrand logs into the system, he sees movies and music in the French. When I log in, I see those in English. We wanted it to be compatible with previous installations. We didn't want to have to do a big installation that renames everyone's folders. And because of these, we have a localized view. We're not actually twiddling the bits on the disk.

It was really important that we made this incredibly fast. And so there's a minimal performance impact. When you go to the finder, it doesn't hang trying to find out what the localizations are. And if a user renames something, so, you know, there is something called music and someone renames it, you know, our legal music, and then emails that out to everyone at the company, well, the folder everyone sees will be that name that the user renamed it. So great new international support. Let's talk about universal access. It is really important to us that everyone gets to enjoy Mac OS X.

and a refreshing beverage. So most of this support for universal access comes for free. You, the developer, don't have to do anything. We just built it into the system. There is minimal developer support needed for a few of the features. We have the zoom feature that allows you to zoom in to see things. This is absolutely free for you. We have inversion, so it gives a high contrast look. This is free. We have a visual, a visible beep. This is also free, no developer work needed. We have sticky keys.

So for some people who can't type with both hands, instead of having to hold down a chord, they can press one key at a time. So Command, Shift, N, sticky keys, comes for free. We have slow keys. Slow keys is for people who, when they're typing, they might accidentally bump a key, and they don't want it recognized as a key to press. So you have to actually press down a button for a certain duration before it's recognized. So that's slow keys.

We have mouse keys. So for some people it's difficult to use a mouse. They can use the numerical keyboard instead. So all of those things are free for the developer. Now, there are a set of things that require minimal work on your part. Generally, it's dealing with keyboard navigation and our assistive APIs.

We have a really nice API for assistive apps like screen readers and it's a single API for both Cocoa and Carbon. So all this stuff is standard and free if you use the standard controls. But if you have a custom control, Or if you override given features of something and you want custom behavior for a standard control, for Carbon you just respond to some Carbon events.

And for Cocoa, you either override some methods or you implement an informal protocol for the assistive APIs. So it turns out if you use just standard controls and widgets, this is all free for you. And of course, there's interface builder support. It's this that enables the screen readers that you saw this morning. So we have a simple screen reader built in, and other screen readers will be built on this API.

So Universal Access. X is now a very good player in the Universal Access world, and I encourage you all to make sure that your app does play with the Universal Access APIs. And this will really, for most of you, just be a verification exercise as opposed to doing any work.

Now let's get to some interesting stuff in Cocoa and Carbon. Quiz time! Who's ready for a quiz? Ready? How do you spot an IAP? Metal, how do you spot a Cocoa app? Tobar, how do you spot a Carbon app? So it turns out I've seen all these web pages that have like a, you know, name that tune kind of thing. I can spot a Cocoa app in, you know, one widget.

We're trying to make that harder and harder. How many IAPs are on the screen? For those of you who didn't see the keynote. So everyone who didn't see the keynote says two, because there's two things that are metal. Answer? There's one. Metal is fully supported in both Cocoa and Carbon, so if you so choose to use Metal, it's supported and there's great interface builder support as well.

What kind of app is this? Cocoa or Carbon? From the audience. Has, uh, Chasing Arrows. It has a stepper control and it has vertical tabs, so it must be Carbon. Right. Wrong. So we've added these to Cocoa. Cocoa is coming. You know, we're trying to get parity with all the widgets in both Cocoa and Carbon.

What kind of app is this? Well, it's got a toolbar. Must be Cocoa. It has combo boxes. Must be Cocoa. Of course, wrong. No, right, no. So, wrong. We've added those to Carbon. This is a Carbon application, but we didn't stop there. We also added drawer support. So there is full drawer support in Carbon.

Transparent Sheet Support in Carbon. Services Support in Carbon. Font panel support in Carbon. And the color panel. Now you look at these last two and you say, "Wait a minute." Those really look like the Cocoa versions of the font panel and the color panel. And in fact they are. So what we did is we just started taking advantage of those pieces of Cocoa and Carbon. We're integrating Cocoa and Carbon.

Now it turns out we've been doing this all along. We haven't made it public for you for the UI pieces, but all along we've been using one framework from the other. And now we're opening up the UI piece to you. The other part has been open the whole time. And people say, "No, that's not possible. You haven't been integrating the two." So let's look at this. This is just a screenshot of TextEdit, the canonical Cocoa example. We shipped the source. You can look at the source.

TextEdit supports QuickTime. You've been able to drag QuickTime movies into TextEdit and they play in line. There's a print panel on it. So what part of this is actually Cocoa? Well, you know, QuickTime's carbon-based, so that's not Cocoa. So the rest must be all Cocoa, right? Well, turns out we just used the Carbon print panel since Tano shipped. So that's not Cocoa. And actually, it turns out the menu bar was Carbon as well.

So it turns out, even for our canonical example of Cocoa, there's a lot of Carbon in it. So we've been doing this integration the whole time. But here's what we've been telling you. We've said, you're on this road and you get to choose which way you want to go.

You can choose to go down the Carbon road, you can choose to go down the Cocoa road. The problem is you get way down that Carbon road and you look across, there's no trees, and you see something on the Cocoa road and you're pretty jealous. You want to take advantage of it.

But the solution has been, well, back your car up all the way to this juncture and rewrite your app in Cocoa. Right? That's not a very good solution. What we're doing for Jaguar is we're giving it a single road. When you're driving down that Carbon road and you want to take advantage of Cocoa, you change lanes. You take advantage of some Cocoa. As you're going down the Cocoa road, you can change lanes and take advantage of Carbon. We're integrating the two for you.

So really, you can use Cocoa and Carbon from each other. Now it turns out non-UI integration has been available for a while. I've heard people, I've seen, you know, complained about, and I've seen on mailing lists, people who are developing for Cocoa, and they say, "I want to read in this file and it has a resource fork, "and I can't get to the resource fork. Why don't you add some APIs for me?" I say we have APIs for you. It's called the Resource Manager.

The Resource Manager is a C API. A Cocoa app can link against and use any C API. I mean, you can use standard C libraries, right? The Resource Manager is the same way. It's just a C library. You can call it from Objective-C. Objective-C is a superset of C. So you've been able to do this already. We talked about these new spell checkers. Those spell checkers are implemented in Cocoa. But anyone who's using Carbon can call directly into that spell checker as well.

And now we're enabling you to do window-based integration. So you can have a Cocoa window inside a Carbon application and vice versa. Alright, let's talk about building blocks. And the future. So whenever people talk about objects they often get to Legos and say you build things with Legos. So this is what it looked like in Tenno, right? You had a, let's say the left structure here is a Cocoa app and the right is Carbon.

And they looked like they were completely their own thing, right? It was all Cocoa and all Carbon. What I've shown you is if you open up the hood, on the Cocoa side we were using some of the Carbon pieces. And on the Carbon side we were using some of the Cocoa pieces.

For Jaguar, we're enabling you to use whole windows from the other framework inside as well as the non-UI pieces. Now our long term thinking and what we're planning not for Jaguar but beyond is to allow you to choose based on a widget. So you can truly use the functionality you want from a given application. application. There's a really good document. I encourage you to download this and read it on connect.apple.com that talks about this integration. But you know, you really got to see it to believe it. So let me show you a demo.

To set this up, there's this company called Tweakfilms. And it's a relatively new company. It started by some guys who used to work at ILM, Industrial Light and Magic. And they're a few of the people who helped work on the animation scenes for A Perfect Storm. Right? So the amazing water animation scenes.

And they'd implemented their stuff on top of Unix. I think they were SGI boxes. And so they were looking for a new platform to go to, not surprisingly. And they looked at Mac OS X and they fell in love with it. Because Mac OS X had great Unix underpinnings. So they could port their stuff directly across. Then they wanted to throw a UI up. And they found the fastest way to create a UI was to use Cocoa. So they created a great Cocoa UI. So it works really, really nicely on X.

Well, as you know, a few weeks ago, Photoshop shipped on Mac OS X. And Photoshop is the canonical CFM Carbon application, right? Very large application, moved over to Mac OS X using Carbon. Now, I was looking at Photoshop, and I really wanted to have some of that TweakFilm's water filters put in.

But, you know, how would that be possible, right? It's a Cocoa application. Well, it turns out, in Jaguar, you can host Cocoa plugins inside a Carbon application. So here is Photoshop, and this is an unmodified Photoshop. We'll bring up this ducky. The ducky looks like he really wants to be in water.

So let me do a selection of where, let's see, let's do the magic wand selection. Go ahead and take off some of the top part here. Alright, so now I have a selection of where I want to add water. I go up to the filter menu, and there's one thing here, Cocoa, Tweak Waves. When I let go there, what it just did Is it loaded, it dynamically loaded a Cocoa plugin? This is Cocoa running inside a Carbon application.

And you can't tell the difference. And that's the point. So, let me change some of the wind angle here. Uh, oh, I like to go ahead and let's reflect it. And of course the thing they're famous for is a little animation. So it's great graphics brought over because we have Unix, a Cocoa application or Cocoa plugin running inside of Photoshop.

Go ahead and say, I like that frame right there. I say okay. It takes, filters the image, adds the water. It's that simple. So you can bring over your Unix applications, you can use Cocoa, and this can be embedded completely within a Carbon application without modifying the Carbon application. So over the last year, we've been doing a lot to evolve the frameworks. And we expect that we're going to see a lot more revolutionary applications from you because of it. Thanks a lot.

So this is the end of our agenda. We talked about evolution, revolution, and how they apply in New Links land and in frameworks. And now last but not least is this morning, hopefully you got this set of CDs. We've put a lot of our heart and a lot of nights to get those to you. And it's pretty software, so don't depend on it. However, we believe you will enjoy it. And there's a lot of features and that's the way we're headed. So please give us some feedback. Thank you.