Announcer: Ladies and gentlemen please welcome senior vice president software engineering Bertrand Serlet.

Good afternoon. Last year at the developers conference I concluded the state of the union by observing there's been a shift in how applications have been designed. A long time ago application were designed solely for functionality. If you were responding to the spec that's it you had an application. And with the Macintosh, of course, that's changed. An application, to be successful, had to be easy to use.

Over the last couple of years I think we've gone to the next level. Your application needs to amaze its users in order to be competitive and to be a great success. So from this derives our mission, which is to help you create amazing applications. And there's different aspects that are going to drive our agenda.

The first one is that for creating an amazing application you need to really leverage the silicon we are living under Moore's Law, which is a great time to live in. And the power is amazing. But we need to make sure that all the power of the silicon flows through the API'ss to your application.

So, that's the first point we'll cover. Of course you need to develop your application quickly. You want time to market. You want to have the right foundations so that you don't have to reinvent the wheel and so we'll cover those foundations. And of course you need to have the right experience, user experience for your applications. And that's our next point. Now to cover those three aspects I have three esteemed colleagues of mine. First Simon Patience who heads Core OS that's pretty much everything non-UI in the OS, the kernel things that layer, the Unix layer and so forth.

Next I have Peter Graffagnino who heads IMG. And IMG's responsible for the audio and the video on the platform. So Peter and his team are saturating your ears and your eyes, that's their mission. Last, Scott Forstall who heads platform experience at the higher level of the OS. That's the system applications, the HI, the UI frameworks. And Scott also heads this other little project on the side that's called iPhone.

So, let's start with power. Who would have thought that we would be shipping an 8-way config? And that's what we've done. Just a few months ago I'm sure a number of you already have that interface, MacPro and new MacPro that's an 8-way. We've come a long way if you go back in history to the first days of computing.

That's the ENIAC in the late 40's, and it was for many a revolution, but another revolution came in of course, with microprocessors. And one aspect of the microprocessors is that very quickly they increased their bit width, 4-bit, 8-bit, 16-bit, that was of course the era of the PC.

And then they moved on into 32-bit and it's only in the last couple of years that 64-bit computers have made it to the mainstream, to the consumer. So, to talk about 64-bit and in general some of the other aspects of power of our modern computers and all this power that's derived from Moore's Law and the silicon, I'd like to ask Simon to come on stage.

Good afternoon. As Bertrand said I run Core OS which creates the software that runs at the heart of Mac OS X and exploits the power of the CPU board silicon. And as he also mentioned we don't do UI. Some people say that the lack of a pretty face extends to me but I don't take any notice of them.

So, first of all we'll talk about 64-bit. Now, the last WWDC we only had the Pro platforms that had 64-bit capable processes. But we've been busy. And now if you look at all for quadrants of our major product lines, the Macbook, the Macbook Pro, the iMac and the MacPro, they all have something in common, which is that they are 64-bit capable. They can run 64-bit applications.

So, why 64-bit? Well, with no legacy instruction set the, or legacy, the instruction set is optimized for fast performance. And in addition on Intel there are more registers to use and so therefore you go back to memory less frequently which increases your performance of your application also. But perhaps more importantly it's the address space, the virtual address space of your application.

With a 64-bit address space there is much simpler programming model. You map all of your data into application and there's no data window to slide up and down as you saw this morning in Steve's keynote, which also can lead, as well as simplicity, to faster applications. The other reason for 64-bit is physical address space. With a 64-bit physical address space you can put in lots of physical memory, lots of RAM. And of course, if you have a virtual address space in the physical address space that's large, now your application can be backed by real memory which increases the performance again.

So, we have had 64-bit machineds for a while. And in Tiger we support the 64-bit but only at the Unix layer. We had the MacPro and the G5 and we supported 64-bit Unix appldications. But now, with Leopard we have 64-bit all the wday up the stack. Now, I also mentioned that there was some exceptions last time no 64-bit CFM, low level QuickTime API's, Sound Manager, QuickDraw, and we've had to add to that list. And so now there's no 64-bit Carbon UI. So Cocoa UI is the way to go for the 64-bit world.

Now we could have a 64-bit, 32-bit, product. But we don't want to do that. It's confusing for customers and also it makes it confusing for the applications which version you want to run on. So we have one SKU, a 64-bit version of Leopard. It will run on any machine, 64-bit or 32-bit processor. And if it's on a 64-bit procesdsor then it will run either 32-bit or 64-bit applications in one product.

Now, we want you to do that too. For your application, your great app, we don't want you to have two SKUs. We don't want you to confuse your customers. And so, consequently we want you also to have a single SKU that can run either 64-bit or 32-bit depending2 on the platform.

Now, you can do that because we have 64-bit tools. Our tools can build a single applications executable which contains both the 32-bit binary and the 64-bit binary in a single package which you can ship to the customers. And you can start doing that in October this year when Leopard ships. So that's 64-bit.

The next thing I want to talk about on the CPU board is not the processor itself but the Vector engines. The Vector engines are a very powerful part of our processor and help accelerate your app. Literally accelerate. And the Accelerate Framework is the way that you can take advantage of these Vector engines. Now you're probably thinking well, you know, what's in there? There's four basic components of the Accelerate Framework. There's the Vector math library, there's linear algebra, signal processing and the image processing libraries.

Now you're probably thinking well, you know, I'm not a PhD. I'm not quite sure what to use all these things for. So, I thought I'd give you an example of where we use these libraries and the functionality in our own apps. So, for vector math, we use this extensively in SoundTrack Pro.

The linear algebra routines are used in junk mail filtering and in mail and also to process the Japanese Input Method. Signal processing, iTunes of course. But iTunes calls FFT one million times per hour. So, these functions have to be very, very fast, and also, in the accelerated speech feature of our accessibility functions.

In image processing we use it for scaling in QuickTime. as you pull the windows out. We use it for raw image conversions from your camera and also Final Cut Pro in de-interlacing. So, we use these functions extensively in our own applications. And we believe if you're doing things like we're doing then you'll be able to get great advantage out of the Accelerate Framework in your own applications and speed them up significantly. So you need to accelerate your application. We have a complex functionality, this math functionality encapsulated behind these API's in accelerate. You can think of this as basically being your PHD in a box.

We have industry leading performance. When we compare ourselves to other implementations we either meet or beat an awful lot of these same API's from other places. We have a platform independent implementation. It doesn't matter if you're on a PowerPC or you're on Intel. We'll pick the appropriate Vector engines. It doesn't matter if we've got SSE 2 or SSE 3 or wide instructions. Whatever it is that the platform has we'll use it. And in addition, we will actually also multi thread the API's for you to get additional performance.

And we're future proofing your application. The next round of the Intel processors with new and improved Vector engines, we will make sure that our API's and Accelerate Framework extract the last ounce of performance out of those new features and also out of the new CPU's as they come along. So, that's the Vector engines.

So, finally I'd like to talk about multi cores and more multi cores. And the fact that we have now large scale SMP on a consumer and PC platform, 8-way machines. So we'll do another trip back in time. We started off with a slow single processor. It took about ten years before we got the first dual processor machine and another ten years before the first dual core arrived. And then quickly follow up by four way configuration in the MacPro.

