308.srt

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

00:00:00.506 --> 00:00:09.516 A:middle
[ Silence ]

00:00:10.016 --> 00:00:13.000 A:middle
[ Applause ]

00:00:13.316 --> 00:00:13.656 A:middle
>> Thank you.

00:00:15.116 --> 00:00:16.056 A:middle
Good afternoon.

00:00:16.936 --> 00:00:19.936 A:middle
Hi, my name is James Wilson
and I'm the Engineering Manager

00:00:20.106 --> 00:00:21.266 A:middle
for the App Store in OS X.

00:00:22.486 --> 00:00:23.906 A:middle
It's great to see
so many of you here

00:00:23.906 --> 00:00:25.366 A:middle
that are interested
in getting paid.

00:00:26.206 --> 00:00:30.026 A:middle
In this session, we're going
to be talking all about how

00:00:30.026 --> 00:00:32.636 A:middle
to protect your digital
sales using receipts.

00:00:35.316 --> 00:00:38.626 A:middle
There's a huge amount of
revenue that is being generated

00:00:39.236 --> 00:00:40.426 A:middle
through In-App Purchases.

00:00:41.536 --> 00:00:48.856 A:middle
In fact, so much so that just a
few days ago, 96% of the top 25,

00:00:48.906 --> 00:00:51.906 A:middle
top grossing apps for the
iPhone were free apps,

00:00:52.936 --> 00:00:54.966 A:middle
and they were using
In-App Purchases alone

00:00:55.466 --> 00:00:59.056 A:middle
to generate enough revenue to
make them top grossing apps.

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

00:01:00.226 --> 00:01:03.776 A:middle
Now that's huge groundswell
of momentum and popularity

00:01:03.836 --> 00:01:06.566 A:middle
for the free with In-App
Purchase, or Freemium model,

00:01:07.356 --> 00:01:09.956 A:middle
combined with the
continued popularity of paid,

00:01:10.166 --> 00:01:11.836 A:middle
with or without In-App
Purchases,

00:01:13.146 --> 00:01:16.136 A:middle
means that there is a lot
of importance for you,

00:01:16.136 --> 00:01:18.636 A:middle
the developer, to protect
those digital sales

00:01:19.516 --> 00:01:23.706 A:middle
and to secure your revenue,
because if your app is easy

00:01:23.706 --> 00:01:27.186 A:middle
to be pirated, cracked,
stolen, and shared around,

00:01:27.946 --> 00:01:31.216 A:middle
there's no money
in that for you.

00:01:31.696 --> 00:01:35.356 A:middle
So in this session, I'm going
to introduce you to the concept

00:01:35.356 --> 00:01:38.926 A:middle
of the receipt, and the
receipt is the foundation upon

00:01:38.926 --> 00:01:41.616 A:middle
which you can build your
business model enforcement logic

00:01:42.036 --> 00:01:45.116 A:middle
directly into your app, as
well as into your servers

00:01:45.276 --> 00:01:47.246 A:middle
that are providing the
content out to your users.

00:01:48.446 --> 00:01:50.796 A:middle
We are going to introduce you
to the receipt, how it works,

00:01:50.796 --> 00:01:53.406 A:middle
what's in it, when you
get them, then we're going

00:01:53.406 --> 00:01:57.416 A:middle
to actually look down into the
code level on both iOS and OS X

00:01:57.926 --> 00:02:00.876 A:middle
as to how you actually go
about validating these receipts

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

00:01:57.926 --> 00:02:00.876 A:middle
as to how you actually go
about validating these receipts

00:02:01.166 --> 00:02:04.626 A:middle
and getting the purchase
information out of them.

00:02:04.826 --> 00:02:05.706 A:middle
We'll do some -- we'll do a look

00:02:05.706 --> 00:02:07.856 A:middle
into some platform
specific concerns about how

00:02:07.856 --> 00:02:11.006 A:middle
to implement receipt
validation, and then finally,

00:02:11.006 --> 00:02:13.406 A:middle
we'll look at the test
environment that you can use

00:02:13.436 --> 00:02:16.206 A:middle
to make sure that you
ship code that's bug free.

00:02:16.776 --> 00:02:20.666 A:middle
So the receipt.

00:02:21.576 --> 00:02:25.976 A:middle
It's exactly like the
receipt that you get

00:02:25.976 --> 00:02:28.066 A:middle
when you're shopping
at a physical store.

00:02:28.646 --> 00:02:30.316 A:middle
Just like when you're
at a department store,

00:02:30.746 --> 00:02:33.736 A:middle
you're at the checkout,
you exchange your cash

00:02:33.736 --> 00:02:34.796 A:middle
for goods that you're buying.

00:02:35.326 --> 00:02:37.086 A:middle
Not only do you get those
goods that you've bought,

00:02:37.496 --> 00:02:38.906 A:middle
but you get a receipt, as well.

00:02:39.446 --> 00:02:43.256 A:middle
That little piece of paper that
verifies exactly what you paid

00:02:43.256 --> 00:02:49.246 A:middle
for in this store, and it's
that little piece of paper

00:02:49.246 --> 00:02:53.006 A:middle
that that physical store that
you're in can use as the basis

00:02:53.006 --> 00:02:55.176 A:middle
of their security
model to make sure

00:02:55.176 --> 00:02:56.986 A:middle
that their goods don't
go walking out the door

00:02:56.986 --> 00:02:58.176 A:middle
with a five finger discount.

00:02:59.556 --> 00:03:02.176 A:middle
Likewise in the App
Store, the receipt is

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

00:02:59.556 --> 00:03:02.176 A:middle
Likewise in the App
Store, the receipt is

00:03:02.176 --> 00:03:03.326 A:middle
that digital equivalent.

00:03:04.706 --> 00:03:08.356 A:middle
The receipt is your trusted and
verifiable record of purchase.

00:03:08.926 --> 00:03:11.836 A:middle
It's issued by the App Store
and contains signatures

00:03:12.066 --> 00:03:15.366 A:middle
and certificates and security
measures that make sure

00:03:15.366 --> 00:03:17.136 A:middle
that it came from
Apple and is unaltered,

00:03:18.316 --> 00:03:21.936 A:middle
and that it ties directly to
your app on a specific device.

00:03:23.186 --> 00:03:25.516 A:middle
Now if you're a paid app, this
is really important obviously

00:03:25.516 --> 00:03:26.886 A:middle
for implementing
copy protection,

00:03:27.966 --> 00:03:29.696 A:middle
and if you're a free app
with In-App Purchases

00:03:29.786 --> 00:03:31.416 A:middle
or a paid app using
In-App Purchases,

00:03:31.906 --> 00:03:33.766 A:middle
the receipt is what you use

00:03:33.766 --> 00:03:35.926 A:middle
to know exactly what
the customer paid for so

00:03:36.436 --> 00:03:38.796 A:middle
that you can unlock
features and content.

00:03:41.196 --> 00:03:44.236 A:middle
So understanding the receipt
and knowing how it works,

00:03:44.396 --> 00:03:47.136 A:middle
knowing how to validate it and
get the purchase information

00:03:47.136 --> 00:03:50.226 A:middle
out of it, is how you
enable your business model

00:03:50.696 --> 00:03:53.596 A:middle
in your apps directly,
as well as in servers

00:03:53.596 --> 00:03:56.416 A:middle
that you have issuing content
and assets out to customers.

00:03:57.826 --> 00:04:01.836 A:middle
Using the receipt is how you
know exactly what the user has

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

00:03:57.826 --> 00:04:01.836 A:middle
Using the receipt is how you
know exactly what the user has

00:04:01.896 --> 00:04:02.376 A:middle
paid for.

00:04:06.076 --> 00:04:07.656 A:middle
Now if you haven't
looked into how

00:04:07.656 --> 00:04:10.996 A:middle
to do receipt validation before,
or maybe you've looked at it

00:04:10.996 --> 00:04:13.516 A:middle
but haven't yet implemented
it, this session is going

00:04:13.516 --> 00:04:15.076 A:middle
to be great for you because
we're going to take you

00:04:15.076 --> 00:04:16.546 A:middle
through a step-by-step look

00:04:16.815 --> 00:04:18.706 A:middle
at exactly how you
validate the receipt

00:04:18.706 --> 00:04:21.476 A:middle
and get the purchase
information out of it.

00:04:22.106 --> 00:04:25.766 A:middle
For my iOS developers who are
already doing receipt checking

00:04:25.966 --> 00:04:29.226 A:middle
in iOS 6 and earlier, using the
methods we had available then,

00:04:30.276 --> 00:04:32.736 A:middle
I've got some new
APIs for you and also,

00:04:32.736 --> 00:04:35.016 A:middle
a change in the receipt
format that is going

00:04:35.016 --> 00:04:36.656 A:middle
to give you even
greater flexibility

00:04:36.656 --> 00:04:40.366 A:middle
and a whole lot more power to
not only validate purchases

00:04:40.486 --> 00:04:43.136 A:middle
on your servers, but to
validate the receipts

00:04:43.216 --> 00:04:44.456 A:middle
on the device itself.

00:04:45.006 --> 00:04:50.586 A:middle
But now for my OS X developers,
I think you'll particularly

00:04:50.586 --> 00:04:53.746 A:middle
like this because the
receipt format that you know

00:04:53.746 --> 00:04:56.436 A:middle
and understand and that we've
been using since we debuted

00:04:57.056 --> 00:04:59.046 A:middle
on the -- since we
debuted the Mac App Store,

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

00:05:00.426 --> 00:05:03.186 A:middle
is now the exact same receipt
format that we are using

00:05:03.186 --> 00:05:06.476 A:middle
across iOS 7 and OS X.

00:05:07.596 --> 00:05:13.396 A:middle
This gives you a unified,
trusted, validated,

00:05:13.726 --> 00:05:17.146 A:middle
proof of purchase or purchase
record across both platforms

00:05:17.256 --> 00:05:19.216 A:middle
to know exactly what the
customer has paid for.

00:05:19.806 --> 00:05:24.306 A:middle
Not only do we now have the
unified receipt model across iOS

00:05:24.306 --> 00:05:28.106 A:middle
and OS X, but the receipt
now includes two new pieces

00:05:28.106 --> 00:05:28.766 A:middle
of information.

00:05:29.726 --> 00:05:31.776 A:middle
If you've opted into the
Volume Purchase Program

00:05:31.776 --> 00:05:34.266 A:middle
to license your app out
to business and education,

00:05:34.576 --> 00:05:36.396 A:middle
there's extra information
in the receipt now

00:05:36.396 --> 00:05:40.126 A:middle
that tells you whether that
receipt is allocated to a user

00:05:40.126 --> 00:05:42.466 A:middle
or whether it has been
revoked from them,

00:05:43.036 --> 00:05:44.906 A:middle
but I think the most
exciting thing that's

00:05:44.906 --> 00:05:46.996 A:middle
in the receipt this year,
especially for you guys,

00:05:47.026 --> 00:05:48.536 A:middle
if you have a paid
app in the store,

00:05:49.416 --> 00:05:50.766 A:middle
is that we've included
information

00:05:50.766 --> 00:05:52.876 A:middle
in the receipt that's going
to let you do a transition

00:05:52.876 --> 00:05:56.476 A:middle
from being a paid app to being
a free app with In-App Purchases

00:05:57.086 --> 00:05:58.966 A:middle
without leaving behind
all the customers

00:05:58.966 --> 00:06:01.476 A:middle
that have already
paid for your app.

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

00:05:58.966 --> 00:06:01.476 A:middle
that have already
paid for your app.

00:06:04.726 --> 00:06:04.946 A:middle
[Applause] Right.

00:06:05.186 --> 00:06:06.116 A:middle
Which is important, right?

