302.srt

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:09.956 --> 00:00:10.726 A:middle
>> Good afternoon.

00:00:11.276 --> 00:00:12.326 A:middle
I'm Noah [phonetic].

00:00:12.536 --> 00:00:14.696 A:middle
I'm here with my
colleague Nick [phonetic].

00:00:14.916 --> 00:00:16.015 A:middle
And we're here to talk to you

00:00:16.015 --> 00:00:18.926 A:middle
about what's new in
Passbook in iOS 7.

00:00:20.496 --> 00:00:23.466 A:middle
Now, some of you have been
building really awesome things

00:00:23.466 --> 00:00:26.286 A:middle
on top of Passbook already, and
we've had a bunch of requests

00:00:26.286 --> 00:00:29.156 A:middle
from you for enhancements,
for new features,

00:00:29.696 --> 00:00:31.136 A:middle
and we've addressed
a ton of those,

00:00:31.136 --> 00:00:32.796 A:middle
and we've added some
new stuff as well.

00:00:32.796 --> 00:00:35.596 A:middle
And I'll be going into all
of that in a lot of detail.

00:00:37.186 --> 00:00:39.246 A:middle
Some of you have looked
at Passbook before

00:00:39.246 --> 00:00:40.196 A:middle
and considered using it

00:00:40.196 --> 00:00:42.626 A:middle
but found it didn't quite fit
your use case at the time.

00:00:43.126 --> 00:00:45.066 A:middle
And we've made a couple of
changes that may affect that,

00:00:45.066 --> 00:00:47.196 A:middle
so I'll be calling
those out as well later.

00:00:47.916 --> 00:00:50.806 A:middle
And, finally, some of you
are entirely new to Passbook

00:00:50.806 --> 00:00:52.606 A:middle
and just kind of curious
about what's going on.

00:00:53.106 --> 00:00:56.696 A:middle
So I'll be -- while our
talks last year went

00:00:56.696 --> 00:00:58.526 A:middle
into a bunch more detail
about how to get started,

00:00:58.526 --> 00:01:01.036 A:middle
how to build your first
pass, and that kind of thing,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:58.526 --> 00:01:01.036 A:middle
how to build your first
pass, and that kind of thing,

00:01:01.036 --> 00:01:03.056 A:middle
I'll still be covering some
high level concepts just

00:01:03.386 --> 00:01:05.736 A:middle
so you have some
idea what's going on.

00:01:05.906 --> 00:01:09.746 A:middle
So without further
ado: let's get started.

00:01:10.416 --> 00:01:12.336 A:middle
There's three main topics
I'll be covering today.

00:01:12.976 --> 00:01:16.816 A:middle
First the Passbook
ecosystem: the different parts,

00:01:16.816 --> 00:01:20.576 A:middle
how they fit together, how
they all talk to each other.

00:01:20.856 --> 00:01:22.806 A:middle
Second: what's new,
what we've added

00:01:22.856 --> 00:01:24.926 A:middle
to passes, to our APIs, the app.

00:01:25.076 --> 00:01:29.236 A:middle
And finally a couple
of tips, tricks,

00:01:29.586 --> 00:01:32.236 A:middle
ideas that might help
you with your debugging

00:01:32.236 --> 00:01:34.146 A:middle
and your development of
Passbook integration.

00:01:34.576 --> 00:01:37.506 A:middle
So let's go to the first
of these, the ecosystem.

00:01:38.086 --> 00:01:41.256 A:middle
To start with: what is a pass?

00:01:41.496 --> 00:01:43.756 A:middle
Well, it's just information
like any other,

00:01:43.856 --> 00:01:46.716 A:middle
but what makes a pass more
useful than just a photo

00:01:46.716 --> 00:01:48.306 A:middle
of a ticket, for instance, is --

00:01:48.346 --> 00:01:51.726 A:middle
first, that it can be
relevant to a time and place.

00:01:52.966 --> 00:01:57.016 A:middle
And second, that it can be used
for something in the real world:

00:01:57.076 --> 00:02:00.546 A:middle
to get into something, to buy
something, to do something.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:01:57.076 --> 00:02:00.546 A:middle
to get into something, to buy
something, to do something.

00:02:01.406 --> 00:02:05.396 A:middle
So how does a pass get
from you to your users?

00:02:05.986 --> 00:02:07.996 A:middle
Well, it starts with
your server,

00:02:08.545 --> 00:02:09.686 A:middle
which generates the pass.

00:02:10.196 --> 00:02:12.696 A:middle
Then it goes through your
website, or an email,

00:02:13.426 --> 00:02:15.836 A:middle
or an app of your own if
you have some existing flow

00:02:15.836 --> 00:02:17.626 A:middle
like buying a boarding pass.

00:02:18.166 --> 00:02:21.536 A:middle
From any of those three,
it goes into Passbook,

00:02:22.606 --> 00:02:23.986 A:middle
into the user's pass library,

00:02:24.686 --> 00:02:26.626 A:middle
and from there they
can interact with it.

00:02:26.626 --> 00:02:28.176 A:middle
There's a couple other
places that it can show

00:02:28.176 --> 00:02:30.406 A:middle
up on the system, and I'll
talk about those more in a bit.

00:02:30.406 --> 00:02:32.576 A:middle
But the core of it is that
it comes from these apps,

00:02:32.616 --> 00:02:36.986 A:middle
goes into your library,
and that's kind of that.

00:02:37.196 --> 00:02:38.636 A:middle
Now, a thing about passes:

00:02:38.666 --> 00:02:40.786 A:middle
since they represent
real-world information,

00:02:41.636 --> 00:02:43.386 A:middle
you expect them to
be up- to-date.

00:02:43.386 --> 00:02:45.436 A:middle
They should always
reflect the current state

00:02:45.856 --> 00:02:47.416 A:middle
of whatever they're
supposed to be used for.

00:02:47.526 --> 00:02:50.706 A:middle
And we could make you go through
that whole flow all over again,

00:02:50.706 --> 00:02:54.236 A:middle
direct your users back to
your app, send them an email,

00:02:54.296 --> 00:02:57.156 A:middle
back through your app, but
that would be a huge pain

00:02:57.156 --> 00:02:58.406 A:middle
and no one would do that.

00:02:58.696 --> 00:03:01.436 A:middle
So we have a better system,
and it's built on top

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:02:58.696 --> 00:03:01.436 A:middle
So we have a better system,
and it's built on top

00:03:01.436 --> 00:03:03.136 A:middle
of the Apple Push
Notification Service.

00:03:03.716 --> 00:03:06.576 A:middle
Your server sends us a
push, we make a request

00:03:06.576 --> 00:03:08.536 A:middle
to your web service,
and you send us

00:03:08.536 --> 00:03:11.216 A:middle
down a new version
of the pass file.

00:03:11.636 --> 00:03:13.666 A:middle
And that seamlessly
replaces the existing pass

00:03:13.666 --> 00:03:14.616 A:middle
in the user's pass library,

00:03:15.066 --> 00:03:19.106 A:middle
and to them the pass is
magically now up-to-date.

00:03:20.806 --> 00:03:23.736 A:middle
So the user has your
pass, it's up-to-date,

00:03:24.216 --> 00:03:25.076 A:middle
how do they then use it?

00:03:25.706 --> 00:03:28.756 A:middle
Well, they bring their
device to your location.

00:03:28.756 --> 00:03:32.396 A:middle
You scan it, the barcode
on it, with some kind

00:03:32.396 --> 00:03:33.396 A:middle
of point of sale system.

00:03:33.976 --> 00:03:35.166 A:middle
That then talks to your server,

00:03:35.166 --> 00:03:38.196 A:middle
which checks whether the pass
is valid, whether it can be used

00:03:38.196 --> 00:03:40.206 A:middle
for whatever transaction
they're trying to complete,

00:03:40.926 --> 00:03:44.016 A:middle
and finds out, okay, the
pass is available to use.

00:03:44.856 --> 00:03:46.246 A:middle
It sends that information
back down,

00:03:46.246 --> 00:03:48.866 A:middle
you complete the
transaction and that's that.

00:03:49.716 --> 00:03:53.506 A:middle
Now, if something changes
about the pass as a result

00:03:54.796 --> 00:03:57.406 A:middle
of this transaction, like
if you've used a coupon

00:03:57.406 --> 00:03:58.346 A:middle
that can no longer be used,

00:03:58.346 --> 00:04:01.266 A:middle
or if you have a store card
whose balance you're updating,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:03:58.346 --> 00:04:01.266 A:middle
or if you have a store card
whose balance you're updating,

00:04:02.286 --> 00:04:03.666 A:middle
your server might
take that opportunity

00:04:03.936 --> 00:04:06.306 A:middle
to then send an update
notification to the pass

00:04:06.446 --> 00:04:09.286 A:middle
and get it up-to-date.

00:04:09.426 --> 00:04:13.176 A:middle
So that's just a vague
high level overview.

00:04:13.676 --> 00:04:15.406 A:middle
Passes are information
that can be used

00:04:15.406 --> 00:04:16.216 A:middle
for something in the real world.

00:04:16.856 --> 00:04:17.726 A:middle
They come from your server.

00:04:18.555 --> 00:04:21.745 A:middle
They get into the user's
pass library via your apps

00:04:21.745 --> 00:04:22.746 A:middle
or via Mail or Safari.

00:04:23.376 --> 00:04:29.136 A:middle
And they are then used by
scanning the barcode on the pass

00:04:29.696 --> 00:04:32.526 A:middle
and checking its
validity with your server.

00:04:32.526 --> 00:04:37.246 A:middle
And finally they can be
updated via the push system

00:04:37.326 --> 00:04:40.936 A:middle
to make sure the pass has the
most up-to-date information.

00:04:41.716 --> 00:04:43.946 A:middle
So that's the ecosystem.

00:04:44.056 --> 00:04:47.216 A:middle
Let's talk about what's
new in Passbook in iOS 7.

00:04:48.236 --> 00:04:51.716 A:middle
First, we've added ways for
you to enrich the content

00:04:51.716 --> 00:04:53.366 A:middle
of your passes, to
make them more useful,

00:04:53.626 --> 00:04:55.516 A:middle
work better, look better.

00:04:56.446 --> 00:04:58.586 A:middle
We've added easier ways to
get passes into Passbook,

00:04:58.786 --> 00:05:01.626 A:middle
both via APIs and via
some really cool new

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:04:58.786 --> 00:05:01.626 A:middle
both via APIs and via
some really cool new

00:05:01.746 --> 00:05:02.866 A:middle
user-facing features.

00:05:03.766 --> 00:05:06.306 A:middle
We've given you more
control over the relevance

00:05:06.306 --> 00:05:09.006 A:middle
of your passes, over when they
show up on the lock screen

00:05:09.006 --> 00:05:10.126 A:middle
of your user's device.

00:05:10.956 --> 00:05:13.236 A:middle
And, finally, we've
added better support

00:05:13.236 --> 00:05:16.286 A:middle
around the whole
using-passes thing.

00:05:16.716 --> 00:05:19.566 A:middle
I'll be more clear
about that later on.

00:05:19.696 --> 00:05:21.706 A:middle
So let's talk about the first
of these, the pass content.

00:05:22.266 --> 00:05:26.446 A:middle
A pass is kind of
structured like an app bundle:

00:05:26.446 --> 00:05:30.056 A:middle
it's a folder that's zipped up,
and the contents look like this.

00:05:30.416 --> 00:05:34.666 A:middle
You have your pass.json which
defines what the pass is,

00:05:34.736 --> 00:05:36.066 A:middle
how it behaves, how it looks.

00:05:36.776 --> 00:05:38.696 A:middle
You have a couple of
localized string files,

00:05:38.836 --> 00:05:40.796 A:middle
the lproge [phonetic]
folders that you see here

00:05:41.126 --> 00:05:45.476 A:middle
which contain strings that get
substituted into your pass.json

00:05:45.816 --> 00:05:48.556 A:middle
for user-facing strings.

00:05:49.016 --> 00:05:52.566 A:middle
You have a couple of icons
and images that we use

00:05:52.566 --> 00:05:56.556 A:middle
to display the pass in Passbook
and elsewhere in the OS.

00:05:56.686 --> 00:06:01.316 A:middle
All of that is signed and
zipped, and there's your pass.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:56.686 --> 00:06:01.316 A:middle
All of that is signed and
zipped, and there's your pass.

00:06:01.836 --> 00:06:05.246 A:middle
So you may have noticed that
things look at little different

00:06:05.246 --> 00:06:07.656 A:middle
in iOS 7, and Passbook's
no exception to that.

00:06:08.106 --> 00:06:10.806 A:middle
Things have less gradients,
they have less shine,

00:06:11.146 --> 00:06:14.296 A:middle
subtler shadows,
that kind of thing.

00:06:14.516 --> 00:06:16.516 A:middle
And for the most part
that won't affect you.

00:06:16.516 --> 00:06:18.666 A:middle
We already will apply the
new look to your passes.

00:06:19.276 --> 00:06:21.376 A:middle
But if you've been
making a particular effort

00:06:21.996 --> 00:06:24.046 A:middle
to match the iOS6 style,

00:06:24.046 --> 00:06:25.376 A:middle
if you've been creating
your own gloss