And then a year later the first dual core on a consumer platform and then a year later the first quad core and the same year we now have an 8-way configuration. So, you can see the trend is, toward multiprocessors is going exponential. We are rapidly increasing the number of processors within a consumer product and a PC product. So that's where the hardware's going. What about the software? Well, for MP hardware you need MP software. What we've done about it we have a scalable OS Core, we have multi-threaded graphics, and we've made our applications MP ready.

So what do I mean? Let's look at each of these. Scalable OS Core, we have the heart of Mac OS X we have the Unix operating system which is a traditionally very scalable system. We've taken things further, in the file system we've added attribute caching to be able to reduce the contention in the file system. In networking we have multiple input threads to be able to support multiple interfaces on different CPU's the BSD has gotten better pthreads faster thread creation and termination. We have faster synchronizations primitives.

The VM is another source of contention in the kernel. We have finer grain locking to be able to get through those VM operations much faster without having to coordinate between CPU's and applications. Even in power management we have asynchronous interfaces now so on power events we can actually do multiple things on different CPU's because the events are asynchronous.

And finally in the kernel core we have per CPU run queues for the scheduler which means we can get hold of your application and run it even faster without having to coordinate across CPU's. Now what does that actually mean when you put it all together? Well, if you look at Tiger, so, this is actually a graph of how much of a CPU do you get when you add an extra CPU? And this is a make of a large source space. So, if you look at Tiger as we add CPU's we get a smaller percent of the CPU each time until by the time you add in that 8th CPU you're only getting about 40 percent of the CPU.

Tiger was never designed to run on machines that big so that's not really surprising. But with all the scaling work we've done with Leopard we have about a 30 percent increase in CPU utilization by the time we get out into the 8th CPU. And so, we're now up into the 71, 72 percent oqf the CPU. It's actually there for your application to use. And this is clearly not the end. We'll be continuing to work on that and improve the amount of CPU utilization that your application can have as you scale up these machines. So, we've done our work in that area.

Multi threaded graphics, OpenGL, Core Animation, Core Image. So we'll start with a Tiger OpenGL workload. Now, GL is actually executed in the same context of the same thread of your application. So you can see that you don't actually get it in concurrency until you get to the point where you can put the work on the GPU. Now, even if you added a second CPU into this picture it doesn't help, because I said, the GL framework is running in the same thread context.

However, in Leopard we have multi threaded OpenGL. And as a consequence when you call into GL it's gone to thread and now you can do the work in parallel with your application which in itself can be done in parallel with the GPU. So, you can get a lot more operations done in the same given time frame. But we haven't just done work in OpenGL.

We've also multi threaded Core Animation. And for this we needed an extra CPU because now when your application calls a Core Animation function which then goes down to OpenGL they're going to all run in parallel because they all have their own threads to be able to execute in. So, you can see that in a given period of time there's even more work that you can do if you take advantage of these multi cores which means that your application could give a richer experience, visual experience to the end user.

So that's OpenGL and Core Animation. With Core Image we've also put a lot of parallelism into that. and so, consequently in this conic filter with each CPU we can render almost a linear improvement in its scalability. So, every time you add a CPU it just gets faster and faster. So, you could see throughout our graphics we're MP ready. We have the frameworks running in separate threads for OpenGL, Core Animation renders in a separate thread, and Core Image we get a linear scale up for the API's.

So what about our applications? They need to be MP ready. But before we talk about that let's take a look at something else. Now, we've all seen these, very rarely of course, but what actually causes the spinning cursor? Well, it's because your event thread is non responsive. And it could be non responsive for a couple of reasons. The first one is it's picked up something from the run loop and it's going off and it's processing a long operation. Some computation, something that's really not being done asynchronously. And so while it's doing that it can't respond to the next event.

Similarly it can go off and be waiting for synchronous event. So, it's actually not even doing anything constructive. It's sitting waiting for some network activity or something like that. But it's still not responding to the network events in the run loop or to the events in the run loop.

So that's what causes a spinning cursor. But it has another effect, it prevents concurrency if you're sitting doing other stuff and more events are arriving you can't be processing them. So, there's no opportunity to have concurrency in your application which actually therefore prevents scaling. And when you're on an 8-way that's what you want to do.

So, you need to make your app MP ready. You do that by being event driven off the run loop. We all know how to do that. But we need to be able to have external events to react to, so notifications. But I think we also need a new MP model.

So, let's talk about notifications first. We know about the Cocoa notifications and in Tiger we introduced BSD notifications. It's a very simple, just a name to rendezvous and no payload. They're extremely fast point to point notifications. But it also has an option to do multi cast notifications by shared memory which are incredibly cheap to invalidate the cache of all other processes by just calling a simple API which does a memory reference and then everybody has been notified of the change of state, very fast, very cheap, very powerful. Now, there's another form of notifications that we've been asked for many times. And we've always had difficulty in working out how to do these efficiently. But in Leopard we think we've solved the problem. And so we have file system change notifications in Leopard.

So, as file system change notifications we can watch entire hierarchies with one call. You only rescan what has changed. So you only get to go off and do the work when the file has changed. And the other interesting feature about file system change notifications is if your process exits and restarts it will get all the changes since it last run. So you don't have to leave your application lying around.

We find this incredibly important and useful for Finder, for Time Machine. These are very powerful API's which we think you'll be able to leverage to great effect also. So, file system change notifications.

I mentioned an MP model. Now, what is today's MP model? MP model for today is threads. And that's pthreads NSThreads and all the inherent complexities of threads. Which is, how many do you need? What do I do if one of them blocks? You know, all the synchronization problems associated at the priority management, very complicated to get right. We think we have a better answer for you and that answer is NSOperation.

NSOperation is a simple pair of interfaces. You basically take the design of your application and you break it down into work elements. You can define the priority to these work elements and you can create dependencies between them. So you make sure that one doesn't run before another. And when you've got them all together you just put them on an operation queue.

But this is a really quick operation to be able to queue up a work element. So, you don't get that spinning cursor because you can then go back and wait for the next event. Now, NSOperationQ is the thing that does all the hard work for you. And it will schedule all your work on as many CPU's as you have in the system whatever that is or as many as the OS will give you.

So, NSOperation, we think, is the new MP model for your application. It allows you to simply divide up your work, queue it up, and then maximize the scalability of the machine that you happen to be running on. You don't have to worry about whether it's a two processor four processor, eight processor machine. the system will be able to get the maximum concurrency out of the amount of work that you've given it and will handle it all for you, so, NSOperation, a new model for MP.

And we've used notifications NSOperation in our apps both the BSD and the fast system change, notifications in our own apps, in Finder, in Mail, in iCal and others. And we find that we both get a better scaling and a better responsiveness from our own applications, which you'll see in Leopard. And we believe that you will get them yourself. So, scale your application because multi cores are here and they're going to get there's going to be more of them.

You need to get your app MP ready. And you do this by freeing up your event thread. You use notifications and adopt NSOperation. And of course, test on an 8-way. So ask your boss to buy you an 8-way MacPro. ( Applause ) So that's MP and the power of the CPU board silicon. And next I'd like to invite Peter up here to talk about some other silicon that's very powerful, the graphics processes.

Thanks Simon.

