Good morning, everyone. My name is Dallas De Atley, and we're going to spend the next hour talking about the new iCloud Storage features that we're introducing with iOS 5 and Mac OS X 11. I'd like to begin by talking about my stuff. I might have stuff on my iPhone or iPod Touch. I might have it on my iPad. - I might even have it on some other type of device.

And it shouldn't matter what device I'm using. I should be able to get access to my stuff, regardless of which one I'm actually using at the moment. So if I create a document-- On my iPad, I should be able to get access to that document on every other device. And I really shouldn't have to do it myself. That said, keeping everything up to date on all of those devices can be really tricky.

Now, there are existing solutions for specific types of data. So for example, Mail on my iPhone and Mail on my Mac both talk with a server via IMAP. And so they're able to keep all of my email up to date between those two devices. The same is true for Contacts, which uses Card Dev.

As well as Calendars that uses CalDAV to specifically keep my calendars up to date between all of my devices. And of course there's iTunes, which copies media to my device, as well as files on behalf of applications. But to be honest, the user shouldn't have to do this himself. The system and the applications should just make sure that his stuff is there, regardless of what device he's on.

So, should each developer have to come up with his own custom solution to do this? For example, you might be working with just regular files. Your document might be a single file on the file system, and that is what you're presenting to the user. You might actually have something a bit more sophisticated, which is what we call a package, which is a collection of files that represent a document. You might also have an application that we call a shoebox app. And a shoebox application collects a lot of files on behalf of the user, and then indexes them, usually with something like a SQLite database, and presents that to the user. A good example would be iPhoto.

But you might not actually be dealing with documents at all. You might be dealing with a smaller set of data that doesn't actually need to be put in a document, but you still want to have that behavior replicated across your app on all of the user's devices. Our solution is iCloud Storage.

It's a new API that's available for any App Store app. And what it does is it provides an iCloud sandbox per application. Now, if you're familiar with sandbox applications on iOS, each application lives within its own sandbox. And its data is isolated from the rest of the system and other applications. So other apps can't get at your data. There are some benefits to this isolation. In particular, it provides security for your data, as well as stability for the system as a whole. But it does make actually moving documents between devices Fairly difficult.

In the case of iCloud Storage in our iCloud Sandbox, what we've done is we've created a sandbox that is accessible to your app that will upload files and data that's in that sandbox, and it will do it automatically. We're also providing a feature that allows you to upload simple key value data if you don't necessarily want to put it into a document. And it works continuously and in real time.

So as you edit your document, those changes are going to be reflected in iCloud. So iCloud Storage is responsible for moving the data between each device that a user is logged into his iCloud account with. And it will notify your application when a file that's available to it in the iCloud Sandbox has been modified.

The system, when it notices that two documents have changed on two different devices, it's going to go ahead and pick a winner. However, we know that the system is not going to get this right every single time. And so through the API, we make it possible for your application to go back and choose the other file if it wants to. Also, it just works. We take care of all the details of taking those files and moving them up to the cloud and moving them to the other user's device on your behalf.

Even if your application isn't running. So if you're on iOS and your application has been suspended, all of your documents that are in that application's iCloud container are still going to be moved up to iCloud. If you're on the Mac, it's the same deal. If the application is quit, we're still going to be moving all of those documents between your device and iCloud.

So how does it actually work? When you create a document, what the system is going to do is break it down into a series of discrete chunks. And the first time you create the document, all those chunks are going to be moved up to the cloud. Now when the user modifies that document, what the system is going to do is determine just the set of changes that have actually been made to the document, and only move those chunks up to the cloud.

And now the cloud has a new and complete version of that file. on the server. So it's atomic. Your application is not going to be notified of a change until all of the changes have actually arrived on the device. It also works with packages. So if your application's document is a package, it will also work with Cloud Storage.