00:06:25.686 --> 00:06:27.876 A:middle
or if you've been sizing
images to fit precisely

00:06:27.876 --> 00:06:29.916 A:middle
within the boundary of
the strip or anything,

00:06:30.356 --> 00:06:32.126 A:middle
then that's going
to look wrong now.

00:06:32.126 --> 00:06:33.666 A:middle
Your passes will look
slightly out of place.

00:06:33.666 --> 00:06:35.106 A:middle
It won't be the end
of the world,

00:06:35.106 --> 00:06:36.876 A:middle
but it will look slightly off.

00:06:37.886 --> 00:06:40.826 A:middle
So the rule of thumb for
that is, well, don't do that.

00:06:40.986 --> 00:06:44.646 A:middle
Follow our guidelines, supply
us the images in the style

00:06:44.646 --> 00:06:45.616 A:middle
and format that we expect,

00:06:45.996 --> 00:06:49.076 A:middle
and trust that we'll
do the right thing when

00:06:49.076 --> 00:06:53.136 A:middle
and if the appearance changes of
what we're applying to passes.

00:06:54.206 --> 00:06:56.556 A:middle
So there is one change to
the appearance that's going

00:06:56.556 --> 00:06:58.946 A:middle
to affect your images that you
will probably need to adapt for,

00:06:59.216 --> 00:07:01.456 A:middle
and that's that passes are now
the full width of the screen.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:06:59.216 --> 00:07:01.456 A:middle
and that's that passes are now
the full width of the screen.

00:07:01.456 --> 00:07:04.806 A:middle
They're 320 points, up from 312,

00:07:05.416 --> 00:07:07.216 A:middle
which means that your
strip images need

00:07:07.216 --> 00:07:08.246 A:middle
to change as well for that.

00:07:08.896 --> 00:07:11.086 A:middle
We'll currently take
your strip image

00:07:11.086 --> 00:07:12.246 A:middle
and scale it up a little bit.

00:07:13.086 --> 00:07:16.216 A:middle
But if you want it to be pixel
perfect, which of course you do,

00:07:16.536 --> 00:07:21.926 A:middle
then you want to change
those images for iOS 7.

00:07:22.736 --> 00:07:26.686 A:middle
And we also no longer expect
you to etch your logos.

00:07:26.686 --> 00:07:27.956 A:middle
You don't need to apply shadow.

00:07:27.956 --> 00:07:29.216 A:middle
Just give those a solid color,

00:07:29.386 --> 00:07:32.666 A:middle
and it will fit right
in, it will look great.

00:07:33.406 --> 00:07:38.036 A:middle
Finally, while iOS 7 Passbook
will only run on Retina devices

00:07:38.036 --> 00:07:41.386 A:middle
because those are the only
ones that support iOS 7 --

00:07:41.746 --> 00:07:45.136 A:middle
we aren't in iPad,
for instance --

00:07:45.136 --> 00:07:47.596 A:middle
you do still need to expect
that your passes are going

00:07:47.596 --> 00:07:48.876 A:middle
to show up on iOS 6 devices.

00:07:48.876 --> 00:07:52.216 A:middle
So you might have them
on the non-Retina screen

00:07:52.336 --> 00:07:53.896 A:middle
on the iPhone 3GS for instance.

00:07:53.986 --> 00:07:56.456 A:middle
So still provide
non-Retina images.

00:07:56.516 --> 00:07:58.916 A:middle
Even though a lot of your
users are going to be

00:07:58.916 --> 00:08:03.146 A:middle
on iOS 7 this fall, be
ready for your passes to end

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:58.916 --> 00:08:03.146 A:middle
on iOS 7 this fall, be
ready for your passes to end

00:08:03.146 --> 00:08:03.916 A:middle
up pretty much anywhere.

00:08:04.986 --> 00:08:06.856 A:middle
So let's talk about grouping,

00:08:07.476 --> 00:08:09.476 A:middle
which is a behavior we
haven't gone into a lot

00:08:09.476 --> 00:08:11.596 A:middle
of detail before, but
you've certainly noticed it

00:08:11.596 --> 00:08:13.226 A:middle
if you've been producing
multiple passes.

00:08:13.976 --> 00:08:16.426 A:middle
Passes group automatically.

00:08:17.146 --> 00:08:20.576 A:middle
Based on a couple of rules,
details not very important,

00:08:21.086 --> 00:08:24.706 A:middle
but sometimes the grouping
behavior is not exactly what

00:08:24.706 --> 00:08:25.256 A:middle
you expect.

00:08:25.446 --> 00:08:27.566 A:middle
If you have an itinerary,
for instance,

00:08:27.566 --> 00:08:28.736 A:middle
for a couple different people,

00:08:29.036 --> 00:08:32.385 A:middle
we might be grouping all those
passes together into one morass

00:08:33.086 --> 00:08:35.926 A:middle
which you might want to
have better control over.

00:08:36.706 --> 00:08:39.155 A:middle
So we now have this
grouping identifier key.

00:08:39.635 --> 00:08:40.426 A:middle
It's just a string.

00:08:40.926 --> 00:08:43.256 A:middle
You specify it and
any passes of yours

00:08:43.256 --> 00:08:45.266 A:middle
that have the same grouping
identifier will group together.

00:08:45.266 --> 00:08:47.516 A:middle
Any that have different
ones will group separately.

00:08:48.116 --> 00:08:51.456 A:middle
So you can use this on event
tickets and boarding passes,

00:08:52.176 --> 00:08:55.416 A:middle
which are the passes that are
most likely to be grouping

00:08:55.416 --> 00:08:57.466 A:middle
in these kind of
cases, and that's useful

00:08:57.466 --> 00:08:58.156 A:middle
if you're doing something

00:08:58.156 --> 00:09:00.676 A:middle
that involves an itinerary
or a multi-day event.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:08:58.156 --> 00:09:00.676 A:middle
that involves an itinerary
or a multi-day event.

00:09:01.936 --> 00:09:03.756 A:middle
So, if you need that, use it.

00:09:04.566 --> 00:09:06.326 A:middle
That's what it's there for.

00:09:06.826 --> 00:09:11.736 A:middle
[ Applause ]

00:09:12.236 --> 00:09:15.386 A:middle
So let's talk about something
different entirely: date fields.

00:09:16.236 --> 00:09:19.026 A:middle
This is a feature that
we added in iOS 6,

00:09:19.476 --> 00:09:23.186 A:middle
basically to make
users' experience

00:09:23.186 --> 00:09:24.856 A:middle
around localization better.

00:09:25.556 --> 00:09:28.206 A:middle
What we do is you give
us an absolute timestamp

00:09:28.496 --> 00:09:30.776 A:middle
and a date style -- short,
medium, long, et cetera --

00:09:31.576 --> 00:09:34.186 A:middle
and we format the
time in a format

00:09:34.186 --> 00:09:35.566 A:middle
that the user will
expect to see.

00:09:35.816 --> 00:09:42.366 A:middle
So if they have their locale set
to show three o'clock or 15.00

00:09:42.366 --> 00:09:44.466 A:middle
or anything like that,
we'll show your time

00:09:44.466 --> 00:09:45.916 A:middle
in the format they
expect it to be,

00:09:45.986 --> 00:09:48.256 A:middle
and it will look
right, it will fit in.

00:09:49.106 --> 00:09:50.636 A:middle
So something that comes

00:09:50.636 --> 00:09:53.576 A:middle
out of our using this
timestamp format is

00:09:53.576 --> 00:09:55.806 A:middle
that we get automatic
time zone adjustment.

00:09:55.806 --> 00:09:58.456 A:middle
So if you have something
like a pass that specifies

00:09:58.456 --> 00:10:02.226 A:middle
that it occurs in in
12 p.m. Pacific time,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:09:58.456 --> 00:10:02.226 A:middle
that it occurs in in
12 p.m. Pacific time,

00:10:02.626 --> 00:10:04.326 A:middle
then the user will
see that as --

00:10:04.576 --> 00:10:07.976 A:middle
I always get this stuff
wrong -- 3 p.m. Eastern.

00:10:09.156 --> 00:10:11.216 A:middle
So that's great.

00:10:11.216 --> 00:10:13.266 A:middle
It usually works in the way
that the users expect it to,

00:10:13.266 --> 00:10:15.206 A:middle
but sometimes you don't
want that behavior.

00:10:15.206 --> 00:10:17.716 A:middle
Sometimes you want to show a
time in the local time zone

00:10:17.716 --> 00:10:18.536 A:middle
that it's going to happen.

00:10:19.046 --> 00:10:21.276 A:middle
If you have a boarding
pass, for instance,

00:10:21.276 --> 00:10:22.456 A:middle
you want to show
the departure time

00:10:22.836 --> 00:10:24.916 A:middle
as when they get to the gate.

00:10:25.306 --> 00:10:27.436 A:middle
Or, if you have a hotel
check-in, for instance,

00:10:28.256 --> 00:10:31.526 A:middle
then again you want to show that
as the time that it is there.

00:10:31.526 --> 00:10:34.656 A:middle
Because people have trouble
converting between time zones,

00:10:34.656 --> 00:10:39.326 A:middle
like I just did, and you want
to help them out with that.

00:10:39.326 --> 00:10:42.876 A:middle
So what we now allow you to do
is to control how that works.

00:10:43.246 --> 00:10:46.026 A:middle
And the workaround that
some people have been using

00:10:46.026 --> 00:10:48.486 A:middle
for this is to just
use text fields

00:10:48.486 --> 00:10:50.146 A:middle
and say "3 PM" for instance.

00:10:50.356 --> 00:10:52.706 A:middle
And that works, your users
will probably get it,

00:10:52.706 --> 00:10:54.136 A:middle
but it's not the
best experience.

00:10:54.136 --> 00:10:56.586 A:middle
It could be better, and we
like making things better.

00:10:57.236 --> 00:11:02.226 A:middle
So we now allow you to disable
that time zone adjustment.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:57.236 --> 00:11:02.226 A:middle
So we now allow you to disable
that time zone adjustment.

00:11:02.726 --> 00:11:05.486 A:middle
It's just a key on date fields.

00:11:05.656 --> 00:11:07.896 A:middle
You say "ignore time
zone" and we drop that.

00:11:07.896 --> 00:11:10.426 A:middle
We show it always in the local
time zone that you specify.

00:11:11.006 --> 00:11:13.066 A:middle
The format hasn't changed:
you can't just leave it

00:11:13.066 --> 00:11:15.106 A:middle
out because we're still
validating against it.

00:11:15.786 --> 00:11:18.936 A:middle
But what you should probably do
here is specify the local time

00:11:18.936 --> 00:11:22.766 A:middle
zone that whatever time you're
trying to show is happening in.

00:11:23.936 --> 00:11:27.696 A:middle
So iOS 6 device users will
get the right experience,

00:11:28.066 --> 00:11:31.556 A:middle
more or less, and iOS 7
ones will get this nice new

00:11:31.986 --> 00:11:33.516 A:middle
ignoring-time-zone behavior.

00:11:34.616 --> 00:11:35.626 A:middle
So that's date fields.

00:11:36.626 --> 00:11:39.546 A:middle
Let's talk about the back of
your passes, about app links.

00:11:40.936 --> 00:11:43.656 A:middle
This is a feature that we
added for a couple of reasons.

00:11:43.816 --> 00:11:47.696 A:middle
It can help promote your apps,
and it provides easy access

00:11:47.696 --> 00:11:51.556 A:middle
to the apps if they have some
way of interacting with a pass

00:11:51.556 --> 00:11:52.586 A:middle
in the user's pass library.

00:11:53.646 --> 00:11:55.236 A:middle
So it looks like this.

00:11:55.576 --> 00:11:58.236 A:middle
You have this banner at the
top of the back of your pass,

00:11:58.536 --> 00:11:59.606 A:middle
kind of like the one in Safari.

00:11:59.606 --> 00:12:00.686 A:middle
It shows your app icon.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:11:59.606 --> 00:12:00.686 A:middle
It shows your app icon.

00:12:00.686 --> 00:12:03.206 A:middle
It shows a button that
will either take them

00:12:03.206 --> 00:12:05.546 A:middle
to an App Store page which
will let them install it

00:12:05.546 --> 00:12:06.276 A:middle
if they don't have it already.

00:12:06.846 --> 00:12:10.066 A:middle
And if they do have it then it
will let them open the app right

00:12:10.066 --> 00:12:10.896 A:middle
from the back of your pass.

00:12:11.636 --> 00:12:13.286 A:middle
So if you have a store
card, for instance,

00:12:13.596 --> 00:12:16.236 A:middle
this can let them
easily get into the app

00:12:16.426 --> 00:12:19.336 A:middle
and check their rewards
or anything like that.

00:12:20.306 --> 00:12:25.706 A:middle
So the question that arises with
these app links, particularly

00:12:25.706 --> 00:12:28.186 A:middle
when you have an app that
can provide multiple passes

00:12:28.586 --> 00:12:31.606 A:middle
like an event app, for
instance, is, well,

00:12:31.606 --> 00:12:33.276 A:middle
which pass did the
user just come from?

00:12:33.336 --> 00:12:34.796 A:middle
You know that they
got into your app,