Good afternoon. I'm going to take you on another little trip through time and look at graphics, in particular game graphics. Some great old memories I'm sure fly by for some of you in the audience as you see these. And as time went on we started to get more and more 3D immersive environments starting to employ the GPU to play games. And you saw the great demo from John Carmack this morning of the incredible new technology. Now what's going on though with these GPU's versus CPU's? I thought I'd do a little graph here.

So, the CPU is, you know, it's the main processor. It has a lot of, it's going more and more parallel. But the GPU is really becoming more programmable and is capable of real computation as well. Let's do a little comparison. So, compare the number of cores in a state of the art CPU versus GPU. We've got 4 in a CPU and 64 in the latest graphics chips. That's 16 times.

Let's look at giga flops. This is a core two duo Pentium 4-way 50 giga flops, 350 giga flops in the latest GPU's about the same from NVIDIA and from ATI. That's a 7X advantage over the CPU. Look at memory band width, six giga bytes per second in a MacPro, 100 giga bytes per second in a GPU memory system. So that's 16 times the efficiency.

And I don't think it's a wild prediction to say that the next generation GPU's are going to deliver a Teraflop of floating point performance, which is really incredible. So if you think of all the competition it's creating in computer architecture it's really an exciting time if you need a lot of computational horsepower. And people are starting to notice. And it's really not just about games now. People are looking at doing scientific computations on GPU's.

For example, there's a problem in medical imaging, which is called image fusion where you have 3D data sets fr=om a CAT scan or MRI. They may be taken at different times with the same patient or may different data sets that you want to align and analyze. And the issue is that things might not quite line up exactly and you really want to be able to compare things. So, you have a big search problem in 3D space with these huge arrays lots of data really difficult problem.

Now, there's a pretty popular library out there that does this on a CPU that people use it takes about 30 minutes on today's CPU it's a big computation. Some researchers running on Macs at the University of Calgary in Calgary Scientific implemented their version of this algorithm on an NVIDIA GPU and they were able to do it in eight and a half seconds. It's an incredible speed up almost 200 times.

So, something is really going on here. they're using both the CPU and the GPU both running flat out doing a lot of computation on the GPU, all of the high band width computations there and then a lot of computation as well on the CPU running the thread optimizer. So, it took a lot of work for them to kind of re factor their algorithm into this computational engine of both CPU and GPU. But it really paid off.

And so I want to try to think a little bit about are there fundamental differences in CPU's and GPU's? Or are GPU's just going to take over the world? And I don't think that's true. I think these things will remain distinct. They may some day be on the same chip together but they're really two different design points in computer architecture and I'd like to cover those.

The first is sort of random access versus streaming access. If you're building streets and you want to get to every house in the neighborhood, then you've gotta build small streets and you've gotta have lots of corners and usually a grid is relatively efficient. If you're building a highway you're only going to have a few exits, you're going to have lots of lanes. So, it's a totally different design point. And that's the same when you're designing architecture for CPU's and GPU's.

Think about latency versus throughput. You can design something that can turn really fast. The CPU can take interrupts. It can branch its execution really quickly. A GPU is more like a bullet train. It goes real fast but, you know, if you want it to go somewhere else you gotta lay some more track or turn at the next junction. So it's, again, a design trade off for throughput versus latency.

Another important difference is how parallelism is expressed in the API's. For a CPU you pretty much have to tell it every load and store to do. so, if you're going to compute an image you have to say read this pixel write that pixel read this pixel write that pixel.

So if there's any parallelism in there, you've kind of lost it all because you're telling it explicitly what to do in a serial fashion. And any parallelism isn't really implicit. Versus, on a GPU, you would just say compute the whole image. And the GPU, because you've expressed the problem to the GPU in a way that has no dependencies it can compute the image in whatever order it wants.

And so, this kind of parallel, explicit versus implicit parallelism is real important to think about. Another is the compilation model. And this is more of a software historical artifact. But CPU's have traditionally been binary compatible. So, you can run, you know, an old x86 binary from 1990 assuming the OS is the same and it'll just work.

So, instruction sets always been the same. And nothing can be further from the truth in GPU's. The micro architecture in every GPU generation is radically different. And so, what, the graphics driver actually has a compiler in it that re expresses the algorithm and optimizes it for the particular GPU.

So, one of the issues is with all this stuff going on parallel processing can't be hidden from the programmer, at least the low level programmer. Those of us that write a lot of really computationally intensive algorithms like code X or image processing or just numeric computing are going to have to deal with some complexity in the coming years. And I think that's real important and exciting.

Now, Apple certainly is here to help you. We have the API's that Simon talked about NSOperationQ, plus traditional Unix message passing. And we have GPU ready Frameworks talked about Core Image and Core Animation, OpenGL is kind of the low level API to get right at the GPU. But there's also a lot of research going on in parallel computing.

GPGPU is a general classification of general purpose computing on a GPU. A lot of interest in that, people are looking at stream computing languages, functional languages, and different transactional memory models that are more like data bases that don't have locks on pthreads everywhere. So at the low level I think there's going to be a lot of, a lot of interesting innovation in software approaches to parallel processing as well.

So, I'll end with a few predictions. This one's probably not very controversial: CPU's will get more cores. GPU's will get more programmable. They'll be able to take more branches and do more computation. But the fundamental architectural differences are always going to remain between the GPU and the CPU. And we're going to be challenged, those of us that work close to the metal to come up with some new approaches to program these things. But as always, our mission at Apple is to try to keep it as easy as possible for the application writer.

And so there'll be lots of work to do to kind of take advantage of all this processing power. So, that's all I wanted to talk about today, was just give you a taste of the innovation going on in the architecture field and look forward to all the great apps you can build with all the computational power that's coming. So great, thank you. Back to Bertrand.

Thanks Peter. So, definitely a lot of interesting silicon in the GPU as well as in the CPU, but you know, it's never enough. People want to have like lots and lots of silicon, entire rooms filled with silicon here. Of course I'm talking about server installation. So the server product, Mac OS X Server has quite a bit of history. In fact if you go back to the way it started it was in the AppleShareIP days. If some of you remember, I mean some of you weren't born then. But that's when it all started.

And the AppleShareIP product was very simple and in fact that was kind of its main differentiator it was easy to use. Okay, that was the Apple value. And in terms of the services that were offered, well it had file and print, okay. That was pretty much it. And that was actually great for a couple of markets, the creative markets and the education market. But that was it. What was kind of missing was the element of power.

And of course with Mac OS X, we had Mac OS X client, we had a Server version. And that had a lot more power because suddenly you had all the power of Unix. And that was one of the premises behind Mac OS X, is to ally the simplicity of the Mac with the power of Unix. And the server definitely benefited tremendously from that. And we were about to add new services, things like Apache okay started out web server on the Internet.

And so, that in turn opened up kind of new markets things like Higher Ed or the Enterprise. And we iterated over the years with that product. Each version of the client OS had a version, a similar version with the server. And the latest that we shipped is, of course, Tiger server. Now Tiger server has a pretty extensive collection of services because what's happened is that we added a whole set of services.

The services that we have typically come from Open Source, what the server product has become, in the Tiger days is, a container for Open Source services. We take the services that are proven and that are reliable because Open Source software is always more reliable than the software you just wrote. And we just make sure they work well together.