It goes peer-to-peer when possible. So while the truth may be in the cloud, the data itself is going to take a shortcut. So if you have two devices that are on the same wireless network, and they're associated with the same iCloud account, they will go ahead and move the data between each other, just as if it had downloaded it directly from iCloud. So there's a bit of an optimization there.

It's able to do this because of the way that iCloud Storage treats the difference between the file's metadata and its data. So the metadata is always pushed to the cloud. And when I say metadata, I'm talking about the information that actually describes the files themselves. So its name, its size, its type, its modification dates. That information is being aggressively pushed up to iCloud any time a file is created or otherwise modified. This is so that iCloud knows about the existence of a file.

As soon as it's been created. And this is a very important concept that we want to get across with iCloud Storage, which is what we're building here is a system where your application is going to know about the existence of a file, even if it might not yet be local on the device. So iCloud in particular will always pull new files. So when the device tells it of a new file, iCloud is going to go ahead and pull that data up to the server so that it always has the most up-to-date copy of the user's data.

Devices are going to pull files when it's appropriate for each platform. This is because your iPhone is going to have radically different performance and power characteristics than your iMac that's plugged into the wall. Your iMac also has a lot more storage. And so the operating system is going to make a decision about when it moves the data automatically, when it's best for that platform. So the OS may pull that data automatically, or it may not. However, your application is still going to know about the existence of that file, and through that, it's going to be able to pull that data automatically.

Through the API, you can then elect to have the system move a document local if it's not already there. So again, this is a big concept that we want to get across today, which is we're building a system where your applications are going to know about all of the files that are available to it via iCloud, even if they're not on the device yet.

So the file exists, but the data might not have arrived yet. At this point, I'd like to invite up Eric Krugler to tell us more about the iCloud services that form the backbone of iCloud Storage. Thank you, Dallas. So I'm going to talk a little bit about the actual service that's behind the iCloud Storage APIs.

Now yesterday, we announced iCloud. iCloud stores your content and wirelessly pushes it to all your devices. iCloud also integrates seamlessly with your app, so everything happens automatically. And we talked about a number of the applications that are integrated with iCloud. So many of these you're familiar with-- your contacts, your calendar, your mail.

We also have enhanced backup, so that backup automatically goes to the cloud. And on restore, you can automatically get everything back down to your device. We also announced PhotoStream, which is a great way to get your photos up into the cloud and onto all of your devices. And we also talked about cloud documents.

Now, cloud documents is the way that you integrate with iCloud. It's the way any application that needs to store data in the cloud and get it to all devices can basically take advantage of the iCloud services. Now, when we set about creating cloud storage, we had a couple choices to make, and one was we could have built a better iDisk. But we decided to take some lessons from iOS, and we thought we should really mimic the model of application-centered document management.

And what that means is that, as Dallas says, you have a sandbox that basically manages your application data. That means you're in total control of the documents. No one else can basically manipulate those documents except your application. And that allows you to have complete control and exclusive rights to make the best presentation for your customers. Now, in doing that, we had to then provide an API.

So it's the iCloud Storage API that gives you direct access into cloud storage to manage the documents. Now we believe iCloud is the absolute best way for you to store your content and get it on all your devices. And because of that, we're making it as easy as possible for customers to adopt iCloud.

So the first way you do that is, well, you make it free. So iCloud is free with iOS 5, as well as with Mac OS X Lion. But in addition to that, we're also making iCloud part of the iOS 5 setup. So any user who purchases a new iPad, an iPhone, an iPod Touch, or upgrades their existing device to iOS 5, goes through the iOS 5 setup.

And in iOS 5 setup, there's a step where you provide your Apple ID, or you can create one. Now most users already have iTunes accounts, and they'll use those accounts right here to basically set up iCloud. But even if they don't have one, right in the flow, they can create a brand new iCloud account, and it gives them immediate access to iCloud.

With that account, you get a free five gigabytes of storage. And with that storage, you basically have access to the iCloud Storage APIs for that customer. So what you can expect is that the vast majority of users who are on iOS 5 will have iCloud. And because they have iCloud, they will have iCloud Storage.

