Ladies and gentlemen, please welcome Vice President, OS Software, Craig Federighi. Hello everybody. Did you have a good morning? Yeah, that was some pretty nice stuff. Well, I am thrilled to be able to kick off the technical session here at, and we're going the other direction. Let's go this way. Let's go forward today.

So I'm here to kick off the technical sessions here at WWDC. Now this morning, we heard a lot of pretty astounding claims about the amount, the number of new developer APIs that were available. 1,500 new APIs for iOS 5 and a staggering 3,000 new APIs for Lion. Now I know a lot of you in the audience are engineers like me and are detail oriented.

You want to get to the bottom of this. You want to learn about every single one of these APIs. We have this hall, I think, all afternoon, and I think there's no time like the present to dig in. I want to start alphabetically with the Accelerate framework. Accelerate. We're going to start with the first header in Accelerate. This is alpha.h. So, V image alpha blend planar 8 takes the following arguments. No, alright. Seriously, okay. Let's work our way through.

Craig Federighi, very nice crowd. All right, let's seriously, let's step back. So our users love the beautiful devices, these physical objects that we make. But I think as Steve said it best this morning, as software people, I think we feel it's the software that's really the soul of these systems. These excellent applications, whether they be for the Mac, the iPhone, or the iPad, are really, I think, what embody the true experience of our platforms.

And we're going to talk today about these set of platforms. This is what this week is really about, the platforms that let you create these great apps. And I want to start by talking about our desktop and mobile platforms and really how they came to be. You know, because most companies in our industry have started down this path of saying, you know, there are two totally separate monoliths.

And in fact, they put a wall between them and caused them to grow apart over time. This is bad for users and ultimately bad for developers. So what are the two different platforms that we're talking about? And what are the two developers who want to target these platforms? Well, from the start, we took a very different path with Mac OS X and iOS.

As we all know, iOS was actually born out of the foundations of Mac OS X. And over time, we've taken innovations and inspirations from iOS and brought them back to the Mac. But these platforms actually sit on a common base of code. And so at this point, as we innovate, those innovations actually feed both platforms.

So what is that platform? Well, it starts down, of course, at the bottom with Core OS, all the Unix stuff, including some really awesome capabilities around power management, some really differentiated security architecture. But as developers, we usually start interfacing at the level of core services, things like the foundation set of object-oriented APIs, grand central dispatch, core data, higher-level networking interfaces. You move up the stack into graphics and media, and you have things like our 2D drawing model, Quartz, and core graphics. Core media for audio and video, OpenGL ES and OpenGL, and then WebKit for HTML5.

These layers are all completely common across these platforms. It's when you get to the highest level of Cocoa and Cocoa Touch where the frameworks actually diverge, but for good reason, because we believe that fundamentally the requirements of a Mac and of a touchscreen device like an iPhone and iPad are different. And so the view system, the controls, the navigation mechanisms necessarily should be different for those layers.

Now we also then have a set of common tools and languages that serve both platforms. Our investment in things like Xcode, LLVM and instruments help with innovations across this entire stack. Now if you look at Lion and iOS 5, there have been a lot of cases where technologies that premiered on one actually now are available on the other.

And I want to go through a few of these because it's pretty interesting. At the Core OS level, sandboxing is something that actually started in iOS 5 and now as we'll talk about later has come to the Mac while some security features like our SSL transport has become public API now in iOS 5.

At the core services layer, take something like core location. Of course, originally pioneered on iOS, now on the Mac and the Mac's accelerate framework has now come in its full glory to iOS 5. At the graphics and media layer, in iOS 4, we saw the introduction of AV Foundation with video editing, playback, there's audio and video.

It's now come the full API set to Lion while core image, as you heard this morning, has come from the Mac to iOS. Even when you get to the top of the stack where the frameworks are actually distinct, there are inspirations and design patterns that have fed across both.