00:06:06.116 --> 00:06:07.966 A:middle
Because you can see that
there's this huge groundswell

00:06:07.966 --> 00:06:10.886 A:middle
of momentum towards the Freemium
model but you don't want

00:06:10.886 --> 00:06:13.526 A:middle
to leave behind people who've
already paid for your app.

00:06:16.096 --> 00:06:18.816 A:middle
So the receipts, this
foundation, this core upon

00:06:18.816 --> 00:06:21.006 A:middle
which you build enforcement
of your business model,

00:06:21.236 --> 00:06:22.316 A:middle
directly into your apps.

00:06:23.876 --> 00:06:26.586 A:middle
When it comes to the finding
exactly how you're going

00:06:26.586 --> 00:06:29.186 A:middle
to enforce your business
model, that's going

00:06:29.186 --> 00:06:31.686 A:middle
to be something that's
unique to your app.

00:06:32.656 --> 00:06:34.146 A:middle
Everyone's app is
different, right?

00:06:35.286 --> 00:06:37.096 A:middle
You have a different
value proposition,

00:06:37.226 --> 00:06:39.486 A:middle
different price point,
different target market,

00:06:39.556 --> 00:06:41.906 A:middle
different customers, different
expectations, everything.

00:06:43.066 --> 00:06:45.776 A:middle
Everyone's app is
unique, and the products

00:06:45.776 --> 00:06:47.456 A:middle
that you're selling,
be it the app itself

00:06:47.456 --> 00:06:50.626 A:middle
or through In-App Purchases,
they have different values.

00:06:51.936 --> 00:06:55.166 A:middle
That uniqueness needs to
translate into how you decide

00:06:55.476 --> 00:06:56.846 A:middle
to enforce your business model

00:06:57.156 --> 00:06:59.586 A:middle
and protect your revenue,
your app and servers.

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

00:07:00.406 --> 00:07:01.346 A:middle
So it's like a recipe.

00:07:02.466 --> 00:07:04.196 A:middle
Together we're going to
bake a cake that's going

00:07:04.266 --> 00:07:05.446 A:middle
to make sure you get paid.

00:07:06.936 --> 00:07:08.636 A:middle
Apple has got some ingredients
that we're going to bring

00:07:08.636 --> 00:07:11.126 A:middle
to the table, but there's
some that you'll need to bring

00:07:11.126 --> 00:07:14.526 A:middle
to the table as well, but the
great thing is that I'm going

00:07:14.526 --> 00:07:17.376 A:middle
to show you that all of these
things that you need to work out

00:07:17.696 --> 00:07:20.866 A:middle
and work out how you want to
approach them, they're all based

00:07:20.866 --> 00:07:23.716 A:middle
on standards that are open and
very well used and there's lots

00:07:23.716 --> 00:07:26.326 A:middle
of examples, third-party
libraries ready to go,

00:07:26.726 --> 00:07:28.076 A:middle
plus you have the flexibility

00:07:28.336 --> 00:07:30.336 A:middle
to write the code
yourself if you choose.

00:07:30.766 --> 00:07:34.376 A:middle
Because Apple gives you the
receipt format specification

00:07:34.376 --> 00:07:37.626 A:middle
itself and the receipt is
based on open standards,

00:07:37.626 --> 00:07:41.576 A:middle
everything in the
receipt is based

00:07:41.576 --> 00:07:43.616 A:middle
on an open standard that's
very well documented,

00:07:44.066 --> 00:07:47.036 A:middle
used industry wide, and is used
in many, many different ways.

00:07:47.576 --> 00:07:52.716 A:middle
We give you the receipt itself,
and we give you instructions

00:07:52.716 --> 00:07:55.516 A:middle
on how to do both on-device
validation for the receipt,

00:07:55.606 --> 00:07:58.706 A:middle
as well as validating the
receipt server-to-server,

00:07:58.956 --> 00:08:00.446 A:middle
if you have servers
out there that need

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

00:07:58.956 --> 00:08:00.446 A:middle
if you have servers
out there that need

00:08:00.446 --> 00:08:02.186 A:middle
to validate these
before issuing content.

00:08:03.466 --> 00:08:06.546 A:middle
But it's up to you guys,
you the developers,

00:08:06.986 --> 00:08:08.656 A:middle
to make some decisions
along the way

00:08:09.526 --> 00:08:12.276 A:middle
about exactly what security
level is important for you,

00:08:12.726 --> 00:08:13.976 A:middle
and I'm going to
call those out to you

00:08:13.976 --> 00:08:14.976 A:middle
as we go through these slides.

00:08:15.516 --> 00:08:20.576 A:middle
[ Pause ]

00:08:21.076 --> 00:08:23.876 A:middle
So let's start with an
understanding of the receipts.

00:08:27.176 --> 00:08:30.906 A:middle
So a receipt, again, just like
the physical receipt you get

00:08:30.906 --> 00:08:34.076 A:middle
in the store, is issued when
a transaction takes place

00:08:34.116 --> 00:08:36.135 A:middle
between the App Store
and your app.

00:08:37.226 --> 00:08:40.806 A:middle
So when your app is purchased
or updated, a receipt is issued.

00:08:42.066 --> 00:08:44.306 A:middle
If someone performs an In-App
Purchase or there are stores

00:08:44.306 --> 00:08:45.476 A:middle
that have completed
transactions,

00:08:46.386 --> 00:08:47.216 A:middle
a receipt is issued.

00:08:48.076 --> 00:08:50.226 A:middle
If you've opted into the
Great Volume Purchase Program,

00:08:50.936 --> 00:08:53.096 A:middle
when the license is
allocated or when it's revoked

00:08:53.096 --> 00:08:55.056 A:middle
from that user, a
receipt's issued.

00:08:56.596 --> 00:08:59.856 A:middle
There's also some on-demand APIs
that you can use within your app

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

00:09:00.266 --> 00:09:01.836 A:middle
to get in your receipt
if it appears

00:09:01.836 --> 00:09:05.056 A:middle
that the one there is missing
or doesn't appear to be valid

00:09:05.056 --> 00:09:06.376 A:middle
for your app on this device.

00:09:08.716 --> 00:09:09.946 A:middle
So what's in these things?

00:09:11.736 --> 00:09:12.926 A:middle
So within the receipt itself,

00:09:13.956 --> 00:09:16.376 A:middle
first and foremost there's
certificates and signatures,

00:09:16.726 --> 00:09:18.666 A:middle
and this allows you to make
sure it came from Apple

00:09:18.666 --> 00:09:19.836 A:middle
and hasn't been tampered with.

00:09:21.026 --> 00:09:23.966 A:middle
There's information that ties
the receipt directly to your app

00:09:24.096 --> 00:09:26.656 A:middle
on a specific device,
so it hasn't been copied

00:09:26.656 --> 00:09:29.206 A:middle
around between people, it
hasn't been copied from one app

00:09:29.256 --> 00:09:32.286 A:middle
to another app, it's
legitimately for your app

00:09:32.676 --> 00:09:36.616 A:middle
on a single device, and then
once you know that it's trusted

00:09:36.616 --> 00:09:39.196 A:middle
and it's for your app on this
device, you can get a whole lot

00:09:39.196 --> 00:09:40.886 A:middle
of purchase information
out of that receipt.

00:09:42.236 --> 00:09:44.526 A:middle
You've got purchase information
about the app itself,

00:09:45.146 --> 00:09:47.536 A:middle
plus the In-App Purchases
that the user has made,

00:09:48.716 --> 00:09:51.286 A:middle
and there's also information
there, I mentioned as well,

00:09:51.286 --> 00:09:52.656 A:middle
about the Volume
Purchase Program,

00:09:54.016 --> 00:09:56.066 A:middle
but I think the most exciting
thing that we've added

00:09:56.066 --> 00:09:59.686 A:middle
to the receipt this year is
the initial purchase date

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

00:10:00.036 --> 00:10:01.686 A:middle
and initial purchase version.

00:10:02.326 --> 00:10:07.926 A:middle
So for everyone that's got a
paid app on the store today,

00:10:08.826 --> 00:10:11.106 A:middle
and you want to make the
transition to being a free app

00:10:11.106 --> 00:10:13.836 A:middle
with In-App Purchases,
previously that used

00:10:13.836 --> 00:10:18.126 A:middle
to be quite a challenge for you,
because if you simply switch

00:10:18.126 --> 00:10:19.816 A:middle
to being a free app
with In-App Purchases,

00:10:20.176 --> 00:10:21.336 A:middle
your customers would have to go

00:10:21.336 --> 00:10:23.006 A:middle
and buy all those
In-App Purchases again,

00:10:23.006 --> 00:10:23.986 A:middle
but they've already paid for it,

00:10:24.666 --> 00:10:25.646 A:middle
and they're not going
to like that.

00:10:27.156 --> 00:10:29.976 A:middle
So now in the receipt
itself we have the date,

00:10:29.976 --> 00:10:33.806 A:middle
when the user first purchased
your app, and the version

00:10:33.806 --> 00:10:35.066 A:middle
that it was at that time.

00:10:36.476 --> 00:10:38.646 A:middle
So you can use this to
make a really informed,

00:10:38.826 --> 00:10:42.606 A:middle
intelligent decision about
what features and content

00:10:42.606 --> 00:10:46.066 A:middle
to grant this user into, so if
your app looks at the receipt

00:10:46.066 --> 00:10:49.356 A:middle
and inspects it and sees this
user bought my app before I made

00:10:49.356 --> 00:10:51.126 A:middle
the switch to being free
with In-App Purchases,

00:10:51.776 --> 00:10:53.146 A:middle
grant them into what
they've paid for,

00:10:53.666 --> 00:10:57.646 A:middle
but if they purchased your app
after you've made the transition

00:10:57.646 --> 00:10:58.976 A:middle
to being free with
In-App Purchases,

00:10:59.566 --> 00:11:01.886 A:middle
you know then not too
unlock features and content

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

00:10:59.566 --> 00:11:01.886 A:middle
you know then not too
unlock features and content

00:11:02.256 --> 00:11:05.246 A:middle
until they make the purchase
and you verify that transaction

00:11:05.386 --> 00:11:06.886 A:middle
with the receipt itself.

00:11:08.256 --> 00:11:10.816 A:middle
So understanding the
receipt not only allows you

00:11:10.816 --> 00:11:12.736 A:middle
to protect your revenue
and your digital sales,

00:11:13.666 --> 00:11:16.476 A:middle
but it's also really
powerful for you

00:11:16.476 --> 00:11:19.796 A:middle
to adjust your business model
to suit changes in the market.

00:11:20.346 --> 00:11:25.586 A:middle
Now speaking of transitions,
I want to talk for a second

00:11:25.586 --> 00:11:28.176 A:middle
to iOS developers who are
already doing receipt checking

00:11:28.176 --> 00:11:30.016 A:middle
for In-App Purchases on iOS 6.

00:11:31.056 --> 00:11:33.526 A:middle
For OS X developers and anyone
else that's not doing this

00:11:33.526 --> 00:11:35.466 A:middle
receipt checking, if
you've got a moment,

00:11:35.676 --> 00:11:37.956 A:middle
hit the documentation
slide and have a look

00:11:37.956 --> 00:11:39.386 A:middle
for the receipt validation
guide,

00:11:39.386 --> 00:11:40.646 A:middle
because that's what we're going

00:11:40.646 --> 00:11:41.806 A:middle
to be going through
very shortly.

00:11:42.346 --> 00:11:48.036 A:middle
But for iOS developers who are
already doing receipt checking

00:11:48.386 --> 00:11:52.056 A:middle
on iOS 6 and earlier
-- don't panic.

00:11:53.246 --> 00:11:56.716 A:middle
Your app as it is today in the
store doing receipt checking