Now, in addition to trying to make this as easy as possible for customers to adopt iCloud, we're also trying to make it easy for developers. So one way to think about this is, you know, what it would take for you to build your own cloud storage service. So if you go down this path, the first thing you're going to have to do is set up and configure a bunch of servers. Whether you buy or rent these, you're going to need the infrastructure to basically service all these requests coming in from all of your devices. This is quite a bit of work. Then you're going to have to create your own protocol. That's always a lot of fun.

You're going to have to write a lot of code, both on the client and on the server, to make sure that everything is efficient and reliably moving between all of your devices in the cloud. You'll need to add push notifications, because your customers are going to expect that everything gets updated immediately.

You'll need to add replication in your data centers for high availability and disaster recovery. And anyone who's done this knows this is an incredibly difficult problem to solve. Once you get this thing operating, well, then you get to be on call all the time. And after all that, you get to pay for the storage and the bandwidth. Or you can simply use the iCloud Storage APIs.

Now, iCloud is a brand new service built from the ground up to basically put users' content in the cloud and distribute it through push down to all the devices. But it's actually built on quite a bit of experience at Apple with cloud services, and some of these you should be very familiar with.

So the first is the iTunes Store. The iTunes Store has distributed 15 billion songs all over the world on the internet. And if you think about it, when iTunes Store was first created, it was at a time when the browser was king. Everyone thought if you're going to do e-commerce, you should use a browser.

But Apple did it different. They said, we're going to build an application that allows you to directly interact with the data you want in the way that makes the most sense. And we're going to create a cloud service called the iTunes Store that works with that application. This was done many, many years ago.

The second application is the App Store. The App Store has distributed 14 billion of your applications over the past several years. And it's done in a way that really is a seamless extension of iOS. It's that same seamless extension that we want to bring to all of iCloud, so that it just works. Now between these two stores, we have around 225 million user accounts. And those user accounts have credit card information and purchase history. So our customers are trusting us with some very critical information. And now we have the Apple Push Notification Service.

APNS is behind Push Email. It's also a developer API that we actually released two years ago at the Worldwide Developers Conference in 2009. So it's given us some great experience with delivering APIs that developers can use to interact with our cloud services. APS is fast, it's efficient, and it's reliably distributed over 100 billion notifications since it started.

FaceTime. So FaceTime is this wonderful service that connects people together wherever they are and whenever they want. And it does it in a way, again, that the user doesn't even know. There's a cloud service behind it that's basically matching up people. And it does this in a way that just works.

And finally, Game Center. So Game Center has been used by 50 million users around the world. These users want to immediately update others with their gaming information. And they want it to just happen. Now. And an important point around these services is also who's behind them. So the same people who help build these services, many of them are the ones behind iCloud. So we have some great engineering behind the service.

Now, in addition to the technology, when you're offering a cloud service, you have to have infrastructure. And Apple's scale really helps here. As you know, we have a new data center. It's out in Maiden. It's huge. It's our third facility. It represents over a $500 million investment in iCloud. And because of this investment, it means that you get to take advantage of this infrastructure simply by using the iCloud Storage APIs. Now, at the keynote yesterday, Roger Rosner demonstrated the iWork applications on an iPhone and an iPad, seamlessly sharing information between each other.

Now, we spent a lot of time with Roger's team talking about cloud storage and the best way that we could provide this feature in applications. Now, the result of that work together was basically the iCloud Storage APIs. And the iWork applications use the exact same iCloud Storage APIs that your applications can use as well.

So there's no reason for you not to join this group. So we look forward to seeing the amazing applications that you develop that take advantage of the iCloud Storage APIs. And with that, I'm going to hand it back over to Dallas, and he's going to take you through the APIs in more detail. Thank you.

So as Eric mentioned, the demo that you saw yesterday in the keynote was done by the iWork team, and they built it directly on these APIs. It didn't have any private interfaces available to them. They built it with the APIs that we're going to be making available in iOS 5 and Mac OS X Lion.