So in the case if you're a Cocoa Touch developer, you know about the view-based table view. If you've ever then tried to go to Cocoa, you said, "Hold on, what's all this NSL stuff?" Well now, we have a view-based table view in Cocoa. Yeah, that's a good thing. Yeah, yeah. Check it out. It makes animations much easier. It's really phenomenal. And in Cocoa Touch, we brought basically NS document over for document-based apps. This is great as well. But of course, there are also apps. I'm going to show you a couple of them.

But there are also innovations that are at the bottom of all of these things, things like Grand Central Dispatch and the new Cloud APIs that are concurrently becoming available for both platforms. So as we built this platform-- What did we build it out of? What was our philosophy? The things that really went to make it up.

Did we choose something like Carbon fiber, sort of a high performance but cantankerous material? Or did we choose steel? It's reliable but it sure is heavy. Or did we use duct tape and bailing wire? Never, never. What actually we took approach focused really on pragmatism. It's this balance of idealism and realism. You know, we would not compromise on true object orientation. We've always needed a dynamic runtime.

And we make extensive use throughout our object oriented frameworks of design patterns like delegation, notification, key value coding, key value observer, model view controller and so forth. But at the same time we needed a system native language that had the performance and efficiency required for our full range of products. How did we do that? Well with Objective C.

Now how's that worked out? Effectively pretty well. We've been able to scale Objective C from powerful many core desktop platforms down to the most demanding sort of small memory relatively low power devices and get fantastic battery life and responsiveness out of these platforms. But this has come at one cost that all of us collectively bear.

And that's manual memory management. Right, we've all done this and we've all made a few mistakes along the way. In fact, Apple's been making this tremendous investment over time in Xcode and developer tools. And those of you who've run our static analyzer have actually seen that the static analyzer will point out things for you. Like you should have retained here or you should have released there. And maybe it occurred to you as it occurred to us.

If it can tell me that, why can't it just do it for me? Well, it turns out later today you're going to hear about how we brought the speed of explicit object management and combined it with the simplicity of garbage collection. This is going to be very big.

Andreas isn't going to be happy that I spilled the beans, but he's going to talk about it more in the next talk. And also, after that, you're going to get a fantastic talk about a number of technologies and graphics and media. These will be much better talks than the one you're experiencing right now. I will be covering the rest of our frameworks. And so I want to talk about the platforms that we are delivering here at WWDC, and in particular, how they enable you to build great apps.

You know, all of you have really set the bar for customers in terms of what they expect from a great application experience. And I want to look at the new capabilities that we brought to our platforms through that lens of how they help you continue to develop an experience that delivers on users and exceeds users' expectations. So what do our users expect? Well, they want apps that are simple, that provide immersive experiences, that are fast and responsive, that are secure and increasingly that are connected.

Well, let's start with simplicity. We've all seen user interfaces look like this. It's really easy to make a mistake and really hard to know how to accomplish the basic task that you're put to inside this UI. We really would seek to develop something a little more like this.

I think even I might be able to do this. And to some extent, I think we've started to achieve that. You know, if any of you have young children, you've seen a one or two or three-year-old pick up an iPhone or an iPad, they become immersed in that device with no teaching whatsoever. It's just, it's immediate and visceral how to work with that. And so we've taken some of our learnings here and applied them to the Mac in terms of the full-screen gestures that you heard about this morning.

So, of course, for the Mac, things are different. We don't believe in a touchscreen Mac where I keep my arms suspended like this all day and smudging up my screen. It's just not the right way to work with a Mac. We have these fantastic multi-touch trackpads. When you have those fantastic multi-touch trackpads, you can do things to simplify, like taking away scrollers. And so now we have overlay scroll bars. These are controls that are not visible when you're not scrolling.

But in fact, they're configurable. Now, most of the time, you don't have to do anything. If you're using NSScrollView, you're going to get overlay scrollers by default, unless your user is using a non-multi-touch device, in which case you'll get legacy scrollers. But if you have the need, you can request legacy scrollers. There's another case in which you would get legacy scrollers, and I don't think any of us want to be in the legacy camp if we don't have to be. And that's when you have controls that you put in the scroll alley.