00:11:56.976 --> 00:12:00.296 A:middle
on iOS 6 will continue
to work in iOS 7.

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

00:11:56.976 --> 00:12:00.296 A:middle
on iOS 6 will continue
to work in iOS 7.

00:12:00.806 --> 00:12:05.386 A:middle
iOS 7 is binary compatible with
the receipt checking methods

00:12:05.386 --> 00:12:11.466 A:middle
that we shipped in iOS 6, but
those APIs are deprecated.

00:12:12.676 --> 00:12:16.726 A:middle
So you need to make the
jump to using the iOS 7 way

00:12:16.726 --> 00:12:18.346 A:middle
of doing receipt validation,

00:12:19.686 --> 00:12:21.546 A:middle
not just because the
receipts are deprecated,

00:12:21.996 --> 00:12:25.126 A:middle
but because now you can actually
do the receipt validation

00:12:25.126 --> 00:12:26.916 A:middle
entirely on the device itself.

00:12:27.546 --> 00:12:30.016 A:middle
You no longer need to
have a server just there

00:12:30.016 --> 00:12:32.166 A:middle
for the purpose of doing
receipt validation for you.

00:12:33.516 --> 00:12:35.516 A:middle
[ Pause ]

00:12:36.016 --> 00:12:37.000 A:middle
[ Applause ]

00:12:37.336 --> 00:12:37.656 A:middle
Thank you.

00:12:40.226 --> 00:12:44.176 A:middle
But what if you want to have one
binary on the store that works

00:12:44.176 --> 00:12:46.946 A:middle
in iOS 6 and 7, and
takes advantage

00:12:46.946 --> 00:12:48.956 A:middle
of the best possible
receipt checking methods

00:12:48.956 --> 00:12:50.276 A:middle
on both of those platforms?

00:12:51.066 --> 00:12:54.746 A:middle
Well, you can, and the way you
do this is you just Weak Link

00:12:54.746 --> 00:13:00.046 A:middle
to the iOS 7 APIs, and
if I lose any of you

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

00:12:54.746 --> 00:13:00.046 A:middle
to the iOS 7 APIs, and
if I lose any of you

00:13:00.046 --> 00:13:02.916 A:middle
when I said Weak
Linking, it's not nearly

00:13:02.916 --> 00:13:04.396 A:middle
as complicated as it can sound.

00:13:05.566 --> 00:13:07.546 A:middle
Weak Linking simply means check

00:13:07.546 --> 00:13:10.056 A:middle
that the API exists
before you go and use it.

00:13:10.886 --> 00:13:15.016 A:middle
This prevents your app crashing
on a platform where the method

00:13:15.016 --> 00:13:17.746 A:middle
or the API doesn't exist; it
prevents you from crashing

00:13:17.746 --> 00:13:19.966 A:middle
with an unrecognized selector
or an unresolved symbol.

00:13:22.356 --> 00:13:24.656 A:middle
So Weak Linking, first
of all, you run --

00:13:24.786 --> 00:13:26.846 A:middle
you call the Response
to Selector

00:13:27.196 --> 00:13:29.476 A:middle
to see whether a given
object will actually respond

00:13:29.476 --> 00:13:30.016 A:middle
to this method.

00:13:30.016 --> 00:13:32.596 A:middle
In this case I'm calling
App Store Receipt URL to ask

00:13:32.776 --> 00:13:34.916 A:middle
for the location of
the unified receipt.

00:13:35.976 --> 00:13:37.196 A:middle
If that returns true,

00:13:38.066 --> 00:13:41.916 A:middle
then I know that this device I'm
running on supports the new way

00:13:41.916 --> 00:13:43.846 A:middle
of doing receipt checking
with a unified receipt

00:13:43.846 --> 00:13:46.816 A:middle
and I can proceed down
that course, but when I go

00:13:46.816 --> 00:13:50.926 A:middle
to call App Store Receipt
URL, I use Perform Selector.

00:13:51.856 --> 00:13:54.216 A:middle
That way I avoid crashing
with unrecognized selector.

00:13:54.216 --> 00:13:57.336 A:middle
So this is what we mean
when we say Weak Linking,

00:13:57.646 --> 00:13:59.936 A:middle
but do this instead of
checking the system version.

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

00:14:00.816 --> 00:14:03.556 A:middle
This uses the runtime to
know exactly what methods are

00:14:03.556 --> 00:14:05.976 A:middle
available and allows you
to take advantage of those

00:14:06.266 --> 00:14:07.136 A:middle
when they're available.

00:14:07.756 --> 00:14:09.616 A:middle
Much better, much
more future proof

00:14:09.996 --> 00:14:11.126 A:middle
than checking the system version

00:14:11.126 --> 00:14:12.686 A:middle
or making arbitrary
decisions based

00:14:12.686 --> 00:14:17.466 A:middle
on the running version
of the OS.

00:14:17.466 --> 00:14:20.966 A:middle
So now we're going to
delve into some code,

00:14:21.716 --> 00:14:22.886 A:middle
but I'll say this
from the outset.

00:14:24.266 --> 00:14:26.766 A:middle
Some of the code and the
concepts that we're going

00:14:26.766 --> 00:14:30.186 A:middle
to look at now might be a bit
outside your comfort zone,

00:14:31.126 --> 00:14:33.616 A:middle
especially if you're used to
dealing with Objective-C and all

00:14:33.616 --> 00:14:35.696 A:middle
of its wonderful,
developer friendly APIs

00:14:35.696 --> 00:14:39.356 A:middle
and App Kit new iKit,
because to validate receipts,

00:14:39.616 --> 00:14:41.316 A:middle
we're going to delve
into some cryptography,

00:14:42.316 --> 00:14:47.006 A:middle
and also some doddering coding
standards, but let's take it

00:14:47.556 --> 00:14:52.186 A:middle
down to the simple fact;
the receipt is just a file.

00:14:52.756 --> 00:14:56.696 A:middle
It's stored in the app bundle,
we give you an API to get a hold

00:14:56.696 --> 00:15:00.096 A:middle
of it, and it's a single
file that has purchased data

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

00:14:56.696 --> 00:15:00.096 A:middle
of it, and it's a single
file that has purchased data

00:15:00.096 --> 00:15:01.916 A:middle
and signatures to
check authenticity.

00:15:03.446 --> 00:15:05.706 A:middle
Don't let the acronyms and
cryptic function names we are

00:15:05.706 --> 00:15:06.796 A:middle
about to look at fool you.

00:15:07.686 --> 00:15:10.546 A:middle
In essence, all we're doing
here is opening a file,

00:15:10.716 --> 00:15:13.676 A:middle
reading it into memory,
running some functions over it,

00:15:13.726 --> 00:15:16.116 A:middle
calling some methods,
checking the return codes

00:15:16.116 --> 00:15:18.306 A:middle
and comparing values, and that's

00:15:18.306 --> 00:15:19.646 A:middle
within the reach
of any developer.

00:15:19.646 --> 00:15:24.056 A:middle
In fact, what I'm
going to take you

00:15:24.056 --> 00:15:30.266 A:middle
through is a three-step process,
and this is a three-step process

00:15:30.316 --> 00:15:34.596 A:middle
to guarantee your
revenue, protect the value

00:15:34.596 --> 00:15:38.206 A:middle
of your products, and make sure

00:15:38.206 --> 00:15:39.966 A:middle
that you retain your
customer loyalty.

00:15:41.056 --> 00:15:41.726 A:middle
Three steps.

00:15:42.346 --> 00:15:45.586 A:middle
This is the WWDC session
that pays for itself.

00:15:47.276 --> 00:15:48.476 A:middle
So step one.

00:15:49.486 --> 00:15:51.206 A:middle
You verify the signature
of the receipt.

00:15:51.406 --> 00:15:52.846 A:middle
This makes sure it
came from Apple

00:15:52.846 --> 00:15:53.896 A:middle
and it hasn't been altered.

00:15:54.366 --> 00:15:56.906 A:middle
No one's tried to add in
some extra In-App Purchases

00:15:56.906 --> 00:15:58.096 A:middle
that they haven't really made.

00:15:58.816 --> 00:16:01.276 A:middle
No one's tried to doctor up
a receipt that's not really

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

00:15:58.816 --> 00:16:01.276 A:middle
No one's tried to doctor up
a receipt that's not really

00:16:01.276 --> 00:16:02.426 A:middle
for an app that they purchased.

00:16:03.036 --> 00:16:03.816 A:middle
That's step one.

00:16:04.696 --> 00:16:07.556 A:middle
Step two is we confirm
that the receipt is

00:16:07.556 --> 00:16:09.866 A:middle
for your app on a given device.

00:16:10.416 --> 00:16:12.526 A:middle
This makes sure that no
one's just copied the receipt

00:16:12.576 --> 00:16:15.596 A:middle
between devices or has tried
to copy a receipt from one app

00:16:15.686 --> 00:16:17.036 A:middle
to another in hope
that it works.

00:16:18.206 --> 00:16:22.116 A:middle
The third step is that
now we trust the receipt

00:16:22.906 --> 00:16:24.576 A:middle
and we know it's for
our app on this device,

00:16:24.716 --> 00:16:26.466 A:middle
we get the purchase
information up out of it

00:16:26.466 --> 00:16:28.746 A:middle
and we make decisions about
what to give the customer,

00:16:29.076 --> 00:16:30.106 A:middle
because they're, at that point,

00:16:30.306 --> 00:16:31.846 A:middle
we know exactly what
they've paid for.

00:16:32.876 --> 00:16:37.216 A:middle
So let's start with step
one, verifying the signature.

00:16:38.856 --> 00:16:42.016 A:middle
Verifying the signature in
simple terms is, step one,

00:16:42.256 --> 00:16:46.136 A:middle
locate the file, and we
do that with this API here

00:16:46.326 --> 00:16:49.096 A:middle
on NSBundle we call
App Store Receipt URL

00:16:49.096 --> 00:16:51.186 A:middle
and this works in
iOS 7 and OS X.

00:16:52.206 --> 00:16:55.076 A:middle
That gives us a URL to find
the actual receipt file,

00:16:55.836 --> 00:16:58.306 A:middle
and the great thing is is
that the OS manages this

00:16:58.306 --> 00:17:00.336 A:middle
for us on both iOS and OS X.

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

00:16:58.306 --> 00:17:00.336 A:middle
for us on both iOS and OS X.

00:17:00.836 --> 00:17:02.636 A:middle
It keeps the receipt
file there for you.

00:17:02.936 --> 00:17:05.296 A:middle
You don't have to process
the receipt yourself anymore

00:17:05.356 --> 00:17:07.496 A:middle
like you used to.

00:17:08.286 --> 00:17:11.546 A:middle
We read the contents into memory
and we verify the signature.

00:17:12.056 --> 00:17:16.896 A:middle
Here's your first decision
point as a developer.

00:17:17.366 --> 00:17:22.306 A:middle
You need to decide what
you're going to use to verify

00:17:22.306 --> 00:17:25.376 A:middle
that signature, and the
great thing is that if you're

00:17:25.376 --> 00:17:27.236 A:middle
at all familiar with
cryptography standards

00:17:27.236 --> 00:17:31.406 A:middle
and secure exchange of data, the
receipt itself is what we refer

00:17:31.406 --> 00:17:33.506 A:middle
to as a PKCS #7 container.

00:17:33.656 --> 00:17:35.296 A:middle
Like I said, don't let
the acronyms fool you.

00:17:35.296 --> 00:17:36.316 A:middle
This is doable.

00:17:37.096 --> 00:17:40.946 A:middle
It's a PKCS #7 container, which
is an open, industry standard,