00:12:35.316 --> 00:12:38.896 A:middle
but you have no idea what pass
they want to interact with.

00:12:39.626 --> 00:12:43.066 A:middle
You might have them go through
your list of passes you have

00:12:43.066 --> 00:12:46.446 A:middle
in your library and
say, you know,

00:12:46.716 --> 00:12:48.076 A:middle
which pass are you
talking about?

00:12:48.596 --> 00:12:49.976 A:middle
But that's not ideal.

00:12:49.976 --> 00:12:53.146 A:middle
It's an additional step, and
they already chose this pass

00:12:53.146 --> 00:12:54.676 A:middle
when they flipped it
over to get to your app.

00:12:55.406 --> 00:12:58.436 A:middle
So what we now allow you to
do is provide a context URL

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:13:00.026 --> 00:13:01.916 A:middle
which we launch your
app with as soon

00:13:01.916 --> 00:13:05.926 A:middle
as the user taps the open
button on the app link.

00:13:06.386 --> 00:13:08.276 A:middle
And so that's really useful

00:13:08.646 --> 00:13:12.046 A:middle
to immediately get
you the information

00:13:12.046 --> 00:13:15.186 A:middle
as to what pass they
just came from.

00:13:15.406 --> 00:13:17.766 A:middle
You might even embed additional
information in the URL itself.

00:13:18.426 --> 00:13:21.686 A:middle
But thanks to this next feature
you don't actually even have

00:13:21.716 --> 00:13:22.996 A:middle
to do that.

00:13:23.136 --> 00:13:26.316 A:middle
Because what we now
have is pass metadata.

00:13:27.316 --> 00:13:30.236 A:middle
You can embed a dictionary
of arbitrary information

00:13:30.416 --> 00:13:33.216 A:middle
in your pass, and your
app can read it off

00:13:34.316 --> 00:13:37.436 A:middle
with a user info property
on a PKPass object.

00:13:38.136 --> 00:13:42.526 A:middle
So what this means is that you
can get semantic information

00:13:42.526 --> 00:13:44.596 A:middle
about the pass without having

00:13:44.596 --> 00:13:46.426 A:middle
to make a round trip
to your web server.

00:13:46.426 --> 00:13:49.836 A:middle
You don't have to check the
serial number with your server

00:13:49.836 --> 00:13:51.036 A:middle
and pull down additional
information,

00:13:51.036 --> 00:13:52.726 A:middle
wait for the network
latency and all that.

00:13:52.786 --> 00:13:54.226 A:middle
It's just right there.

00:13:54.496 --> 00:13:57.896 A:middle
So your app can quickly
and easily show information

00:13:57.896 --> 00:13:58.886 A:middle
about the pass to the user.

00:13:58.886 --> 00:14:00.976 A:middle
It can even do it in conditions

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:13:58.886 --> 00:14:00.976 A:middle
It can even do it in conditions

00:14:00.976 --> 00:14:03.066 A:middle
where there's no network access
-- on an iPod, for instance.

00:14:03.636 --> 00:14:06.966 A:middle
So that should be really
useful if you've got an app

00:14:06.966 --> 00:14:08.726 A:middle
that integrates with
your passes.

00:14:10.086 --> 00:14:13.396 A:middle
And one thing about this is that
while you can probably trust

00:14:13.396 --> 00:14:14.766 A:middle
that this information
did come from you,

00:14:14.766 --> 00:14:16.036 A:middle
because you signed the pass,

00:14:16.336 --> 00:14:18.166 A:middle
it might not necessarily
be up-to-date.

00:14:18.166 --> 00:14:20.296 A:middle
So if you have anything
valuable or sensitive,

00:14:20.696 --> 00:14:22.306 A:middle
like a store card
balance, for instance,

00:14:22.306 --> 00:14:24.156 A:middle
you should still check
it with your server

00:14:24.396 --> 00:14:25.246 A:middle
if you have the opportunity.

00:14:26.516 --> 00:14:27.766 A:middle
So that's app links.

00:14:28.686 --> 00:14:31.476 A:middle
Let's talk about text
links, and the text

00:14:31.826 --> 00:14:32.766 A:middle
on the back of your passes.

00:14:33.336 --> 00:14:37.016 A:middle
The idea for these is that
you can provide additional

00:14:37.016 --> 00:14:38.666 A:middle
information related
to your passes.

00:14:38.816 --> 00:14:41.586 A:middle
So you can provide
contact information

00:14:41.586 --> 00:14:43.526 A:middle
or the location of an event.

00:14:43.526 --> 00:14:45.426 A:middle
And to make that more
useful for your users,

00:14:46.076 --> 00:14:49.766 A:middle
we run data detectors on
them: we turn things that look

00:14:49.766 --> 00:14:51.286 A:middle
like useful information
into links.

00:14:51.286 --> 00:14:54.206 A:middle
So an address opens maps,
a phone number allows them

00:14:54.206 --> 00:14:56.316 A:middle
to call it, that kind of thing.

00:14:56.866 --> 00:14:58.226 A:middle
But sometimes that
doesn't behave right.

00:14:58.226 --> 00:15:01.396 A:middle
You can see here I have a
confirmation number that's being

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:14:58.226 --> 00:15:01.396 A:middle
You can see here I have a
confirmation number that's being

00:15:01.396 --> 00:15:03.876 A:middle
confused as a phone number,
and an address that --

00:15:04.256 --> 00:15:05.976 A:middle
I don't know whether
this exists --

00:15:05.976 --> 00:15:08.906 A:middle
but it's not a real place

00:15:09.236 --> 00:15:11.216 A:middle
which we shouldn't be
giving directions to.

00:15:12.156 --> 00:15:14.716 A:middle
So what we now allow you
to do is control this

00:15:14.806 --> 00:15:17.036 A:middle
and set what kind
of data we detect.

00:15:17.586 --> 00:15:20.146 A:middle
So your confirmation
number stays clean of links.

00:15:20.176 --> 00:15:22.536 A:middle
Your things that you don't
want to be directions

00:15:22.536 --> 00:15:25.116 A:middle
to they don't turn
into directions links.

00:15:25.446 --> 00:15:27.376 A:middle
And that's going to
be really helpful.

00:15:27.376 --> 00:15:29.906 A:middle
And your users probably
weren't bothered by this,

00:15:29.906 --> 00:15:31.676 A:middle
but it was a little confusing.

00:15:32.036 --> 00:15:35.366 A:middle
And this makes your
passes look better.

00:15:36.146 --> 00:15:40.026 A:middle
So the way this works
is an array

00:15:40.026 --> 00:15:44.456 A:middle
of strings containing the
list of data detector types

00:15:44.456 --> 00:15:45.286 A:middle
that you want us to run.

00:15:45.286 --> 00:15:48.656 A:middle
So that can be phone
numbers, addresses,

00:15:48.656 --> 00:15:49.916 A:middle
emails, anything like that.

00:15:50.256 --> 00:15:52.266 A:middle
You just provide the list of
what you want us to detect,

00:15:52.266 --> 00:15:55.356 A:middle
and anything you leave
out we won't look for.

00:15:55.596 --> 00:15:57.866 A:middle
So the default, of
course, is "all".

00:15:57.866 --> 00:16:00.806 A:middle
If you don't provide this key,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:15:57.866 --> 00:16:00.806 A:middle
If you don't provide this key,

00:16:00.806 --> 00:16:02.596 A:middle
then we just do our
existing behavior.

00:16:03.066 --> 00:16:06.696 A:middle
But if you're seeing any issues
with data detectors turning

00:16:06.696 --> 00:16:08.666 A:middle
up when you don't want
them to, use this.

00:16:09.096 --> 00:16:09.746 A:middle
It will help.

00:16:09.746 --> 00:16:13.166 A:middle
I mentioned URLs,
and this is something

00:16:13.166 --> 00:16:15.046 A:middle
that we've heard a lot
about from you guys.

00:16:15.746 --> 00:16:18.136 A:middle
Specifically, that
when you embed URLs

00:16:18.136 --> 00:16:20.106 A:middle
on your passes, they look bad.

00:16:20.556 --> 00:16:22.316 A:middle
They're long, they're
ugly, they're opaque.

00:16:22.616 --> 00:16:25.906 A:middle
You can have a long URL
with your company's website,

00:16:26.136 --> 00:16:27.816 A:middle
or you can have a
URL-shortened one

00:16:28.126 --> 00:16:30.326 A:middle
which is not your company's
website but is even more opaque.

00:16:30.526 --> 00:16:33.436 A:middle
So that's not the ideal user
experience, and you have

00:16:33.476 --> 00:16:35.776 A:middle
to include lots of explanatory
text saying "if you want to talk

00:16:35.776 --> 00:16:38.916 A:middle
to our nice support people, tap
this link below," et cetera.

00:16:39.516 --> 00:16:44.706 A:middle
So what we've added to
fix this is embedded URLs.

00:16:45.206 --> 00:16:47.996 A:middle
[ Applause ]

00:16:48.496 --> 00:16:49.496 A:middle
So it works like this.

00:16:50.166 --> 00:16:53.196 A:middle
There's a new key on your field
that's called attributed value

00:16:54.096 --> 00:16:55.946 A:middle
which is in addition to
the existing value key.

00:16:56.196 --> 00:16:58.936 A:middle
So you can see here
I've included this

00:16:58.936 --> 00:17:01.146 A:middle
with more information,
explanatory text,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:16:58.936 --> 00:17:01.146 A:middle
with more information,
explanatory text,

00:17:01.276 --> 00:17:04.576 A:middle
and I've also included
a much shorter --

00:17:04.576 --> 00:17:05.836 A:middle
at least to the user's eye --

00:17:06.266 --> 00:17:08.705 A:middle
version of this which does the
same thing and looks way better.

00:17:10.165 --> 00:17:13.986 A:middle
So it's a standard
HTML-style link tag.

00:17:14.205 --> 00:17:17.586 A:middle
You've probably seen it
before, but it's not full HTML.

00:17:17.586 --> 00:17:19.346 A:middle
If you want to make your
text bounce around the screen

00:17:19.346 --> 00:17:23.766 A:middle
or do marquees or sparkle, no,
no, we don't let you do that.

00:17:23.766 --> 00:17:25.556 A:middle
And it's only on back
fields, of course,

00:17:25.556 --> 00:17:27.986 A:middle
because as before we
only allow links there.

00:17:29.156 --> 00:17:32.116 A:middle
But that should be a great way

00:17:32.116 --> 00:17:34.796 A:middle
to make your passes look way
better and to simplify things.

00:17:34.796 --> 00:17:36.946 A:middle
And basically it means your
users have a way better

00:17:36.946 --> 00:17:39.536 A:middle
experience with your passes.

00:17:39.536 --> 00:17:40.306 A:middle
One note about this.

00:17:40.786 --> 00:17:43.586 A:middle
iOS 6 devices have no idea what
an attributed value key is.

00:17:44.226 --> 00:17:45.996 A:middle
You still need to
include the value

00:17:46.206 --> 00:17:49.836 A:middle
for backwards compatibility,
so: do that.

00:17:49.836 --> 00:17:52.456 A:middle
Let's review all this.

00:17:53.506 --> 00:17:56.546 A:middle
First, we have the new look.

00:17:56.976 --> 00:18:00.836 A:middle
If you've been matching the old
style by making your own gloss

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:17:56.976 --> 00:18:00.836 A:middle
If you've been matching the old
style by making your own gloss

00:18:00.836 --> 00:18:03.676 A:middle
or shadows or fitting
things to the dimensions

00:18:03.676 --> 00:18:05.286 A:middle
that you thought were
going to be forever...

00:18:05.906 --> 00:18:06.406 A:middle
don't do that.

00:18:06.616 --> 00:18:07.806 A:middle
Just follow our guidelines,

00:18:08.456 --> 00:18:10.626 A:middle
and we'll do the right
thing with your graphics.

00:18:12.176 --> 00:18:14.056 A:middle
We now allow you
to do date fields

00:18:14.056 --> 00:18:15.236 A:middle
without time zone adjustment.

00:18:16.986 --> 00:18:23.626 A:middle
We've added app links for
context URLs along with metadata

00:18:24.526 --> 00:18:26.346 A:middle
which allows you to pull
information off your pass

00:18:26.576 --> 00:18:28.266 A:middle
without having to make a
round trip to your server,

00:18:28.266 --> 00:18:29.866 A:middle
consume resources, et cetera.

00:18:30.656 --> 00:18:33.026 A:middle
And, finally, we've given
you better links on the back

00:18:33.026 --> 00:18:35.316 A:middle
of your passes via more
control over data detectors

00:18:35.746 --> 00:18:38.366 A:middle
and via the new embedded URLs.

00:18:40.016 --> 00:18:42.076 A:middle
So that's what's
new in pass content.

00:18:42.076 --> 00:18:45.716 A:middle
Let's talk about how you
get passes into Passbook.

00:18:45.716 --> 00:18:46.996 A:middle
We've made a lot
of changes here.

00:18:47.956 --> 00:18:50.926 A:middle
The first one -- well,
first, an overview.

00:18:52.346 --> 00:18:54.096 A:middle
Passes, as I said,
come from your server.

00:18:54.226 --> 00:18:56.946 A:middle
They go through Mail or
Safari, which can handle things