We've all seen apps that say, "Well, we're wasting all the space in the app." "We're wasting space for a scroll alley anyway, so let's put the magnification control and the view selector." Well, if you do that, of course, we have no choice but to fill the remaining area with scroll bars. So this is something that you want to get rid of. These are no longer what you want. Now, one of the more controversial changes that we've made for Lion is we've changed the mapping of the scrolling direction.

Now, it turns out that if you look at really the way it works, and let's say Snow Leopard or on a PC, you push up on the scroll bar, not because you're pushing the content up, but actually because you're pushing the scroll bar up, which is going to push the content down.

It's in fact exactly the opposite of dealing with your content. You're moving the viewport, you're not moving the content. Well, in Lion, we said no, We're going to say when you move your finger up, you're pushing the content up. That's the most natural thing and it turns out it feels great as soon as you flip your brain entirely around.

So, there was a time we flipped it around internally of course and people started running and they said, you know I think there's something fundamental here. I think there's something about a trackpad where it really just has to work backwards and it's you know the people are never going to get it. It's going to be impossible. It turns out and I implore you all to do this. Give it a week. Try. Your brain will flip and then you won't be able to use your snow leopard machines anymore.

So give it a try. It's really great. Most of the time, as a developer, you don't have to do anything in order to react to the change in scrolling direction. But there are some cases where you do. If you have a place where you're interpreting scroll events to physically model, let's say, moving a slider, well, when we-- or a play head, for instance, on a playback tool, well, then when we flip the scroll direction, suddenly the user moving their fingers right is going to cause your control to go left. For those rare cases, we have an API that let you be aware of the scrolling direction and adapt to it directly. But normally, you don't have to worry about this.

There's another area where we've simplified by taking something away, and that's with navigation gestures. Previously in Snow Leopard, for instance, you had navigation gestures usually took three or four fingers to move between pages. We've taken a finger away, not with a cleaver or anything, but we've just taken the necessity to have those fingers away by making the scroll gesture capable of doing navigation. So if you move your fingers to scroll, you in fact are going to be able to navigate. But you may be asking, "Well, hold on, that's the scroll gesture. What about scrolling?" Well, let me give you a quick demonstration to show you how it works.

And while I'm at it, I'm just going to show you a couple of other things about scrolling. So I'm going to bring up a web page here. Let's bring up the Wikipedia page about Lion. So of course, I can push my content up, pull it down. I can flick and I get momentum. It's all a lot of fun.

I can bounce at the top like this. One thing, this is-- on the Mac, you can often have very long documents. And you could, of course, wheel away and scroll and scroll and scroll and scroll, which works great most of the time. But one thing we didn't mention this morning is that if you do need to get at your scroll bar, in fact, you can. So if I start scrolling and then I move toward the scroll thumb, it stays visible. When I get to it, the alley appears.

And I can click and move very quickly, scroll my whole document end to end very quickly. Now note, though, this isn't truly a hover area. I can't go over here and just hover and have it come up. Because there could be content in the underlying document that I'm trying to get at and the scroll bar would keep getting in the way. So you actually start scrolling with your fingers.

And then you just move toward the alley. And you can manipulate the scroll bar. Now I want to show you a little bit about that scroll to navigate. We're going to drill in here on a site. And I'm going to drill down to another page within this site.

and I'm going to scroll, okay? And as I scroll to the side, what you're going to see is what actually happens is I start pulling the page. I start navigating, right? I pull and I navigate. But what happens if I zoom in such that I have horizontal scrolling? You see now there's a horizontal scroll bar there. Well, now as I scroll, I actually hit the end. I'm actually scrolling, right? If I go here, I hit the end, but now that I'm at the end, I pull aside and I'm navigating.

