Build Better Apps with CloudKit Dashboard

Good morning.

My name is Dave Browning.

I'm on the CloudKit team here at Apple, and I'm super excited to talk to you about some new things in CloudKit, especially a brand-new CloudKit Dashboard. If you're not familiar with it, the Dashboard is a web application designed to help you as you're adding CloudKit functionality to your apps.

So first, I'd like to talk about some of our goals behind the things we're announcing today, and at a high level, as the title of this session suggests, we really want to help you build better applications on top of CloudKit, and we want to do that in a number of different ways.

First, we want to help you through all stages of your app's lifecycle.

So, when you're first learning about CloudKit, when you're starting to build your functionality into your application, when you're beta testing with users, when you're getting your app out into the App Store, going to production, scaling up, really honing in your user experience, and then finally, potentially supporting customer problems in the wild.

We want to give you the tools necessary to help you throughout all of those phases. We also want to give you a way to experiment with the entire API. Now, obviously, you can jump right in to Xcode and start using our API and figuring out how it works, but we want to give you something to sit alongside Xcode that lets you visually play with that same API so that you can experiment with it, understand how it works, while you're building that functionality into your application.

We also want to give you visibility into all events across the system, across all of your users, and especially once you're out in production in the App Store and growing your user base, we want to help you understand the aggregate behavior, the communication among all those users back at the CloudKit server.

Now, before I jump into a live demo of the Dashboard, I want to do two things.

First, let's do a quick refresher of some CloudKit concepts.

If you've used CloudKit before, you'll be familiar with some of this, but it's a good foundation, if you haven't used it, because I'll be using these concepts throughout the session. And then after that, second, I want to show you and talk about an example iOS application that we built on top of CloudKit that I'll be demoing today alongside the Dashboard to show you how the Dashboard can help you when you're testing and building your application.

Alright. So, first, some CloudKit concepts.

At the end of the day, you're using the API to store records back to the CloudKit server.

This is your structured data, your keys and values, and as a reminder, the values can be different types, strings, ints , doubles, an asset, which is a binary file.

When you store a record, it always exists inside of what we call a zone.

A zone is basically a bucket of records, and it's a foundational piece of some of our APIs that we'll talk about in a bit.

A zone always exists in a database, and some databases allow you to create different zones, if you need to bucket records in different ways.

All of your users have their own private database. This is where you store their private data that only they can see.

They also have their own shared database, and this is because last year, we launched CloudKit Sharing, and if one of your users shares data with another one, that data shows up in their shared database.

You can think of it as a proxy back to the owner's private data.

And then finally, there's a public database which everyone can read and write to, and there's one of those.

All of this data, all of these databases live in side of an environment.

When you're building your application, this is the development environment, and at the environment level, you define your schema, your record types, the type of data you'll be storing, and potentially indexes, if you're going to be querying it.

Now, you're using the development environment as you're building your app, and then once you put your app in a store, it talks to the production environment.

So, we give you a way to promote your schema changes to the production environment, and then in production, all of your users have their own private, shared, and one public database there, separate from the development environment.

And then, all of this lives in the highest-level concept, which is a container.

Container has a unique identifier, and it usually maps one to one with your application.

Okay, so that was the CloudKit concepts.

So, I mentioned that we built an example application on top of CloudKit that I want to use today during the demo.

So, let's talk about it.

It's a to-do list app, the age-old example. It's relatively simple.

The idea is, users can create to-do lists, and they can have items inside of there.

So, let's talk about the data model that we'll be using, since we'll be storing this data back to CloudKit.

So, every time your user creates a to-do list in the app, we'll create a List record on the server.

Whenever they create items within the list, we'll have an item record for each, and we need a way to point the item back to the list to which it belongs, and in CloudKit, you do that with a reference, which is basically a pointer back to another record via its identifier.

And, in this case, we're going to use what's called the parent reference.

The parent reference is a system field that exists on every record.

It's there for you by default, and it's the way in CloudKit that you logically tell the server when something has a parent. So, in this case, we'll point the item back to the List record using this parent reference.

Now, we also, in this example app, wanted to allow our users to securely share to-do lists with other users using CloudKit Sharing.

So, here's how that will work in the data model.

Our List record will be what we call a Root record, and it will point to a Share record.

A share is where you define the set of participants and their permissions, and because we use the parent reference to point items back to a list, they automatically get included in the share for us. You don't have to go and share them separately.

To learn more about sharing, make sure to go back and check out last year's session, What's New with CloudKit.

Okay, so that's how we're going to be storing the data.

Now, let's talk about the APIs we're going to be using, how we'll communicate back to the server.

So, the way we wanted this application to work is that if the user opens it up and creates to-do lists with items on their iPhone, but they also have an iPad, and they run the app there, we want that data to be synchronized.

And, because we're using sharing, if I share a list with someone else, and either of us edits it, we want the other to