00:18:56.946 --> 00:18:59.996 A:middle
on their own, or in your apps
you have a couple of APIs,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:19:00.156 --> 00:19:03.176 A:middle
the PKAddPassesViewController
which allows you

00:19:03.176 --> 00:19:07.026 A:middle
to present a pass to be added
to a user's pass library,

00:19:07.526 --> 00:19:10.466 A:middle
and a couple of PKPassLibrary
methods that allow you to update

00:19:10.466 --> 00:19:12.136 A:middle
and remove passes
from the library.

00:19:12.136 --> 00:19:15.706 A:middle
And the thing about this is:
if you have a bunch of passes

00:19:15.706 --> 00:19:18.546 A:middle
to get to the user you have
to add them one at a time,

00:19:18.716 --> 00:19:20.666 A:middle
one after another, present
an add-pass view controller,

00:19:20.666 --> 00:19:23.146 A:middle
present another one, et cetera,
and your users are either going

00:19:23.146 --> 00:19:25.676 A:middle
to get fed up going through
those or they're not going

00:19:25.676 --> 00:19:28.596 A:middle
to get fed up but they're
going to send you nasty emails.

00:19:29.096 --> 00:19:30.576 A:middle
And we want to save
you from that.

00:19:30.576 --> 00:19:34.886 A:middle
So what we've added is a new way

00:19:34.946 --> 00:19:37.136 A:middle
to get multiple passes
into Passbook.

00:19:37.546 --> 00:19:39.126 A:middle
And to demo that
I'd like to bring

00:19:39.126 --> 00:19:40.246 A:middle
up Nick Circosta [phonetic].

00:19:40.246 --> 00:19:41.096 A:middle
[ Applause ]

00:19:41.096 --> 00:19:48.536 A:middle
>> Thanks, Noah.

00:19:49.026 --> 00:19:51.636 A:middle
So as Noah said we've got some
great new features to PassKit

00:19:51.776 --> 00:19:55.816 A:middle
in iOS 7 to allow you to
get passes easier than ever.

00:19:56.006 --> 00:19:58.286 A:middle
So what we have here is a
relatively simple application,

00:19:58.286 --> 00:19:59.526 A:middle
a collection-view-based
application

00:19:59.526 --> 00:20:06.456 A:middle
and let's just go ahead and
run it and see how it looks.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:19:59.526 --> 00:20:06.456 A:middle
and let's just go ahead and
run it and see how it looks.

00:20:06.456 --> 00:20:06.646 A:middle
[ Pause ]

00:20:06.646 --> 00:20:09.046 A:middle
Yay, we're all going
to a film festival.

00:20:09.046 --> 00:20:11.716 A:middle
So if we were, say, running
this application on iOS 6,

00:20:12.256 --> 00:20:14.506 A:middle
and a user wanted to add a
movie ticket for each one

00:20:14.506 --> 00:20:17.126 A:middle
of these films, they would most
likely tap each on in turn,

00:20:17.126 --> 00:20:20.166 A:middle
and then you'd present an
add-passes view controller

00:20:20.166 --> 00:20:22.376 A:middle
for each one and
ingest it into Passbook.

00:20:22.376 --> 00:20:24.786 A:middle
But we're going to do something
a little bit cooler now

00:20:24.876 --> 00:20:25.576 A:middle
in iOS 7.

00:20:26.576 --> 00:20:28.346 A:middle
So what we have here is
a method that's called

00:20:28.346 --> 00:20:29.316 A:middle
when we tap the add button.

00:20:30.216 --> 00:20:32.566 A:middle
And as with anything, when we're
working with the pass library,

00:20:32.566 --> 00:20:33.686 A:middle
the first thing we want
to do is, of course,

00:20:33.686 --> 00:20:35.326 A:middle
get a reference to
the pass library.

00:20:35.476 --> 00:20:37.436 A:middle
Same as always, we
do a PKPassLibrary

00:20:37.516 --> 00:20:38.006 A:middle
alloc-init [phonetic].

00:20:39.256 --> 00:20:41.766 A:middle
Now, next we're going to call
this new method we've added,

00:20:41.766 --> 00:20:43.646 A:middle
called -addPasses:with
CompletionHandler:.

00:20:44.386 --> 00:20:46.866 A:middle
Now, in this particular
instance, we're passing

00:20:46.866 --> 00:20:48.286 A:middle
in this array of selected films

00:20:48.556 --> 00:20:50.886 A:middle
which contains all the films
the user has selected in the UI.

00:20:51.956 --> 00:20:54.646 A:middle
And it's going to return it
to the completion handler one

00:20:54.646 --> 00:20:56.916 A:middle
of two PKPassLibrary
add statuses.

00:20:57.776 --> 00:20:59.386 A:middle
So let's take a look
at the first one.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:21:00.376 --> 00:21:02.356 A:middle
As with all these notifications,
you should always make sure

00:21:02.356 --> 00:21:04.916 A:middle
that you're performing any
operations on the main thread.

00:21:06.146 --> 00:21:08.536 A:middle
So the first status
you might receive is a

00:21:08.536 --> 00:21:10.166 A:middle
PKPassLibraryShouldReviewPasses.

00:21:10.636 --> 00:21:12.846 A:middle
Now this means that the
user has tapped "review".

00:21:13.246 --> 00:21:16.676 A:middle
Now, you're going to initialize
a PK add passes view controller

00:21:16.736 --> 00:21:19.706 A:middle
when this occurs, and what you
might notice is that instead

00:21:19.706 --> 00:21:21.806 A:middle
of just passing in one
pass like in iOS 6,

00:21:21.916 --> 00:21:23.926 A:middle
we can now pass it
an array of passes,

00:21:24.306 --> 00:21:25.996 A:middle
which in this case is
our selected films array.

00:21:25.996 --> 00:21:29.146 A:middle
You're going to obviously
want to set the delegates

00:21:29.146 --> 00:21:31.756 A:middle
so you can get the notification
callback when the user is going

00:21:31.756 --> 00:21:34.086 A:middle
to just dismiss it, and
then we're just going

00:21:34.086 --> 00:21:35.626 A:middle
to present it to our user.

00:21:36.636 --> 00:21:40.726 A:middle
Now, the second status is the
PKPassLibraryDidAddPasses.

00:21:41.416 --> 00:21:43.306 A:middle
Now this means that the
user tapped "add all"

00:21:43.726 --> 00:21:45.436 A:middle
and chose not to
review the passes.

00:21:46.346 --> 00:21:50.596 A:middle
Now, we're also going to
update our movie posters UI,

00:21:50.596 --> 00:21:52.616 A:middle
and I'll touch on that
method in a moment.

00:21:52.936 --> 00:21:55.846 A:middle
I do want to add, just as a
piece of information to you,

00:21:55.846 --> 00:21:57.936 A:middle
that in a future seed --
this is not in seed 1 --

00:21:57.936 --> 00:22:00.436 A:middle
we will be adding a
third status to determine

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:21:57.936 --> 00:22:00.436 A:middle
we will be adding a
third status to determine

00:22:00.436 --> 00:22:02.866 A:middle
if the user cancelled
adding those passes.

00:22:02.896 --> 00:22:07.666 A:middle
So as we continue down
the code we also have the

00:22:07.666 --> 00:22:10.176 A:middle
"add-passes view controller
did finish" delegate method.

00:22:10.656 --> 00:22:12.516 A:middle
And in this particular
instance we're also going

00:22:12.516 --> 00:22:14.976 A:middle
to update our movie
posters when that occurs.

00:22:15.436 --> 00:22:18.806 A:middle
Now, I've got a movie posters,
relatively simple method here,

00:22:19.146 --> 00:22:21.836 A:middle
we're going to use the
pass library -containsPass:

00:22:21.836 --> 00:22:24.436 A:middle
method to check to see if those
passes were actually added

00:22:24.756 --> 00:22:25.426 A:middle
to Passbook.

00:22:26.106 --> 00:22:28.226 A:middle
And when that occurs we're just
going to set a simple property

00:22:28.226 --> 00:22:30.336 A:middle
in our model and then
read our collection view

00:22:30.596 --> 00:22:33.386 A:middle
and fit a nice fade
on the passes we have.

00:22:34.266 --> 00:22:36.086 A:middle
Let's go ahead and run that.

00:22:36.586 --> 00:22:39.016 A:middle
[ Pause ]

00:22:39.516 --> 00:22:42.566 A:middle
Cool. Now I really want
to see Epic, Iron Man,

00:22:42.566 --> 00:22:44.086 A:middle
and the new Star Trek movie.

00:22:44.296 --> 00:22:44.896 A:middle
Let's tap add.

00:22:44.896 --> 00:22:47.116 A:middle
Now, as we said, the user
is going to be presented

00:22:47.116 --> 00:22:48.246 A:middle
with this alert,
and they can choose

00:22:48.246 --> 00:22:49.396 A:middle
to either review or add all.

00:22:49.786 --> 00:22:51.656 A:middle
Add all just means
add it to Passbook.

00:22:52.166 --> 00:22:54.656 A:middle
Review will mean "let
me see those passes",

00:22:54.726 --> 00:22:56.936 A:middle
so we're going to tap "review".

00:22:57.026 --> 00:22:59.366 A:middle
And there we have our
three movie passes.

00:22:59.626 --> 00:23:02.056 A:middle
And when we do that we're
just going to tap "add all",

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:22:59.626 --> 00:23:02.056 A:middle
And when we do that we're
just going to tap "add all",

00:23:02.056 --> 00:23:06.636 A:middle
they look pretty good to me,
and nicely animate those out.

00:23:06.636 --> 00:23:06.936 A:middle
Wonderful.

00:23:06.936 --> 00:23:13.986 A:middle
[Applause] And with
that back to Noah.

00:23:13.986 --> 00:23:14.053 A:middle
[ Pause ]

00:23:14.053 --> 00:23:14.356 A:middle
>> Thanks, Nick.

00:23:15.056 --> 00:23:16.146 A:middle
So that's pretty cool.

00:23:16.196 --> 00:23:20.306 A:middle
Let's talk about a bit
of the details behind it.

00:23:20.646 --> 00:23:23.716 A:middle
It's a method on
PKPassLibrary as Nick said:

00:23:24.186 --> 00:23:25.786 A:middle
-addPasses:with
CompletionHandler:.

00:23:26.496 --> 00:23:29.606 A:middle
And you can call this and it
will just present that alert

00:23:29.606 --> 00:23:32.406 A:middle
where the user can
then easily just tap

00:23:32.406 --> 00:23:34.106 A:middle
"add all" or, as
you saw, "review".

00:23:34.686 --> 00:23:37.366 A:middle
If it's "add all" then
your passes just go

00:23:37.366 --> 00:23:38.076 A:middle
into their pass library.

00:23:38.076 --> 00:23:40.576 A:middle
There's nothing more
that you have to do.

00:23:40.576 --> 00:23:42.876 A:middle
If they tap "review",
though, you're responsible

00:23:42.876 --> 00:23:45.456 A:middle
for then presenting a
PKAddPassesViewController,

00:23:45.936 --> 00:23:47.986 A:middle
which has this new
initializer, -initWithPasses:.

00:23:48.646 --> 00:23:53.116 A:middle
So that will allow
them to then choose

00:23:53.116 --> 00:23:54.696 A:middle
to add all the passes
or cancel out.

00:23:55.456 --> 00:23:57.486 A:middle
And as you might
gather from that,

00:23:58.006 --> 00:23:59.506 A:middle
both these APIs are
all or nothing.

00:23:59.506 --> 00:24:02.676 A:middle
If the user doesn't want to have
one of the passes then they have

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:23:59.506 --> 00:24:02.676 A:middle
If the user doesn't want to have
one of the passes then they have

00:24:02.676 --> 00:24:05.156 A:middle
to cancel the whole thing or
go back and delete it later,

00:24:05.156 --> 00:24:07.686 A:middle
which would be kind of a pain.

00:24:07.686 --> 00:24:09.826 A:middle
So what you should do, as
you just saw in this demo,

00:24:10.196 --> 00:24:13.966 A:middle
is provide your own UI for
choosing which passes they want.

00:24:13.966 --> 00:24:16.186 A:middle
If you have any situation where
the user is going to choose

00:24:16.186 --> 00:24:19.326 A:middle
from multiple passes, do that
first, then present this,

00:24:19.326 --> 00:24:21.116 A:middle
and you'll be good to go.

00:24:22.116 --> 00:24:25.076 A:middle
So that's the new API we
have around adding passes.

00:24:25.886 --> 00:24:27.466 A:middle
Let's talk about sharing.

00:24:29.206 --> 00:24:31.766 A:middle
You may have noticed, if
you've used Passbook in iOS 7,

00:24:32.416 --> 00:24:36.126 A:middle
that each pass now has a
share button in the corner.

00:24:36.766 --> 00:24:38.416 A:middle
And when you tap that
it brings up this sheet

00:24:39.536 --> 00:24:42.976 A:middle
which allows your users
to send passes via mail

00:24:43.326 --> 00:24:44.896 A:middle
or AirDrop or iMessage.

00:24:45.696 --> 00:24:48.436 A:middle
And this is really good
for some use cases,