We test them and we put a nice user interface. And I think this has opened up yet new markets, more new markets, things like small enterprises or big computing centers. In fact, we've had quite a bit of success with Tiger server in terms of high performance computing, which is not at all what we had worked to build in the product. It just happened and that was great.

Now, let's do kind of forward, let's move forward now to Leopard server. And what we're adding with Leopard server is innovation. There's a lot of innovation in Leopard server. We start with all the services that we have in Tiger and then we add a new set of innovative services.

I'm not going to cover them in detail because that will be covered in this conference. But there's things like a new Wiki server that's really great. There's a Spotlight server, there's Podcast Producer to help you produce Podcasts, lots and lots of innovation. And I think we are going to create new markets that will leverage all this set of server features.

So, that's Mac OS X Server. And it's very pleasing to bring innovation in the server space where in the past we've been kind of having, for the most part a container of open source services. That's kind of the new step in the evolution of the server product. So, we've talked a lot about power.

We talked about power of the CPU 64-bits the Accelerate Framework and MP, the power of the GPU and the large scale power coming from server installations. But what you want is not just the power. You want the ability to create your applications quickly. You want to build applications fast.

And this has been a preoccupation that we've had since the beginning of the Macintosh, way back in system one in the Mac OS 1 days, I think it was called system one in those days. We've focused on having a Toolbox, in fact the Macintosh had the first GUI Toolbox in those days.

And Toolbox is all about reuse of the code that we do so that you can create fantastic applications. And the Toolbox evolved for the years, see, stacks of inside Macintosh, those of you who were born then, grew a little bigger, it grew a little more complex. And so with Mac OS X we've took the opportunity to really simplify all this.

And that yielded the Carbon Toolbox that was a clean up of the old Toolbox so that it can last another decade. We also added the Classic environment to make sure that we can bring along our users from Mac OS 8 and 9 onto Mac OS X. And of course, we added Cocoa, our toolbox for the future moving forward with object orientation and so forth.

Now as time went by we stopped investing in the classic environment. There was no need since you had brought all these native applications onto the platform. Then a few years ago we engaged into another transition that was the Intel transition when we switch from PowerPC to Intel. And one of the things that we built in which is really a key for a successful transition was this Rosetta Compatibility box to make sure again we can bring our users along and that we have a successful transition. Now, I have to tell you that pretty much as soon as we shipped it we stopped investing in Rosetta. We haven't been spending much resources on Rosetta at all. We know it's going to fade away notably because you've brought many universal applications on the platform.

Now there will be a time in the future when we will stop investing in Carbon, a lot.

A lot of the new energies all the energies or resources go to Cocoa frameworks. Cocoa is our toolbox moving forward and that's why we decided to have the 64-bit UI expressed only in Cocoa and not Carbon.

Cocoa is how we implement most of our system at, it's kind of our little secret for fast implementation of apps. And in fact, even the new Cover Flow in finder is actually a Cocoa object that we reused. Now Cocoa, as you know, is best on the language and that's a very big leverage point, the language, because of course it affects a lot of lines of code. So, I'll talk a little bit about the language.

Then there's all the Cocoa frameworks and of course there's the tool that much really match with both the language and the frameworks to get the full productivity. So, I'm going to cover briefly each 3. So first let's start with the language. The language for Cocoa is Objective-C. Now Objective-C is really mostly C if you look at the B and F it's mostly C. What we added to C is a very thin layer to do object orientation, to define classes and methods. And at the heart of Objective-C you have the dispatcher, the message dispatcher.

And that's the Runtime. And it's very powerful, very dynamic. Now when we look at what features we are going to add to the language to have more productivity, we want to be very careful in adding just a few things. But we have a number of goals in mind.

One of the goals, of course is to have the language more expressive so that you have less code to write. Less code is always a good thing as we know as long as the function remains the same. We want to make sure that the code is inherently more reliable.

We want to make sure it runs faster and I'm sure everyone appreciates that. And we know that there are many folks who come into the platform, we have seen a tremendous growth in our developer community over the last few years. and those folks typically do not know Objective-C. So we want to make sure we lower the bar to entry that it's more approachable. So, with these goals in mind the first feature that we added to Objective-C is we added Garbage Collection to the Runtime.

So, garbage collection is opt-in, an application decides whether it wants to be garbage collected or not. And we actually ship in Leopard two applications that are garbage collected. The whole set of Cocoa frameworks works both ways, either collected or not collected which I think is kind of a first for garbage collected system. And when you use a garbage collector you have a very modern very efficient garbage collector. It does multi-threading correctly it's using all the modern techniques for being incremental and generational.

So, obviously with a garbage collector you have way less code because you don't have, you know, all this memory allocations, deallocation code And your code is extremely reliable compared to standard non collected code. I mean we all know that many of the bugs come from allocation issues. I'm not going to claim it's faster. It's definitely a little bit more work fundamentally to clean up, to find out what is garbage and stash that away.

And, it's definitely more approachable. In fact, the other few come from languages like Java or the scripting languages. Well, all those languages are garbage collected, all modern languages are garbage collected. So that's the first feature we've added to the language. Second feature, a very, very common pattern is to have collections, collections of things and then you want to iterate in that collection. So, it used to be a few lines of code and we just added a "for each" construct that enables you to have a single liner. It's very conceptually simple. It's correct because it's actually way more expressive, way more readable.

It's more reliable because it has certain properties when you muted the collection underneath that now it's detected. It actually runs faster because we've added a protocol to each (inaudible) in the arrays in such collections by batches. And it makes the code more approachable as well. The third feature we added is the pattern to have accessors, to have like setters and getters.

So you can take this entire pile of code to do setters and getters and do it right with the memory allocation. And just change that with just one line. And that's a properties feature, again, a lot more expressiveness, more reliable, less opportunities to have subtle errors, and more approachable.

And last, we have an enhanced Runtime. We've totally optimized the Runtime for 64-bits. We had no binary constraint, binary compatibility constraint in the 64-bit world. So we took advantage of that to make sure we have like the speed of light in terms of execution. And we also adopted a C++ exception model which is faster when you don't take an exception. So we have a number of features here.

I mean it's not a huge set of features but they're very leveraged they impact your code if you choose to use those features. And so we call that Objective-C 2.0. We think it's a sufficient step in function. So, that was a brief overview of what we've done with the language. Now, let's talk about the frameworks.

We've had over the years a number of Cocoa frameworks. Some of the frameworks that have been there from day one our foundation, which is kind of the non UI portion of Cocoa and the AppKit to do a GUI frameworks. And I'm not trying to do an exact picture here of the Cocoa frameworks. Now we added a number of frameworks over the years. Some that I want to mention because I think they are significant: our CoreData to deal with persistency, CoreImage framework to deal with image transformations, WebKit to deal with everything web, notably rendering HTML.

And the AddressBook framework that enables you to use the same data base as the Address Book application is using underneath which is a per user persistent kind of data base. So, in Leopard we're adding more frameworks some of them that I mentioned, one to do something very similar to the AddressBook framework which is a CalendarStore API that enables you to access the data base that iCal is using with the events.