So if you were at Ali Ozer's talk about what's new in Cocoa, he started talking about NS File Manager, which is the first API that we've extended to support Cloud Storage. As I mentioned, the way that Cloud Storage fundamentally works is you take the documents that you want to sync, and you put them into your app's iCloud sandbox. NS File Manager is how you do that.

We're also going to be talking about NS Metadata Query. If you're familiar with the Spotlight APIs on Mac OS X, we're also making NS Metadata Query available for iCloud Storage in particular, which will allow your application to discover all of the files that are available to it. We're also introducing a new class in UI Document-- excuse me, a new class called UI Document in Cocoa Touch that encapsulates all of the Cloud Storage APIs that you might need for doing a UI kit-based document.

In addition, we've extended NS Document to also support cloud storage. And the vast majority of your applications are going to be able to take advantage of these two classes to participate in cloud storage. However, we're also providing a glass of ice water for our Windows developers, so they can participate in cloud storage as well.

And we also have this key value data store that we're introducing in the event that your application doesn't need to sync entire documents, but it still wants to move simpler key value information between devices. I would like to point out that key value store is only available on iOS and Mac OS X line.

So let's get into NS File Manager a little bit. The first API is that it allows you to move a file into the iCloud sandbox. So that's how you tell the system that you intend to make this available to other devices. That's all you have to do. You just put it in that sandbox, and the system will begin moving it up to iCloud, and reflecting it down to the other devices on your behalf.

In addition, we're also going to talk about the NS Metadata Query APIs, which will tell you about all of the files that are available. You can use NS File Manager to determine if you've got a URL in hand, if it's currently a part of iCloud. It will also allow you to locate the physical location of the iCloud sandbox for your application, in case you need to do something a little bit more sophisticated than just put this file in it.

Another feature that we're introducing with iCloud Storage is the ability to publish a URL for downloading. So if you've created a document, and for example, you want to mail it as an attachment to someone who is To another user, what you can do is you can use the NS File Manager APIs to publish that document. It will give you back a URL, and then you can send that in an email.

Then the person on the other end can download that document in a web browser like Safari. One thing to note about the published URLs is that they will expire after a certain amount of time, so they're not permanent. We're also introducing NS Metadata Query that provides an asynchronous discovery and notification API that allows your applications to learn about all of the files that are available to it, even if they're being created on another device.

To do this, we're introducing two new search scopes to NS Metadata Query. The first is NS Metadata Query Local Document Scope. Say that three times fast. And what this does is, it's a scope that will return all of the documents that are local to your application on that device. So these are, in the case of an iOS app, the documents that traditionally are inside of your local sandbox. But now you can get access to all of them via the standard API.

We're also introducing a second scope called NS Metadata Query Ubiquitous Document Scope, which will return the list of documents that are local to your application, but also all of the other documents that might be on another device that are known to iCloud. Once you receive all the information from this query, you're going to get back a list of NSMetadata items. And so we've extended the set of attributes for NSMetadata item to help describe those files, now that they're available to you. The first are a set of standard file attributes, like its name, its localized display name, its size, and its modification dates.

But we're also going to be providing a set of iCloud attributes as well. So these are things like-- Is the file currently being uploaded to iCloud, or is it being downloaded to your device? Percentage complete for the amount of data that's currently made it up to the cloud or not. As well as if the file had a conflict when it was being transferred to iCloud. So as I mentioned previously, the system will go ahead and resolve conflicts automatically. And what I mean by that is that the system is going to choose a winner.

And NSMetadata query is going to allow you to discover that the system went ahead and chose a winner. And we're going to talk about some API that's also being introduced that then allows your application to go and make a better decision on behalf of the user if the system didn't quite get it right.

I would like to point out that these new scopes do not work with the more complex predicates. So if you're familiar with the Spotlight APIs on Mac OS X, these are a little bit simpler. So UIDocument is a new class that we're introducing in Cocoa Touch with iOS 5. And what it provides is a simple asynchronous reading and writing model for your documents. So if you're writing an application on iOS that is managing documents, you want to be using UIDocument.