00:17:40.986 --> 00:17:45.796 A:middle
cryptographic scheme for
embedding a payload of data

00:17:45.796 --> 00:17:47.026 A:middle
around certificates
and signature

00:17:47.026 --> 00:17:48.996 A:middle
to guarantee its
origin and authenticity.

00:17:50.436 --> 00:17:53.486 A:middle
The good thing is that
because that is such an open

00:17:53.486 --> 00:17:56.836 A:middle
and very widely used standard,
you have a huge amount

00:17:57.356 --> 00:17:59.716 A:middle
of options available
to you in terms

00:17:59.716 --> 00:18:01.736 A:middle
of deciding how you
verify this signature.

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

00:17:59.716 --> 00:18:01.736 A:middle
of deciding how you
verify this signature.

00:18:02.956 --> 00:18:06.626 A:middle
At one end of the extreme,
there are third party libraries

00:18:06.626 --> 00:18:08.896 A:middle
that you can get off the shelf
that are freely available,

00:18:09.466 --> 00:18:11.126 A:middle
put them in your
project, use them,

00:18:11.896 --> 00:18:14.236 A:middle
and they will do the
certificate validation for you.

00:18:15.656 --> 00:18:18.226 A:middle
But at the other end of the
extreme, if the security

00:18:18.226 --> 00:18:21.156 A:middle
that you want for protecting
your sales requires you

00:18:21.156 --> 00:18:23.226 A:middle
to own this code
end-to-end yourself,

00:18:23.946 --> 00:18:25.526 A:middle
then because this
is an open standard

00:18:25.526 --> 00:18:28.156 A:middle
with specifications
available, you can do that.

00:18:28.726 --> 00:18:31.056 A:middle
You could write your own code
to validate this signature

00:18:31.056 --> 00:18:34.076 A:middle
if you wanted, and of course
there's the great middle ground

00:18:34.076 --> 00:18:36.526 A:middle
of there being lots of examples
and sample code out there

00:18:36.896 --> 00:18:40.556 A:middle
that you can use and
leverage to suit your needs.

00:18:41.076 --> 00:18:46.356 A:middle
The example that we provide
in the documentation is

00:18:46.356 --> 00:18:48.556 A:middle
to use Open SSL to
verify the signature.

00:18:49.216 --> 00:18:53.896 A:middle
Open SSL is an extremely well
used cryptographic library.

00:18:53.896 --> 00:18:56.206 A:middle
It's used on many different
operating systems for millions

00:18:56.206 --> 00:18:57.826 A:middle
and millions of secure
operations,

00:18:58.976 --> 00:19:02.086 A:middle
and if we used Open SSL to
do the verification for us,

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

00:18:58.976 --> 00:19:02.086 A:middle
and if we used Open SSL to
do the verification for us,

00:19:02.576 --> 00:19:03.456 A:middle
here's what it would look like.

00:19:04.336 --> 00:19:06.326 A:middle
We assume, first of all,
you've loaded up the receipt

00:19:06.326 --> 00:19:09.026 A:middle
into memory and a copy of
Apple's Root CA Certificate

00:19:09.026 --> 00:19:10.896 A:middle
and you can find that
certificate online,

00:19:11.816 --> 00:19:14.486 A:middle
and we've stored these in two
root variables here, B receipt

00:19:14.556 --> 00:19:18.486 A:middle
and BX 509, X 509 being
the standard that's used

00:19:18.486 --> 00:19:20.176 A:middle
to encode Apple's
Root CA Certificate.

00:19:21.556 --> 00:19:24.196 A:middle
The first thing we do is we
want to take those raw bytes

00:19:24.196 --> 00:19:25.906 A:middle
from the receipt
and convert them

00:19:25.906 --> 00:19:29.396 A:middle
into a PKCS #7 data structure
so that Open SSL can work

00:19:29.396 --> 00:19:32.446 A:middle
with it at a code level.

00:19:32.556 --> 00:19:36.256 A:middle
Next, to verify the signature,
we need to tell Open SSL

00:19:36.646 --> 00:19:39.806 A:middle
who we are actually expecting
to have signed this certificate,

00:19:39.886 --> 00:19:41.676 A:middle
who we're expecting
it to have come from.

00:19:42.836 --> 00:19:44.666 A:middle
So we load up Apple's Root CA

00:19:44.666 --> 00:19:46.736 A:middle
and we create a certificate
store.

00:19:47.386 --> 00:19:48.616 A:middle
We add that certificate in.

00:19:49.976 --> 00:19:51.146 A:middle
With our certificate in hand,

00:19:51.676 --> 00:19:54.266 A:middle
and our PKCS #7 data
structure ready to go,

00:19:55.086 --> 00:19:57.986 A:middle
we simply call PKCS #7 Verify.

00:19:57.986 --> 00:20:00.856 A:middle
We check the result.

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

00:19:57.986 --> 00:20:00.856 A:middle
We check the result.

00:20:01.886 --> 00:20:04.716 A:middle
If result's one, the
receipt is valid.

00:20:05.476 --> 00:20:05.836 A:middle
That's it.

00:20:06.406 --> 00:20:08.366 A:middle
And the great thing is

00:20:08.986 --> 00:20:13.086 A:middle
that calling PKCS #7 Verify also
actually returns back to you

00:20:13.086 --> 00:20:15.076 A:middle
that payload of data
that's inside the receipt,

00:20:15.416 --> 00:20:18.696 A:middle
the actual purchase information
that you want to get a hold

00:20:18.726 --> 00:20:21.266 A:middle
of to make decisions about
what the users purchased.

00:20:24.216 --> 00:20:28.946 A:middle
So right now, we have a receipt
that we know came from Apple

00:20:28.946 --> 00:20:32.846 A:middle
for an App Store Purchased app,
and we know that it's authentic

00:20:32.846 --> 00:20:33.686 A:middle
and hasn't been altered.

00:20:34.676 --> 00:20:37.986 A:middle
The next thing we need to do is
confirm that it is definitely

00:20:37.986 --> 00:20:42.186 A:middle
for our app on this device,
and to do that we need

00:20:42.186 --> 00:20:46.076 A:middle
to actually inspect these raw
bytes of data that we took

00:20:46.076 --> 00:20:48.476 A:middle
out from the receipt
payload itself.

00:20:49.436 --> 00:20:54.686 A:middle
Now that payload of data,
we arrange that in a series

00:20:54.686 --> 00:20:56.466 A:middle
of attributes that have
a Type and a value.

00:20:57.736 --> 00:21:00.276 A:middle
We encode these using a
standard called ASN.1.

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

00:20:57.736 --> 00:21:00.276 A:middle
We encode these using a
standard called ASN.1.

00:21:01.286 --> 00:21:04.066 A:middle
ASN.1 again, I know I sound like
I'm repeating myself, but again,

00:21:04.066 --> 00:21:07.386 A:middle
is a very widely used open
and industry-standard,

00:21:07.826 --> 00:21:12.106 A:middle
and it's been round for a long,
long time, and that's great

00:21:12.336 --> 00:21:15.236 A:middle
because that means that there
is a wealth of options available

00:21:15.236 --> 00:21:19.386 A:middle
for you for how to read
that doddering ASN.1 format.

00:21:20.386 --> 00:21:23.726 A:middle
ASN.1 is the abstract
syntax notation.

00:21:24.846 --> 00:21:28.346 A:middle
It allows us to write in
a textual form like this,

00:21:29.196 --> 00:21:32.876 A:middle
a description of how we've laid
out the actual bytes contained

00:21:32.876 --> 00:21:35.666 A:middle
within the receipt,
and what this body

00:21:35.666 --> 00:21:38.976 A:middle
of text here tells you is that
we have arranged those bytes

00:21:38.976 --> 00:21:41.586 A:middle
in the receipt as a
sequence of attributes.

00:21:42.896 --> 00:21:47.046 A:middle
In a cocoa sense, it would be
kind of like having NSArray full

00:21:47.076 --> 00:21:49.266 A:middle
of NSObject sub-classes
that we've created

00:21:49.766 --> 00:21:51.786 A:middle
that have a type property
and a value property.

00:21:53.556 --> 00:21:56.156 A:middle
That's essentially what we've
defined here with this block

00:21:56.156 --> 00:22:01.346 A:middle
of ASN.1, and here's your second
decision point as a developer.

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

00:21:56.156 --> 00:22:01.346 A:middle
of ASN.1, and here's your second
decision point as a developer.

00:22:02.366 --> 00:22:05.216 A:middle
You need to decide what
you're going to use to read

00:22:05.216 --> 00:22:07.966 A:middle
that ASN.1 encoded
data at the code level.

00:22:10.376 --> 00:22:13.886 A:middle
Now documentation that we've
had on the developer site

00:22:14.266 --> 00:22:17.386 A:middle
since we debuted the Mac App
Store has included an example

00:22:17.386 --> 00:22:19.556 A:middle
of using a third-party
tool called ASN1c.

00:22:21.476 --> 00:22:24.596 A:middle
ASN1c is a third-party
tool that allows you

00:22:24.596 --> 00:22:27.246 A:middle
to essentially take this textual
representation of the data

00:22:27.976 --> 00:22:30.776 A:middle
and ASN1c creates for you
a bunch of boilerplate code

00:22:30.776 --> 00:22:33.566 A:middle
that you can copy straight
into your project, build it,

00:22:34.226 --> 00:22:36.666 A:middle
and it gives you some
functions and data structures

00:22:36.666 --> 00:22:39.566 A:middle
that you can use to actually
work with these attributes

00:22:39.636 --> 00:22:40.436 A:middle
that are in the receipt,

00:22:40.606 --> 00:22:42.376 A:middle
the actual purchase
information you want.

00:22:43.906 --> 00:22:46.536 A:middle
Another option you
could use is Open SSL.

00:22:46.856 --> 00:22:49.986 A:middle
It can also open read ASN.1
coded data, and again,

00:22:49.986 --> 00:22:52.676 A:middle
it's this wide range of
options you've got available,

00:22:53.616 --> 00:22:56.336 A:middle
from the extreme of taking
a library that already exist

00:22:56.996 --> 00:22:58.626 A:middle
to the extreme of
writing it yourself,

00:22:59.426 --> 00:23:01.426 A:middle
and all the middle
ground of finding examples

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

00:22:59.426 --> 00:23:01.426 A:middle
and all the middle
ground of finding examples

00:23:01.426 --> 00:23:02.636 A:middle
and making informed decisions

00:23:02.636 --> 00:23:04.446 A:middle
about exactly how you
want to do this yourself.

00:23:05.886 --> 00:23:08.696 A:middle
Just remember it's a risk and
reward calculation for you.

00:23:09.776 --> 00:23:12.236 A:middle
At this end of the spectrum of
taking a third-party library

00:23:12.236 --> 00:23:14.786 A:middle
and using it, the
reward is obviously rapid

00:23:14.786 --> 00:23:15.596 A:middle
development time.

00:23:15.596 --> 00:23:17.316 A:middle
You can get this up and
running really quickly.

00:23:17.936 --> 00:23:20.826 A:middle
The risk is when you take
someone else's library

00:23:20.826 --> 00:23:22.716 A:middle
and use it, you get
their bugs, as well.

00:23:24.736 --> 00:23:28.086 A:middle
The middle ground of finding
some examples to guide you,

00:23:28.086 --> 00:23:30.966 A:middle
of finding some samples that
are out there and using some

00:23:30.966 --> 00:23:33.546 A:middle
of that code, may be
a good middle ground

00:23:33.546 --> 00:23:36.526 A:middle
if that's the level of security
you want, and at the other end

00:23:36.526 --> 00:23:39.176 A:middle
of the extreme, if your
products are so high value