And ImageKit, which is a framework to deal with images, collection of images. And last but not least CoreAnimation, to deal with animation. So I'm not going to cover all this there's a lot of sessions that will. I just want to put a plug here for ImageKit and CoreAnimation because I think they are frameworks that many of you will be able to use in a number of applications.

So, first, let's talk about ImageKit. ImageKit has a number of facilities. One of the facilities is an object called, a class called BrowserView to just display a bunch of images along with the labels. And you have all kinds of bells and whistles to actually control exactly what you want to display.

It's very fast. We've tested it up to a quarter million images. And the reason why it's really fast is that we are fairly optimal in terms of totally leveraging the GPU for rendering and making sure we use a minimal amount of memory. Obviously if you are loading in all the memory for all the images in your process you are not going to scale up to a quarter million images.

Another object you may benefit from is the slideshow object. So now if you have a collection of objects you can do what we've done in a number ofapps, which is provide the user with a slideshow. We have a picture taker object so you don't need to learn how USB and Firewire cameras work or built in cameras.

You just have a few lines of code and now you can leverage a camera that's present in nearly all the Macs that we ship. And we have an object to let end-users do simple editing of images. This is not Photoshop. This is simple image editing. But again, it's very easy for you with just a few lines of code to set up your application so that it proposes an image editing panel.

Next, Core Animation, now you saw Core Animation this morning, you've seen the wall, the Apple TV wall done with Core Animation done in just a few days for the initial kind of wall. And it was fun to see that demo kind of come together just in the last few weeks. And you've seen it in action. You've seen Core Animation in action when you saw Time Machine because that's all implemented using Core Animation.

Core Animation is to render scenes. Now the scenes that it renders, the model is that you have a hierarchy of layers. It's not just a flat set of layers. It's a hierarchy which means when you want to move a portion of a tree everything kind of moves along.

You have some constraints that you can express very simply for the layout. And you can use that for really two different purposes. You can use that for the contents of your application for the main document if you want, which is kind of what we did with the wall.

Or you can use that for the UI of your application, or the widgets, or the chrome, kind of, of your app. And we have two API's we have the Core Animation API per say that you use for the contents that's really easy to use. That's all implicit so you specify how you want things to be, you specify the new state of things and it automatically derives a transition that needs to happen in time. Or you can use the AppKit API which has been integrated with the Core Animation API. And then your view hierarchy will transform into a scene hierarchy into a layer hierarchy which will get rendered. And we have Interface Builder support for it.

So this was a very, very brief overview of a couple of the frameworks there's a lot more. But to get the full power of the frameworks you need to have the tools, the right tools, that's really a design with integration in mind. And if you go back in time the history of tools at Apple has been a little checkered. You know, sometimes on sometimes off. And it's really with Xcode that we committed big time on tools. This is the first time that we decided we'd have a great set of tools and we've stuck to it and we're sticking to it.

So after the introduction of Xcode 1.0 we have Xcode 2.0 to make sure it has all the features that you need. And of course after that we spent some time to make sure we prepared for the universal binaries for creating universal apps. And what's really pleasing is the last year has been spent mostly on innovative features, you know, beyond kind of the nuts and bolts. Now that that's done we can move on onto kind of new features.

Some of the new features Xray, Xray is an application to deal with performance and we've had a great collection of performance tools, things like Shark and Sampler and all that stuff. But it was very disparate there was no unity in all those performance tools. And now with Xray we've unified all that with a notion of time kind of passing by which is always present in performance.

Another new app that we have part of the developement tools is DashCode, which enables you to create widgets very simply. We have a new Interface Builder. Interface Builder that we've rewritten from scratch. And it's very, very fresh. It has, of course, it has more power with the Core Animation properties and all that stuff. But it's very fresh. It really feels very different.

We have Automator tool in the Lepoard tool set. Now Automator 1 we were really pleased how Automator has done that. It enables people to really design simple work flows, people who are not necessarily hard core programmers. And what we've done with Automator 2.0 to work is retain the simplicity the spirit of Automator 1.0 but at the same time add quite a bit of power with things like variables so that now you can have work flows that are a little more complex.

But there's progressive disclosure here and you are not faced as a sophisticated user using Automator with all that complexity. And the last app that's part of the set of course is Xcode itself. We use Xcode both to name the umbrella of the whole set of development tools as well as the IDE. And there's lost of iterated features in X code.

So, we've talked about language, frameworks, and tools. And if you step back this is all about knowledge, encapsulation and reuse. Everything we learned by doing our own system applications we try to encapsulate and put that knowledge in these frameworks and these tools. And this is actually what we do across different product lines as well. All the knowledge we've had built in Mac OS X we've been using that knowledge to build Apple TV and the iPhone.

Those products were built with the same language some of the same libraries and the same tools. So this is all about building applications fast. But of course applications need to have the right experience. And for that I'd like to ask Scott to come on stage, Scott.

Thank you friend. Alright, I get the pleasure of walking you through the Leopard user experience. But first, let me take you back in time to the user experience you missed.

Now that was a UI, text based, command line. And then we screwed it all up in 1984 with this little thing called the Mac.

So, the Mac really changed everything. It, for the first time, brought a graphical user interface to the consumer with multiple windows, true WYSIWYG, all accessible with a mouse. Now each subsequent release after the original Mac, we refined the UI, we added things like MultiFinder, we added color, we went a little nuts in color sometimes. We love that background I guess.

We, you know, we added things, we added an apps switcher. And by the time we got to Mac OS 9 we really had, you know, a cacophony of UI's. It didn't look like it was all from the same OS. And so, with the introduction of Mac OS X we came out with a new UI called Aqua and we unified everything. We had these nice translucent title bars. It took Microsoft a good six years to copy that part.

We had innovations like sheets so panels associated with their window. And of course we added the dock. And now with each subsequent release of Mac OS X, we've continued to iterate and refine the design. So, we've experimented with different levels of transparency. We've experimented with different renderings of controls. We've had brushed metal. We've gone and we've added a sidebar for fast access to any folder.

But again, by the time we got to Tiger a lot of these experiments had gone in different directions. And so, for Leopard one of our design decisions was to go ahead, pick the best elements out of Tiger, innovate beyond that, and once again have a nice unified look. And that's exactly what we did.

So here is the look of Leopard. Again we've added, you know, a three dimensional aspect to it, it's gorgeous new dock brush metal is gone.

And so we've done a lot. And let me walk you through it. But let me start by just talking about the window because that's where we started. We started with the window. We now have a single unified window look across the board.

It has different flavors of it. This is the one if you don't have a toolbar or anything. So, a simple title bar, simple single unified look for Leopard looks like that. You can have an optional toolbar. And again, we integrated it in to look like a single piece. And you can have an optional status bar as well. The next problem we wanted to solve was seeing what is currently the active window. Let me pull up a few windows.

If you were to look at this on Tiger it would be difficult to tell what the active window is. And the reason is for metal windows we didn't really have an inactive look. I mean we took the color out of the buttons and text went slowly gray on the title bar. But that was it.

But now we have this unified look. It has an active look. It has an inactive look. And we do one more thing. We pop out a deep shadow for the front most ap. And now as you see when I go around the horn it's really easy to tell which application is currently key. So, very clear what the active app is what the inactive apps are.