It provides a simple autosaving mechanism. So the model on iOS is the user doesn't have to go click a Save button. This same feature is also being introduced in Mac OS X Lion. But by using UIDocument, you get that for free. It also includes automatic support for suspended apps. So if you're running on iOS and your application is suspended, the user switches out, or the system needed more resources, your documents are automatically going to be saved by the UIDocument system. This also includes the new Cocoa Document model that Ali started talking about in the web. So what's new in Cocoa Talk this morning? And by taking advantage of UIDocument, you're also going to be taking advantage of iCloud storage support.

On Mac OS X, NS Document has also been extended to provide support for iCloud Storage. This includes a new modernized document model. And if you were at Craig's talk yesterday, he talked a little bit about what we're building here. And in particular, it's a document model that is making it easier for your applications to manage concurrent access to the same document. So on the Mac, That might mean two applications that are talking to the same document, but the exact same APIs are what also allow two applications running on two different devices to coordinate via iCloud Storage.

If the case where NS Document isn't exactly going to be the right thing for your app, it sits on top of lower level APIs, the first of which is NS File Coordinator. And NS File Coordinator allows your application to coordinate with other applications and basically says, "Hey, I've currently got this document loaded, and I'm making changes to it." There's also the NS File Presenter protocol, which is how your application interacts with the system to say that I've loaded this document, and I'm presenting its contents to the user.

One of the things Craig mentioned yesterday was the idea that with the new version support, we can have multiple versions of the document on disk, but when the user actually goes and clicks on it and drags it into mail, we need to make sure that we have the latest version being used as the attachment. And it's NS File Presenter, which is how the system also communicates back with your app.

So it helps you manage concurrent access to a document. And lastly, there's the NS File Version APIs, which in the context of iCloud Storage, is how your application can get access to that other conflicted document in the case where the system made a choice for conflict resolution, and your application can make a better decision on behalf of the user. So it allows you to manage multiple versions, as well as iCloud conflicts. As I mentioned, we also have a Windows API available. What it will allow you to do is discover the iCloud Sandbox on that platform, and receive notifications when files are modified.

Now, there's an entire set of applications that we call Shoebox app, and a good example of that is iPhoto. And this is because not every document is a simple file or even a simple package. Instead, what you might have is a database that indexes a wide set of files on behalf of the user, and then presents that in an understandable way in the UI.

Now, most shoebox applications are built using our core data APIs, and core data does take advantage of iCloud Storage. So, if you're building an application that uses a simple file, or a package, or it uses core data, all of those can participate in iCloud Storage, and your documents will move from an iOS device to a Mac, and to a Windows device as well. At this point, I'd like to talk a little bit more about the key value data API that we're providing. This API is when you want to store a small amount of information.

So, for example, if you have an application that tracks the set of stocks on behalf of a user, or the cities they're interested in, and their weather app. or the pages that I read in a book, this is the perfect API for doing that. It allows you to reflect an application's behavior across all of the user's devices, so that he doesn't have to keep entering in all of that.

In particular, it's for storing a small amount of information. So if you start shoving lots of things in here, you're going to violate the quota. We're introducing a new API in both iOS and Mac OS X that we call NS Ubiquitous Key Value Store. It stores simple plist values. So the standard objects that you would serialize in a property list today, these are the types of values that we put up in the store. Your own custom objects won't work. You'll have to serialize them into an NSData, and then put them into the key value store.

We have a reserved quota per application. So iCloud Storage, as they mentioned previously, iCloud Storage has a five gigabyte quota that's free for the user, but it includes their mail, their cloud backups, and all of their iCloud Storage documents. NS Ubiquitous Key Value Store is a separate quota that is just for your app.