00:23:39.716 --> 00:23:42.476 A:middle
that you absolutely have to
own this yourself end-to-end,

00:23:43.596 --> 00:23:46.066 A:middle
the ASN.1 specifications
are available for you,

00:23:46.156 --> 00:23:47.846 A:middle
you could write your
own parser if you want.

00:23:48.296 --> 00:23:51.716 A:middle
Here's how it would
look if we used ASN1c.

00:23:51.816 --> 00:23:55.656 A:middle
The first one I'm trying
to call there, BRD Coder,

00:23:57.216 --> 00:24:00.326 A:middle
takes in my receipt bytes
itself, the actual payload

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

00:23:57.216 --> 00:24:00.326 A:middle
takes in my receipt bytes
itself, the actual payload

00:24:00.326 --> 00:24:03.456 A:middle
of data we got, and it gives
me a data structure back

00:24:03.506 --> 00:24:06.766 A:middle
that I can use to set up a
full loop and iterate over each

00:24:06.766 --> 00:24:08.166 A:middle
of these attributes
in the receipt.

00:24:09.906 --> 00:24:13.426 A:middle
Whether you use ASN1c,
Open SSL, or roll your own,

00:24:13.896 --> 00:24:16.536 A:middle
you're generally going to end
up in some sort of full loop

00:24:16.566 --> 00:24:19.426 A:middle
to iterate over these
attributes in the receipt,

00:24:19.936 --> 00:24:24.256 A:middle
just like with an NSArray, you'd
use 4 ID Object NArray and have

00:24:24.256 --> 00:24:26.236 A:middle
that loop ready to
iterate over these things.

00:24:26.786 --> 00:24:31.246 A:middle
So getting back to
validating that the receipts

00:24:31.246 --> 00:24:32.636 A:middle
for our app on this device.

00:24:34.236 --> 00:24:38.086 A:middle
There's four attributes that
we are particularly interested

00:24:38.086 --> 00:24:39.086 A:middle
in here.

00:24:39.676 --> 00:24:41.466 A:middle
Let's go with the first
part of this equation,

00:24:41.926 --> 00:24:45.286 A:middle
that the receipt is for
your app on this device.

00:24:46.566 --> 00:24:48.396 A:middle
To know it's for your
app, you want to look

00:24:48.396 --> 00:24:51.256 A:middle
at attributes Type 2 and
3, so in that full loop,

00:24:51.256 --> 00:24:52.686 A:middle
when I'm looping
over the attributes,

00:24:53.056 --> 00:24:56.816 A:middle
checking the actual attribute
type, we'd look for Type 2

00:24:56.876 --> 00:24:58.626 A:middle
and we'd know that that's
the bundle identifier.

00:24:59.746 --> 00:25:02.056 A:middle
We'd look for Type 3 and know
that it's the bundle version.

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

00:24:59.746 --> 00:25:02.056 A:middle
We'd look for Type 3 and know
that it's the bundle version.

00:25:02.856 --> 00:25:05.746 A:middle
We can take these and compare
these to the running app.

00:25:05.746 --> 00:25:07.866 A:middle
If they match, the
receipt's for your app

00:25:07.866 --> 00:25:08.956 A:middle
and this version of your app.

00:25:10.066 --> 00:25:11.036 A:middle
You might not want to check it

00:25:11.036 --> 00:25:12.296 A:middle
against the info
paylist, though.

00:25:13.666 --> 00:25:15.976 A:middle
That's all too easy for
someone to edit the info paylist

00:25:16.116 --> 00:25:18.646 A:middle
and have it match the receipt
that they want you to validate,

00:25:18.986 --> 00:25:21.586 A:middle
so you might want to hardcode
these values into your app.

00:25:22.296 --> 00:25:26.536 A:middle
The second part of the
equation is we now know it's

00:25:26.536 --> 00:25:30.656 A:middle
for your app, but is it for
your app on this device only?

00:25:32.046 --> 00:25:36.016 A:middle
Now the way we do that
is we need three pieces

00:25:36.016 --> 00:25:36.726 A:middle
of information.

00:25:37.936 --> 00:25:41.226 A:middle
Firstly, we need the
unique identifier

00:25:41.226 --> 00:25:42.546 A:middle
for the device that
it's running on.

00:25:42.886 --> 00:25:45.746 A:middle
If you're on an iOS device,
that's your identifier

00:25:45.746 --> 00:25:48.096 A:middle
for vendor that you
find from UI device.

00:25:48.636 --> 00:25:51.626 A:middle
If you're on OS X, that's
the machine's globally unique

00:25:51.626 --> 00:25:55.156 A:middle
identifier, or GUID, and
there's a sample code available

00:25:55.156 --> 00:25:56.436 A:middle
on the documentation site

00:25:56.436 --> 00:25:58.466 A:middle
that shows you exactly
how to derive that GUID.

00:25:59.306 --> 00:26:00.946 A:middle
So that's the first
bit of information.

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

00:25:59.306 --> 00:26:00.946 A:middle
So that's the first
bit of information.

00:26:01.406 --> 00:26:05.576 A:middle
A sequence of bytes that
uniquely identifies this device

00:26:05.636 --> 00:26:06.256 A:middle
that you're running on.

00:26:06.846 --> 00:26:10.026 A:middle
The second piece of information
we need is your bundle

00:26:10.026 --> 00:26:11.926 A:middle
identifier, because
it's for your app.

00:26:12.426 --> 00:26:13.926 A:middle
So we take these
bytes and memory

00:26:13.926 --> 00:26:15.966 A:middle
that uniquely identified
the device,

00:26:16.326 --> 00:26:20.266 A:middle
concatenate on the string of
bytes that represent your app,

00:26:20.446 --> 00:26:21.416 A:middle
the bundle identifier.

00:26:22.846 --> 00:26:27.096 A:middle
Then we take these attribute
Type 4, the opaque value.

00:26:27.826 --> 00:26:29.556 A:middle
It's just a series of bytes.

00:26:30.946 --> 00:26:33.506 A:middle
Append those series of bytes
onto this long string of bytes

00:26:33.506 --> 00:26:35.906 A:middle
that you're forming in
memory, device identifier,

00:26:36.306 --> 00:26:38.456 A:middle
bundle identifier, opaque value.

00:26:39.616 --> 00:26:41.246 A:middle
When you've got this
long string of bytes,

00:26:41.766 --> 00:26:43.656 A:middle
you create an SHA-1
hash of those,

00:26:43.916 --> 00:26:47.156 A:middle
which gives you a 20 byte hash
of this long string of bytes.

00:26:47.786 --> 00:26:48.776 A:middle
Creating a hash is easy.

00:26:48.776 --> 00:26:51.136 A:middle
You can use common crypto;
you could use Open SSL,

00:26:51.226 --> 00:26:53.996 A:middle
whatever you want to do.

00:26:54.246 --> 00:26:58.086 A:middle
If you compare that hash to the
value here in attribute Type 5

00:26:58.086 --> 00:27:01.256 A:middle
and it matches, you've
successfully confirmed it's

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

00:26:58.086 --> 00:27:01.256 A:middle
and it matches, you've
successfully confirmed it's

00:27:01.256 --> 00:27:03.436 A:middle
for your app on this device.

00:27:04.866 --> 00:27:05.756 A:middle
Now how does that work?

00:27:06.736 --> 00:27:10.076 A:middle
How does that convoluted set
of steps there actually confirm

00:27:10.186 --> 00:27:12.096 A:middle
that it's for your
app on this device?

00:27:12.906 --> 00:27:15.596 A:middle
Well, the reason is --
well the way it works,

00:27:16.156 --> 00:27:17.936 A:middle
is that at the time
of the transaction,

00:27:18.206 --> 00:27:20.686 A:middle
the result in this receipt
being issued by the store,

00:27:21.176 --> 00:27:22.806 A:middle
we did the exact
same calculation.

00:27:23.936 --> 00:27:25.886 A:middle
When an In-App Purchase
was made, for example,

00:27:26.576 --> 00:27:29.356 A:middle
we took the identifier of the
device making the purchase,

00:27:29.536 --> 00:27:31.556 A:middle
the bundle identifier of
the app making the purchase,

00:27:31.906 --> 00:27:35.266 A:middle
[inaudible] opaque value,
hashed it, put it in the receipt

00:27:35.266 --> 00:27:37.546 A:middle
as attribute Type 5,
and then signed it

00:27:37.596 --> 00:27:38.866 A:middle
and shipped the receipt to you.

00:27:39.436 --> 00:27:43.426 A:middle
So if your calculation of
runtime matches our calculation

00:27:43.426 --> 00:27:47.286 A:middle
of the time of purchase, it's
for your app on this device.

00:27:48.836 --> 00:27:52.206 A:middle
But now we can get into the
really interesting end of this

00:27:52.206 --> 00:27:57.336 A:middle
which is what did
they actually pay for?

00:27:57.546 --> 00:28:00.846 A:middle
When you're iterating over those
attributes within the receipt

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

00:27:57.546 --> 00:28:00.846 A:middle
When you're iterating over those
attributes within the receipt

00:28:00.916 --> 00:28:02.776 A:middle
and you've got those
Type 2, three, four,

00:28:02.776 --> 00:28:03.906 A:middle
and five attributes out,

00:28:04.596 --> 00:28:07.306 A:middle
if you're offering In-App
Purchases, you're also going

00:28:07.306 --> 00:28:10.446 A:middle
to see one or more
Type 17 attributes.

00:28:11.086 --> 00:28:13.256 A:middle
Now the Type 17 attribute,

00:28:13.886 --> 00:28:16.826 A:middle
the value of that is actually
a nested set of attributes

00:28:17.176 --> 00:28:19.846 A:middle
that tells you about an In-App
Purchase that has been made,

00:28:20.866 --> 00:28:25.046 A:middle
so which of these Type 17
attributes contains an attribute

00:28:25.166 --> 00:28:28.676 A:middle
-- a nested attribute in there,
these Type 17 01, 02, 03, 04,

00:28:29.506 --> 00:28:31.836 A:middle
that tell you the quantity
and the product identifier

00:28:31.836 --> 00:28:34.906 A:middle
of what was purchased?

00:28:35.036 --> 00:28:38.526 A:middle
And again we give you the
ASN.1 textual representation

00:28:38.526 --> 00:28:39.826 A:middle
of how we've encoded this data

00:28:40.406 --> 00:28:41.846 A:middle
so you've got the same
options available.

00:28:41.846 --> 00:28:45.156 A:middle
You could use Open SSL to read
this, ASN.1 to generate code

00:28:45.156 --> 00:28:48.336 A:middle
to read it, write your own,
whatever suits the value

00:28:48.336 --> 00:28:51.266 A:middle
of your products and the
level of security you want.

00:28:53.856 --> 00:28:56.826 A:middle
So let's recap some of the
key technologies we've just

00:28:56.826 --> 00:28:57.946 A:middle
talked about.

00:28:59.856 --> 00:29:02.916 A:middle
Firstly, it's a PKCS
#7 container.

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

00:28:59.856 --> 00:29:02.916 A:middle
Firstly, it's a PKCS
#7 container.

00:29:03.606 --> 00:29:06.316 A:middle
I guarantee if you Google
for that, you'll be amazed

00:29:06.316 --> 00:29:09.326 A:middle
at the wealth of information
that's out there to find out how

00:29:09.326 --> 00:29:11.996 A:middle
to read those, verify them,
and validate the signature.

00:29:12.766 --> 00:29:15.196 A:middle
This is not something unique
to the App Store receipt.

00:29:15.596 --> 00:29:18.036 A:middle
It's done in millions
of different ways.

00:29:18.576 --> 00:29:22.116 A:middle
You could get Open SSL to
do it if you wanted to,