The next thing we did is take an application like this, we have standard panels. So standard Leopard panels which, again, go along with the language of the standard unified window look. But, we realized we needed to add a little bit more for panels. The reason for that is that there are a number of applications nowadays which are going full screen. And, we think that's a good thing for three different types of applications.

So the first type are applications that are media centric. Alright, so photo viewing, video viewing, this is a movie applications, this is QuickTime. So for media centric applications there are times when you want to get everything else out of the way so the user can concentrate directly upon the media itself.

The second type of application we think makes sense as a full screen app are truly immersive experiences. So, an example of that is time machine. when you're in Time Machine you don't want to see today's Finder and today's files. You really are in this model immersive experience. The third type of application that makes sense as a full screen application are games. So those three makes sense. We don't think many others do. But when you look at a full screen application like this, those panels, they stand out.

And the problem is those panels are trying to be the stars themselves, right. The star of a full screen application and the reason you do full screen applications is so the content can be the star. And so for Leopard we're adding another panel type called the heads up display look. And this is it. So, if you have a.

( Applause ) What these panels let you do is the star is the content. It allows you to concentrate on the content while still having your panels here. Now for consistency's sake applications that go full screen and use panels in full screen can also use these heads up displays or HUD look in their window look as well.

Now, here's another example of an application this is iPhoto, full screen editing, use the HUD look, and they can use it outside the full screen display as well. Here's Aperture, again the HUD look allows you to concentrate on the pictures themselves instead of the panels Here's iChat, video chat, again the video effects picker is a HUD look in an out a full screen time machine. The quick look feature we've added uses the HUD look so you can concentrate on the contents. But again, the HUD look is not for everything. This here is Pages.

Pages is not a multimedia app. It's not a full screen application. So for something like Pages it can use the standard Leopard panel look same thing's true here for the Finder, the inspector panel should use the standard Leopard look. So, we think for most applications now we have this great unified window look across the board And for some applications that go full screen the judicious use of HUD panels will really allow you to concentrate on the content itself.

Alright, now let's look at a bunch of different windows. Here are all the windows you know and love in Tiger right now. Here's one of the older Aqua window looks. Here is a unified toolbar title bar look. We've got a metal topped window. Here's another sort of standard Aqua look.

Here's a full brushed metal window and a second one. And here's the Spotlight window which is somewhat similar to the Mail window. And we have the Find which is another brush metal thing. So, let me walk you through what we've done with each of these apps to go to the new unified Leopard window look.

Start with brush metal. Brush metal is gone. So, yeah, I've heard it at the feedback forums each year. We love brush metal, get rid of it. So, the nice unified look, and again we see we get rid of some of the interstitial space so you can concentrate on the content of the application instead of the window itself.

Here's another one with Preview. So here we had a separate title bar and toolbar, again combines beautifully into the new and unified window look. Mail, we're experimenting with this new look in Tiger and it works perfectly in Leopard. This is an interesting one. We had a Spotlight window and a Finder window which when you did searching in Finder it did pretty much the exact same thing.

And not only did we have two windows and two apps which didn't make a lot of sense, but we also had completely different UI's for them. So, we're doing a couple things here. the first thing is we are integrating all the functionality from the Spotlight window into the Finder window so they're not two windows anymore.

The next thing we're doing is we start by brushing out the metal and get the new look. We go to our standard sidebar so we have this new standard sidebar with a little bit of color, make it pop a little bit. We remove the interstitial space.

All of the icons which used to be just pure generic icons are now previews of the documents inside them. And of course we've added really nice new view with cover flow and quick looks on top of that. So, we think you're going to absolutely love the new Finder.

Now, you're asking yourself, let me back up one second here. You're asking yourself okay we've changed the UI. How much work is it going to be for all of you? You all, this is your job and you're wondering if we've just added a few months of work. You know this is good job security but we want this to be easy so you can be implementing the features that you're being asked to do instead. And so the answer is, if you were a good citizen meaning you're either using Cocoa and letting Cocoa do the drawing for you or you're a Carbon application and you're using the theme API's the new look comes for free.

So, what we did as a test of this is we downloaded two random apps off version tracker, ran them on Tiger, did a screen shot, ran them on Leopard, did a screen shot. And here they are. So the first one here, Transmit, a popular FTP tool, this is just the straight up binary downloaded running on Tiger. And here it is running on Leopard. No change whatsoever, automatically picks up the new unified look.

Here's another one, this is an educational app Again this is a metal app with even a metal panel. Here's how it looks when running on Tiger. And here's how it looks running on Leopard. No change whatsoever. So, hopefully for most of you you're letting the Frameworks do the work of the drawing and it should just come straight across. So, let's put it all together. Here's all the different window types that we had on Tiger.

And this is what it looks like on Leopard, nicely unified single unified window across the board. Now the next thing we did is we changed out the background to be a photo. And we really believe that people should be customizing their machines. We see them customizing their machines and they customize it with, you know, photos of their kids, of their family, of their friends, of nature shots they take.

And so we want the UI to work beautifully with your photos. So the first thing we did here is we add a new menu bar. Now, this new menu bar actually plays a number of tricks, a number of photographic tricks. We actually do some burning and some dodging. So you'll see the Apple and actually the text will absorb some of the color from the back. And yet it's still readable. So there's a whole lot of processing going on to make sure that this one was gorgeous with your photos.

The next thing we do is we add a little bit of 3D. = so we pop out the active window with a deeper shadow. And then we slide in this brand new three dimensional dock which actually reflects. I know it's hard to see for some of you, this three dimensional dock which reflects the icons, reflects the windows, reflects the icons and gives us more of a 3D look overal=l. So again, this is what it looked like on Tiger And now with all the changes this is Leopard, Tiger, and Leopard. Now we went one step further.

We want you to be really to be able to take full advantage of putting your own photos on the desktop. And so part of that means we need to clean up your desktop. And we're doing that by adding another feature called stacks. So let me add in, a little function now that's hiding here in the dock which is stacks. And we have these stacks and this one here is a download stack.

So with this download stack any file that you download from Safari will go right on the top of this stack, stay off of your photo on the desktop and allow you to see your own photos on the desktop. If you are writing an application today which downloads files, make sure that you're downloading it to the standard download location. It'll automatically animate and appear on the top of our download stack and keep the desktop clean.

So this right here is the new look of Leopard. I think you're absolutely going to love it. So as Bertrand said at the top, our agenda first power, being able to build really fast applications take advantage of the hardware. Foundations provide the frameworks so you can easily write great applications really fast. And experience, we want you to build the best applications possible. And that really is our job. Our job is we want to have as many world class applications best of breed running on the Mac.

And we think we've done a pretty good job of that. If you look out there today there are over 17,000 native applications for Mac OS X, thank you.

17,000, and this really forms a whole constellation of choices for our collective users. On top of that there are another more than 3,000 widgets, which have been built. So thank you for that.

So this really forms, you know, it adds to this constellation of choices. But nowadays a lot of applications that used to be written as client applications are written as web applications. There's a lot of banking sites now. Instead of having a client you go to the bank's website and do your banking there.