00:24:48.436 --> 00:24:51.096 A:middle
and you may be possibly
worried about it for others,

00:24:51.096 --> 00:24:52.916 A:middle
but I'll talk about
that in a second.

00:24:53.816 --> 00:24:55.996 A:middle
What this means is that if you
have a pass that you want to be

00:24:55.996 --> 00:24:58.566 A:middle
in a bunch of peoples' hands,
that is now super easy.

00:24:59.166 --> 00:25:02.076 A:middle
They just say, you know, "hey,
friends, I went to Store,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:24:59.166 --> 00:25:02.076 A:middle
They just say, you know, "hey,
friends, I went to Store,

00:25:02.076 --> 00:25:04.146 A:middle
I got Thing, Thing is cool,
you should go to Store

00:25:04.146 --> 00:25:05.606 A:middle
and get Thing: take this pass".

00:25:06.516 --> 00:25:07.226 A:middle
It's great.

00:25:08.186 --> 00:25:09.396 A:middle
If you have a situation

00:25:09.396 --> 00:25:13.156 A:middle
where you've given one user
multiple passes that belong

00:25:13.156 --> 00:25:15.846 A:middle
to multiple people,
then they can then hand

00:25:15.846 --> 00:25:18.926 A:middle
out this movie ticket to
their friends they just bought

00:25:19.136 --> 00:25:21.286 A:middle
for this
everyone-going-to-see-a-movie

00:25:21.286 --> 00:25:24.476 A:middle
kind of scenario.

00:25:25.256 --> 00:25:28.156 A:middle
And, as I said, you might
now be worried about this

00:25:28.156 --> 00:25:31.186 A:middle
because your passes might now be
in multiple places and, "oh no,

00:25:31.186 --> 00:25:32.136 A:middle
where's my security model?"

00:25:32.776 --> 00:25:34.436 A:middle
That was already
very much possible.

00:25:34.576 --> 00:25:37.326 A:middle
Your users could
forward emails around,

00:25:37.326 --> 00:25:38.576 A:middle
they could share screen shots.

00:25:38.856 --> 00:25:40.746 A:middle
You might even have more
legitimate use cases

00:25:40.746 --> 00:25:43.636 A:middle
like restoring from an
iCloud backup or syncing

00:25:43.636 --> 00:25:45.076 A:middle
from one device to another.

00:25:45.596 --> 00:25:47.386 A:middle
So it's just now way more easy,

00:25:47.696 --> 00:25:48.816 A:middle
and we've made the
user experience

00:25:48.816 --> 00:25:51.926 A:middle
around it better,
as we sometimes do.

00:25:52.216 --> 00:25:55.246 A:middle
So the key thing to take away
from that is that if it matters

00:25:55.246 --> 00:25:58.066 A:middle
to you that your pass is on
multiple devices, validate them.

00:25:58.096 --> 00:26:01.746 A:middle
Check the barcode:
that's what it's for.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:25:58.096 --> 00:26:01.746 A:middle
Check the barcode:
that's what it's for.

00:26:01.806 --> 00:26:03.106 A:middle
So that's sharing.

00:26:03.106 --> 00:26:05.386 A:middle
Let's talk about something
that you may recognize

00:26:05.386 --> 00:26:07.736 A:middle
from last year, the
Add to Passbook badge.

00:26:08.496 --> 00:26:09.966 A:middle
This has proved to
be really useful.

00:26:10.086 --> 00:26:12.026 A:middle
Users look for it,
they recognize it,

00:26:12.026 --> 00:26:14.486 A:middle
they know that it means "I can
tap this, I can get a pass,

00:26:14.486 --> 00:26:15.926 A:middle
it will be easy, it
will be awesome".

00:26:17.536 --> 00:26:21.696 A:middle
And it's great for
using in content,

00:26:21.696 --> 00:26:22.956 A:middle
in websites and email...

00:26:22.956 --> 00:26:24.256 A:middle
in body content.

00:26:24.256 --> 00:26:26.766 A:middle
But we've seen a couple of cases
of people thinking they have

00:26:26.836 --> 00:26:28.576 A:middle
to use it and wedging it
into their UI somewhere

00:26:28.576 --> 00:26:31.196 A:middle
where it doesn't fit --
sticking it in a navigation bar

00:26:31.336 --> 00:26:32.346 A:middle
or in an action sheet.

00:26:32.666 --> 00:26:34.306 A:middle
And you don't have to do that.

00:26:34.306 --> 00:26:36.046 A:middle
Just design for your app.

00:26:36.906 --> 00:26:41.156 A:middle
If you have some custom look
that this badge will not fit in,

00:26:41.376 --> 00:26:42.566 A:middle
don't use it: use
your own thing.

00:26:43.026 --> 00:26:44.386 A:middle
It will be all right.

00:26:44.976 --> 00:26:47.796 A:middle
So this badge ties
into a new feature

00:26:47.796 --> 00:26:49.396 A:middle
that we're really
excited about that some

00:26:49.396 --> 00:26:52.296 A:middle
of you may have seen
already, called code scanning.

00:26:53.066 --> 00:26:57.316 A:middle
And the idea here is it's a
really, really low-friction way

00:26:57.316 --> 00:26:58.776 A:middle
to get a pass into
your user's hands.

00:26:58.776 --> 00:27:01.246 A:middle
You don't have to send them
to a website, you don't have

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:26:58.776 --> 00:27:01.246 A:middle
You don't have to send them
to a website, you don't have

00:27:01.246 --> 00:27:02.926 A:middle
to get their email address,
you don't have to get them

00:27:02.926 --> 00:27:05.116 A:middle
to install an app:
it's just there.

00:27:05.116 --> 00:27:10.076 A:middle
And the idea is you put a URL
to a pass into a 2D barcode,

00:27:10.796 --> 00:27:13.336 A:middle
and from Passbook they
can scan that code

00:27:13.336 --> 00:27:17.306 A:middle
and turn it into a pass.

00:27:17.996 --> 00:27:22.536 A:middle
So we've had a bunch of ideas
about how you can use this.

00:27:22.536 --> 00:27:23.716 A:middle
I'm sure you'll come
up with many more.

00:27:24.326 --> 00:27:25.646 A:middle
But let's talk about
these a bit.

00:27:26.196 --> 00:27:29.076 A:middle
You've probably seen codes being
used in marketing materials

00:27:29.076 --> 00:27:30.036 A:middle
that say, hey, go
to our website,

00:27:30.036 --> 00:27:31.756 A:middle
scan this code instead
of typing it in.

00:27:32.316 --> 00:27:35.376 A:middle
But that's not the only option.

00:27:35.766 --> 00:27:37.386 A:middle
Your codes can be anywhere.

00:27:37.896 --> 00:27:40.836 A:middle
If you're printing something
individual like a receipt,

00:27:41.046 --> 00:27:42.696 A:middle
or a paper ticket
for some reason,

00:27:43.166 --> 00:27:45.616 A:middle
then you can put a code
that's unique to that user

00:27:45.796 --> 00:27:47.876 A:middle
on that receipt saying,
hey, here's a coupon

00:27:47.876 --> 00:27:50.946 A:middle
for Thing related to
Thing-You-Just-Bought.

00:27:50.946 --> 00:27:54.286 A:middle
Or, on an event ticket, you can
give someone a Passbook version

00:27:54.596 --> 00:27:57.736 A:middle
of their paper pass or
paper ticket rather.

00:27:58.396 --> 00:28:03.426 A:middle
But even if you are printing a
single code that's going to end

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:27:58.396 --> 00:28:03.426 A:middle
But even if you are printing a
single code that's going to end

00:28:03.426 --> 00:28:05.876 A:middle
up in a lot of places, in a
magazine ad or on a banner

00:28:05.876 --> 00:28:07.696 A:middle
or anything like
that, they don't have

00:28:07.696 --> 00:28:09.216 A:middle
to point to a single pass.

00:28:09.806 --> 00:28:12.136 A:middle
You can just point that
URL at a web service

00:28:12.136 --> 00:28:13.516 A:middle
that can send down
a unique pass.

00:28:13.516 --> 00:28:16.406 A:middle
So you might be able
to get some information

00:28:16.406 --> 00:28:17.906 A:middle
on how many people
are using your passes.

00:28:18.136 --> 00:28:21.236 A:middle
Or, you could do something
like the first N people

00:28:21.236 --> 00:28:23.766 A:middle
who scan this code get
this really awesome pass,

00:28:23.766 --> 00:28:25.266 A:middle
that kind of thing.

00:28:25.536 --> 00:28:26.756 A:middle
So there's a bunch of
possibilities here.

00:28:26.756 --> 00:28:30.536 A:middle
And to show you one of the
ones that we've thought about

00:28:30.536 --> 00:28:35.146 A:middle
and implemented, I'm going
to bring up, again, Nick.

00:28:35.646 --> 00:28:40.666 A:middle
[ Applause ]

00:28:41.166 --> 00:28:41.646 A:middle
>> Thanks, Noah.

00:28:41.996 --> 00:28:44.746 A:middle
We're really excited about pass
scanning in iOS 7 so I'm going

00:28:44.746 --> 00:28:45.856 A:middle
to give you a quick demo here.

00:28:46.086 --> 00:28:48.846 A:middle
What we have here
is a simple web form

00:28:48.896 --> 00:28:51.436 A:middle
for a survey running
outside our movie theaters

00:28:51.556 --> 00:28:53.706 A:middle
on a nice little kiosk.

00:28:53.826 --> 00:28:56.596 A:middle
Nothing really advanced, just
some simple drop down fields,

00:28:57.046 --> 00:28:59.956 A:middle
and we'll make sure
those values are correct.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:29:00.216 --> 00:29:01.466 A:middle
And we're going to
click all done.

00:29:01.466 --> 00:29:04.236 A:middle
Now, that's going to present
the user with a nice QR code

00:29:04.236 --> 00:29:06.756 A:middle
that they can scan with
their Passbook device.

00:29:07.036 --> 00:29:09.516 A:middle
But you may be asking, well,
what exactly happens here?

00:29:10.266 --> 00:29:13.106 A:middle
So let's take a look at
the URL that we're going

00:29:13.106 --> 00:29:14.976 A:middle
to be putting inside here.

00:29:15.486 --> 00:29:18.886 A:middle
So the URL is pointing to
a web server that's running

00:29:18.886 --> 00:29:19.956 A:middle
on this local laptop.

00:29:20.666 --> 00:29:22.866 A:middle
And you may be wondering,
well, why are there a bunch

00:29:22.866 --> 00:29:24.346 A:middle
of post variables on
the end of this URL.

00:29:24.956 --> 00:29:27.386 A:middle
Well, as Noah said, you
don't actually need to point

00:29:27.386 --> 00:29:29.136 A:middle
to a static PK pass file.

00:29:29.196 --> 00:29:29.726 A:middle
We can just point

00:29:29.726 --> 00:29:32.516 A:middle
to a generation service
and that [inaudible].

00:29:33.846 --> 00:29:36.296 A:middle
And you may be asking, well,
why don't we just, say,

00:29:36.296 --> 00:29:37.366 A:middle
send those variables away.

00:29:37.366 --> 00:29:39.336 A:middle
Well, the interesting
thing in this scenario is

00:29:39.336 --> 00:29:41.586 A:middle
that this kiosk doesn't actually
have to be live connected

00:29:41.586 --> 00:29:42.406 A:middle
to the internet in any way.

00:29:42.516 --> 00:29:46.126 A:middle
It can just be all locally
running and still be dynamic.

00:29:46.216 --> 00:29:49.016 A:middle
And the nice thing about
this is, of course,

00:29:49.056 --> 00:29:51.416 A:middle
prior to iOS 7 the user
would have to enter some sort

00:29:51.416 --> 00:29:58.086 A:middle
of email address for you to send
them a pass and now they don't.

00:29:58.316 --> 00:30:00.366 A:middle
One thing we do want
to point out is

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:29:58.316 --> 00:30:00.366 A:middle
One thing we do want
to point out is

00:30:00.366 --> 00:30:02.276 A:middle
that if you are running
a generation service,

00:30:02.276 --> 00:30:05.206 A:middle
in this particular
case it's in PHP,

00:30:05.206 --> 00:30:08.186 A:middle
do remember the PKPass
MIME type in your header

00:30:08.436 --> 00:30:12.056 A:middle
so that Passbook knows that
you're giving us down a pass.

00:30:12.246 --> 00:30:14.916 A:middle
So, without further ado,
let's go and scan this one.

00:30:15.506 --> 00:30:19.586 A:middle
So we're going to
launch Passbook in iOS 7.

00:30:20.406 --> 00:30:21.306 A:middle
And, as Noah said, some

00:30:21.306 --> 00:30:23.036 A:middle
of you may have noticed
there's a scan code button.

00:30:23.496 --> 00:30:24.896 A:middle
So let's tap that.

00:30:24.896 --> 00:30:26.296 A:middle
In this particular
case we're going

00:30:26.296 --> 00:30:29.856 A:middle
to give our users a really nice
treat for filling out our form.

00:30:30.416 --> 00:30:32.906 A:middle
Who doesn't love free popcorn?

00:30:33.206 --> 00:30:34.476 A:middle
And that's pass scanning.

00:30:34.656 --> 00:30:34.916 A:middle
Thank you.