95% of the time, your user has content that isn't horizontally scrolling, and they just flick, flick, flick to navigate. But if they find themselves in a condition like this where they're scrolling, they scroll, and then they keep pulling through and they navigate. So that's how that works with scrolling and navigation in Lion. Let's go back to a moment to the slides.

So how do you implement versions? Well, pretty much use NSDocument. But if your main document window in the application is what shows up in that time machine-like versions UI. And so when you're in there, if your app has needs where it doesn't make sense to have this operation appear in versions, you can do a version-specific UI, or changes specific to versions, by listening for the notifications that tell you that that's actually the context for your UI.

So let's talk now about immersive experiences. We know the iPad, for instance, has great full-screen immersive experience. And we took that lesson and brought it to the Mac. And you've seen that in apps like Preview that take a windowed interface and provide a context where you're completely immersed in the app.

Well, you've heard about how full screen is now system-wide capability in Lion. There's some important differences if you have a full app that supports full screen currently when you move it to Lion. For one, full screen is no longer the system global mode where the idea is the user can't do anything until they exit out of full screen because they're just they're locked in full screen then they have to get out. So things like the menu bar in the dock need to stay accessible at all times even when you're in full screen.

You also have a lot of options about how standard controls behave when you're in full screen to adapt your UI. And I want to show you a couple of examples of how things like the toolbars can behave differently depending on the right context for the app. So let's take a quick look at that.

I'm going to start with a really simple full screen experience. And that is iCal. I'm going to take iCal. You know, so iCal has a toolbar here that actually is useful all the time pretty much. If I'm looking at my calendar, I probably want access to these controls. So when I go full screen, we see that in this case, the toolbar stays visible. I can get at all of these controls.

But if I want to get, for instance, at my menu bar as I go up, it isn't just that the menu comes down, it's that the whole toolbar comes down. So this happens automatically if you're using NS Toolbar, but if your controls are just tiled into the top of your window and we don't know about them, we can't animate them down. So you're going to want to make sure you put everything that needs to move down into your toolbar.

We also have popovers. So this is now a standard control, the popover control. And you want to think about, in many cases, as your app goes full screen, that instead of using floating palettes, which could then stay and clutter the full screen experience, that you transition to popovers. And there are really simple APIs for doing that. Now, if you look at an application here like Safari, notice right now Safari is actually showing my bookmarks bar.

If I take that full screen-- Notice that the bookmarks bar actually disappears because Safari has put that part of its view in what's called the accessory view. It's a new API in the toolbar such that it's only revealed when the rest of the toolbar is animated down. So you can have certain controls that you tuck away while in full screen but make them accessible on demand to your users. So that's another alternative.

But the most ambitious area where you'll see us using in full screen is something like preview. So here in preview you see I have right now a sidebar up. I have a single page view of this document. And now I'm going to take this full screen. And the first thing I want you to notice is the custom transition as we move from full from a single page view to a facing pages wide view. You see that the page actually swept out from behind into a transition where now we have facing pages. Let's go out and you'll watch it tuck away. And as it tucks away, it actually even fades back in the sidebar and the chrome. So let's watch that again.

But these controls, you notice also now I'm completely focused on the content because Preview has opted to hide its toolbars completely and to hide its sidebars. So depending on your app, in Keynote when I'm editing, I want to have my sidebar actually available all the time, but in Preview it doesn't. It doesn't make sense. So this is really the kind of tradeoff decision that you have to make as you design your app, but we've provided all the framework ability for you to set those policies in a sensible way.

So how do you implement full screen apps? Well, there are APIs in NS Application to say that your app supports full screen. You can identify which windows are capable of going full screen. For instance, Mail's main window goes full screen, but there's no full screen control on each of its composed windows. So you have that choice. And as I mentioned, a lot of APIs are on Toolbar and so forth to handle revealing behavior. We also in WebKit now have JavaScript APIs for going full screen for your web apps as well.