You'll receive change notifications when specific keys and values change on another device. But it does not do any conflict resolution. It's much, much simpler. Instead, the last change wins. So if you have your app on an iPhone, an app on an iPad, If I set a value on my iPhone, and then I set it on my iPad, the value set by the iPad is what's the truth in iCloud.

So I'd like to talk a little bit about what this code might actually look like in your application. It's fairly simple, and as Ali mentioned previously, if you've used NS user defaults before, it's going to look pretty familiar. The first thing you'll do is get your default store.

And you will also register for notifications from the device when something changes. And this is pretty standard notification API. Once you've gotten your store, you then tell the system to synchronize, and what it will do is synchronize any changes you've made with the server. Now, if you call it for the first time, it's going to bring down the key value data that is currently up in iCloud. So in the case where you actually want to set stuff in key value data, that's it.

That's all you have to do. You set specific property list type values in your store. You also want to take those changes and write them out on a disk. And then you call synchronize, and they'll be moved up into the cloud. As I mentioned, the system does not support conflicts, and so whoever made a change to a particular key last is the winner.

Now, when you receive that notification, one of the pieces of information we're going to give you is the reason that you got that notification. There can be a few different ones. The first is that this is the initial download, so your app is launched on a new device for the first time, and you're going to get a notification that we're bringing down all the key value data associated with your app.

You're also going to get a notification if a particular key was changed on another device, and this is also how the system's going to tell you if you violated the quota, if you've just put too much information into it. Once you get your notification, you determine the reason that we called it, we're going to give you back a list of the keys that actually changed, and at that point, you can go look up their values with the key value data store, and you've moved that data between two devices.

So we've talked about the APIs that you can take advantage of to add iCloud Storage to your app. And at the end of the session, I'm going to show you a bunch of the more in-depth talks about each API you can go to, and there's also a ton of labs.

But what do you have to do to get started? The first thing you need to do is update your provisioning profile with Xcode 4. And what you're going to need to do is add two new entitlements to your application to indicate to the system that you want to participate in iCloud Storage. This first one, Ubiquity Container Identifiers, is how you indicate to the system that you want to put documents into an iCloud sandbox. And the second one is if you want to use the Key Values Store as well.

So you may be in a position where you don't just want to sync your document with one application. You might have a Lite and a Pro version of your app, and iCloud Storage will support that. So if a user has on one device the Lite version of your app and the Pro version on a different, they're going to be able to share documents with each other, even if they have different bundle identifiers. You might also have a suite of apps that work together that understand each other's document formats and can work on those documents concurrently.

And the way we allow you to do this is with that first container entitlement that I talked about. This is how you're going to be able to specify that I want this set of apps to be able to access each other's files on all of the user's devices. And if you've adopted NS File Manager, and you've adopted NS Metadata Query, you're going to get all of that support for free. You don't have to do anything new, in addition to the previous API, to take advantage of this between multiple versions of your apps.

Also, because you might have a Lite and a Pro version, you can use iCloud Storage to manage how the quota is displayed to the user. I'll talk about the quota in a moment, but in particular, you're going to be able to manage the display set, so you can give a unified user experience to the user when they're trying to figure out what documents are taking up space. So in particular, with regards to the quota, the user gets five gigabytes free, and they can manage their quota through settings or system preferences on the Mac.

So what they're going to see is they're going to see, for example, their cloud backups, but then for each application that's participating in iCloud Storage, they can then drill into it, and look at their individual documents. As I mentioned, the quota is shared across your mail, your cloud backups, and your iCloud Storage documents. And the individual user can go in and delete a specific document if he wants to. He can also delete all of the data associated with a document.

So we've talked about the APIs that are available to you. We've also talked about what you have to do to get up and running. There are some things we'd like you to consider if you add iCloud Storage to your application. In particular, avoid saving your document if nothing has actually changed. Every time you modify a file in the iCloud sandbox, the system is going to do work.

It's going to determine what changes have been made, and it's going to want to move them up to iCloud. So if there's not any actual substantial change to the document from the point of view of the user, then you probably don't need to be making any changes to the actual files in that sandbox.