00:30:34.916 --> 00:30:34.983 A:middle
[ Applause ]

00:30:34.983 --> 00:30:35.266 A:middle
>> Thanks, Nick.

00:30:35.266 --> 00:30:42.806 A:middle
So we're pretty excited
about that.

00:30:43.556 --> 00:30:46.886 A:middle
We can't wait to see what
you people do with it.

00:30:46.886 --> 00:30:49.406 A:middle
Let's talk about a
couple of details here.

00:30:50.436 --> 00:30:53.626 A:middle
First the URL that you give
us has to return a pass.

00:30:53.816 --> 00:30:56.096 A:middle
If you point us to a website
and try to get your users fill

00:30:56.096 --> 00:30:57.916 A:middle
out an extra form or
whatever -- not going to work.

00:30:58.096 --> 00:30:59.786 A:middle
We will drop that on
the floor and say, hey,

00:30:59.786 --> 00:31:02.106 A:middle
sorry, this is not a pass.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:30:59.786 --> 00:31:02.106 A:middle
sorry, this is not a pass.

00:31:02.106 --> 00:31:05.826 A:middle
So the URL has to be HTTPS
just like your web services.

00:31:06.046 --> 00:31:06.996 A:middle
We like things to be secure.

00:31:08.076 --> 00:31:09.136 A:middle
And this supports any

00:31:09.136 --> 00:31:12.946 A:middle
of the standard Passbook barcode
formats, QR, PDF-417, and Aztec.

00:31:13.826 --> 00:31:15.316 A:middle
Let's review all this.

00:31:15.786 --> 00:31:18.926 A:middle
First, we have the new
add-multiple-passes API

00:31:19.436 --> 00:31:22.456 A:middle
on PKPassLibrary and
PKAddPassesViewController.

00:31:22.926 --> 00:31:25.616 A:middle
And something I didn't mention:
the add-pass view controller,

00:31:25.616 --> 00:31:27.106 A:middle
you can still use
that by itself.

00:31:27.166 --> 00:31:28.616 A:middle
If you want to add
multiple passes

00:31:28.616 --> 00:31:30.926 A:middle
and you always want the user
to see them you can do that.

00:31:31.266 --> 00:31:32.936 A:middle
But if you're using
the PKPassLibrary API,

00:31:33.216 --> 00:31:34.706 A:middle
if the user chooses
to review the passes,

00:31:34.706 --> 00:31:37.066 A:middle
you have to use the add
pass view controller then

00:31:37.416 --> 00:31:40.216 A:middle
to show them the passes
that you're trying

00:31:40.216 --> 00:31:41.216 A:middle
to get into their library.

00:31:42.196 --> 00:31:45.966 A:middle
We have sharing which
is great for cases

00:31:45.966 --> 00:31:48.296 A:middle
where you want your pass to
be in multiple places at once.

00:31:48.736 --> 00:31:51.706 A:middle
But it also means that
since it's much easier

00:31:51.706 --> 00:31:55.416 A:middle
than it was before, you should
be validating your passes

00:31:55.466 --> 00:31:58.406 A:middle
if you care about them
being on multiple devices.

00:31:58.406 --> 00:32:02.976 A:middle
Just make sure that
you're doing that.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:31:58.406 --> 00:32:02.976 A:middle
Just make sure that
you're doing that.

00:32:04.126 --> 00:32:06.676 A:middle
And, let's see.

00:32:07.516 --> 00:32:09.636 A:middle
So we have the Add
to Passbook badge

00:32:09.636 --> 00:32:11.046 A:middle
which we still encourage
you to use.

00:32:11.506 --> 00:32:12.746 A:middle
It works great in content.

00:32:12.946 --> 00:32:15.896 A:middle
If you're doing it in an app,
use it where it's appropriate.

00:32:15.896 --> 00:32:17.996 A:middle
Don't try to wedge it in places
where it doesn't look right.

00:32:17.996 --> 00:32:20.866 A:middle
And, finally, we have
the new code-scanning API

00:32:21.416 --> 00:32:24.856 A:middle
which is really cool and
is a super low friction way

00:32:25.236 --> 00:32:27.926 A:middle
to get passes into
users' pass libraries.

00:32:29.076 --> 00:32:31.486 A:middle
So that's what's new
in getting passes.

00:32:31.486 --> 00:32:33.906 A:middle
Let's talk about relevance
which I mentioned earlier.

00:32:34.586 --> 00:32:38.996 A:middle
The idea of your passes showing
up in your lock screen is

00:32:38.996 --> 00:32:40.926 A:middle
that it's really, really
easy to get to them.

00:32:41.356 --> 00:32:42.396 A:middle
It's a single swipe away.

00:32:42.396 --> 00:32:46.106 A:middle
Users don't have to open
their phone and unlock it,

00:32:46.366 --> 00:32:47.666 A:middle
dig through their
apps, find Passbook,

00:32:47.666 --> 00:32:49.196 A:middle
dig through their passes,
find your pass, et cetera.

00:32:49.446 --> 00:32:52.206 A:middle
It's just right there when
they need it, and that's great.

00:32:52.506 --> 00:32:54.666 A:middle
Users love that they
have this quick access.

00:32:55.896 --> 00:32:59.576 A:middle
And it's the most important
method that you can use

00:32:59.956 --> 00:33:01.756 A:middle
to get your users
to use your passes.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:59.956 --> 00:33:01.756 A:middle
to get your users
to use your passes.

00:33:01.886 --> 00:33:03.946 A:middle
If your pass is relevant
where they're ready to use it,

00:33:04.556 --> 00:33:07.086 A:middle
they will recognize
that and use your pass,

00:33:07.086 --> 00:33:10.826 A:middle
and you'll get that usage.

00:33:12.736 --> 00:33:15.046 A:middle
So there's something that we've
seen some confusion about,

00:33:15.046 --> 00:33:17.316 A:middle
both from users and developers,
which is the difference

00:33:17.316 --> 00:33:18.996 A:middle
between relevance
and notifications.

00:33:19.796 --> 00:33:23.136 A:middle
If you change something
about a pass,

00:33:23.136 --> 00:33:26.506 A:middle
that generates a notification:
you have something saying, hey,

00:33:26.506 --> 00:33:27.356 A:middle
there's something new here.

00:33:27.856 --> 00:33:29.936 A:middle
Relevance is passive,
so to speak.

00:33:30.156 --> 00:33:33.976 A:middle
It's a way to make
your passes available

00:33:33.976 --> 00:33:35.586 A:middle
when they're ready to be used.

00:33:36.476 --> 00:33:37.916 A:middle
So we just wanted
to clarify that.

00:33:39.176 --> 00:33:41.796 A:middle
In iOS 6, the API we
introduced was based

00:33:41.796 --> 00:33:44.496 A:middle
on geographic coordinates,
on points on the map.

00:33:45.066 --> 00:33:50.216 A:middle
You could specify ten locations
with geocoordinates and whatnot,

00:33:51.176 --> 00:33:52.996 A:middle
and within a certain range

00:33:53.126 --> 00:33:56.596 A:middle
of those places we'd make
the pass relevant based

00:33:56.596 --> 00:33:58.556 A:middle
on the pass style
and other factors.

00:33:59.996 --> 00:34:02.166 A:middle
And if you wanted to change
any of those locations,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:33:59.996 --> 00:34:02.166 A:middle
And if you wanted to change
any of those locations,

00:34:02.166 --> 00:34:05.456 A:middle
if you had a bunch of them,
more than ten, and your user was

00:34:05.456 --> 00:34:09.366 A:middle
in a particular area, or if you
had locations that moved around,

00:34:09.366 --> 00:34:11.456 A:middle
vehicles -- trains,
for instance --

00:34:12.496 --> 00:34:15.416 A:middle
then you would have to
push an update to the pass

00:34:15.766 --> 00:34:17.226 A:middle
to get those new
locations into it

00:34:17.226 --> 00:34:22.085 A:middle
which is not the
ideal way to do that.

00:34:22.085 --> 00:34:23.346 A:middle
So we have a new API for this.

00:34:23.346 --> 00:34:26.585 A:middle
It was meant to address
some of the requests we got

00:34:26.585 --> 00:34:27.716 A:middle
about this from developers.

00:34:28.466 --> 00:34:29.326 A:middle
It's called proximity.

00:34:29.936 --> 00:34:33.176 A:middle
It's based around iBeacons,

00:34:33.356 --> 00:34:34.505 A:middle
which you might have
seen mentioned

00:34:34.606 --> 00:34:35.386 A:middle
in the keynote on Monday.

00:34:35.565 --> 00:34:39.806 A:middle
The idea is this API on Core
Location which allows you

00:34:39.806 --> 00:34:42.656 A:middle
to have devices that
broadcast a unique identifier

00:34:42.946 --> 00:34:43.606 A:middle
over Bluetooth.

00:34:44.036 --> 00:34:47.446 A:middle
And the way that
we're using that --

00:34:48.346 --> 00:34:50.496 A:middle
since Core Location provides,
of course, APIs to pick

00:34:50.496 --> 00:34:54.186 A:middle
up that broadcast -- is that
we can now make passes relevant

00:34:54.186 --> 00:34:55.815 A:middle
whenever they're near
one of these devices.

00:34:57.025 --> 00:35:00.786 A:middle
And that allows you a
ton of extra flexibility.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:34:57.025 --> 00:35:00.786 A:middle
And that allows you a
ton of extra flexibility.

00:35:01.266 --> 00:35:05.136 A:middle
It means that you can have any
number of locations as long

00:35:05.136 --> 00:35:06.736 A:middle
as they have beacons
broadcasting the same

00:35:06.736 --> 00:35:07.526 A:middle
unique identifier.

00:35:07.806 --> 00:35:10.716 A:middle
If you have a location that
moves around, like a taco truck,

00:35:10.716 --> 00:35:12.596 A:middle
you can just keep a beacon
with you, and you don't have

00:35:12.646 --> 00:35:15.356 A:middle
to update the pass to say
"here is where I'm going to be"

00:35:15.666 --> 00:35:16.896 A:middle
because the pass
is already going

00:35:16.896 --> 00:35:18.556 A:middle
to be relevant wherever you are.

00:35:19.146 --> 00:35:21.646 A:middle
So that's really cool and
we're really excited about it.

00:35:21.646 --> 00:35:23.446 A:middle
Let's talk about the API.

00:35:25.006 --> 00:35:27.896 A:middle
It looks kind of like the
locations one, only instead

00:35:27.896 --> 00:35:29.486 A:middle
of a pair of coordinates
you're just specifying a

00:35:29.486 --> 00:35:30.246 A:middle
unique identifier.

00:35:30.876 --> 00:35:33.046 A:middle
And Passbook will look
for that identifier,

00:35:33.146 --> 00:35:36.196 A:middle
and when it is detected
your pass becomes relevant.

00:35:36.536 --> 00:35:38.356 A:middle
It's really simple,
it's really easy,

00:35:38.606 --> 00:35:40.026 A:middle
and it should help you a lot

00:35:40.426 --> 00:35:43.556 A:middle
with more flexible
conditions for pass relevance.

00:35:44.266 --> 00:35:46.756 A:middle
Of course we support up
to ten different beacons,

00:35:47.076 --> 00:35:49.146 A:middle
which is less important than
it was with the location API

00:35:49.756 --> 00:35:53.686 A:middle
because the beacons can all be
broadcasting the same unique ID

00:35:53.686 --> 00:35:54.976 A:middle
-- it doesn't really
matter how many there are --

00:35:55.496 --> 00:35:58.556 A:middle
but if you want to do
something different with those,

00:35:58.556 --> 00:35:59.616 A:middle
if you want to use,
for instance,

00:35:59.616 --> 00:36:01.316 A:middle
different relevant text
for different beacons

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:35:59.616 --> 00:36:01.316 A:middle
different relevant text
for different beacons

00:36:01.576 --> 00:36:02.856 A:middle
in a department store,
for instance,

00:36:03.646 --> 00:36:06.936 A:middle
then you can have multiple
beacons in your pass,

00:36:06.936 --> 00:36:08.826 A:middle
we'll look for those and
display the appropriate text

00:36:08.856 --> 00:36:09.706 A:middle
when we detect the beacon.

00:36:10.736 --> 00:36:13.676 A:middle
And, finally, something
really cool about this is

00:36:13.676 --> 00:36:18.516 A:middle
that iOS devices running iOS 7
can act as beacons themselves.

00:36:20.096 --> 00:36:21.896 A:middle
So if you have a
point-of-sale app or something

00:36:22.576 --> 00:36:23.746 A:middle
that is already integrating

00:36:23.746 --> 00:36:26.286 A:middle
with Passbook you now
have a really easy way

00:36:26.636 --> 00:36:28.146 A:middle
to make your passes relevant

00:36:28.396 --> 00:36:29.646 A:middle
when they're near
that point of sale.

00:36:30.326 --> 00:36:33.106 A:middle
You just have your app
broadcast the beacon ID

00:36:33.566 --> 00:36:35.146 A:middle
and we'll pick it up,
and your pass will be

00:36:35.146 --> 00:36:36.956 A:middle
on the user's lock screen and
you'll be ready to use it.