Now, in iOS, Of course, immersive experiences often are all about immersive games, extremely responsive, high performance games. This often means coding in OpenGL ES. And there's a lot of boilerplate code that's been necessary traditionally to get your app all set up for OpenGL. Well, no longer. This afternoon you'll hear about GL Kit. That, yeah, GL Kit makes it-- Really a few lines of code to get your context all right to do your OpenGL game. We also have UI kit skinning. So you're building a game and yeah, this is important.

Because you built a game with a custom look, and you don't want to have to reinvent the wheel in terms of implementing custom controls that match the look of the environment of your game. Well, now with UIKit Skinning, you can set custom images, tint colors, and set the custom look of those controls to appear either globally across your app or contextually based on where you are in the app.

We're going to hear more about this this afternoon. So another value that users-- another expectations of users is that our apps are fast. They want blazingly fast performance, and they don't want to wait. Now, we have all kinds of computational power at our disposal. We have very fast CPUs.

Often we have multiple cores. It's not for lack of computation often that we're waiting. It's because we may be tying up the main thread doing something while at the same time we're just squandering the rest of our resources. Well, we all know the solution to this problem. We just need to multi-thread our application. Can identify the parallel bits and isolate them in threads. We can lock all our data. We can write ourselves a custom thread manager. This is hard to do, and it's even harder to get right.

And so back in Snow Leopard and iOS 4, we introduced GCD. And you really have to make this just a fundamental part of your app development technique. You break your code down into small blocks. It's block based. And then there's a very low overhead, high performance scheduler that will scale up and scale down based on the computational resources available to you.

So we did this in development of the iPad and iOS 4, and that was a single core machine, single core CPU for the iPad. But because we built with GCD, when we introduced the iPad 2, we saw instant benefits in terms of excellent utilization of both cores. And in fact, our use of GCD ended up being a huge part of why the iPad 2 provides an experience that's roughly twice as fast as that of the original iPad.

So if you use GCD, you get a lot of that parallelism for free. Well, GCD is improved now for iOS 5 and Lion. You have now the ability to do serialized scheduling of background I/O and also to manage private concurrent queues. So if you are not using GCD, it's time to start.

Another area new to iOS is Core Image. This is GPU accelerated image processing. We brought a base set of 17 filters, things like red eye detection, face detection, color correction, and so forth. And these can actually be composed in a variety of ways and built into an optimized image processing pipeline that executes in the GPU to give you results really fast.

Now another kind of processing that we can parallelize very well is with the Accelerate framework, which we heard about earlier at the beginning of the talk. This, our image processing algorithms that, and matrix processing algorithms that we've hand tuned in assembly code optimized for our specific platforms. And they take advantage of the actual vector instructions in ways that mere mortals I think never could do. We have a handful of people in the world who know how to do this. And they've done it to these algorithms in the Accelerate framework.

So if you have an algorithm that's covered by Accelerate, you really want to take advantage of this. We see performance advantages relative to naive implementations of as much as 10x for Accelerate algorithms. And we brought the full set now to iOS. Now of course, no matter how much you take advantage of these technologies up front, to really optimize your app, you need to measure.

instruments let you get a great view of the performance of your application. It does performance sampling of both memory use and CPU, provides ways to create rerunable UI automation scenarios so you can test your app under different circumstances. And now for iOS 5 and Lion, we have retained cycle debugging to help you find leaks and set up weak references. And for iOS, we also brought SysTrace to iOS to give you better debugging information. And as you'll hear later this afternoon, fantastic OpenGL performance tools to give you a level of insight into your OpenGL performance that I think you've never seen on any platform.

I want to talk now about security. We all know that iOS has a sandboxing model that allows applications to be kept so that each of them has access only to their data and we're an application to run wild or become compromised. The only damage you can do is to its own data because its data is locked with it in the sandbox and it can't get out.

Well, we want to bring sandboxing to line, but you have to say, well, this is a really challenging problem because here we have applications, which you see at the top that have access or need to have access to files that the user is organized into common places in the file system.