Also, avoid publishing private information. For example, with the publishing API that we're providing, what you don't want to do is surprise your user. For example, if you have undue stacks in your document, what you might be doing is keeping a history of all of the edits that the user has made to that document, and that information itself is within the files being moved up to iCloud.

What this undo stack actually represents are the set of decisions that the user has made about his data. He's decided the specific things that he doesn't want in the document. But if you've saved that in the document itself, and then he's published it, well, now it's been made available to someone else, and he might not have intended that. So that's something you want to keep in mind when you're building your applications. I'm going to go ahead and show you a little bit of a demo.

In addition, none of the APIs that we discussed today are appropriate for storing passwords or other credentials that your application might use to communicate with another service. If you are dealing with passcodes or you are dealing with credentials, you should be using the Keychain API. And there's a session later this week that will go into greater detail about how to use that and our data protection APIs on iOS.

There's an internet maxim that talks about being conservative in what you do, and liberal in what you accept. One of the great things about the App Store is that it makes it very easy for developers to make new versions of their apps available. The user can update, the system takes care of all of that infrastructure on your behalf. But what this might mean is that your user has one version of an app on his phone, and a different version on his Mac, or a different version on his iPad, and they might have different document formats.

You might have updated the version, you might be writing things out in a different way, and you're going to need to be prepared for that, because you might see a document in the latest version of your app, that was actually created by an older version. And you need to be prepared for what that might mean.

So you want to respect other file formats in your version in the apps that are running on the user's device. For example, with regards to the file formats, your document might be sorting something from A to Z in your newest version. But the previous version of your application actually stored it in Z to A.

So if you modify that document, and you write it back out in one sorting format, the document then moves to the device that older version. It might then turn around and write it back out in Z to A. And now you're ping-ponging data back and forth between those devices. Also, if your application is generating cached data, this isn't the type of thing you need to be moving around between iCloud. So if your application can auto-generate it on one app, it can auto-generate it on the other device as well.

Also, use the Key Value Data Store when it's appropriate for your application. If you don't need to be putting things in large documents, you just need to be syncing a small amount of information between your devices, Key Value Data Store is the API you want to use. So to recap what we've talked about today, we talked about the iCloud Storage feature and the problems that we're trying to solve on behalf of our developers. In particular, let the operating system move it through for you. The OS on each device and the iCloud service have taken all the difficult work of building all of the infrastructure and dealing with all of the protocols for moving data, and we'll move it for you.

It will be available on iOS, Lion, and Windows later this year. In particular, we went into the iCloud Storage APIs that you can use for taking advantage of iCloud Storage in your app. We talked about the new UI Document class that's being introduced in Cocoa Touch, as well as the extensions we've made to NS Document. Again, for the vast majority of your apps, these are the two classes that all you're going to need to use to take advantage of iCloud.

That said, if you need to do more specific and more detailed work, there's also the File Coordinator, Presenter, and Version APIs for managing your stuff directly. And if you were building a shoebox application and you used core data, you're also going to be able to take advantage of iCloud Storage. And lastly, we talked about the key value data store, and how you can sync small amounts of information.

So we have a number of sessions later this week that are going to go into greater detail on each of the APIs that I've talked about today. There's autosave inversions in Mac OS X Lion. That's going to talk more about the NS document model that we're introducing. There's also a What's New in Core Data on iOS talk, that if you are building a sandbox application, you definitely want to go to this talk. There's taking advantage of file coordination, as well as storing documents in iCloud using iOS 5. That's going to go into a lot of detail about UI document itself.

As I mentioned, none of the APIs we've discussed today are appropriate for things like passwords and credentials. But if you are dealing with that type of information, you should go to the Securing Application Data talk. And there will be a repeat of the What's New in Core Data talk on Mac OS X for the Mac, not for iOS. All right? Thank you very much for your time, and I hope you have a great time at the conference this week.