The amazing thing about this is today there are over 100 million websites, 100 million websites. So there truly are a universe of applications of people to choose from, some clients some web based. I found this chart interesting. This is a chart of the growth of websites. You'll see today it will actually up north of 118 million websites.

You can see what happened during the dot com bust, which is amazing. It was only about a year, year and a half and it really actually just leveled off. It went down slightly. But it is once again on a tare upward. The great thing is these applications are available to people running a Mac because of Safari. Now we're really, really pleased with Safari.

We have been investing heavily with Safari. And with Safari 3.0 this comes with Leopard and will go to Tiger as well we're extremely pleased with it. And we start with the UI. Our design goal with Safari was to build a web browser which stayed out of the way and allowed your websites, your web applications to be the star.

Alright, we didn't want the browser itself to be the star of it. And so, we tried to make it very simple up top and let all the rest of the content be your content and yours be the star. The next thing we really paid attention to was performance.

Now this is the iBench benchmark. Smaller numbers are better. The question is how fast can you perform it. And again we are more than twice as fast as the competition. So, we have a very, very fast browser that's for JavaScript, HTML obviously this also important. And again we are more than twice as fast.

Now, we've also been aggressive about adding features. And I'll talk about just one. We think that people are using more and more tabs nowadays. So with the new Safari and Safari 3.0 we allow you to do things like grab a tab drag it off, have it turn into its own window. You can also grab a window and put it into another window so it becomes a tab. So, you can really manage multiple windows and multiple tabs extremely well.

We are also huge advocates of open standards. We love the fact that the web allows you to write an application that runs on multiple platforms. We think it's a really important thing. And so we are active members of the open standard community and are supporting all of Web 2.0 and Ajax. We've added a tremendous amount of support in the new Safari.

So, everything across the board from HTML to CSS to Java script, you name it we are adding support for all the standards out there. And a lot of work has gone in in the last year for this. What that means is applications like Google docs which would not run in the previous Safari, now run great in the new Safari. It also means.

Another website that people have been looking at Zillow which tells you, you can find houses with the Web 2 application. It will allow you to find that four bedroom house in San Francisco for 65 million dollars. So, that'll come in useful. Now at the heart of Safari at the heart of the application is the engine. And the engine of Safari is WebKit.

And WebKit is Open Source. Web kit has a thriving Open Source community. We have a number of contributors from very large companies many of which are here today. We also have a really large number of individuals who contribute to it. So, it has an absolute thriving community. And for us, that's really important.

We want to make it better and better add more and more standards. And we think that's great because for us WebKit isn't just the heart of Safari, which it is. It's also the heart of a lot of the applications on our system. The dictionary app is just a WebKit based application. In fact the transcripts you see in iChat are done using WebKit.

Our help system is done using WebKit. In fact one of the features that we've added for Leopard is this stationery feature in Mail. And it allows you to send beautiful stationery to anyone. And they can all read it because the stationery that comes is HTML. Well turns out even in the composed window in Mail when you're writing this email you're editing HTML live we make it feel like it's just a text editor so we don't even let you know it's HTML it's HTML and it's using the WebKit engine. And of course Dashboard is built completely on top of WebKit. So, we think that everyone deserves Safari. Alright, we got great user interface, great performance, great features, it's open source, it's open standards. We think everyone deserves Safari.

So a couple of weeks ago Steve was asked about iTunes on Windows. And his response was well, we build iTunes for Windows and a lot of people on Windows tell us that iTunes is their favorite app. It's the best app on Windows. In fact, giving iTunes to someone on Windows is sort of like giving a glass of ice water to someone in hell.

Now, we think those people stuck in Windows hell are really thirsty. And they deserve a second glass.

And so that's why today.

This is why today we announced we are taking Safari from Mac OS X, we have ported it to Windows to both XP and to Vista.

It comes across, it is the same WebKit engine, the same open source WebKit engine that powers Safari on the Mac now powers Safari on Windows. It has the same performance. So let's look at this JavaScript performance. Smaller numbers are better. We are whupping IE in their own house.

It's their own OS and we've come over and in a few months we're whupping them. HTML same thing, alright, we have no hooks into the OS that are special. As a third party we are twice as fast as IE on their own OS. We have the same features. We brought across the same feature set from Mac OS X to Windows. And as I said it is the same open source engine.

So we've had a thriving open source community so far with Safari when it's just in the Mac. We expect it's just going to explode now that it's on Windows. We support the same open standards on Safari on Windows as we do on the Mac. All of Web 2.0 and AJAX and we're aggressively moving that forward.

But you know compatibility is about more than just open standards. It's about people using the application and testing against it. And we know there are some sorry souls out there who just have a Windows PC. And they're writing their websites and they don't know if it runs on Safari. Well now, they can download Safari and run it on that Windows PC we expect the compatibility will go up. But we want to go one step further than that. We're actually building in tremendous debugging tools directly into Safari.

So, as a developer you can turn on this tool, yeah you're going to love this.

As a developer you can turn this on. It'll tell you exactly what resources have been downloaded, which ones haven't, how much time it took to download them, if you have and error in your HTML or your CSS, it'll point that out.

We're going to make Safari one of the best debug tools for building a website. So my expectation is soon web developers out there on Windows and the Mac will use Safari not just to test against but actually to build their websites for, and then they'll go test against IE.

So, as of yesterday we had Safari on a single platform now as Mac OS, Mac OS X. As of today we have Safari on two platforms Mac OS X and Windows. But, in 18 days we're going to have Safari on a third platform and that, plat phone, that's and that is iPhone. Safari on iPhone runs the exact same open source engine which is WebKit.

So we share that same engine between Safari on Mac OS X, Safari on Windows, and Safari on iPhone. It's the same engine. So we've been getting these questions though. Is the iPhone open? Is it an open platform? And the fact is because of this icon right down here, because Safari is on it, it is, you can write extensible applications for iPhone as web applications. Now let me show you what this looks like.

So, we have the same rendering engine across the board. So this is what the New York Times looks like when rendered in Safari on the Mac. This is what it looks like rendered in Safari on Windows. Here's what it looks like rendered in Safari on iPhone. Now, here's what it looks like on these other, so called, smart phones.

But this is what it looks like on the iPhone, you know.

Same thing here for a Google search. So here's a Google search result, Safari on the Mac, Safari on Windows, the same Google search result on Safari on iPhone. And again, on these

Other devices. Let's go back to Safari on the phone. One more example the BBC I think is a great news site, Safari on the Mac, Safari on Windows, Safari on iPhone. I really, I don't know what they're trying to do here. I mean the more and more you look at it Safari on iPhone gives you the full Internet. But these other phones they're give you sort of this, I don't know, baby web.

If you want the entire Internet on your phone you've gotta come to iPhone. Now, on top of this, so you can see how it's laid out. You can see the entire page. It's rendered the same way. But to access different parts of it we use the touch screen interface, so you can double tap on any region. We actually do an analysis on that part of the page and then pull it forward so you can see it full screen. You can double tap to zoom back out. You can move to different parts of the page.

If you turn it landscape we actually have an accelerometer so we know when you've gone landscape versus portraits. We can tell this automatically. You can zoom out, you can zoom into a story in landscape. And scroll through it. It works great. So our goal has been number one out of the box to make it so you can view any website out there of those, you know, 100 million websites on the phone without change.