They may have a bunch of documents in their desktop or in their documents folder. In fact, a single document may be used by multiple applications. You may first open an image in an image editor and then you may open it in preview later, so they all need access.

So how can we accomplish the get the benefits of sandboxing inside of a Mac app? Well, what we've done is when you sandbox your application, it in fact is in a sandbox and it has some private data, the equivalent to what would be until the library application support and preferences and caches and so forth. But it doesn't actually have access to its documents. So if it tries to go out and grab a particular path in the file system, it can't. So how do we let the user actually get at the files they want? Well, if the user does something.

Like opening the open panel, save panel, dragging a file in finder on top of an app icon or a window, we contact something called PowerBox. PowerBox is a privileged system process that displays its UI such that it looks like it's running inside the app, but it's actually not.

And it knows that, oh, the user actually, this user explicitly tried to access that RTF file. And when it does, then the PowerBox is able to dynamically extend the file. So it can extend that application sandbox to poke a hole in it such that it can access just that file.

So at this point, the user has the view that actually TextEdit can access any document they want to open when in fact at the security level, TextEdit can only access that one file that the user has asked or granted the permission, if you will, for sandbox for TextEdit to access. Works really well. So yeah, it's pretty good.

Now, how do you set up a sandbox in Lion? Well, it's set up with entitlements like an iOS, and as I mentioned, it prevents really either an app that has programming errors, let's assume there are no malicious apps out there, but one that has programming errors or one that's become compromised. You know, had a security vulnerability, someone compromised that app, took it over, and now it's maybe doing bad things.

You can sandbox your apps really easily. In fact, we've taken third party apps without source code applied the entitlements to them and been able to run them in the sandbox in many cases without modification because a lot of in a lot of cases these power matter just setting your entitlements and things like power box work transparently for you But you do need to make sure that if you've hard-coded paths in your UI Instead of use the proper query api's you know things change when you're in the sandbox those paths won't be accessible where you think they are You need to code sign your app which you can do in Xcode and you need to set the minimum set of Entitlements that are necessary for your app to function So what are these entitlements there things like does this app need to have power box to let user open documents? You know if it's a game the answer may well be no all the data is already stored in the sandbox There's no need to go outside the sandbox Does it need to access common media like movies or pictures or music does it need access to the network? Does it need access to the mic or the camera or personal identity of personal information? All of these are expressible as entitlements and you can set them up in Xcode There are also are A set of temporary exception entitlements Okay These are entitlements that because we recognize you've written your applications in the past and they may be do have certain coding practices that in the near term Won't work in the sandbox you can ask for very specific Holes up front to be placed in your sandbox to do things that are not generally safe in the sandbox model We will be requiring six months from when Lion ships for apps submitted to the app store to be sandboxed.

And you need to justify your entitlement. So if you write a screen saver and you say, well, I need access to the address book and the calendar and the microphone, then you should just tell us why it is that your screen saver needs those things. I'm sure you have a great reason.

But if you don't, then that will be a problem for getting the app accepted. And if you use any of these temporary entitlements, you need to tell us why they're needed. And those temporary exceptions, of course, are temporary. This is just a transition strategy so you can get your app clean, running in the sandbox in the safest way possible. So another security feature, data protection in iOS.

By default, if a user has a PIN, all the data is encrypted at the device level. But you have an additional capability with data protection to lock the data to an own device. Only the user is actually logged in with their PIN currently. So it unlocks on the fly and relocks when the user is logged effectively not past the PIN screen. We now have support in Core Data to make it really easy for your Core Data apps to take advantage, to allow offer your users this additional level of protection if it makes sense.

FileVault2 FileVault2 is a completely new implementation. It's based on a new volume format called Core Storage and it encrypts the entire drive. You cannot boot your Mac when you're using this without first actually entering your password. We have a new feature called FileVault2. It's a login screen that makes it look like you're logging into your Mac, but actually it hasn't even booted yet.

