Transcript
[ Applause ]
>> 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
[phonetic], 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
see those edits.
So, we have a core data, we're
locally storing all of our data
locally in core data, and we do
this for quick reads and writes,
and for offline access.
But, every time there's a
modification, when there's
network availability, we want to
send that back to the server.
The server holds the truth.
And, if we use in CloudKit
what's called subscriptions, we
can have the server send push
notifications to my other
devices or to other users'
devices whenever data they care
about changes.
So, here's how we're going to
make that work in the example
app.
The first time it runs, we're
going to create a
CKDatabaseSubscription on the
server for that user's private
database.
That tells the server to send
push notifications to this
user's devices whenever their
private data changes, anything
inside their private database.
We also, because we're using
sharing, have a subscription in
their shared database.
So, CloudKit will now send push
notifications to this user's
devices when data changes in
either of those places.
Now, once we receive one of
those push notifications in our
app, or when it launches, we
need a way to ask the server for
the changes that exist that we
don't have yet, and we're going
to do that with
CKFetchDatabaseChangesOperation.
This asks the server, "Please
tell me what zones have
changed," remember, we mentioned
zones earlier, "inside of this
database."
And, if any of them did, we can
then turn around and ask the
server what records changed
inside of that zone, or those
zones, with CKFetchRecordZone
ChangesOperation.
To learn more about this, check
our last year's session,
CloudKit Best Practices, and
because it is such a commonly
used workflow, we've added new
documentation called
"Maintaining a Local Cache of
CloudKit Records," that walks
you through this workflow and
gives you a bunch of Swift code
so that you can build it into
your application.
Now, because fetching changes is
such a common thing, we've built
the ability to play and
experiment with it right inside
the Dashboard.
So, let's go take a look.
Alright. So, up on the screen,
on the left side, you can see
the new CloudKit Dashboard, and
on the right side, I'm sharing
the screen of this iPhone
running that example to-do list
application that I mentioned
before.
Now, if you look in the
Dashboard, we're on the home
page.
I'm signed in with my developer
account, and the first thing you
can see are all of your
developer teams, all of the
teams that you're a part of,
because you may be a part of
more than one team.
For each team, you can see the
CloudKit containers that that
teams owns, and you can quickly
see which ones have been
deployed to production and which
ones are still in development.
If you have a bunch of teams, or
a bunch of containers, you can
always filter down the list up
at the top.
Now, in this case, this is the
container I'm using for this
example app that I'm demoing, so
let's click in.
When you click into a container,
you see the development and
production environments that I
mentioned earlier, side by side.
And, in this case, we're using
the development environment,
because I'm still building this
example app.
So, let's click into the data
section, and into a tab called
Zones.
This lets you play with the zone
API in CloudKit.
You can ask the server for zone
information inside of a specific
database.
Now, in this case, I want to
show you, I'm logged into the
Dashboard with my developer
account, and that Apple ID is
the same one on my device.
It's my personal iCloud account,
and my developer account.
So, because it is my personal
iCloud account, I can see my
private and shared databases.
>> So here, the Dashboard asks
you, "Would you like to load
zones from a private database
for this account, a shared
database, or the public
database?"
And, let's do the private
database.
Because we want to use the fetch
changes APIs, we're going to
check this box to fetch the
zones that have changed inside
of this database since a certain
point in time.
Now, the way this API works is,
it allows you to specify a
change token which marks where
in history you have synchronized
up to.
You can apply that here, and
we're going to leave it blank,
which tells the server we want
all changes inside of this
database since the beginning of
time, and if I fetch the
changes, you see we get a
result.
This To-dos zone is the zone
that my application created the
first time it ran on this
device, and it gives us a place
to store the future records that
we'll be saving as the user
creates to-do lists and items.
Notice that the server returned
a change token which, it's
populated automatically in this
field, marking that we've moved
forward in time.
So, if I fetch changes again
with this token now, the server
says, "No zones have changed
since then," so we're up to
date.
Now, if I clear that token and
we go back since the beginning
of time, we'll see my To-dos
zone.
If I hover this row, the
Dashboard gives us a handy
little link to then go and fetch
the record changes inside of
this zone.
So, let's do that.
Notice it's taken us over to the
Records tab.
It's chosen my private database,
the To-dos zone that I clicked
on, and it said we want to load
record using the fetch changes
APIs.
And, we see two results over on
the right.
The first is a List record, and
if you look on the right side of
the screen, you'll see that's
because I've already created a
to-do list in my application,
Vacation Ideas, and it's stored
that back to the server, and so
the server is telling us about
that change.
We also see a shared record, but
we'll get back to that in just a
second.
So, much like the fetch database
changes, when you fetch zone
changes, the server returned to
us the change token where we are
now in history, so if I fetch
changes again, it says there are
no new record changes inside of
this zone since that point of
time.
Alright. Now, let's take the iOS
application and create a new
to-do list.
Or, maybe not.
Well, the good news is, oh,
there it goes.
It caught up.
Alright. And, let's name this
one Chores, because
unfortunately I'll have to do
those.
Alright. So, that technically
saved back two lists to the
server, so we have three here in
our iOS application.
Now, let's jump back to the
Dashboard and fetch those
changes inside of this zone
since the last time, when it
said there weren't any.
So now, when I fetch changes, we
see those two List records that
I just created in the app.
And, if I tap on the record name
for that second one, it opens up
what we call the Record Editor.
This shows you information about
that specific record, and in
this case, we can see its unique
record name.
We can see the record type, and
in this case, it's a List record
type, like I mentioned before,
when we were talking about the
data model.
It's in my private database in
the To-dos zone, and it was
created and modified by me just
a second ago.
Down below, you can see the
fields that we stored for this
record, and in this case, we're
using a Name field to store the
name that the user provided in
the application.
So, I've decided, chores don't
sound very exciting, so let's
rename this to Movies to Watch,
and change the to-do list.
Now, I'm going to save this back
to the Server view of the
Dashboard, and I want you to
watch the iOS application on the
right side.
So, the Dashboard changed, saved
that record change back to the
server.
The server saw that I had a
subscription for my private
database, sent a push
notification to my device.
My application saw that push,
turned around, fetched the new
changes, updated its local core
data cache, and now you can see
the UI reflects the fact that
we've changed that list to
Movies to Watch.
So, hopefully that walks you
through some of the things that
you can do now with the fetch
changes API.
Let's jump back to slides and
recap what we just talked about.
So, in the Dashboard, when we
use the Record Editor to modify
that record to update it on the
server, it used the publicly
available CloudKit Web Service
APIs that all of you can use.
It sent an HTTP post to the
records modify end point, and it
sent a JSON body saying, "I
would like to update this
record," and set its name field
to Movies to Watch.
That corresponds to the
CKModifyRecordsOperation in the
iOS, the native API, which we're
using in the example iOS
application up here.
When we fetched zone changes
inside of our To-dos zone, that
used the publicly available
records changes end point, and
it said, "Server, please tell me
the set of records that have
changed in the To-dos zone for
days of count since this change
token."
And, that corresponds to the
CKFetchRecordZone
ChangesOperation in the native
API, which we're using in our
app.
So, the point here is that the
Dashboard now lets you play with
the exact same APIs that you're
using in your native and web
applications, hopefully allowing
you to understand and debug
functionality as you're building
it into your application.
Now, I mentioned that part of
getting all of this data
synchronization to work is
subscriptions and push
notifications, so let's jump
back into the Dashboard and see
how it's given us the ability to
experiment and understand more
of this behavior.
So, I'm going to close out the
Record Editor, and as a
reminder, we're in the
development environment data
section.
There's a new tab here for
Subscriptions.
If I click it, this lets me use
the subscriptions API in
CloudKit to fetch down
subscriptions that exist inside
of a specific database.
So, I'm going to ask what
subscriptions exist in my
private database, and we see
that our server returned a
result.
It's a database subscription,
and I've given it the ID of
private changes, which is
something I chose in my code.
So, that's a subscription that
exists that will tell the server
to send push notifications
whenever my private data
changes.
If we look in the shared
database, we also see a database
subscription there, like I
mentioned, with the ID, shared
changes.
Now, there are subscriptions and
push notifications and you're
fetching changes, potentially
across multiple devices.
There's a lot going on here.
Wouldn't it be awesome to see a
log of all of these events as
they're happening on the server?
Well, now there is.
If I click back up to the
container, thanks, there's a new
section called Logs that I'm
going to click into for the
development environment.
This starts on a feature we call
Live Log.
It opens up a real-time
connection back to the CloudKit
server, and the server will push
events as they happen right to
your browser.
It loads a bit of history, so
here we can see some requests we
were doing from iOS, from the
app up here, as well as from the
Web Service API, because that's
what the CloudKit Dashboard was
using.
We can see we were doing some
record modifies, some zone
fetches, etc. Now, let me clear
this out, and let's create a new
list, and watch what happens in
the log.
So, I'm going to create a list,
then we see the event pop in, or
boom.
So, here we can see some
information about the specific
event, but let's jump back into
slides and talk about all of the
things you might see show up in
your log.
So, here's an example row, like
we just saw in the user
interface.
Let's walk through each column
and see what shows up.
The first one is the time.
This is the time at which the
event happened on the server.
The next column is the platform.
This tells you which platform
the request came from.
Because CloudKit is available
iOS macOS, tvOS, and watchOS,
you may see all of those show up
here, if you're building apps on
those platforms.
You also see the version of the
platform, and if you're using
the Web Service API to build a
web application or to extend
your app to another platform,
then you'll see it show up here
as web.
The next column is the user.
This will show you the CloudKit
user record ID.
Now, in this case, if the person
that sent this event is on your
developer team, we know their
name, and we'll show it.
So, we knew my name, because I'm
logged into Dashboard on my
team, and this is handy as
you're testing things out with
people on your team in
development.
But, for everyone else, for all
of your normal users, it will
show you the CloudKit user
record ID.
The next column is the type of
the event.
This is most commonly database,
as you're interacting with the
database API, but if you have
subscriptions and CloudKit is
sending push notifications on
your behalf, you will see pushes
show up right here in this log
as they happen.
You will also see sharing events
called out separately.
The next column is the operation
ID.
So, as of iOS 10.3, and the
newest version of macOS Sierra,
CloudKit will automatically
create unique IDs for every
operation that you're issuing in
the native API, and you will see
them show up here.
The next column is operation
group name, which we'll get back
to in just a second, and the
final column are the set of
details specific to this type of
event.
Now, in this case, it was a
database event, and so we can
see the type of database
operation that we issued back to
the server.
This one was a zone fetch, but
you'll see things like record
modify, database changes,
depending on the type of
operations you're submitting.
In this case, because it's a
database operation, we could see
it was in the private database,
and in the To-dos zone.
We also see the server latency.
Now, this is how much time it
took the CloudKit server to
process this, but note that it
doesn't include internet latency
or the time spent getting from
the client to the server and
back.
You can see the request size,
and the response size.
You can also see the hardware
identifier, and no, this is not
a new iPhone.
This is actually the identifier
for an iPhone 6s Plus, like I'm
running up here.
>> Some more information about
operation groups, which we'll
talk about in just a second, and
finally, the request ID.
This is interesting, because
when you issue an operation via
the API, that usually maps to a
one-to-one request, but in some
cases, the client may need to
issue multiple network requests
to carry out your operation, and
if it does, you will see
multiple rows show up in the log
with the same operation ID but
different request IDs, allowing
you to differentiate.
If an event leads to an error,
you will see it called out in
red, and it will tell you the
specific type of error.
In this case, I tried to fetch a
zone that didn't exist, and so
the server said this was a zone
not found.
Alright. So, I mentioned
operation groups a couple times,
so what's that about?
Well, new in iOS 11 and all of
the other matching platforms,
we've provided, as you probably
guessed, the ability to group
operations based on application
logic.
So, let me give you an example.
In this example to-do list app,
there are a number of things
that it needs to do when it
first launches, in the
initialization logic.
It needed to create a zone on
the server within which to store
our records.
It needs to create two
subscriptions.
Remember, I mentioned the
database subscription in the
private and shared database.
And, it needs to fetch down any
existing changes in the private
and shared database, and then
potentially fetch zone changes.
So, there's a number of
operations, all of which
encompass the initialization
logic, and so we now have a way
to group all of that logic
together.
Now, as you probably know, there
are a number of Apple
applications built on top of
CloudKit, and I'd like to give
you some examples of how we use
operation group names in our
apps.
So, iCloud Backup is built on
top of CloudKit.
So, every night when your iPhone
or iPad is plugged in and on
Wi-Fi, it'll automatically back
itself up.
That may take a number of
CloudKit operations to do, and
so we can group those up inside
of an operation group named
Automated Backup.
If the user triggers one
manually, we can call that out
separately as a Manual Backup.
And, when they go to restore the
data on a new device, we can
have an operation group that
encompasses all of the
operations within.
iCloud Photo Library is built on
top of CloudKit, and they use
operation groups to designate
when they're setting up your
library, downloading thumbnails,
or fetching a movie that you
tapped on.
iCloud Drive is built on
CloudKit, and so they have
operation groups to call out
when they're initially pulling
down any changes from a server,
when they do so after a push
because of a subscription, or
when you tap into a file to
download it.
So, let's look at the API.
So, there's a new class,
CKOperationGroup.
It provides you an operation
group ID set for you by the
system.
It allows you to specify a
CKOperationConfiguration, which
we'll talk about in just a
second.
It allows you to provide a name.
This is any string that makes
sense in your application, and
the names on the previous slide
were ones that we use, and you
want to be careful not to put
personally identifiable
information into this.
This is your app logic, what
it's doing.
The next property is quantity.
This is an integer that you can
set, and it's completely up to
your application.
So, some examples from our apps
might be when we're backing
something up in iCloud Backup,
we might designate how many
files we're backing up.
Or, in iCloud Photo Library,
when they're downloading
thumbnails, we could use it to
say how many thumbnails are
being downloaded in this group.
But, the point is, it's
completely up to your
application.
You could also set the expected
send and receive sizes, and this
tells the server, I'm sorry,
tells the client how much data
you think you're estimating will
be sent back and forth between
you and the server.
And, notice the type is
CKOperationGroupTransferSize,
and this is an enum which allows
you to specify an order of
magnitude.
So, the point is, is that it's
an order-of-magnitude estimate.
It doesn't have to be perfect
exact byte counts.
And, by setting things like
these properties, as well as
properties like quality of
service, this allows the system
to optimize when network calls
are sent back to the server
based on the network conditions
of your user's device.
Finally, once you've configured
an operation group, you can add
an operation to it by applying
it to its group property.
Now, I mentioned
CKOperationConfiguration, so
let's talk about that for a
second.
In the past, you used to define
properties like
qualityOfService,
allowsCellularAccess,
isLongLived on an operation.
That is now deprecated, and
instead, you apply it to a
CKOperationConfiguration, and
the reason for that is because
we found that it was very easy
to forget to apply these to all
of the operations that you're
issuing in your client.
So now, you can set it up maybe
once or a few times.
You can apply it specifically to
an operation, if that makes
sense, or hopefully more likely,
to an entire operation group,
which applies it to all of the
operations within, and that was
that default configuration
property on operation group that
we saw before.
OK. So, if you look back at that
example log event from before,
let's call out some of the
things that we saw around
operation groups.
So here, you can see in the log
the operation group name, so I
can see this event happened
because of my applications
initialization logic.
You can also see its unique
operation group ID and a
quantity property, if you set
it.
Now, at every event, you can see
the operation group that it
applied to.
You can then see the specific
operation that applies, based on
the operation ID, and if it
leads to multiple requests, you
can always see the specific
request ID.
Alright. So, with this new log
feature and the things being
exposed, let's take a minute to
talk about privacy.
As you know, Apple cares very
deeply about our users' privacy,
but with CloudKit, we also
understand that you're working
with a system that you don't own
or have full control over, yet
you still need to debug customer
problems.
So, with both of those things in
mind, here's how it works.
As a reminder, when you log into
the CloudKit Dashboard with your
iCloud account, you can see your
private and shared data in your
private and shared databases,
just like I showed.
But, you cannot see the private
and shared data of other users.
You can see the public data in
the public database, because
it's meant to be public, and you
can now see log events for you
and every other user.
However, log events do not
include the data.
So, for example, some of the
events we would see in the case
of this to-do list app, you
could see that my account was
issuing record modifies, but you
couldn't see that I was creating
a list named Vacation Ideas, or
Chores, or Movies to Watch.
So, we hope that this balance
really allows you to debug
problems as they happen, while
still keeping your customers'
data safe and private.
OK, so I mentioned earlier that
we wanted to add the ability to
share in this example
application.
We want to let our users
securely share a to-do list with
other users so that they can
collaborate.
As a reminder, this was our data
model.
We point items back to a list
via the parent reference, and we
have the list as the root record
in a share.
Now, we've added some of the
ability to debug and explore
more of this in CloudKit
Dashboard, so let's go take a
look.
Now, on the right side of the
screen, I want you to look at
the iOS app.
I'm going to tap into that top
Vacation Ideas List record, and
you'll notice that it shows us
some information saying that
this is already shared.
So, what happened was, I created
this to-do list on my phone,
which means it's in my private
database, so I'm the owner, but
I invited my friend, Emily
Parker, to share this, because
she's a travel expert, and I
wanted her to give me some ideas
on where to go on vacation.
So, in the Dashboard, if we go
back to the data section,
remember, the last time we were
looking at the records in my
private database in the To-dos
zone, and if we fetch changes
until we get to a point where
nothing has changed, so the
Dashboard is up to date, let's
add an item in the iOS
application.
So, let's say I would love to go
to Paris.
So, my iOS app has stored that
record as an Item record back to
the server, and if I fetch
changes in the Dashboard again,
we see it show up.
I'm going to tap on the record
name and open up the Record
Editor.
Again, we can see this is of the
Item record type.
It's in my private database in
the To-dos zone, and down under
the Field section, we can see
Paris, the name that I provided
in the iOS app.
Now, if I zoom in a bit, you'll
notice there's a section here
labeled Sharing, and it tells us
that this record is a
descendant.
That means that it points to a
parent via its parent reference.
The Dashboard tells us the
record name for that parent, and
provides us a little jump icon
to load that parent up inside
the Record Editor.
So, let's do that.
So now, we're looking at a List
record, and this is the Vacation
Ideas List record within which
we created the Paris item.
In the Sharing section, we can
see that this is a Root record
in a share.
It points to a specific share.
It tells us what that name is,
and we can open up that share.
So now, we're looking at a
CloudKit.share record, and down
below, you'll see on the share,
you can actually see information
about the sharing participants.
So, in this case, you can see me
as the owner, and Emily, having
accepted.
You can add and remove
participants right here to test
out how your app behaves when
that data is modified on the
server.
This allows you to browse
relationships, and if the Record
Editor detects that there are
any other types of references in
your record, it will also let
you jump to them, and we have a
bit of back and forward History
buttons up here in the top left.
So, that shows you a bit of how
you can view and navigate the
data relationships going on with
sharing.
>> Let's take a look at how logs
can help you out when you're
doing sharing functionality in
your app.
So, I'm going to load up the
logs.
Let's clear it out.
Let's create another item in my
iOS application.
So, let's say I'd also really
like to go to Vienna, Austria.
Now, I'm going to hit Return.
I want you to watch the
Dashboard log.
So first, we see a request come
in for the record modify.
We can see, notice my operation
group name.
I'm using one saying, "Oh, this
is logic for creating an item in
the application.
It was a record modify in Dave's
private database."
After that, we can subsequently
see that CloudKit sent a push
notification to Emily.
It was in her shared database
because of a subscription called
Shared Changes that we set up on
her device when she first ran
the app.
The push notification made it to
Emily's device, and then her app
turned around and fetched
database changes, and then zone
changes, and notice the
operation group name, fetching
changes after notification.
So, we really hope that this
will help you as you're
debugging and trying to
understand what's happening
across multiple devices and
potentially, multiple users in
sharing cases.
Now, in this case, we were in
the Live Log, but we also have a
feature called Historical Log.
This allows you to go back and
view events that happened in the
past.
We store events for up to seven
days, and you can do things
like, show me all the events
that happened yesterday, let's
say, between 9 and 10, and you
can provide a bunch more
filters, and this will return to
you all the events matching
those filters.
Alright. The last thing that I
would like to talk about is
telemetry.
So, last year we offered
CloudKit Telemetry, and this
year we've expanded the
offering.
As a reminder, telemetry is your
way to understand aggregate
behavior happening across all of
your users' devices coming into
your container.
In this case, we're looking at
the development environment, so
we're seeing information that
I've been playing with from this
app onstage.
You can choose a time filter, so
you can choose the last year,
the last 30 days, the last day,
or the last hour, and let's look
at the last hour, since that's
when we've been onstage playing
with this app.
You can ask for telemetry
information that applies to
everyone's private database,
everyone's shared database, or
just the public database, and
let's leave it on private.
You can also view telemetry
information around all
operations within that time
window for the private
databases, and we'll tell you
the specific types of
operations, and how many of each
came in during that time window.
So, you could say, "I would like
to see telemetry information
only for record modify
operations."
But, in this case, let's look at
it for all operations.
The first graph you see at the
top is called Requests.
This shows you all of the
requests coming into the server,
again, during this specific time
window, and for the private
databases, and how many requests
for each type came in at a time
slice.
Notice it's called requests, and
not operations, and that's
because, as I said before, as
you're issuing operations from
the API, in some cases, that
leads to multiple requests, and
we want to give you visibility
into all of the requests.
So, here we can see that I was
doing record modifies, database
changes, subscription modifies,
and how many of each.
We hope that this helps you,
during development, understand
how many types of requests
you're sending in, as you start
to test and build your app.
And then, in production, and
we'll see some examples in a
second, we really hope it lets
you monitor the types of request
coming in across all of your
users, to check for things like
drops or spikes that may mean
there's a bug as you release new
app versions.
If I scroll down a bit, the next
graph is called Server Latency.
Here, we're exposing to you
exactly how long, again, it took
the server to process these
events.
We show you the 50th and the
95th percentile, and as a
reminder, you can jump in and
see how long it takes for
certain types of operations.
And, the reason we want to give
you this information is so that
it helps you understand how long
it takes to process the type of
operation that you're adding to
your application, so that you
can choose the right one,
depending on the experience that
you're trying to build.
The next graph is Error Counts.
This used to be called Error
Rate, so we used to show you
what percentage of requests
failed.
Now we show you how many exact
ones failed, and how many users
it affected, and the specific
types of errors.
So, in this case, you can see at
this time slice, there was one
error.
It was a conflict, which meant I
tried to update something that
was already updated on the
server, and it affected one
user.
So, we hope that this
information will allow you to
detect when you might have
problems in your app causing
more errors, and to understand
what percentage of your user
base it might be affecting.
And finally, you still have
access to your average request
size, which shows you how much
data is coming in to the server.
Now again, this was my
development environment.
Let's jump back to slides and
take a look at some example
screenshots of these graphs in
the wild.
So, here's a Request graph from
one of your containers in the
wild, and you can see, on any
one day, they do about 2.3
million record fetch operations
across all of their users in the
private database.
And, what's interesting is if
you look at this scale, you can
actually start to see trends
across weekday and weekends.
And so, these developers can
hopefully use this to, like I
said, monitor for spikes or
drops, changes in this behavior,
as they release new versions.
And, of course, if you change
how you interact with CloudKit,
then maybe you expect a change.
Here's an example of an Errors
graph in the wild.
Notice that they have about, oh,
on any one day, 1500
zone-not-found errors, but it's
only affecting about 55 users,
which could be a small
percentage of their total user
base.
So, it might mean that there's
an edge case in their
application where it gets into a
weird state where it thinks a
zone exists that doesn't
actually exist in the server.
We have CKError documentation
that used to tell you all the
types of errors you might see.
We've updated that to explain
what each error means, and how
you might handle that in your
application.
So, the errors you'll see show
up in this graph map back to
that documentation.
We also give you some telemetry
around the push notifications
that CloudKit is sending for
your application in the wild.
It's separated based on the
subscriptions in the private,
public, and shared database, and
this is sort of a sanity check.
If a customer complains that
data is not synchronizing, you
can go here and feel good that
CloudKit is still sending push
notifications, that
subscriptions are still
configured right in your
application.
OK. So, what did we cover today?
Well, we've launched a brand-new
CloudKit Dashboard.
We hope you check it out, try it
out.
Please give us your feedback,
let us know what works, what
doesn't work, what else you'd
like to see there.
We've launched a new
CKOperationGroup API.
We hope you've started to see
the help it can provide you,
especially when looking in the
Dashboard Log, to understand
exactly what code led to what
network request being sent back
to the server.
Like I said, we want all of your
feedback.
It really does guide what we do,
so follow Radars, post on the
forums, let us know.
For more information, here's a
link back to this specific
session, and we also have an
email address, cloudkit@apple.
You're always welcome to reach
out and ask us any questions you
have.
And with that, thank you very
much.
Have a wonderful conference.