00:36:38.076 --> 00:36:39.656 A:middle
Pretty neat.

00:36:40.276 --> 00:36:41.676 A:middle
One final thing about relevance.

00:36:42.106 --> 00:36:44.666 A:middle
Something that we've had
some requests for is a way

00:36:44.666 --> 00:36:47.346 A:middle
to control how far away
a pass becomes relevant.

00:36:47.636 --> 00:36:49.386 A:middle
Because we use different
radiuses for these,

00:36:49.386 --> 00:36:50.726 A:middle
and if you have, for instance,

00:36:50.726 --> 00:36:52.996 A:middle
a bus station that's using
boarding-pass-style passes,

00:36:53.386 --> 00:36:55.286 A:middle
then you might see complaints
from a user saying, hey,

00:36:55.286 --> 00:36:56.966 A:middle
this pass is becoming
relevant like a kilometer

00:36:56.966 --> 00:36:59.156 A:middle
and a half away, what's
going on with that?

00:36:59.156 --> 00:37:00.906 A:middle
And the reason would
be, of course,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:36:59.156 --> 00:37:00.906 A:middle
And the reason would
be, of course,

00:37:00.906 --> 00:37:03.796 A:middle
that we size boarding-pass
relevance for an airport or so.

00:37:04.546 --> 00:37:08.046 A:middle
So what we now allow you to do
is just control that distance.

00:37:08.266 --> 00:37:11.136 A:middle
You can specify a radius

00:37:11.496 --> 00:37:13.116 A:middle
around which your pass
will become relevant --

00:37:13.496 --> 00:37:17.126 A:middle
and note that that's a cap, not
a replacement for our value.

00:37:17.126 --> 00:37:20.246 A:middle
So if you want to make your pass
relevant all over the Bay Area,

00:37:20.246 --> 00:37:22.376 A:middle
then you're going to
have to put out a lot

00:37:22.376 --> 00:37:24.676 A:middle
of beacons or something.

00:37:24.676 --> 00:37:25.746 A:middle
So let's review all this.

00:37:26.406 --> 00:37:30.686 A:middle
First, relevance is a
quick, easy way for users

00:37:30.686 --> 00:37:31.706 A:middle
to get access to your passes.

00:37:32.096 --> 00:37:33.126 A:middle
Shows up on their lock screen.

00:37:33.216 --> 00:37:36.606 A:middle
They can swipe, get to the
pass, move on with their lives.

00:37:37.956 --> 00:37:40.646 A:middle
Relevance and notifications
are two different things.

00:37:41.816 --> 00:37:44.956 A:middle
One is active, one is passive.

00:37:44.956 --> 00:37:48.346 A:middle
Beacons now allow you to have
way more flexible relevance

00:37:48.566 --> 00:37:49.836 A:middle
by setting up these devices

00:37:49.836 --> 00:37:51.056 A:middle
and broadcasting a
unique identifier.

00:37:52.346 --> 00:37:54.686 A:middle
And, finally, we allow you
to control the distance

00:37:54.686 --> 00:37:55.976 A:middle
at which your pass
has become relevant

00:37:56.746 --> 00:37:57.966 A:middle
when using location API.

00:37:59.126 --> 00:38:00.606 A:middle
So that's relevance.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:59.126 --> 00:38:00.606 A:middle
So that's relevance.

00:38:00.916 --> 00:38:02.016 A:middle
Let's talk about updates.

00:38:02.526 --> 00:38:05.986 A:middle
Now, this hasn't changed much
since iOS 6; we're just calling

00:38:05.986 --> 00:38:07.876 A:middle
out a couple things about it.

00:38:07.876 --> 00:38:11.696 A:middle
And first off, if
you're not using updates

00:38:11.766 --> 00:38:13.686 A:middle
when your pass can
change, you should be.

00:38:13.976 --> 00:38:14.346 A:middle
They're great.

00:38:14.346 --> 00:38:19.526 A:middle
It means that your pass can
be up-to-date, can stay alive

00:38:19.766 --> 00:38:22.076 A:middle
with whatever information
it's supposed to represent.

00:38:22.506 --> 00:38:26.306 A:middle
If you've got a
boarding-pass-type ticket

00:38:26.306 --> 00:38:29.406 A:middle
or a store card that doesn't
update when something changes

00:38:29.406 --> 00:38:31.706 A:middle
about it, then you're kind of
missing out on an opportunity

00:38:31.706 --> 00:38:33.906 A:middle
to make your user's
experience way better.

00:38:35.616 --> 00:38:39.526 A:middle
So a thing about updates is that
if you include a change message

00:38:39.606 --> 00:38:42.346 A:middle
for fields that have
changed then we show it

00:38:42.346 --> 00:38:43.556 A:middle
as a notification to the user.

00:38:44.666 --> 00:38:45.806 A:middle
And if you're going to use

00:38:45.806 --> 00:38:49.376 A:middle
that you should follow the same
principles that you would use

00:38:49.376 --> 00:38:50.876 A:middle
when sending notifications
via an app.

00:38:50.876 --> 00:38:52.746 A:middle
You don't want to
nag your users.

00:38:53.226 --> 00:38:56.306 A:middle
If you send a push
every couple of hours

00:38:56.306 --> 00:38:58.226 A:middle
to someone's store card
saying, "hey, there are things

00:38:58.226 --> 00:39:00.026 A:middle
in our store, hey, check out
this other thing in our store",

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:38:58.226 --> 00:39:00.026 A:middle
in our store, hey, check out
this other thing in our store",

00:39:00.556 --> 00:39:01.936 A:middle
they're eventually going
to get fed up with that.

00:39:01.936 --> 00:39:04.166 A:middle
They're going to turn automatic
updates off and you'll lose

00:39:04.166 --> 00:39:05.226 A:middle
that channel to your users.

00:39:05.226 --> 00:39:07.116 A:middle
So use them sparingly.

00:39:07.116 --> 00:39:08.636 A:middle
Make sure there's
something the user cares

00:39:08.636 --> 00:39:12.066 A:middle
about when you're
updating your pass.

00:39:12.066 --> 00:39:14.326 A:middle
So I mentioned that
we've made some changes

00:39:14.326 --> 00:39:18.196 A:middle
around using passes.

00:39:18.446 --> 00:39:21.866 A:middle
As I mentioned, the idea is
that you scan the barcode

00:39:21.866 --> 00:39:23.526 A:middle
on the user's pass, check
it with your server,

00:39:24.146 --> 00:39:27.536 A:middle
and then complete
whatever transaction you're

00:39:28.006 --> 00:39:29.406 A:middle
going through.

00:39:29.636 --> 00:39:33.766 A:middle
And so the code scanning feature

00:39:33.766 --> 00:39:36.796 A:middle
that we showed off a
minute ago is actually based

00:39:36.796 --> 00:39:39.726 A:middle
on an API that's now
available to you in iOS 7.

00:39:40.416 --> 00:39:41.636 A:middle
And it's on AVFoundation.

00:39:42.486 --> 00:39:45.236 A:middle
It's part of the
camera metadata thing.

00:39:45.236 --> 00:39:46.906 A:middle
I'll refer to the talk
that talks about it

00:39:46.906 --> 00:39:48.066 A:middle
in way more detail later.

00:39:49.146 --> 00:39:52.926 A:middle
And so what this means is that
if you have a point-of-sale app

00:39:52.926 --> 00:39:57.086 A:middle
or something, like I mentioned
earlier, then you can now have

00:39:57.086 --> 00:39:59.096 A:middle
that kind of be an
end-to-end integration.

00:39:59.096 --> 00:40:02.546 A:middle
It can make the passes relevant,
and now it can scan the passes

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:39:59.096 --> 00:40:02.546 A:middle
It can make the passes relevant,
and now it can scan the passes

00:40:02.546 --> 00:40:06.156 A:middle
for you, and you can
then do whatever you need

00:40:06.156 --> 00:40:06.996 A:middle
to do with them.

00:40:07.426 --> 00:40:09.896 A:middle
But this means you can
make better point-of-sales

00:40:09.896 --> 00:40:12.096 A:middle
and improve your user's
experience around their passes.

00:40:12.476 --> 00:40:14.986 A:middle
There are some third party APIs
people have been using already

00:40:14.986 --> 00:40:16.906 A:middle
for this, but we think
this one's kind of great.

00:40:18.156 --> 00:40:20.776 A:middle
And, of course, it supports
all the pass barcode types

00:40:20.916 --> 00:40:22.706 A:middle
like I mentioned earlier.

00:40:22.706 --> 00:40:23.536 A:middle
[ Applause ]

00:40:23.536 --> 00:40:32.646 A:middle
So let's talk about expiration.

00:40:33.956 --> 00:40:36.436 A:middle
Something we had a
lot of requests for --

00:40:36.586 --> 00:40:38.166 A:middle
again, both from users
and developers --

00:40:38.166 --> 00:40:41.406 A:middle
is a way to know when your
users can no longer use a pass.

00:40:41.846 --> 00:40:45.336 A:middle
So what we now allow you
to do is to mark a pass

00:40:45.426 --> 00:40:47.276 A:middle
as expired in the Passbook UI.

00:40:48.046 --> 00:40:51.056 A:middle
We gray out the barcode, we
show "this pass has expired"

00:40:51.526 --> 00:40:57.046 A:middle
in whatever language, and
that is basically just a way

00:40:57.046 --> 00:41:00.356 A:middle
that you can cue your users and
say, "hey, don't bother trying

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:57.046 --> 00:41:00.356 A:middle
that you can cue your users and
say, "hey, don't bother trying

00:41:00.356 --> 00:41:01.856 A:middle
to use this pass: it's
been used already".

00:41:02.696 --> 00:41:04.606 A:middle
There's two keys that
you can use for this.

00:41:04.966 --> 00:41:06.916 A:middle
The first is an expiration date,

00:41:07.466 --> 00:41:09.726 A:middle
after which we'll automatically
mark the pass as expired.

00:41:09.776 --> 00:41:15.146 A:middle
And the second is a voided key
which you can push to the pass

00:41:15.406 --> 00:41:16.636 A:middle
if you want to immediately
update it --

00:41:16.636 --> 00:41:18.096 A:middle
if someone has just
used their ticket

00:41:18.096 --> 00:41:20.936 A:middle
or if their store card is
now entirely out of funds

00:41:20.936 --> 00:41:21.636 A:middle
or anything like that.

00:41:23.266 --> 00:41:26.936 A:middle
And you should note that
this is not an absolute.

00:41:27.176 --> 00:41:29.156 A:middle
You could be looking at a
screen shot of the pass,

00:41:29.156 --> 00:41:31.116 A:middle
the update might not
have made it to the pass,

00:41:31.496 --> 00:41:33.556 A:middle
so this should not be your form

00:41:33.556 --> 00:41:35.436 A:middle
of security just
graying out your barcode.

00:41:35.436 --> 00:41:37.996 A:middle
It's really just meant as
a visual cue to your users

00:41:38.226 --> 00:41:40.556 A:middle
to let them know when they
can and can't use a pass.

00:41:41.406 --> 00:41:43.826 A:middle
So as before, if
it matters to you

00:41:43.826 --> 00:41:45.486 A:middle
about your pass being used
multiple times or being

00:41:45.486 --> 00:41:47.156 A:middle
on multiple devices:
validate it.

00:41:47.156 --> 00:41:48.466 A:middle
Check the barcode
with the server.

00:41:48.786 --> 00:41:51.436 A:middle
That's what it's for.

00:41:51.656 --> 00:41:55.356 A:middle
So to review that, we have the
code-scanning API now available

00:41:55.356 --> 00:41:59.246 A:middle
on AVFoundation, and
we have these new keys

00:41:59.246 --> 00:42:01.986 A:middle
to expire your passes, to mark
them as expired in the UI.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:41:59.246 --> 00:42:01.986 A:middle
to expire your passes, to mark
them as expired in the UI.

00:42:02.916 --> 00:42:06.296 A:middle
And, again, if it matters
to you your pass being

00:42:06.296 --> 00:42:08.996 A:middle
on multiple places or used
multiple times: validate them.

00:42:08.996 --> 00:42:10.576 A:middle
Check the pass with your server.

00:42:11.956 --> 00:42:12.906 A:middle
So that's what's new.

00:42:12.906 --> 00:42:17.016 A:middle
Let's talk a couple of tips,
tricks, things to help you

00:42:17.016 --> 00:42:19.446 A:middle
with your development
and make your Passbook

00:42:19.446 --> 00:42:20.916 A:middle
integration better.

00:42:21.906 --> 00:42:24.366 A:middle
First, we have some
developer settings

00:42:24.596 --> 00:42:25.566 A:middle
which you may have seen before.

00:42:25.686 --> 00:42:27.456 A:middle
They're in Settings > Developer.

00:42:28.386 --> 00:42:32.106 A:middle
And they're really useful
for debugging your passes

00:42:32.336 --> 00:42:34.506 A:middle
and your web services
and all kinds of things.

00:42:35.356 --> 00:42:39.176 A:middle
First, there's a logging switch,
which allows you to see a bunch

00:42:39.176 --> 00:42:40.656 A:middle
of extra information
about what we're doing,

00:42:40.656 --> 00:42:42.956 A:middle
about what your pass
might be doing.