And when you do, we unlock the drive and boot. So there's no way that secure files, files you want to keep protected, can leak outside of the domain of the encryption because the entire drive is encrypted. You may say, well, I'm a little worried about that because that means everything's encrypted. Maybe I'm going to pay a big performance cost.

But in fact, we have incredibly optimized algorithms that take advantage of the special encryption instruction sets and the latest Intel processors. And we have a new feature called FileVault2. To make encryption basically completely transparent. And so if you have a laptop and you care about protecting your data, FileVault2 is a phenomenal solution. And I personally run with it exclusively. So our final. Yes, run with it. It's great.

So our final area of user expectation is around connectivity. Now you saw earlier today Twitter and the tweet sheet. So the real important story here is that within settings, you have single sign-on. Your user sets up once for Twitter, and then all the apps that need to use Twitter can access that without requiring specific sign-on from the user.

If you want to let them tweet URLs and images, well, you can just use the tweet sheet. But you also have arbitrary API access using TW request to make other Twitter requests as well. So it's a really convenient way to add Twitter to your applications. Of course, the big story around being connected is around iCloud. And iCloud is about storing your data in the cloud and making it wirelessly available on all of your devices.

But it's also about being built in to applications so that users actually don't have to think about the cloud at all. Each application has a private piece of the cloud where it can store its data and keep its data available across all devices that are running that application.

Cloud storage breaks into two fundamental capabilities-- the key value store and mobile documents. So the key value store is like a dictionary in the sky or an NS mutable dictionary in the sky. It's meant for small data. So it has a limited number of keys and a limited size of these keys. We're talking tens of kilobytes that you have to work with here.

And it's really meant for things like what page am I currently on in my notebook? What level am I on in this game right now? And this data is actually synchronized asynchronously. It's synchronized with the devices, whether or not they're currently running your app, such that when you then start that app on another device, the data is already there and available. So this is really easy to use, really convenient.

And you should really have all of those kinds of app settings available here with the key value store. The other big one, of course, is the dictionary store, or the mobile documents. This lets you have your documents available everywhere. Your app writes its documents into cloud storage in a private sandbox. And then the data is automatically transferred asynchronously up to the cloud.

And the actual metadata about the file is transferred asynchronously from the data. And this is important for responsiveness, because if you make an update, for instance, on your iPhone or create a new document, both the metadata and the data can get stored up in the cloud. And the metadata can move down automatically to all devices. So they all know about the existence of the file, what the current version is, and so forth.

But the actual data, which is the large part, can move later or only when it's needed. The user could pull it down on demand, if that's the way you want to do it. And while it can pull from the cloud, as well, if two machines or two devices are on the same LAN, when it comes time to get data, it can actually pull it across the LAN without taking the additional bandwidth to go up to the internet.

So the data is encrypted for both transfer and it's encrypted and storage when it's stored with us. It's stored in a geographical location that's close to the user. So you aren't sending all your data to Cupertino if you're in Germany. It's going to be a low latency connection to get to your data.

And, you know, once your users stored your data in the cloud, you may want to provide them the ability to share it. And so there's an API to actually get URLs that you can then hand out through email or whatever in your app so that they can then pass that off to friends or family and they can download documents that are stored in the cloud. Yeah, it's useful.

So how do you enable cloud storage? Well, first of all, give users a choice. The expectation is, and you saw this in Roger's iWork demo, that when the app starts up, it's going to say, do you want to put your documents in cloud storage? Maybe they do, maybe they don't. Give them a choice. If they choose yes, and I think most of them will, you can request entitlements to cloud storage that will give you access to your cloud storage sandbox folder.

And then, well, if you're using our new UI document support in iOS 5, or if you're already using NS Document on Lion, you have built-in support to actually get that document and put it in the cloud. It's really easy. If you insist on not doing that, you can roll your own. Again, we have APIs in NS File Manager, NS File Presenter, and File Coordinator that help you coordinate when data can come in from the cloud and when you're making modifications to the document so that you don't get smashed by edits happening in another way.