00:29:22.596 --> 00:29:23.436 A:middle
you could roll your own,

00:29:23.436 --> 00:29:25.366 A:middle
or use any other option
that's available to you.

00:29:25.366 --> 00:29:26.086 A:middle
It's up to you.

00:29:26.196 --> 00:29:27.276 A:middle
You decide the complexity.

00:29:27.816 --> 00:29:31.856 A:middle
And the actual data itself
is encoded using ASN.1,

00:29:32.506 --> 00:29:33.666 A:middle
and again the same applies.

00:29:33.836 --> 00:29:40.106 A:middle
Lots of options available to
decide how to read that data.

00:29:40.286 --> 00:29:43.426 A:middle
Now those of you that are really
in the know might be thinking

00:29:43.426 --> 00:29:45.306 A:middle
to yourself this guy doesn't
know what he's talking about.

00:29:46.116 --> 00:29:50.246 A:middle
Open SSL doesn't exist on iOS,
and if I link to it on OS X,

00:29:50.466 --> 00:29:52.006 A:middle
I get a billion and
one compile errors.

00:29:52.526 --> 00:29:58.346 A:middle
You got me, but there's
a good reason for that,

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

00:30:00.286 --> 00:30:02.906 A:middle
because if you're using a
dynamically linked library

00:30:04.346 --> 00:30:05.536 A:middle
on the device that
you're running

00:30:05.536 --> 00:30:09.046 A:middle
on to verify your signature and
get your purchase information,

00:30:09.946 --> 00:30:11.566 A:middle
imagine how easy it
would be for someone

00:30:11.566 --> 00:30:14.546 A:middle
with less honorable intents to
swap that library out with one

00:30:14.546 --> 00:30:15.586 A:middle
that said everything is good.

00:30:17.456 --> 00:30:20.816 A:middle
So make sure all the
code that you are using

00:30:21.146 --> 00:30:22.286 A:middle
to validate your receipts

00:30:22.286 --> 00:30:25.836 A:middle
and get this purchase
information is linked statically

00:30:26.126 --> 00:30:27.556 A:middle
into your binary
you're submitting.

00:30:28.206 --> 00:30:31.086 A:middle
That way you are certain
that the code that's going

00:30:31.086 --> 00:30:33.486 A:middle
to confirm this,
protect your revenues,

00:30:33.836 --> 00:30:36.976 A:middle
protect your digital sales,
is the code you intended

00:30:37.636 --> 00:30:39.536 A:middle
and hasn't been messed with.

00:30:41.756 --> 00:30:43.316 A:middle
Now everything we
talked about there is

00:30:43.316 --> 00:30:46.056 A:middle
about validating the
receipt on the device itself,

00:30:46.906 --> 00:30:49.246 A:middle
which is great now that
you can do that in iOS 7

00:30:49.476 --> 00:30:50.816 A:middle
with the unified receipt format.

00:30:51.366 --> 00:30:55.966 A:middle
A lot of you are going
to have servers out there

00:30:56.636 --> 00:31:00.136 A:middle
that issue these -- these,
you know, Game Levels, assets,

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

00:30:56.636 --> 00:31:00.136 A:middle
that issue these -- these,
you know, Game Levels, assets,

00:31:00.306 --> 00:31:03.576 A:middle
contents, periodicals,
whatever it might be,

00:31:04.226 --> 00:31:06.746 A:middle
and you don't want those servers
to just be handing those assets

00:31:06.746 --> 00:31:08.166 A:middle
out to anyone that
asks for them right?

00:31:09.316 --> 00:31:11.176 A:middle
Your servers need to
be able to validate

00:31:11.176 --> 00:31:13.976 A:middle
that these purchases
are real and authentic

00:31:14.536 --> 00:31:16.216 A:middle
and that the user
really has paid for it

00:31:16.216 --> 00:31:18.416 A:middle
to make sure you
get paid for it.

00:31:19.216 --> 00:31:20.266 A:middle
So Apple provides you

00:31:20.266 --> 00:31:23.716 A:middle
with a server-to-server
online validation service.

00:31:24.686 --> 00:31:25.656 A:middle
Here's how this works.

00:31:26.806 --> 00:31:30.036 A:middle
Your app on the device
gets the receipt.

00:31:30.196 --> 00:31:32.776 A:middle
Your app sends the
receipt up to Apple --

00:31:32.776 --> 00:31:36.086 A:middle
sorry, up to, your app sends
the receipt up to your server,

00:31:36.086 --> 00:31:40.326 A:middle
and it would usually do that as
part of the request for a piece

00:31:40.326 --> 00:31:42.226 A:middle
of content or an
asset, so for example,

00:31:42.226 --> 00:31:43.766 A:middle
if they've just bought
Game Level 5,

00:31:44.256 --> 00:31:46.116 A:middle
your app would just make
a request to your servers

00:31:46.116 --> 00:31:47.596 A:middle
and say "Hey, give
me Game Level 5,"

00:31:48.286 --> 00:31:50.556 A:middle
and it would include the
receipt in that request.

00:31:51.736 --> 00:31:54.636 A:middle
Then your server can take
that receipt and send it

00:31:54.636 --> 00:31:56.086 A:middle
to Apple's validation service.

00:31:56.956 --> 00:31:58.126 A:middle
We crack open the receipt,

00:31:58.306 --> 00:32:00.416 A:middle
confirm that the receipt
is authentic and unaltered,

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

00:31:58.306 --> 00:32:00.416 A:middle
confirm that the receipt
is authentic and unaltered,

00:32:01.126 --> 00:32:04.536 A:middle
and we return back to you a
JSON code, coded block of data,

00:32:04.536 --> 00:32:06.536 A:middle
that describes the
purchase that was made,

00:32:07.556 --> 00:32:10.256 A:middle
and because that's returned
in JSON, it's really easy

00:32:10.256 --> 00:32:11.336 A:middle
for your service to pause it,

00:32:11.336 --> 00:32:17.876 A:middle
no matter what platform you're
running on, but this is only

00:32:17.876 --> 00:32:21.046 A:middle
to be used for your server
to talk to our server

00:32:21.046 --> 00:32:21.986 A:middle
to validate the receipt.

00:32:23.706 --> 00:32:26.496 A:middle
It's not to be used for
your app to talk directly

00:32:26.496 --> 00:32:27.896 A:middle
to the validation service.

00:32:28.386 --> 00:32:32.186 A:middle
So if you're doing that today,
you really need to stop,

00:32:33.086 --> 00:32:35.936 A:middle
because you can now validate the
receipt on the device in itself.

00:32:36.296 --> 00:32:39.806 A:middle
And another thing
that's important to note

00:32:39.846 --> 00:32:43.706 A:middle
about the online validation
service is it can only do two

00:32:43.706 --> 00:32:45.436 A:middle
of those three steps
that we just looked at.

00:32:45.976 --> 00:32:50.206 A:middle
It can validate that the receipt
is authentic and unaltered,

00:32:50.206 --> 00:32:53.586 A:middle
and it can return back to
you the purchase information,

00:32:54.536 --> 00:32:57.476 A:middle
but it doesn't confirm that
the receipt was intended

00:32:57.476 --> 00:32:59.526 A:middle
for your app on a given device.

00:32:59.886 --> 00:33:01.776 A:middle
You still want to do
that at the device level.

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

00:32:59.886 --> 00:33:01.776 A:middle
You still want to do
that at the device level.

00:33:06.836 --> 00:33:10.316 A:middle
So now let's look at some
platform specific implementation

00:33:10.316 --> 00:33:12.106 A:middle
details about how we
validate the receipts.

00:33:12.606 --> 00:33:18.456 A:middle
Let's start with iOS 7.

00:33:18.626 --> 00:33:21.986 A:middle
On iOS, when your
app 4 first launches,

00:33:22.516 --> 00:33:25.076 A:middle
you want to validate the
receipt as soon as possible,

00:33:25.626 --> 00:33:27.036 A:middle
and I mean way before you get

00:33:27.036 --> 00:33:28.646 A:middle
to application did
finish launching,

00:33:28.936 --> 00:33:31.646 A:middle
in fact way before you get
anywhere near UI application

00:33:31.646 --> 00:33:32.476 A:middle
or the main run loop.

00:33:33.306 --> 00:33:34.566 A:middle
Do this in the main function.

00:33:35.116 --> 00:33:36.946 A:middle
Do this before anything else.

00:33:37.896 --> 00:33:39.936 A:middle
Check that the receipt
exists and validate it.

00:33:40.696 --> 00:33:42.716 A:middle
Now if it doesn't exist or
it appears to be invalid

00:33:42.716 --> 00:33:44.156 A:middle
on that device, and
that can happen,

00:33:45.426 --> 00:33:46.886 A:middle
refresh it using Store Kit.

00:33:47.876 --> 00:33:50.596 A:middle
Store Kit now has the SK
Receipt Refresh Request,

00:33:51.976 --> 00:33:53.866 A:middle
which you can use to get
yourself a new receipt

00:33:53.866 --> 00:33:55.336 A:middle
to do your receipt validation,

00:33:56.756 --> 00:33:59.016 A:middle
but you don't always
need the latest

00:33:59.016 --> 00:34:00.186 A:middle
and most up-to-date receipt.

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

00:33:59.016 --> 00:34:00.186 A:middle
and most up-to-date receipt.

00:34:00.696 --> 00:34:04.996 A:middle
Use what's there first,
because as soon as you start one

00:34:04.996 --> 00:34:06.716 A:middle
of these SK Receipt
Refresh Requests,

00:34:07.436 --> 00:34:08.676 A:middle
the first thing the
user is going

00:34:08.676 --> 00:34:10.985 A:middle
to see is an authentication
prompt to sign

00:34:10.985 --> 00:34:14.005 A:middle
into the App Store, and
it's not acceptable to do

00:34:14.005 --> 00:34:16.886 A:middle
that on every launch, so only
do it if the receipt is missing

00:34:16.916 --> 00:34:18.025 A:middle
or appears to be invalid,

00:34:19.295 --> 00:34:21.116 A:middle
and this will require
a network connection.

00:34:21.746 --> 00:34:24.386 A:middle
So just keep that in mind when
you're working out how stringent

00:34:24.386 --> 00:34:27.426 A:middle
to be, and how secure your
business model enforcement is,

00:34:28.326 --> 00:34:30.246 A:middle
that if the device doesn't
have a network connection,

00:34:30.295 --> 00:34:31.596 A:middle
it won't be able
to get a receipt.

00:34:31.596 --> 00:34:37.156 A:middle
Now OS X is a little different.

00:34:37.216 --> 00:34:41.716 A:middle
On OS X, for an App
Store purchased app,

00:34:41.716 --> 00:34:43.166 A:middle
the receipt will
always be there.

00:34:43.346 --> 00:34:45.376 A:middle
The only time you wouldn't
see a receipt on OS X is

00:34:45.376 --> 00:34:48.466 A:middle
when you're developing the app
and you run it and you need

00:34:48.466 --> 00:34:49.616 A:middle
to get a receipt to test with,

00:34:50.266 --> 00:34:52.936 A:middle
and the receipt should always
be there, but if it appears

00:34:52.936 --> 00:34:56.065 A:middle
to be invalid, as in it's
perhaps not for this device,

00:34:56.436 --> 00:34:58.706 A:middle
which could happen if apps
are migrated from one machine

00:34:58.706 --> 00:35:03.286 A:middle
to another, then your app
exists with a Code 173.

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

00:34:58.706 --> 00:35:03.286 A:middle
to another, then your app
exists with a Code 173.

00:35:03.836 --> 00:35:07.666 A:middle
This special Exit Code
tells OS X in the App Store

00:35:07.716 --> 00:35:10.746 A:middle
that you believe your receipt's
invalid and you want a new one.