00:42:43.276 --> 00:42:45.206 A:middle
If you have validation
errors they'll show up there.

00:42:45.536 --> 00:42:46.926 A:middle
If you have weird
things happening

00:42:46.956 --> 00:42:49.166 A:middle
with your web service
like [inaudible].

00:42:50.586 --> 00:42:53.846 A:middle
We have a switch to
allow HTTP services.

00:42:53.916 --> 00:42:55.286 A:middle
If you're doing some
early development,

00:42:55.286 --> 00:42:56.866 A:middle
if you don't have your
server's certificate set up,

00:42:57.146 --> 00:42:59.546 A:middle
you can turn the switch
on, point your passes

00:42:59.546 --> 00:43:02.096 A:middle
at some local server
without any validation

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:42:59.546 --> 00:43:02.096 A:middle
at some local server
without any validation

00:43:02.096 --> 00:43:04.786 A:middle
and it will just work.

00:43:04.786 --> 00:43:07.776 A:middle
And finally, we have a new
switch which ties into a feature

00:43:07.776 --> 00:43:11.216 A:middle
that we haven't really talked
about before but that some

00:43:11.216 --> 00:43:13.056 A:middle
of you may notice,
which is rate limiting.

00:43:13.796 --> 00:43:17.056 A:middle
So if you push a punch of
updates to a pass in a row,

00:43:17.696 --> 00:43:19.786 A:middle
that means we have to keep
downloading the pass over

00:43:19.786 --> 00:43:21.636 A:middle
and over again, and that
uses the user's battery,

00:43:21.636 --> 00:43:23.716 A:middle
it uses a bunch of
your server resources.

00:43:24.686 --> 00:43:27.126 A:middle
And so we will throttle
that back.

00:43:27.126 --> 00:43:28.096 A:middle
If we get a ton of updates

00:43:28.096 --> 00:43:29.906 A:middle
in a row we'll start
decreasing the rate

00:43:29.906 --> 00:43:32.616 A:middle
at which we actually
check for the pass.

00:43:33.346 --> 00:43:36.606 A:middle
And that helps users and means

00:43:36.606 --> 00:43:38.586 A:middle
if you have some
unexpected issues

00:43:38.586 --> 00:43:40.806 A:middle
in your push system
then you're not going

00:43:40.806 --> 00:43:43.446 A:middle
to get an unexpected spike of
server load, which is great.

00:43:43.446 --> 00:43:45.506 A:middle
But if you're testing something,
if you're actually trying

00:43:45.506 --> 00:43:47.076 A:middle
to send a ton of pushes
to a pass in a row,

00:43:47.386 --> 00:43:49.076 A:middle
then that's kind of
a problem for you.

00:43:49.406 --> 00:43:51.006 A:middle
And so you can turn this on

00:43:51.006 --> 00:43:53.336 A:middle
and we will update
the pass immediately

00:43:53.336 --> 00:43:54.836 A:middle
for every push that
you send to us.

00:43:55.776 --> 00:43:58.266 A:middle
So use that if you need it.

00:43:58.976 --> 00:44:01.476 A:middle
Something to note
about all of these is

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:43:58.976 --> 00:44:01.476 A:middle
Something to note
about all of these is

00:44:01.476 --> 00:44:03.446 A:middle
that they're only available
on development devices.

00:44:03.446 --> 00:44:06.796 A:middle
Your users will not have
these switches in most cases

00:44:06.796 --> 00:44:08.556 A:middle
and they will almost certainly
not have them turned on.

00:44:08.756 --> 00:44:12.236 A:middle
So your web services in
production do need to be HTTPS,

00:44:12.386 --> 00:44:16.996 A:middle
and they do need to be aware
at least of the rate limiting

00:44:16.996 --> 00:44:18.746 A:middle
that we do if you're
sending a ton of pushes.

00:44:20.356 --> 00:44:25.186 A:middle
So I mentioned that the logging
could help you find issues

00:44:25.186 --> 00:44:26.086 A:middle
with your web services.

00:44:26.326 --> 00:44:28.826 A:middle
And that will work great
for you if you're doing this

00:44:28.826 --> 00:44:30.536 A:middle
in a development
environment and testing

00:44:30.536 --> 00:44:33.936 A:middle
out the first implementation
of your server.

00:44:34.386 --> 00:44:37.226 A:middle
But in production we have
something else for you.

00:44:37.346 --> 00:44:40.216 A:middle
And this was mentioned
briefly in last year's talk

00:44:40.426 --> 00:44:42.196 A:middle
about the web service API.

00:44:43.576 --> 00:44:47.336 A:middle
And all it is is a way for
you to easily catch issues

00:44:47.656 --> 00:44:48.626 A:middle
with your implementation.

00:44:49.216 --> 00:44:51.236 A:middle
If your web service is
sending us down things

00:44:51.236 --> 00:44:53.946 A:middle
that aren't passes, or if you're
sending pushes that don't result

00:44:53.946 --> 00:44:56.396 A:middle
in an actual change to the
pass, we will tell you.

00:44:56.396 --> 00:45:00.146 A:middle
We will send a message to
this URL with logs on the end,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:44:56.396 --> 00:45:00.146 A:middle
We will send a message to
this URL with logs on the end,

00:45:00.146 --> 00:45:03.566 A:middle
and that will let you know
that something is happening.

00:45:03.566 --> 00:45:04.756 A:middle
So watch this endpoint.

00:45:05.096 --> 00:45:07.486 A:middle
If you're getting reports
from your users of some issues

00:45:07.486 --> 00:45:11.026 A:middle
in production, you could make
a ton of surveys and ask people

00:45:11.026 --> 00:45:13.816 A:middle
"what were you doing when you
didn't get this pass updated".

00:45:14.196 --> 00:45:17.516 A:middle
Or, you can just watch
this endpoint and find

00:45:17.516 --> 00:45:19.996 A:middle
out what's going on
from us directly.

00:45:20.896 --> 00:45:22.066 A:middle
So that's really useful.

00:45:23.226 --> 00:45:25.246 A:middle
The most common issue
that we've seen --

00:45:25.246 --> 00:45:27.206 A:middle
and that we do message
to this endpoint --

00:45:28.076 --> 00:45:31.676 A:middle
is people not using the
Last-Modified/If-Modified-Since

00:45:31.766 --> 00:45:32.196 A:middle
system.

00:45:32.706 --> 00:45:35.576 A:middle
And the way that works -- again
more detail in last year's talk,

00:45:35.576 --> 00:45:37.136 A:middle
but I can summarize it --

00:45:37.516 --> 00:45:40.306 A:middle
is that when you update a
pass you can send out a header

00:45:40.646 --> 00:45:42.576 A:middle
with a blob of information
saying "here is

00:45:42.576 --> 00:45:43.756 A:middle
when we last changed this pass".

00:45:43.896 --> 00:45:46.876 A:middle
And then the next request we
make will include that header

00:45:46.876 --> 00:45:48.896 A:middle
and say "have you
changed it since then?"

00:45:48.896 --> 00:45:52.566 A:middle
If the answer is "no", your
server sends down an HTTP 304

00:45:52.956 --> 00:45:55.686 A:middle
"nothing changed" and we
don't download the pass.

00:45:55.776 --> 00:45:59.026 A:middle
And that saves both your users'
batteries and cellular usage,

00:45:59.026 --> 00:46:01.616 A:middle
and it saves your
server resources.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:45:59.026 --> 00:46:01.616 A:middle
and it saves your
server resources.

00:46:01.766 --> 00:46:03.216 A:middle
So: use that.

00:46:04.446 --> 00:46:06.156 A:middle
It's kind of nice.

00:46:06.916 --> 00:46:08.916 A:middle
So let's review all this.

00:46:09.086 --> 00:46:10.856 A:middle
First, the ecosystem.

00:46:11.546 --> 00:46:14.016 A:middle
Passes are information that
can be used in the real world.

00:46:14.676 --> 00:46:15.806 A:middle
They come from your server.

00:46:16.436 --> 00:46:19.056 A:middle
They get into the user's
pass library via apps

00:46:19.356 --> 00:46:20.496 A:middle
of various descriptions.

00:46:21.516 --> 00:46:22.746 A:middle
They're redeemed or used

00:46:22.746 --> 00:46:24.086 A:middle
by scanning the barcode
on the pass.

00:46:24.536 --> 00:46:26.816 A:middle
And you can update them
using our push mechanism.

00:46:28.756 --> 00:46:29.766 A:middle
What's new with passes?

00:46:30.026 --> 00:46:32.016 A:middle
We have richer pass content.

00:46:32.836 --> 00:46:34.986 A:middle
We have some easier ways
to get passes, both APIs

00:46:34.986 --> 00:46:36.596 A:middle
and user-facing features.

00:46:36.946 --> 00:46:41.166 A:middle
We have more control over pass
relevance, the new beacon API

00:46:41.166 --> 00:46:42.896 A:middle
and the new distance
restrictions.

00:46:43.986 --> 00:46:46.216 A:middle
And we finally have a couple
of things that could help you

00:46:46.456 --> 00:46:48.776 A:middle
around the whole
using-your-passes experience.

00:46:49.146 --> 00:46:52.776 A:middle
Tips and tricks: use
the developer settings.

00:46:52.776 --> 00:46:54.676 A:middle
They have real useful
information for you.

00:46:55.846 --> 00:46:57.316 A:middle
And use the logging endpoint

00:46:57.476 --> 00:47:00.286 A:middle
because it will help you catch
your errors in production

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:46:57.476 --> 00:47:00.286 A:middle
because it will help you catch
your errors in production

00:47:00.356 --> 00:47:01.536 A:middle
which is super useful.

00:47:03.606 --> 00:47:07.876 A:middle
Finally, we have a lot of new
APIs, as you've just seen.

00:47:07.876 --> 00:47:10.086 A:middle
We have a couple of
new user features

00:47:10.086 --> 00:47:13.866 A:middle
that can affect how you
integrate with Passbook.

00:47:15.226 --> 00:47:17.586 A:middle
If it matters to you about your
pass being on multiple devices:

00:47:17.586 --> 00:47:19.336 A:middle
validate them, check
the barcodes,

00:47:19.336 --> 00:47:21.806 A:middle
because it is way easier for
passes to be everywhere now.

00:47:22.506 --> 00:47:24.556 A:middle
And, finally, give us feedback.

00:47:25.596 --> 00:47:27.556 A:middle
You might have noticed that
I keep calling things out as

00:47:27.556 --> 00:47:29.946 A:middle
"this is from a request
we had from developers".

00:47:29.946 --> 00:47:32.476 A:middle
And there's a reason for
that, which is that a lot

00:47:32.476 --> 00:47:35.606 A:middle
of these ideas are based on
requests that we've gotten.

00:47:35.606 --> 00:47:37.066 A:middle
So tell us what you want.

00:47:37.146 --> 00:47:38.246 A:middle
We will listen.

00:47:38.246 --> 00:47:40.136 A:middle
We read every bug that you file.

00:47:40.286 --> 00:47:43.376 A:middle
You can talk to our evangelist,
Paul Marcos [phonetic].

00:47:44.386 --> 00:47:47.716 A:middle
There's documentation
on developer.apple.com,

00:47:48.266 --> 00:47:50.406 A:middle
and we will be in the
Apple developer forums.

00:47:51.816 --> 00:47:55.096 A:middle
Finally, there's a
couple of new sessions

00:47:55.096 --> 00:47:55.946 A:middle
that are related to this.

00:47:55.946 --> 00:47:58.826 A:middle
The What's New in Camera Capture
one is actually right now,

00:47:58.826 --> 00:48:01.036 A:middle
so you are too late, but you
can watch the video later.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:47:58.826 --> 00:48:01.036 A:middle
so you are too late, but you
can watch the video later.

00:48:01.736 --> 00:48:05.286 A:middle
That talks about the new
AVFoundation code-scanning APIs.

00:48:06.086 --> 00:48:09.416 A:middle
The next talk, Integrating
Passbook Into Your Ecosystem,

00:48:09.666 --> 00:48:11.366 A:middle
is actually really
interesting because it's

00:48:11.366 --> 00:48:13.066 A:middle
from the Apple Store app team

00:48:13.406 --> 00:48:17.006 A:middle
who developed a really nice
integration of Passbook

00:48:17.006 --> 00:48:20.396 A:middle
with their gift cards that
was based entirely on the API

00:48:20.396 --> 00:48:23.616 A:middle
that you guys are using,
on the public APIs.

00:48:23.666 --> 00:48:26.526 A:middle
They aren't us, and you
can go to their talk

00:48:26.526 --> 00:48:29.746 A:middle
to get a really good idea for
what Passbook integration looks

00:48:29.746 --> 00:48:33.026 A:middle
like in a really large
scale, high value system.

00:48:33.946 --> 00:48:36.246 A:middle
So, go to that talk:
it is at 3:15.

00:48:37.246 --> 00:48:41.016 A:middle
Finally, the iBeacons API that
I mentioned is in CoreLocation.

00:48:41.406 --> 00:48:46.086 A:middle
Thanks for coming.

00:48:46.086 --> 00:48:46.153 A:middle
[ Applause ]

00:48:46.153 --> 00:48:46.220 A:middle
NW