This is because the system actually has really smart policies around helping you resolve conflicts, automatically resolve conflicts, should concurrent editing occur. Also, if you're a core data app, there's great news, because core data makes it possible for you to have your core data database, or perhaps for a shoebox app, for instance, automatically synced via iCloud storage.

Go Core Data. So as I mentioned, the storage for your is normally on a per application basis, and that's normally keyed by the bundle ID of your application. That's what gives you access to your particular piece of the cloud. But you may have an application on the Mac that has a different bundle ID than the copy of your application available for iOS. And in that case, they're different bundle IDs. And we have a mechanism that lets you actually collect those two and allow them to access the same area.

Or you might have a lite version, a free version of your app, and a pro version of your app. And you may want to allow users to upgrade without having them suddenly unable to access their common cloud storage. And so there are APIs to let you do that kind of collection of multiple applications data under a common domain. That domain must be tied to your company, though. So this isn't about ganging together multiple apps across vendors and providing access.

So you've built your great app. You've taken advantage of all of these platform APIs and the ones you're going to hear about later today. And whether you did it for love or for money, the chances are that you want to get it out to a lot of people. And you want to get it to market.

Well, how do we do this? Well, of course, we have these great app stores. We made some enhancements. You heard about earlier today in-app purchase on the Mac App Store. We now have Store Kit. And the APIs are extremely similar for in-app purchase to what you're used to on iOS, pretty much identical. We support delta updates. It just works. You submit your package just as you did before. We compute the deltas ourselves as part of our ingest process into the app store. And we'll give your users just the changes when they go to do downloads.

We've also enabled push notifications. You also heard-- I'm going to tell you about how we have Newsstand. If you have a subscription-based application, there are APIs to allow you to get those much more elegantly in front of your users. But if you're in this marketplace, you really want to go global. We have over 90 countries supported by the app store and over 41 languages with millions of users.

And if you've talked to developers who've taken their app and focused on making it available to non-English languages, they're going to be able to get that. So we've got a lot of different ways to do that. We've got a lot of different ways to do that. We've got a lot of different ways to do that. We've got a lot of different ways to do that. We've got a lot of different ways to do that. We've got a lot of different ways to do that.

We've got a lot of different ways to do that. We've got a lot of different ways There's really a phased approach to making your app available to other locales. First, localize the metadata for your application in the app store. People are going to have a lot better time finding it if, in fact, they can read what in the heck your app is when they look at the description in the app store.

You can then internationalize your app. There are system APIs that make sort of common things easy to do internationally. If you take advantage of them, you're covered. And then you get down to translation of the content and the templates of your document. Well, sometimes that translation is going to affect the layout of the application. And we have new technology in Lion that allows you, when you localize the app, to have a lot of that layout done for you automatically. It's actually called Auto Layout. So, if you've set up -- yes, Auto Layout is fantastic.

If you've set up, let's say, something in interface builder like this -- and you know when you drag something in interface builder, you get those little guides that come out that kind of say, "Oh, okay, you look like you're about the right distance. I know these two things seem to be different." And you can see that they're all connected together.

Well, now, those automatically establish constraints or relationships between the controls or the borders of the documents. So, now, you save something like this that's a placeholder. And when you fill it with real text, For instance, as the English text, when I put the German text and things get bigger, it actually can cause the entire UI to adjust the panel to get taller, for instance.

If the user picks, for instance, a right-to-left language, it in fact can actually mirror the UI. Auto Layout is really useful technology whether or not you're using it for localization, but it's great for localization as well. So those are app stores. We hope you commercialize your app or give it away very successfully. And hopefully you can get one of these checks from Apple for a bazillion simoleons or whatever it may be. And if not, at least get a lot of love from your users.

So this has been just skimming the surface of some of what's new on our three platforms. We have two great talks coming this afternoon around the dev tools and around graphics, and a whole host of sessions available to you for the rest of the week. Thank you very much and have a fantastic WWDC.