00:35:12.086 --> 00:35:14.006 A:middle
Again, the first thing
that your user is going

00:35:14.006 --> 00:35:16.816 A:middle
to see here is a prompt to
sign into the App Store,

00:35:16.896 --> 00:35:20.226 A:middle
even if they're already signed
in, so definitely don't do this

00:35:20.226 --> 00:35:22.336 A:middle
on every launch, only do
it if the receipt appears

00:35:22.336 --> 00:35:24.886 A:middle
to be invalid, and again,

00:35:25.196 --> 00:35:26.766 A:middle
network connection
will be required.

00:35:30.916 --> 00:35:34.326 A:middle
Now for everyone doing In-App
Purchases, whether it's on iOS

00:35:35.006 --> 00:35:38.636 A:middle
or OS X, because now OS X
supports subscription In-App

00:35:38.686 --> 00:35:43.186 A:middle
Purchases as well, there are
some differences in the type

00:35:43.236 --> 00:35:46.086 A:middle
of In-App Purchases
that are offered insofar

00:35:46.086 --> 00:35:47.776 A:middle
as how they're represented
in the receipt,

00:35:47.776 --> 00:35:49.666 A:middle
especially over the
lifecycle of the receipt.

00:35:51.066 --> 00:35:53.906 A:middle
Consumables and non-renewing
subscriptions.

00:35:54.996 --> 00:35:56.486 A:middle
They're a one-off
purchase, right?

00:35:57.386 --> 00:35:59.896 A:middle
So if you've got a racing car
game, you might offer the user

00:35:59.896 --> 00:36:02.866 A:middle
to purchase 500 gallons of gas
through an In-App Purchase.

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

00:35:59.896 --> 00:36:02.866 A:middle
to purchase 500 gallons of gas
through an In-App Purchase.

00:36:03.806 --> 00:36:07.166 A:middle
You would expect that that 500
gallons of gas is used once,

00:36:07.766 --> 00:36:09.946 A:middle
only on that device, and
once it's done, it's gone.

00:36:10.556 --> 00:36:12.816 A:middle
You can't restore
transactions and get 500 gallons

00:36:12.816 --> 00:36:16.056 A:middle
of gas back each time, nor would
you expect to have 500 gallons

00:36:16.056 --> 00:36:19.136 A:middle
of gas on your iPad and
then magically another 500

00:36:19.166 --> 00:36:22.476 A:middle
on your iPhone and whatever
other devices you might have.

00:36:22.936 --> 00:36:24.616 A:middle
So these are one-time purchases.

00:36:24.616 --> 00:36:28.056 A:middle
Once they're used, they go on.

00:36:28.276 --> 00:36:32.106 A:middle
Likewise in the receipt,
you'll only ever see a record

00:36:32.106 --> 00:36:35.306 A:middle
of a consumable or a
non-renewing subscription once,

00:36:35.956 --> 00:36:38.376 A:middle
and you'll only see it in
the receipt that's issued

00:36:38.456 --> 00:36:40.256 A:middle
at the time of that transaction,

00:36:40.256 --> 00:36:42.046 A:middle
at the time they
make that purchase.

00:36:43.346 --> 00:36:46.546 A:middle
It won't be present in receipts
that are issued in the future,

00:36:46.706 --> 00:36:48.566 A:middle
so if the user then
makes another purchase,

00:36:49.196 --> 00:36:51.486 A:middle
that consumable that they
bought before won't be in there.

00:36:52.676 --> 00:36:54.546 A:middle
If they restore transactions,
that consumable,

00:36:54.546 --> 00:36:57.636 A:middle
it won't be in there, so you
get one chance to see it,

00:36:57.866 --> 00:36:58.996 A:middle
one chance to validate it,

00:36:58.996 --> 00:37:01.466 A:middle
and then set whatever
state you need.

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

00:36:58.996 --> 00:37:01.466 A:middle
and then set whatever
state you need.

00:37:02.966 --> 00:37:04.366 A:middle
Now non-consumables

00:37:04.366 --> 00:37:06.876 A:middle
and auto-renewable subscriptions
are the exact opposite

00:37:07.186 --> 00:37:09.436 A:middle
because these are permanent
purchases that are designed

00:37:09.436 --> 00:37:13.246 A:middle
to persist across devices,
so if I bought Game Level 5,

00:37:14.026 --> 00:37:17.476 A:middle
but I then get a new iPhone,
and I restore my transactions

00:37:17.826 --> 00:37:19.756 A:middle
or I restore transactions
on another device,

00:37:19.856 --> 00:37:22.436 A:middle
I expect that Game Level 5 is
there ready for me to play.

00:37:24.216 --> 00:37:26.146 A:middle
Likewise, with auto-renewable
subscriptions.

00:37:26.146 --> 00:37:28.416 A:middle
If I subscribe on one device,
I want to be able to use

00:37:28.416 --> 00:37:29.666 A:middle
that subscription on others.

00:37:30.736 --> 00:37:32.056 A:middle
So these non-consumables

00:37:32.056 --> 00:37:35.116 A:middle
and auto-renewable subscriptions
are always in the receipt,

00:37:36.376 --> 00:37:39.186 A:middle
and they can be restored
using the Store Kit API

00:37:39.426 --> 00:37:41.066 A:middle
to restore completed
transactions.

00:37:41.146 --> 00:37:45.626 A:middle
So keep that in mind when you're
deciding how you persist state

00:37:45.696 --> 00:37:47.456 A:middle
based on In-App Purchases
that have been made.

00:37:48.156 --> 00:37:50.316 A:middle
Consumables, non-renewing
subscriptions,

00:37:50.796 --> 00:37:51.816 A:middle
only in there once.

00:37:52.306 --> 00:37:56.266 A:middle
One shot. Non-consumables and
auto-renewable subscriptions,

00:37:56.926 --> 00:37:57.796 A:middle
always in the receipt.

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

00:38:03.156 --> 00:38:07.666 A:middle
But what happens if, even after
you've requested a new receipt,

00:38:08.236 --> 00:38:09.586 A:middle
it still appears to be invalid?

00:38:10.666 --> 00:38:12.936 A:middle
Your app launched, you
did the receipt checking,

00:38:13.186 --> 00:38:15.496 A:middle
it didn't look right,
you requested a new one,

00:38:15.946 --> 00:38:18.826 A:middle
checked it again, it
still didn't look right.

00:38:20.176 --> 00:38:22.566 A:middle
This doesn't mean necessarily

00:38:23.036 --> 00:38:25.746 A:middle
that something evil
is happening.

00:38:25.906 --> 00:38:27.626 A:middle
There might be reasons
why this is happening,

00:38:29.226 --> 00:38:30.336 A:middle
and you should make sure

00:38:30.336 --> 00:38:33.216 A:middle
that whatever user experience
you implement here, particularly

00:38:33.216 --> 00:38:37.536 A:middle
on iOS, is tasteful and suits
the value of your products,

00:38:38.086 --> 00:38:42.816 A:middle
and I say iOS in particular
because on iOS, apps can't quit.

00:38:43.326 --> 00:38:44.926 A:middle
There's no way to quit your app.

00:38:45.166 --> 00:38:45.936 A:middle
It keeps running.

00:38:46.906 --> 00:38:49.776 A:middle
So if the receipt appears to be
invalid and you've determined

00:38:49.776 --> 00:38:52.106 A:middle
that this user is not
eligible to use your app,

00:38:52.106 --> 00:38:54.596 A:middle
or the In-App Purchases that
they think they have based

00:38:54.596 --> 00:38:57.246 A:middle
on the receipt, then
it's up to you

00:38:57.246 --> 00:38:58.826 A:middle
to design that user experience.

00:38:59.216 --> 00:39:00.926 A:middle
You might decide to
make the app read only,

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

00:38:59.216 --> 00:39:00.926 A:middle
You might decide to
make the app read only,

00:39:01.126 --> 00:39:03.456 A:middle
block parts of the UI,
whatever you want to do,

00:39:04.126 --> 00:39:05.456 A:middle
but please make sure
it's tasteful

00:39:05.456 --> 00:39:07.476 A:middle
and make sure it respects
the value of your products

00:39:07.476 --> 00:39:08.726 A:middle
and what your users
would expect.

00:39:08.726 --> 00:39:14.036 A:middle
Now OS X is different because in
the model of OS X, apps can quit

00:39:14.036 --> 00:39:17.156 A:middle
and they do, and that's
exactly what we want you to do

00:39:17.156 --> 00:39:18.196 A:middle
if the receipt's invalid.

00:39:18.406 --> 00:39:19.056 A:middle
Every time.

00:39:19.946 --> 00:39:21.506 A:middle
Always Exit 173.

00:39:22.696 --> 00:39:27.636 A:middle
The App Store will handle
showing the UI for you depending

00:39:27.636 --> 00:39:29.406 A:middle
on various conditions of why

00:39:29.406 --> 00:39:30.896 A:middle
that receipt may
still be invalid.

00:39:31.786 --> 00:39:35.836 A:middle
For example, if the receipt
just plain appears to be invalid

00:39:35.836 --> 00:39:37.956 A:middle
or perhaps it looks as though
it might have been forged,

00:39:38.786 --> 00:39:40.806 A:middle
we'll present UI telling
the user please go

00:39:40.806 --> 00:39:42.766 A:middle
and re-download this app
from the purchases page,

00:39:43.056 --> 00:39:44.116 A:middle
which if they have
really bought it,

00:39:44.116 --> 00:39:46.176 A:middle
should get them a new
copy with a new receipt.

00:39:47.466 --> 00:39:49.956 A:middle
Or if you've opted into
the Volume Purchase Program

00:39:49.956 --> 00:39:51.726 A:middle
and they had a license
but it's been revoked

00:39:51.726 --> 00:39:53.676 A:middle
and they're expired,
we tell them that, too,

00:39:53.676 --> 00:39:56.606 A:middle
and encourage them to go and
buy their own copy, but on OS X,

00:39:56.836 --> 00:40:00.666 A:middle
let us drive the UI,
always just Exit 173.

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

00:39:56.836 --> 00:40:00.666 A:middle
let us drive the UI,
always just Exit 173.

00:40:01.516 --> 00:40:05.936 A:middle
[ Pause ]

00:40:06.436 --> 00:40:08.366 A:middle
Now let's talk about
the test environment.

00:40:08.856 --> 00:40:14.266 A:middle
As powerful as this is to
protecting your revenue,

00:40:14.966 --> 00:40:18.106 A:middle
making sure you get paid, that
your app's not being ripped off,

00:40:18.576 --> 00:40:21.086 A:middle
retain those loyal customers
that are happy that they've paid

00:40:21.086 --> 00:40:24.076 A:middle
for what they're getting,
it's really powerful.

00:40:24.076 --> 00:40:26.226 A:middle
The receipt's the foundation
upon which you do that,

00:40:27.766 --> 00:40:31.246 A:middle
but a bug in this part of your
code could have some really

00:40:31.246 --> 00:40:32.296 A:middle
bad consequences.

00:40:33.026 --> 00:40:36.156 A:middle
A bug in this part of your code
could potentially give away

00:40:36.156 --> 00:40:39.306 A:middle
assets and content that maybe
the user hasn't paid for,

00:40:40.146 --> 00:40:41.516 A:middle
but even worse, a
bug in this part

00:40:41.516 --> 00:40:43.706 A:middle
of your code could
lock customers

00:40:43.706 --> 00:40:45.736 A:middle
out of things they really
actually have paid for.

00:40:46.276 --> 00:40:51.706 A:middle
We all know exactly how they're
going to tell you about that.

00:40:52.256 --> 00:40:55.206 A:middle
So Apple gives you
the test environment.