But we want to go a step beyond that and enable you to build applications that are really customized for iPhone itself. And to do that there's really three things you need to consider. The first are standards. The second is the size of the screen. And the third is the fact that we have a touch interface. So let me start with the first one.

This is the exact same rendering engine WebKit as it is on Safari on the Mac and Safari on Windows. And we support all the same standards. But, we do not support the extras. So, we support Web 2.0 and AJAX. We do not support Flash or Java inside it.

That clapping is not coming from Macromedia.

The next is the size of the screen. So one of our design considerations for iPhone was to have the biggest display possible. And that's one reason we didn't mold the buttons or the key board into the plastic. We bring them in when needed and then we can get rid of it when we don't need it anymore. And so, if you look at our screen it's huge compared to other smart phones.

It's small compared to the iMac in the corner of your office. So, the best way to layout your websites is to do it in sort of a newspaper model, which is nice columns where when you double tap and zoom in that fully zoomed in column has a font which is big enough to be read without doing horizontal scrolling.

So, I mean if you've gone to journalism school, the way they tell you to lay things out for newspapers and magazines is always to have relatively thin columns. Those work perfectly on iPhone. The third thing is your finger is not a mouse. So we do a lot of things on the phone to make sure that, you know, as you move around you can scroll and you can tap links. And we make this work pretty seamlessly. But the fact is there are certain events that you get on a desktop that we do not get on iPhone.

We don't get hover events, and we don't get sort of a moved event, right. So, we don't know that your fingers are moving in space around here and we can't do roll over space in that. When you touch the screen and start moving now we're actually doing scrolling on there. And so if you make sure that your website works without hover or move events, and there's a set of other things to think about which will be talked about at a session tomorrow then you can make it so your website works just great.

And we think by taking these things into account you can actually build really great applications. In fact it's because we have Safari on here but it's more than that. it's the fact that iPhone is basically an always connected device, right? It's not like your portable that sometimes isn't connected.

Because you have cellular edge connection or you have wifi connection it's basically an always connected device. And so, a web application, which is built for iPhone and customized for iPhone can have the same look, feel, behavior and presence as a built in application like the one I demoed this morning. So let me go ahead and walk you through a few demos of iPhone.

Alright, so here again is iPhone. I can slide this across to unlock it. And here we are at the home screen. So again, Safari is right here on what we call our dock. Here's the home page. But let me take you to say, Google news. So here's loading up Google news, and you'll notice that they've done, you know, they have these nice columns. And even while it's loading I can double tap on a story, it zooms it right in to fill that. double tap again to go out, I can double tap on the side.

So we're actually doing a pretty complex analysis of the page to make sure that we zoom in on the right part. Now, when you have that story here, if I turn it into a landscape orientation with the accelerometer inside we notice you've sort of the normal to the earth center has changed on it and we rotate.

And so now you can read this story. it's a bigger font because we make it sort of grow. The exact same column you're seeing to fit the screen, turn it back here, works just like that. so again, even things that might look like they'd be hard to hit like the side you can double tap to zoom it in.

you could, you know tap on something, it automatically goes out, loads that in. so first of all we think that, you know, most websites out there are going to work just great without any change whatsoever. We also support media on here. so, let me go ahead and go to the Pixar website for the Incredibles.

If I tap on this here it'll actually start streaming over, if I tap on it here, or maybe not, maybe they've taken the trailer down right now. There we go, it'll start streaming live this trailer directly from their website, so, again video playing over the web to iPhone.

Now, just like when you're in the web browser if I turn this sideways we notice that it automatically play it like this. And if I double tap we zoom to full screen.

So I can tap here to bring up controls. I can actually grab the scrubber on the top and I'm moving it so I can move to different part in the video, automatically scrubs through it.

Can pause, can play, here are the controls.

Go back to the movie aspect ratio.

Yes we have to play either Disney or Pixar movies at all demos.

So iPhone supports many media types and in the graphics and media state of the union later today they'll go into more details on exactly which ones. But, basically it's, you know, things like MP3's or anything that we have, hardware decode 4 on the device, we play back, which is just great. So we actually think you can build websites and web applications taking advantage of media as well.

And so the last one, this is the same one I showed you this morning. But let me talk a little bit more about it, which is this application, which is the Apple directory application. So our IS department decided they wanted to front our LDAP data base in an iPhone specific application.

Now, they didn't have access to iPhones at the time. We were very strict. And so they did it by building application knowing what the dimensions of the device were in Safari. And tested the whole thing in Safari. And it wasn't until like the last moment we gave them some artwork and then they made it good look and feel here. But there's a lot you can do just by writing your website, your web page and testing it in Safari itself.

So again, if I type like, say a single letter here it should come back with everyone who has that letter in here. I can pick someone, so let's go ahead and pick Kathy, and it goes out and it grabs that person's card. And so, again if you tap on things like phone number there's a telephone URL it's a Tel colon style anchor and that automatically offers to call. You can tap it goes ahead and calls. So you can add these Tel URL's directly into your web applications and integrate with the services provided by iPhone.

Again things like email, we have a built in email client. And we have these panels, these sheets which will slide up. There's a standard email URL. So if you imbed that in your web applications it'll do the same thing. We actually do some smart things even with like phone numbers trying to look to see if you've forgotten what to tell URL and turn it into a phone number. But the best is if you actually use the standard Tel URL.

And again, I showed several of these things this morning, let me show one more which is the maps thing, which I think' really, really great. The fact that we have Google maps built into the phone, to the iPhone, and so it'll show you exactly where this person is. You can go into satellite view.

You can actually take and you can pinch and zoom in and out just like that. so, we have this nice multi touch display. In fact, if you're going to go visit the person you could even turn on traffic, it'll show you what the traffic is around there. And so, the ability for you to write a great application specifically for iPhone we think is going to be huge.

And really it took, you know less than a person month for this and the person didn't even have access to the iPhone for a long time. And it ended up being less than 600 lines of code. So it's going to be really easy to write really, really powerful applications. Here's exact, you know, the same demo here. walking through it looks the same on the built in contacts application as it does on the web one. And again you can tap to call.

So to do that we decided to ally the simplicity of the Mac with the power of Unix. And of course that became the Aqua user interface and the underpinnings that we have today. We also, of course, had the two toolboxes The Carbon Toolbox as a bridge from the past and the Cocoa toolbox for forward developments.

And, the following few years we spent, we have a lot of hard work to establish Mac OS X to shape the first version of Mac OS X in 2001, and after that, to rapidly spread in more breadth and shape other releases of Mac OS X, Jaguar, Panther, Tiger. and over the last few years with that OS solidly established. We've been able to spend more resources on innovative technologies, things like Spotlight, Dashboard, Core Image, Core Animation.

And it's very pleasing to see that you have developed lots of applications that take advantage of those technologies, over 20 thousand applications to date. And that's both kind of native apps as well as widgets. So Mac ecosystem is doing great. I really look forward to your next set of 20,000 applications.

But you know there's another expanding universe out there. And that's the universe of web applications. And now, I would like to encourage you not just to develop a traditional native application but also to consider developing a web application that runs great on the Mac, okay on Windows, and great on the iPhone. Hope you've enjoyed the conference thank you.