00:40:55.736 --> 00:40:59.096 A:middle
The test environment is like
a replica of the App Store

00:40:59.096 --> 00:41:02.416 A:middle
that you can use to make
transactions, get receipts,

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

00:40:59.096 --> 00:41:02.416 A:middle
that you can use to make
transactions, get receipts,

00:41:02.416 --> 00:41:05.816 A:middle
use In-App Purchases, without
actually exchanging any money.

00:41:08.016 --> 00:41:10.766 A:middle
The test environment allows you
to test your code in this area

00:41:10.766 --> 00:41:12.106 A:middle
for receipt validation, as well

00:41:12.106 --> 00:41:13.616 A:middle
as In-App Purchases,
really thoroughly.

00:41:14.026 --> 00:41:16.646 A:middle
You can see how your app has
with no receipt, with a receipt,

00:41:16.646 --> 00:41:19.416 A:middle
when it's invalid, when it's
refreshes, all those sorts

00:41:19.416 --> 00:41:23.106 A:middle
of code parts, and there's also
APIs in Store Kit that allow you

00:41:23.106 --> 00:41:25.986 A:middle
to get a Volume Purchase Program
license in various states

00:41:25.986 --> 00:41:28.006 A:middle
of valid, revoked, expired,

00:41:28.416 --> 00:41:30.846 A:middle
so you can really thoroughly
test this, and please do,

00:41:31.406 --> 00:41:35.016 A:middle
because it's crucial that when a
user pays money for your content

00:41:35.016 --> 00:41:36.826 A:middle
and your app, that they get it,

00:41:36.826 --> 00:41:38.506 A:middle
and that a bug doesn't
prevent them,

00:41:38.776 --> 00:41:41.906 A:middle
so the test environment is
exactly what you use to verify

00:41:42.096 --> 00:41:43.946 A:middle
that this works before
you submit your code.

00:41:45.176 --> 00:41:47.496 A:middle
So how in iOS?

00:41:48.166 --> 00:41:50.386 A:middle
Run the device from
Xcode; use the Shake It API

00:41:50.466 --> 00:41:51.426 A:middle
to get yourself a receipt.

00:41:52.616 --> 00:41:54.546 A:middle
Make sure your app is
development signed, though.

00:41:54.916 --> 00:41:57.546 A:middle
That's how the iOS App Store
knows to route your request

00:41:57.546 --> 00:41:58.546 A:middle
to the test environment.

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

00:42:00.496 --> 00:42:01.426 A:middle
OS X developers.

00:42:01.426 --> 00:42:02.176 A:middle
A little bit different.

00:42:02.966 --> 00:42:06.126 A:middle
Build your app in Xcode,
run it from find to first.

00:42:06.856 --> 00:42:11.716 A:middle
Why? Because if you Exit 173
while you're debugging an Xcode,

00:42:11.716 --> 00:42:12.746 A:middle
Xcode doesn't care.

00:42:13.716 --> 00:42:17.556 A:middle
So you've got to run your
app from Finder to get

00:42:17.596 --> 00:42:20.846 A:middle
that initial receipt,
because when you Exit 173

00:42:20.846 --> 00:42:22.866 A:middle
after being launched from
Finder, the App Store

00:42:22.866 --> 00:42:25.126 A:middle
in OS X sees it, we
get you a new receipt,

00:42:25.706 --> 00:42:28.626 A:middle
but make sure you're development
signed because that's how,

00:42:28.626 --> 00:42:31.796 A:middle
again, the App Store in OS X
knows to route that request

00:42:31.796 --> 00:42:32.806 A:middle
to the test environment,

00:42:33.286 --> 00:42:36.716 A:middle
and just in case you missed
the very deliberate repetition

00:42:36.716 --> 00:42:41.256 A:middle
on those last two slides,
your app must be signed

00:42:41.576 --> 00:42:42.876 A:middle
with your development
certificate

00:42:43.076 --> 00:42:44.346 A:middle
to use the test environment.

00:42:44.726 --> 00:42:48.046 A:middle
It's the only way the OS
knows to route your request

00:42:48.046 --> 00:42:50.666 A:middle
for a receipt and also
to do In-App Purchases

00:42:50.666 --> 00:42:54.676 A:middle
to the test environment, and
not the production store.

00:42:56.416 --> 00:42:58.576 A:middle
Also another common
gotcha with this is,

00:42:58.856 --> 00:43:02.206 A:middle
sign-out of the App Store
with your production account,

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

00:42:58.856 --> 00:43:02.206 A:middle
sign-out of the App Store
with your production account,

00:43:03.236 --> 00:43:05.436 A:middle
because that production account
that you use, your Apple ID

00:43:05.436 --> 00:43:08.566 A:middle
that you use to buy songs and
movies and apps, that won't work

00:43:08.566 --> 00:43:09.476 A:middle
in a test environment.

00:43:10.266 --> 00:43:13.066 A:middle
The test environment only works
with test environment accounts

00:43:13.436 --> 00:43:16.396 A:middle
that you set up for
your app only.

00:43:16.986 --> 00:43:22.416 A:middle
Now one last word, and that's

00:43:22.416 --> 00:43:24.306 A:middle
on the app submission
review process

00:43:24.306 --> 00:43:25.216 A:middle
that we all know and love.

00:43:27.036 --> 00:43:28.306 A:middle
When you're developing your app,

00:43:29.126 --> 00:43:32.246 A:middle
you're using your development
certificate, building

00:43:32.246 --> 00:43:34.286 A:middle
and compiling and code
signing with that certificate,

00:43:34.286 --> 00:43:37.296 A:middle
and that allows you to
use the test environment.

00:43:38.486 --> 00:43:40.616 A:middle
When you submit your app to
the store to get it sold,

00:43:41.956 --> 00:43:44.216 A:middle
you're assigning that with
your distribution certificate,

00:43:44.216 --> 00:43:46.966 A:middle
your production certificate,
which allows the app

00:43:46.966 --> 00:43:49.146 A:middle
to then work with the
production store to make sure

00:43:49.146 --> 00:43:50.836 A:middle
that you get paid when
you app is purchased

00:43:51.036 --> 00:43:52.316 A:middle
and when In-App Purchases
are made,

00:43:53.136 --> 00:43:54.966 A:middle
but app review is
a little different

00:43:54.966 --> 00:43:56.606 A:middle
and it's a really
important distinction,

00:43:57.216 --> 00:43:59.486 A:middle
especially when you go to
implement receipt validation.

00:43:59.856 --> 00:44:03.966 A:middle
The app reviewers are actually
testing your production site,

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

00:43:59.856 --> 00:44:03.966 A:middle
The app reviewers are actually
testing your production site,

00:44:04.236 --> 00:44:05.876 A:middle
ready to go into
the store binary,

00:44:06.906 --> 00:44:08.376 A:middle
but against the test
environment,

00:44:09.496 --> 00:44:10.686 A:middle
so your production signed

00:44:10.686 --> 00:44:13.626 A:middle
out will see test
environment receipts.

00:44:13.986 --> 00:44:16.636 A:middle
So don't invalidate them,

00:44:16.986 --> 00:44:18.806 A:middle
just because you think
I'm production signed

00:44:18.806 --> 00:44:20.576 A:middle
and I should never be
seeing the test environment.

00:44:21.276 --> 00:44:23.256 A:middle
That means the reviewers won't
be able to test your app,

00:44:23.376 --> 00:44:25.596 A:middle
won't be able to confirm
your receipt validation works

00:44:25.596 --> 00:44:28.726 A:middle
and your In-App Purchases
work, and it's an express

00:44:28.766 --> 00:44:29.626 A:middle
to the rejection queue.

00:44:29.626 --> 00:44:34.866 A:middle
In summary, to make sure

00:44:35.496 --> 00:44:41.186 A:middle
that your digital
sales are protected,

00:44:41.726 --> 00:44:44.386 A:middle
that your revenue is
secured, and the value

00:44:44.386 --> 00:44:45.646 A:middle
of your product is maintained

00:44:45.646 --> 00:44:48.506 A:middle
and that your products can't be
stolen, cracked, and pirated,

00:44:49.546 --> 00:44:51.316 A:middle
verify and inspect the receipts.

00:44:52.576 --> 00:44:56.306 A:middle
Now on iOS 7, just like on OS
X, you can do this on device

00:44:57.146 --> 00:44:58.876 A:middle
and you can do it
server-to-server as well,

00:44:58.876 --> 00:45:00.316 A:middle
for servers that
are issuing content.

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

00:44:58.876 --> 00:45:00.316 A:middle
for servers that
are issuing content.

00:45:01.136 --> 00:45:02.746 A:middle
But choose a model
that suits you.

00:45:03.186 --> 00:45:06.446 A:middle
Remember that long
gamut of options

00:45:06.446 --> 00:45:09.826 A:middle
that you've got available,
from the third-party libraries

00:45:09.826 --> 00:45:12.686 A:middle
that are ready to go, to
rolling your own with some help

00:45:12.686 --> 00:45:15.726 A:middle
from examples and samples, to
looking at the technical specs

00:45:15.726 --> 00:45:18.916 A:middle
and writing your own code from
scratch, the point you arrive

00:45:18.916 --> 00:45:22.446 A:middle
at on that spectrum should speak
to the value of your products

00:45:23.056 --> 00:45:24.836 A:middle
and the level of
security you want

00:45:25.026 --> 00:45:26.416 A:middle
in your receipt model
enforcement.

00:45:27.526 --> 00:45:30.326 A:middle
Also, don't forget that it's
important to choose a way

00:45:30.326 --> 00:45:33.176 A:middle
of doing the receipt validation
that's a little bit unique,

00:45:33.866 --> 00:45:36.586 A:middle
because if everyone
chose the exact same way

00:45:36.586 --> 00:45:40.176 A:middle
to do receipt validation,
then it would be all too easy

00:45:41.066 --> 00:45:44.306 A:middle
for those evil folks with the
less honorable intentions to go

00:45:44.306 --> 00:45:46.366 A:middle
and find those really
common code segments

00:45:46.876 --> 00:45:47.676 A:middle
and work around them.

00:45:48.826 --> 00:45:51.846 A:middle
So make sure you do things
a little bit special,

00:45:51.896 --> 00:45:56.006 A:middle
a little bit unique to your app,
but no matter how you do it,

00:45:56.006 --> 00:45:59.146 A:middle
use the test environment,
and to use that you've got

00:45:59.146 --> 00:46:03.536 A:middle
to be development signed, using
your test environment accounts.

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

00:45:59.146 --> 00:46:03.536 A:middle
to be development signed, using
your test environment accounts.

00:46:05.456 --> 00:46:06.756 A:middle
Now for more information,

00:46:07.336 --> 00:46:11.006 A:middle
you can contact our excellent
evangelist Paul Marcus.

00:46:12.626 --> 00:46:15.536 A:middle
We have documentation that
we're updating for iOS

00:46:15.536 --> 00:46:17.066 A:middle
and OS X available online

00:46:17.066 --> 00:46:19.276 A:middle
and that's the receipt
validation programming guide,

00:46:20.066 --> 00:46:22.976 A:middle
and of course there's the very
active Apple developer forum

00:46:22.976 --> 00:46:25.226 A:middle
as well, where you're welcome
to ask all manner of questions

00:46:25.226 --> 00:46:26.916 A:middle
about receipt validations,
Store Kit,

00:46:26.916 --> 00:46:29.196 A:middle
In-App Purchases,
whatever you need.

00:46:30.316 --> 00:46:30.586 A:middle
Thank you.

00:46:31.516 --> 00:46:35.516 A:middle
[ Applause ]

00:46:36.016 --> 00:46:46.026 A:middle
[ Silence ]