305.srt

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

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

00:00:11.056 --> 00:00:12.286 A:middle
>> Good morning and
welcome to the session

00:00:12.286 --> 00:00:14.206 A:middle
about using StoreKit
for In-App purchases.

00:00:14.926 --> 00:00:18.346 A:middle
So ... [Applause] Thank you.

00:00:19.016 --> 00:00:21.266 A:middle
So why are we even
sitting here in this room?

00:00:21.726 --> 00:00:24.556 A:middle
Well, because more and
more apps are switching

00:00:24.556 --> 00:00:25.396 A:middle
to In-App purchases.

00:00:25.726 --> 00:00:27.066 A:middle
In fact, when I was
making the slides

00:00:27.066 --> 00:00:30.126 A:middle
on June 2nd, it was shocking.

00:00:30.686 --> 00:00:31.266 A:middle
This works?

00:00:32.716 --> 00:00:38.076 A:middle
An amazing 96 percent of the
top 25 top grossing iPhone apps

00:00:38.076 --> 00:00:40.016 A:middle
in the U.S. were using
In-App purchases.

00:00:40.286 --> 00:00:42.446 A:middle
Of course that number
has changed every day

00:00:42.506 --> 00:00:44.256 A:middle
and today it dropped
embarrassingly

00:00:44.256 --> 00:00:47.536 A:middle
to a miserable like 88 percent.

00:00:48.006 --> 00:00:51.526 A:middle
So apps are switching and we
want to better support them.

00:00:51.526 --> 00:00:52.916 A:middle
And we made a bunch of changes,

00:00:53.236 --> 00:00:54.616 A:middle
and we'd like to share
them with you today.

00:00:55.746 --> 00:00:59.256 A:middle
So first we'll talk about the
changes that we made to --

00:00:59.776 --> 00:01:02.496 A:middle
to StoreKit and then we'll
review the In-App purchase

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

00:00:59.776 --> 00:01:02.496 A:middle
to StoreKit and then we'll
review the In-App purchase

00:01:02.496 --> 00:01:05.226 A:middle
process and highlight the
changes that you might want

00:01:05.226 --> 00:01:08.886 A:middle
to make, and also discuss a few
of the options and decisions,

00:01:08.886 --> 00:01:10.686 A:middle
and the APIs you might
want to use, as well.

00:01:11.226 --> 00:01:13.756 A:middle
Then we'll demystify
the test environment

00:01:13.756 --> 00:01:15.296 A:middle
because it's really
important to use it.

00:01:15.966 --> 00:01:18.006 A:middle
Then we'll have a
grab-bag of tips straight

00:01:18.006 --> 00:01:20.906 A:middle
from the app review team to make
sure you can pass the app review

00:01:21.026 --> 00:01:21.836 A:middle
with flying colors.

00:01:23.306 --> 00:01:24.906 A:middle
So first, what's
new in StoreKit?

00:01:26.436 --> 00:01:28.496 A:middle
So at the core, StoreKit
is a payment system.

00:01:28.726 --> 00:01:31.836 A:middle
It possesses transactions and
for every single transaction,

00:01:32.146 --> 00:01:35.326 A:middle
it hands the application
a receipt and the security

00:01:35.326 --> 00:01:37.156 A:middle
of the whole model
comes from the receipt.

00:01:37.156 --> 00:01:39.716 A:middle
And if there's only one thing
you remember from today,

00:01:40.296 --> 00:01:42.516 A:middle
is that the security
is in the receipt.

00:01:43.496 --> 00:01:45.976 A:middle
So you can decide
to make this as safe

00:01:45.976 --> 00:01:47.676 A:middle
as possible as you want to.

00:01:47.676 --> 00:01:49.096 A:middle
You can really choose
the safety level.

00:01:49.096 --> 00:01:51.346 A:middle
If your accountant warrants it,
you can do very, very secure

00:01:51.346 --> 00:01:53.836 A:middle
and you can do whatever what
with it, but in the end,

00:01:53.836 --> 00:01:54.996 A:middle
the security is in the receipt.

00:01:56.016 --> 00:01:59.606 A:middle
And it's not very
difficult to verify receipts,

00:01:59.686 --> 00:02:01.226 A:middle
but there's a bunch of
details you want to get right.

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

00:01:59.686 --> 00:02:01.226 A:middle
but there's a bunch of
details you want to get right.

00:02:01.816 --> 00:02:04.676 A:middle
So we spun off a separate
session called, "Using Receipts

00:02:04.676 --> 00:02:07.006 A:middle
to Protect Your Digital
Sales," in Presidio

00:02:07.006 --> 00:02:09.566 A:middle
at 2:00 p.m. You'll learn all
the tools, the technique s,

00:02:09.566 --> 00:02:11.686 A:middle
the APIs to verify the receipt
and all the options you have.

00:02:12.166 --> 00:02:15.466 A:middle
So I very much recommend
that you attend that session.

00:02:15.966 --> 00:02:18.576 A:middle
Now, let's take a
step back and look

00:02:18.786 --> 00:02:20.376 A:middle
at the history of the receipt.

00:02:21.336 --> 00:02:23.856 A:middle
In 2009, IOS introduced
In-App purchases

00:02:24.196 --> 00:02:28.666 A:middle
and for every In-App purchase,
we give you a receipt and it was

00:02:28.666 --> 00:02:30.716 A:middle
up to the application to
store it and manage it.

00:02:31.446 --> 00:02:36.406 A:middle
And then in 2011, the OS X added
the Mac App Store and threw

00:02:36.406 --> 00:02:38.026 A:middle
in a new receipt
in this ecosystem.

00:02:38.356 --> 00:02:40.176 A:middle
It's the app purchase receipt.

00:02:40.266 --> 00:02:42.426 A:middle
It's a proof of purchase
for the application itself.

00:02:43.596 --> 00:02:46.516 A:middle
So when we added enough
purchases to the Mac App Store,

00:02:47.266 --> 00:02:49.166 A:middle
we decided to unite
all these receipts

00:02:49.406 --> 00:02:51.176 A:middle
into one big unified receipt.

00:02:52.226 --> 00:02:56.286 A:middle
And today, I'm very excited to
announce that iOS is switching

00:02:56.286 --> 00:02:57.806 A:middle
to the same unified receipt,

00:02:57.806 --> 00:02:59.366 A:middle
which proved to be
so successful.

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

00:03:00.856 --> 00:03:02.536 A:middle
[applause] So, thank you.

00:03:02.936 --> 00:03:03.706 A:middle
I'm glad you appreciate that.

00:03:05.376 --> 00:03:08.986 A:middle
So, it's the same receipt
format for iOS 7 and OS X.

00:03:09.446 --> 00:03:10.976 A:middle
It is managed for
you by StoreKit,

00:03:11.086 --> 00:03:12.896 A:middle
which means we store it
in the [inaudible] system

00:03:12.896 --> 00:03:15.376 A:middle
and we give you an API to access
it anytime you want to check it.

00:03:16.516 --> 00:03:19.576 A:middle
And you can now validate
that receipt just like OS X

00:03:19.746 --> 00:03:22.076 A:middle
on the device, which means
you don't need your own

00:03:22.076 --> 00:03:22.856 A:middle
servers anymore.

00:03:24.566 --> 00:03:25.886 A:middle
[Applause and cheering] Some
people have implemented that,

00:03:27.406 --> 00:03:27.686 A:middle
I see.

00:03:27.896 --> 00:03:29.526 A:middle
And there's another bonus.

00:03:30.286 --> 00:03:33.156 A:middle
This receipt contains the orange
box, the app purchase receipt

00:03:33.666 --> 00:03:35.696 A:middle
and you can use this
for two things.

00:03:36.226 --> 00:03:38.366 A:middle
First, if you want this
extra level of security,

00:03:38.366 --> 00:03:40.626 A:middle
if you to make sure your
application has been really paid

00:03:40.686 --> 00:03:43.046 A:middle
for, then you can
check this receipt

00:03:43.046 --> 00:03:45.106 A:middle
and make sure has been
purchased on this device

00:03:45.106 --> 00:03:46.126 A:middle
and everything is legit.

00:03:46.956 --> 00:03:50.976 A:middle
But it also helps you if want
to transfer to the premium level

00:03:50.976 --> 00:03:52.866 A:middle
where the application is free
and you sell the content.

00:03:53.646 --> 00:03:54.566 A:middle
How's that possible?

00:03:55.606 --> 00:03:58.576 A:middle
So say your application
is stocked in the store

00:03:58.576 --> 00:04:00.896 A:middle
as a paid application and
at some point in time,

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

00:03:58.576 --> 00:04:00.896 A:middle
as a paid application and
at some point in time,

00:04:01.016 --> 00:04:03.486 A:middle
you want to make this
application a free application.

00:04:04.556 --> 00:04:07.176 A:middle
The problem is that when the
user restores to a new device,

00:04:07.626 --> 00:04:10.316 A:middle
you have no idea when they
purchased the application.

00:04:10.316 --> 00:04:12.246 A:middle
So did they purchase the paid
version or the free version?

00:04:12.306 --> 00:04:13.896 A:middle
So you don't know what
content they're entitled to.

00:04:14.546 --> 00:04:17.606 A:middle
So, if you look into the
app purchase receipts,

00:04:18.046 --> 00:04:21.375 A:middle
you'll find a purchase date
and this will allow you to know

00:04:21.375 --> 00:04:23.026 A:middle
if your user is entitled
to content,

00:04:23.116 --> 00:04:26.826 A:middle
or if the user purchased
after you switched to premium.

00:04:27.366 --> 00:04:29.286 A:middle
Now of course, we are
talking about transition,

00:04:30.126 --> 00:04:34.446 A:middle
which means that we have the
old style receipts around

00:04:35.046 --> 00:04:37.026 A:middle
and to be very clear,
they are duplicated.

00:04:38.096 --> 00:04:41.636 A:middle
But fear not, your
existing apps will continue

00:04:41.636 --> 00:04:42.506 A:middle
to work, of course.

00:04:43.186 --> 00:04:46.026 A:middle
Even, in fact, if you take your
existing code and you rebuild it

00:04:46.026 --> 00:04:48.066 A:middle
against the iOS 7 SDK,

00:04:48.066 --> 00:04:49.556 A:middle
the application will
continue to work.

00:04:50.386 --> 00:04:52.566 A:middle
You'll still get your
receipts, but you'll get a bunch

00:04:52.566 --> 00:04:53.626 A:middle
of duplication warnings.

00:04:54.266 --> 00:04:56.616 A:middle
And I'm sure you got the --

00:04:56.986 --> 00:04:59.666 A:middle
you heard distinctive
slide about 93 percent

00:04:59.666 --> 00:05:02.316 A:middle
of the applications, of
the users having updated

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

00:04:59.666 --> 00:05:02.316 A:middle
of the applications, of
the users having updated

00:05:02.316 --> 00:05:03.596 A:middle
to the latest version
of the iOS.

00:05:04.286 --> 00:05:06.436 A:middle
That means people will
transition to iOS 7.

00:05:07.046 --> 00:05:08.926 A:middle
And that means it's high
time to transition --

00:05:08.926 --> 00:05:10.946 A:middle
it's time to start transitioning
to a new receipt style.

00:05:12.286 --> 00:05:13.606 A:middle
But in the meantime,
you probably want

00:05:13.606 --> 00:05:16.236 A:middle
to support both the old style
and new style of receipts

00:05:16.686 --> 00:05:19.316 A:middle
and the right way to do this is
not to check for the OS version,

00:05:19.786 --> 00:05:22.766 A:middle
it is to use weak linking so
you only keep the two good paths

00:05:22.766 --> 00:05:26.526 A:middle
around and you want to check
if your main bundle responds

00:05:26.526 --> 00:05:28.886 A:middle
to the selector for the new
API added to access a receipt.

00:05:31.136 --> 00:05:34.286 A:middle
Next is Volume Purchase Program.

00:05:35.186 --> 00:05:36.866 A:middle
We're adding a new
licensing model here.

00:05:37.946 --> 00:05:40.766 A:middle
If you opt into this
program then you are allowing

00:05:40.766 --> 00:05:43.996 A:middle
large-volume purchasers,
think large companies,

00:05:44.246 --> 00:05:46.346 A:middle
think universities,
think schools.

00:05:46.776 --> 00:05:50.496 A:middle
You're allowing them to buy your
application in bulk and then

00:05:50.496 --> 00:05:52.836 A:middle
for a school to assign
licenses to the students.

00:05:53.556 --> 00:05:55.046 A:middle
And when the school year ends,

00:05:55.786 --> 00:05:58.286 A:middle
the school can take the
licenses back from the students

00:05:58.556 --> 00:06:00.976 A:middle
and assign them to the
new batch of students.

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

00:05:58.556 --> 00:06:00.976 A:middle
and assign them to the
new batch of students.

00:06:01.446 --> 00:06:03.276 A:middle
So that really unlocks
the education market

00:06:03.416 --> 00:06:05.646 A:middle
and the large enterprise
market for applications.

00:06:06.716 --> 00:06:10.006 A:middle
Now if you look at it from
a device point of view,

00:06:10.556 --> 00:06:13.116 A:middle
when the school year ends
and the students walk away,

00:06:13.376 --> 00:06:16.376 A:middle
the school will revoke --
will revoke the licenses.

00:06:17.046 --> 00:06:19.406 A:middle
This will start a 30-day
grace period during

00:06:19.406 --> 00:06:21.306 A:middle
which the students can
still launch the application

00:06:21.306 --> 00:06:22.586 A:middle
and they can back
up their documents

00:06:22.586 --> 00:06:23.466 A:middle
and whatever they want.

00:06:23.596 --> 00:06:24.456 A:middle
They are warned about this.

00:06:25.296 --> 00:06:28.336 A:middle
But then when the 30-days --
the 30-day grace period expires,

00:06:28.736 --> 00:06:30.336 A:middle
the license becomes revoked.

00:06:31.076 --> 00:06:34.146 A:middle
And on iOS, when the
license is revoked,

00:06:34.146 --> 00:06:36.666 A:middle
iOS will prevent the
launch of the application.

00:06:36.666 --> 00:06:39.426 A:middle
And instead of launching,
it will display dialog

00:06:39.426 --> 00:06:42.906 A:middle
to explain the situation
and offer the students

00:06:42.906 --> 00:06:44.566 A:middle
to buy the application
to keep using it.

00:06:45.486 --> 00:06:48.156 A:middle
OS X has a different
security model.

00:06:48.346 --> 00:06:50.136 A:middle
On OS X your application
will have to launch,

00:06:50.816 --> 00:06:54.096 A:middle
discover it is expired, and
then exit with a special code

00:06:54.096 --> 00:06:56.436 A:middle
so that the finder can display
this dialog and offer people

00:06:56.436 --> 00:06:57.386 A:middle
to buy your applications.

00:06:58.506 --> 00:07:00.396 A:middle
But again, the security
is in the receipt.

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

00:06:58.506 --> 00:07:00.396 A:middle
But again, the security
is in the receipt.

00:07:00.816 --> 00:07:03.996 A:middle
So in both cases, it is the
application's responsibility

00:07:04.446 --> 00:07:06.996 A:middle
to check the receipt and enforce

00:07:06.996 --> 00:07:08.656 A:middle
and make sure the
application stops running

00:07:08.656 --> 00:07:10.266 A:middle
if the -- if it is expired.

00:07:11.346 --> 00:07:13.116 A:middle
And to do this, we added
new fields in receipts.

00:07:14.356 --> 00:07:17.036 A:middle
So we've just touched
the surface.

00:07:17.076 --> 00:07:19.606 A:middle
If you want to know more about
this volume purchasing program,

00:07:19.976 --> 00:07:22.206 A:middle
you can watch a video of the
session that happened yesterday

00:07:22.286 --> 00:07:23.646 A:middle
about extending your
applications

00:07:23.646 --> 00:07:24.946 A:middle
for enterprise and education.

00:07:26.276 --> 00:07:29.606 A:middle
And also you can attend the
session in Presidio at 2:00 p.m.

00:07:29.606 --> 00:07:31.976 A:middle
about validating the receipts,
which will tell you everything

00:07:31.976 --> 00:07:36.396 A:middle
about the new fields we
added to the receipts.

00:07:37.036 --> 00:07:40.076 A:middle
Next, hosted In-App
purchases can now be free.

00:07:41.446 --> 00:07:44.956 A:middle
And what that really means
is, you can use them for --

00:07:44.956 --> 00:07:47.686 A:middle
to distribute message content
that all the user's need.

00:07:48.186 --> 00:07:49.876 A:middle
So think like musical
instruments,

00:07:49.876 --> 00:07:53.906 A:middle
or you know musical samples
-- not navigation packages,

00:07:53.906 --> 00:07:55.696 A:middle
anything that's huge
and that you have

00:07:55.696 --> 00:07:57.036 A:middle
to distribute to the same users.

00:07:57.406 --> 00:07:58.866 A:middle
You can use host
in-app purchases.

00:07:58.996 --> 00:08:02.156 A:middle
You can upload this to the Apple
server and Apple will host this,

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

00:07:58.996 --> 00:08:02.156 A:middle
You can upload this to the Apple
server and Apple will host this,

00:08:02.256 --> 00:08:04.516 A:middle
Apple will serve it, and
Apple will even download it

00:08:04.516 --> 00:08:05.836 A:middle
in the background
for re-application,

00:08:06.106 --> 00:08:07.226 A:middle
so it's very convenient.

00:08:08.166 --> 00:08:09.846 A:middle
In fact, many applications,

00:08:09.846 --> 00:08:11.596 A:middle
that's' the only
reason they had servers,

00:08:11.596 --> 00:08:12.636 A:middle
to back their applications.

00:08:13.006 --> 00:08:14.536 A:middle
If that's the case, you
don't need servers anymore,

00:08:14.616 --> 00:08:15.416 A:middle
so its way simpler.

00:08:16.206 --> 00:08:19.226 A:middle
But keep in mind that
they are In-App purchases

00:08:19.696 --> 00:08:22.586 A:middle
so they still -- you know, the
user still has to buy them,

00:08:22.586 --> 00:08:24.336 A:middle
although it's for
free, and authenticate.

00:08:24.936 --> 00:08:26.936 A:middle
And they still have to go
through the app review process,

00:08:27.126 --> 00:08:32.186 A:middle
but they're a very convenient
way to distribute some content.

00:08:32.285 --> 00:08:35.395 A:middle
Now, let's review the four types
of In-App purchases we have

00:08:35.626 --> 00:08:36.785 A:middle
in the Apple ecosystem.

00:08:37.836 --> 00:08:41.436 A:middle
On the one end of the spectrum,
we have consumable products.

00:08:41.905 --> 00:08:43.836 A:middle
It's for things like gold coins,

00:08:44.206 --> 00:08:45.536 A:middle
things you can buy
multiple times,

00:08:46.026 --> 00:08:48.306 A:middle
but every time StoreKit
hands it only once

00:08:48.306 --> 00:08:50.766 A:middle
through the application and
the application takes over

00:08:50.766 --> 00:08:51.606 A:middle
and manages the amount

00:08:51.606 --> 00:08:53.366 A:middle
of remaining gold coins
or whatever it is.

00:08:53.366 --> 00:08:55.926 A:middle
And because it's managed
by your application,

00:08:56.086 --> 00:08:58.466 A:middle
StoreKit does not
restore it to past devices

00:08:59.076 --> 00:09:00.986 A:middle
because you're managing it.

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

00:08:59.076 --> 00:09:00.986 A:middle
because you're managing it.

00:09:01.306 --> 00:09:02.876 A:middle
Now on the other
end of the spectrum,

00:09:03.556 --> 00:09:06.286 A:middle
we have non-consumable
products and it's for things

00:09:06.286 --> 00:09:09.626 A:middle
like magazines, things
that when you buy them,

00:09:09.666 --> 00:09:10.616 A:middle
you own then forever.

00:09:10.616 --> 00:09:12.746 A:middle
And those are completely
managed through StoreKit

00:09:13.056 --> 00:09:16.236 A:middle
and StoreKit will -- will
restore them across devices

00:09:16.236 --> 00:09:17.076 A:middle
and manage them completely.

00:09:17.616 --> 00:09:22.306 A:middle
Now since we're talking about
magazines, if you are dealing

00:09:22.306 --> 00:09:24.876 A:middle
with periodicals
then you can use the

00:09:24.876 --> 00:09:26.236 A:middle
auto-renewable subscriptions.

00:09:27.026 --> 00:09:30.776 A:middle
And those -- what a user really
buys is a period of time.

00:09:30.776 --> 00:09:34.006 A:middle
The user buys a period of time,
a subscription period and when

00:09:34.006 --> 00:09:35.086 A:middle
that period finishes,

00:09:35.606 --> 00:09:37.986 A:middle
[inaudible] store will
automatically renew the

00:09:37.986 --> 00:09:40.236 A:middle
subscription period
and drop a transaction

00:09:40.396 --> 00:09:41.556 A:middle
into the device payment queue.

00:09:42.266 --> 00:09:44.196 A:middle
So it's, again, managed
by StoreKit.

00:09:44.736 --> 00:09:45.916 A:middle
And you also have the option

00:09:46.106 --> 00:09:50.576 A:middle
to provide a free subscription
period to the users in exchange

00:09:50.576 --> 00:09:53.686 A:middle
for them opting in to share in
their personal data with you.

00:09:54.406 --> 00:09:56.366 A:middle
And the data from the
field shows that a majority

00:09:56.366 --> 00:09:58.196 A:middle
of people actually
trust your applications

00:09:58.196 --> 00:09:59.906 A:middle
and trust your brands, so
they opt in to share the data.

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

00:10:00.276 --> 00:10:07.366 A:middle
Now, for all the other types
of time-based In-App purchases,

00:10:08.116 --> 00:10:09.946 A:middle
you should use non-renewing
subscriptions.

00:10:10.186 --> 00:10:14.606 A:middle
You can view them
conceptually as consumables

00:10:14.906 --> 00:10:19.336 A:middle
because the user -- when the
user purchases them they're only

00:10:19.336 --> 00:10:22.026 A:middle
handed once to the application
and the application takes over

00:10:22.386 --> 00:10:24.986 A:middle
and manages the subscription
in whatever way

00:10:24.986 --> 00:10:26.886 A:middle
that makes sense
for the application.

00:10:27.216 --> 00:10:28.446 A:middle
So it is extremely flexible.

00:10:28.446 --> 00:10:30.326 A:middle
You can do any kind of
subscription model here.

00:10:31.086 --> 00:10:33.766 A:middle
But -- sorry -- in
fact, it is so flexible

00:10:33.766 --> 00:10:37.436 A:middle
that it has no duration
information inside the

00:10:37.436 --> 00:10:38.176 A:middle
purchase object.

00:10:38.176 --> 00:10:40.026 A:middle
It is really up to you to
implement it the way --

00:10:40.456 --> 00:10:42.156 A:middle
a way that's meaningful
to your application.

00:10:42.956 --> 00:10:44.316 A:middle
So that's typically used --

00:10:44.316 --> 00:10:47.346 A:middle
typically used for things
like access to fly charts --

00:10:47.506 --> 00:10:50.246 A:middle
the latest fly charts,
access to financial services,

00:10:50.416 --> 00:10:53.016 A:middle
all the professional apps.

00:10:53.616 --> 00:10:54.576 A:middle
Now if you summarize,

00:10:55.736 --> 00:10:58.596 A:middle
iOS supports all four
types of in-app purchases.

00:10:59.746 --> 00:11:02.886 A:middle
OS X supports only
consumables and non-consumables.

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

00:10:59.746 --> 00:11:02.886 A:middle
OS X supports only
consumables and non-consumables.

00:11:03.666 --> 00:11:07.056 A:middle
And as you've probably
guessed, today we're excited

00:11:07.476 --> 00:11:09.576 A:middle
to bring subscriptions
to OS X Mavericks.

00:11:11.136 --> 00:11:14.536 A:middle
So the first question we
expect is how can they make

00:11:14.536 --> 00:11:17.026 A:middle
that content available
on both platforms?

00:11:17.806 --> 00:11:20.996 A:middle
And the answer is you
can, but the product

00:11:20.996 --> 00:11:23.556 A:middle
and identifiers are
separate in OS X and iOS.

00:11:24.146 --> 00:11:26.576 A:middle
So you will have to use
your own account management,

00:11:27.286 --> 00:11:30.256 A:middle
track the subscription
on one platform,

00:11:30.256 --> 00:11:32.716 A:middle
and make the content available
on the other platform,

00:11:33.246 --> 00:11:37.046 A:middle
and that wraps the updates
for In-App purchases.

00:11:38.706 --> 00:11:40.846 A:middle
Now, let's go through the
In-App purchase process

00:11:41.466 --> 00:11:44.676 A:middle
and let's highlight the few
changes you'll have to make

00:11:44.676 --> 00:11:45.976 A:middle
to transition to new receipts.

00:11:46.706 --> 00:11:48.416 A:middle
And also on the way we'll
make a bunch of stops,

00:11:48.516 --> 00:11:50.026 A:middle
and we'll discuss all
the options you have,

00:11:50.026 --> 00:11:52.416 A:middle
all the APIs you can use
to deal with the content

00:11:52.416 --> 00:11:55.576 A:middle
and all the issues
connected to In-App purchases.

00:11:56.186 --> 00:12:00.386 A:middle
So I'm going to assume here
that you already know the basics

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

00:11:56.186 --> 00:12:00.386 A:middle
So I'm going to assume here
that you already know the basics

00:12:00.386 --> 00:12:03.216 A:middle
of StoreKit and that you
probably have an application

00:12:03.216 --> 00:12:04.766 A:middle
to store and an iOS
application running.

00:12:05.196 --> 00:12:07.806 A:middle
Now if you don't, I will gladly
point you to the [inaudible]

00:12:07.806 --> 00:12:11.636 A:middle
on the website, and to the
introductory session we had last

00:12:11.636 --> 00:12:13.846 A:middle
year that you can watch a
video for on the website.

00:12:15.046 --> 00:12:17.846 A:middle
So what do we need to make
an In-App purchase process?

00:12:18.426 --> 00:12:20.016 A:middle
We need really three
large phases.

00:12:20.806 --> 00:12:23.186 A:middle
First you have to set up the
products in Action Connect

00:12:23.936 --> 00:12:26.266 A:middle
and if it's hosting In-App
purchases, if you have content,

00:12:26.266 --> 00:12:29.426 A:middle
you want to package your
content inside of Xcode.

00:12:29.556 --> 00:12:32.396 A:middle
Then the user can make the
purchase on the client --

00:12:32.556 --> 00:12:35.776 A:middle
the device or the Mac, and
when purchase happens you want

00:12:35.776 --> 00:12:38.276 A:middle
to verify receipts and
you can do this either

00:12:38.366 --> 00:12:40.526 A:middle
on the client or on the server.

00:12:41.606 --> 00:12:44.636 A:middle
So let's assume here
that you have set

00:12:44.706 --> 00:12:46.416 A:middle
up your [inaudible] already.

00:12:46.416 --> 00:12:47.806 A:middle
So when the user wants to --

00:12:48.276 --> 00:12:52.636 A:middle
sorry, the In-App purchase
process is this long process

00:12:52.636 --> 00:12:54.876 A:middle
of stages and the first thing
you want to do is figure

00:12:54.876 --> 00:12:55.956 A:middle
out what you want to sell.

00:12:56.796 --> 00:12:58.756 A:middle
And you really have
two major options here.

00:12:59.206 --> 00:13:01.916 A:middle
If you have In-App
purchases like game options,

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

00:12:59.206 --> 00:13:01.916 A:middle
If you have In-App
purchases like game options,

00:13:02.006 --> 00:13:03.336 A:middle
things just unlocking the game,

00:13:03.796 --> 00:13:06.186 A:middle
then you can just
bake the identifiers

00:13:06.266 --> 00:13:07.136 A:middle
into your application.

00:13:07.256 --> 00:13:09.036 A:middle
That's perfectly fine.

00:13:09.106 --> 00:13:11.896 A:middle
Now, if you have -- if you're
sending content like magazines

00:13:11.896 --> 00:13:15.526 A:middle
or comics, then you probably
want to fetch your identifier

00:13:15.526 --> 00:13:17.316 A:middle
from your server so that
it can be very dynamic.

00:13:18.626 --> 00:13:21.896 A:middle
So we know what we want to
sell now, but now we have

00:13:21.896 --> 00:13:23.566 A:middle
to fetch the information
about the product

00:13:23.646 --> 00:13:24.736 A:middle
to display to the user.

00:13:25.846 --> 00:13:29.516 A:middle
And to do this, you first want
to create a set of identifiers

00:13:30.716 --> 00:13:32.186 A:middle
and then with a set
of identifiers,

00:13:32.186 --> 00:13:34.006 A:middle
you can create a
StoreKit products request.

00:13:35.446 --> 00:13:37.626 A:middle
You want to add yourself
as delegate to request

00:13:38.266 --> 00:13:39.086 A:middle
and start the request.

00:13:40.006 --> 00:13:41.166 A:middle
And that's all there is to do

00:13:41.166 --> 00:13:42.616 A:middle
and the request will
be sent to the server.

00:13:43.276 --> 00:13:45.466 A:middle
And when it comes down from
the server with a response,

00:13:46.036 --> 00:13:48.946 A:middle
your delegate will
fire with either --

00:13:48.946 --> 00:13:51.676 A:middle
fire with error because
the device was --

00:13:51.796 --> 00:13:54.196 A:middle
may be offline, not very
interesting but you still have

00:13:54.196 --> 00:13:57.656 A:middle
to handle it or if you're
online -- that's a good case,

00:13:57.696 --> 00:14:01.076 A:middle
you will get, "Did
receive response."

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

00:13:57.696 --> 00:14:01.076 A:middle
you will get, "Did
receive response."

00:14:01.676 --> 00:14:04.336 A:middle
And the response will
contain two things.

00:14:05.236 --> 00:14:07.696 A:middle
The first thing is invalid
product identifiers.

00:14:08.346 --> 00:14:10.516 A:middle
It's the unlucky case where
you ask for information

00:14:10.516 --> 00:14:12.186 A:middle
of the product that is
not in the store anymore

00:14:12.836 --> 00:14:14.906 A:middle
and that could be
because maybe you removed

00:14:14.906 --> 00:14:16.096 A:middle
from the store Action Connect,

00:14:16.696 --> 00:14:18.316 A:middle
or maybe you just
didn't make it available

00:14:18.316 --> 00:14:20.456 A:middle
in this specific country
for any kind of reason.

00:14:21.356 --> 00:14:26.086 A:middle
So, it's a case to keep in
mind, but in most of the cases,

00:14:26.166 --> 00:14:29.436 A:middle
the product is valid and
you will get a product

00:14:29.436 --> 00:14:30.316 A:middle
rating response.

00:14:30.956 --> 00:14:34.976 A:middle
So, that production rating
contains StoreKit products.

00:14:35.646 --> 00:14:38.736 A:middle
And each of those has all the
attributes you want to use

00:14:38.826 --> 00:14:40.826 A:middle
to display the -- to
display the contents.

00:14:41.736 --> 00:14:45.876 A:middle
So, you'll find a title
localized in the country

00:14:45.876 --> 00:14:46.616 A:middle
of the store accounts.

00:14:47.346 --> 00:14:49.536 A:middle
You'll find the description
localized for the same country.

00:14:50.336 --> 00:14:53.366 A:middle
You'll find a price in the
currency of the store accounts

00:14:54.276 --> 00:14:56.506 A:middle
and you'll find the locale,
which contains the currency.

00:14:57.356 --> 00:14:59.276 A:middle
And if it's a hosted
In-App purchase,

00:14:59.946 --> 00:15:03.346 A:middle
well you'll also get the content
size and the content version.

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

00:14:59.946 --> 00:15:03.346 A:middle
well you'll also get the content
size and the content version.

00:15:03.826 --> 00:15:05.546 A:middle
And you can use this
information for things

00:15:05.966 --> 00:15:09.716 A:middle
like offering the user to
upgrade to a new version

00:15:09.836 --> 00:15:11.826 A:middle
or just telling then
they're up to date.

00:15:12.736 --> 00:15:14.736 A:middle
So there's one question
we get very often.

00:15:15.026 --> 00:15:17.466 A:middle
How do you display
the product price?

00:15:17.556 --> 00:15:19.676 A:middle
And it's difficult,
dollar goes in to franc,

00:15:19.806 --> 00:15:23.206 A:middle
Euros goes in the back,
where does the Yen go,

00:15:23.206 --> 00:15:25.006 A:middle
and then you have
decimal separators.

00:15:25.366 --> 00:15:30.156 A:middle
So the best way to deal with
this is to be super lazy.

00:15:30.936 --> 00:15:32.296 A:middle
And we have this class

00:15:32.296 --> 00:15:33.966 A:middle
in the system called
NS Number Formatter.

00:15:33.966 --> 00:15:37.296 A:middle
And if you create one of
those and you said it's style

00:15:37.296 --> 00:15:40.176 A:middle
to be a currency style,
and you set it's locale

00:15:40.176 --> 00:15:42.726 A:middle
to be the locale you got
from the product response,

00:15:43.386 --> 00:15:45.846 A:middle
then all you have to do
is go string from number

00:15:46.206 --> 00:15:47.436 A:middle
with the price you
got from the store

00:15:47.666 --> 00:15:49.886 A:middle
and this gives you a string that
you can display to the user.

00:15:50.506 --> 00:15:51.276 A:middle
So it's pretty simple.

00:15:52.406 --> 00:15:55.086 A:middle
What you should really not
do is try to do any kind

00:15:55.086 --> 00:15:58.976 A:middle
of currency conversion because
the price the store gives you

00:15:59.246 --> 00:16:02.916 A:middle
and the price currency that the
store gives you is what we will

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

00:15:59.246 --> 00:16:02.916 A:middle
and the price currency that the
store gives you is what we will

00:16:02.916 --> 00:16:03.766 A:middle
charge to the user.

00:16:04.056 --> 00:16:06.026 A:middle
So it is the price that should
be displayed to the user.

00:16:06.536 --> 00:16:09.146 A:middle
So that's the best way to do
it, just display the price as is

00:16:09.146 --> 00:16:10.976 A:middle
and get help for formatting
the price with the unit

00:16:10.976 --> 00:16:14.016 A:middle
and all these kinds of things.

00:16:14.216 --> 00:16:18.976 A:middle
Now we have information
and now it's time to kind

00:16:18.976 --> 00:16:20.916 A:middle
of expose the user to the goods.

00:16:21.176 --> 00:16:23.606 A:middle
You want to show the in-app
purchase you are to the user.

00:16:23.796 --> 00:16:25.986 A:middle
And this is completely
up to the application.

00:16:26.706 --> 00:16:29.816 A:middle
Why? Well, because only
you know your application.

00:16:30.036 --> 00:16:32.046 A:middle
Only you know your content.

00:16:32.046 --> 00:16:34.606 A:middle
Only you can actually present it
in a way that does it justice,

00:16:34.906 --> 00:16:36.956 A:middle
in a way that's attractive,
that fits the game play,

00:16:37.246 --> 00:16:38.276 A:middle
or the application style.

00:16:38.816 --> 00:16:41.886 A:middle
So it's something that's worth
investing some time and effort

00:16:41.886 --> 00:16:44.266 A:middle
in to get it right because
when you get it right,

00:16:44.586 --> 00:16:45.836 A:middle
it has a huge impact.

00:16:45.836 --> 00:16:48.036 A:middle
It shows dramatically
on the sales numbers.

00:16:49.116 --> 00:16:52.946 A:middle
So for example, if you're
selling comics then you want

00:16:52.946 --> 00:16:55.306 A:middle
to build a comic store,
a gorgeous comic store.

00:16:55.676 --> 00:16:56.586 A:middle
This is comiXsology.

00:16:56.586 --> 00:17:00.366 A:middle
Look at that, it has
a 99 cent specials.

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

00:16:56.586 --> 00:17:00.366 A:middle
Look at that, it has
a 99 cent specials.

00:17:00.516 --> 00:17:01.596 A:middle
It has [inaudible] Sprint.

00:17:01.596 --> 00:17:02.886 A:middle
It is attractive.

00:17:02.916 --> 00:17:03.516 A:middle
You can browse.

00:17:03.516 --> 00:17:04.126 A:middle
You can discover.

00:17:04.445 --> 00:17:07.386 A:middle
It has all the features you want
to have in a real comic store.

00:17:08.886 --> 00:17:12.126 A:middle
Now if you're a game and your
currency is like, you know,

00:17:12.126 --> 00:17:15.746 A:middle
gold coins, then again you want
to display these gold coins

00:17:15.746 --> 00:17:17.116 A:middle
in a way that fits
your application,

00:17:17.596 --> 00:17:20.126 A:middle
in a way that fits the game
play, so at the right moment

00:17:20.126 --> 00:17:22.276 A:middle
in the game so that people
are in the right mood

00:17:22.276 --> 00:17:24.376 A:middle
and they don't feel like
they're pressured to buy.

00:17:25.046 --> 00:17:26.486 A:middle
This is Heyday.

00:17:26.486 --> 00:17:29.906 A:middle
It's a free application
yet its number three --

00:17:30.226 --> 00:17:31.976 A:middle
it's the third top
grossing application today.

00:17:32.566 --> 00:17:35.846 A:middle
So that really shows that when
you do it right, it works.

00:17:36.706 --> 00:17:39.286 A:middle
So let's assume here
that you do it right,

00:17:39.286 --> 00:17:43.996 A:middle
because why else would you
do it, and make the purchase.

00:17:43.996 --> 00:17:45.776 A:middle
So the user has clicked
this bag of coins

00:17:46.176 --> 00:17:47.226 A:middle
and you want to make
the purchase.

00:17:48.396 --> 00:17:51.546 A:middle
So to do this you want to
create a StoreKit payment object

00:17:52.326 --> 00:17:54.296 A:middle
with the product you get
from the product response,

00:17:55.296 --> 00:17:58.066 A:middle
and then you add this
payment to the payment queue,

00:17:58.536 --> 00:17:59.566 A:middle
and that's all you have to do.

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

00:18:00.376 --> 00:18:01.846 A:middle
StoreKit will take over.

00:18:01.906 --> 00:18:05.166 A:middle
StoreKit will start the dialog
to ask the user to authenticate,

00:18:05.716 --> 00:18:07.476 A:middle
and then StoreKit
will also ask the user

00:18:07.476 --> 00:18:10.246 A:middle
to make sure they really want
to buy this bag of coins.

00:18:11.376 --> 00:18:12.606 A:middle
And if the user says buy,

00:18:12.906 --> 00:18:15.996 A:middle
StoreKit will send the payment
request up to the server.

00:18:16.606 --> 00:18:20.106 A:middle
So I'm going to interrupt
the smooth flow here

00:18:20.386 --> 00:18:23.926 A:middle
and open a parenthesis
about irregular activity.

00:18:24.836 --> 00:18:29.166 A:middle
So Apple has an advanced engine
to discover irregular activity

00:18:29.166 --> 00:18:30.686 A:middle
and block it before
it even happens

00:18:31.516 --> 00:18:32.596 A:middle
and that's the best case.

00:18:33.416 --> 00:18:35.656 A:middle
But there's cases where we can't
detect it before it happens

00:18:36.016 --> 00:18:36.736 A:middle
so we can't block it.

00:18:37.286 --> 00:18:39.816 A:middle
So the purchases go through
and then we have to --

00:18:40.176 --> 00:18:42.846 A:middle
we will eventually detect
it anyway so we'll have

00:18:42.846 --> 00:18:44.346 A:middle
to refund the customer.

00:18:44.626 --> 00:18:46.476 A:middle
We'll have to pull back
the function developers

00:18:46.906 --> 00:18:50.516 A:middle
and that tarnishes everybody's
reputation; tarnishes ours

00:18:50.616 --> 00:18:52.486 A:middle
and your application's
name might be associated

00:18:52.486 --> 00:18:53.016 A:middle
to the scheme.

00:18:53.016 --> 00:18:56.516 A:middle
So it is in our -- our
interests are aligned.

00:18:56.516 --> 00:18:58.806 A:middle
It is in our interest
to block the activity

00:18:58.806 --> 00:18:59.556 A:middle
as much as possible.

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

00:19:00.656 --> 00:19:04.866 A:middle
So here's one case where
we're going to be asking

00:19:04.866 --> 00:19:05.726 A:middle
for your collaboration.

00:19:06.876 --> 00:19:10.466 A:middle
Imagine three devices are
making In-App purchases

00:19:10.986 --> 00:19:13.216 A:middle
with three different --
three different Apple IDs.

00:19:14.156 --> 00:19:15.476 A:middle
There's really nothing
suspicious here.

00:19:15.766 --> 00:19:16.916 A:middle
There could be three,
could be dozens.

00:19:17.396 --> 00:19:18.616 A:middle
That's what the story's about.

00:19:18.616 --> 00:19:21.066 A:middle
Its millions of devices
making millions of purchases

00:19:21.286 --> 00:19:24.226 A:middle
with millions of Apple
IDs, so it's really hard

00:19:24.226 --> 00:19:25.976 A:middle
to block this kind of
activity when it's fraudulous.

00:19:27.166 --> 00:19:30.406 A:middle
But now if I tell you, "Oh,

00:19:30.486 --> 00:19:32.566 A:middle
all these devices
are buying gold coins

00:19:34.156 --> 00:19:37.526 A:middle
and all these devices are
crediting those gold coins

00:19:37.986 --> 00:19:40.976 A:middle
to the same game
account," then suddenly

00:19:40.976 --> 00:19:43.196 A:middle
that picture becomes
highly suspicious.

00:19:43.946 --> 00:19:45.966 A:middle
And it's something
that, if you help us,

00:19:46.106 --> 00:19:47.246 A:middle
we can detect and block.

00:19:48.256 --> 00:19:51.166 A:middle
And to do this, we've added
API in StoreKits for you

00:19:51.166 --> 00:19:54.066 A:middle
to provide us with an
opaque account identifier.

00:19:54.856 --> 00:19:56.136 A:middle
So let's be very clear.

00:19:56.756 --> 00:19:58.336 A:middle
It has to be an opaque
identifier.

00:19:58.846 --> 00:20:01.976 A:middle
That means we don't want to know
your account names or users.

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

00:19:58.846 --> 00:20:01.976 A:middle
That means we don't want to know
your account names or users.

00:20:02.046 --> 00:20:04.106 A:middle
We really don't want
to know about this.

00:20:04.836 --> 00:20:07.346 A:middle
The only thing we want to
be able to do is in fact

00:20:07.456 --> 00:20:10.346 A:middle
if multiple devices
are making purchases

00:20:10.526 --> 00:20:13.466 A:middle
for the same game accounts,
so it has to be opaque.

00:20:13.466 --> 00:20:15.246 A:middle
It has to be your user account.

00:20:15.666 --> 00:20:17.446 A:middle
So don't give us the Apple
ID, we know this already.

00:20:18.116 --> 00:20:21.146 A:middle
Don't give us your
account's name; we don't want

00:20:21.146 --> 00:20:21.826 A:middle
to know the account's name.

00:20:22.376 --> 00:20:23.796 A:middle
That's really your
business, not ours.

00:20:24.476 --> 00:20:25.736 A:middle
Don't give us the
password, obviously.

00:20:26.456 --> 00:20:29.136 A:middle
What we suggest you do
is hash the account name

00:20:29.666 --> 00:20:32.796 A:middle
so that gives you -- that gives
us an opaque identifier that's

00:20:32.796 --> 00:20:36.066 A:middle
going to be the same across
devices yet will not allow us

00:20:36.066 --> 00:20:37.096 A:middle
to identify your accounts.

00:20:38.076 --> 00:20:40.036 A:middle
And to do this, when you
create your payment object,

00:20:40.806 --> 00:20:43.586 A:middle
you only have to set the
application username property

00:20:43.996 --> 00:20:45.526 A:middle
to be that hash of
user accounts.

00:20:46.086 --> 00:20:50.486 A:middle
So let's close this in
unpleasant parenthesis

00:20:51.206 --> 00:20:53.406 A:middle
and go back to the
In-App purchase process.

00:20:53.976 --> 00:20:55.806 A:middle
So you have issued the purchase

00:20:56.526 --> 00:21:00.616 A:middle
and the store will be processing
it, and it will come back

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

00:20:56.526 --> 00:21:00.616 A:middle
and the store will be processing
it, and it will come back

00:21:00.716 --> 00:21:02.286 A:middle
to the device as a transaction.

00:21:03.516 --> 00:21:07.776 A:middle
So you will be informed, because
your payment queue server will

00:21:07.776 --> 00:21:09.626 A:middle
be invoked with data
transactions

00:21:10.166 --> 00:21:13.396 A:middle
and you'll receive no change
all in array of transactions.

00:21:13.556 --> 00:21:15.326 A:middle
The first thing it will
do usually is eat right

00:21:15.326 --> 00:21:17.226 A:middle
through those.

00:21:17.226 --> 00:21:20.216 A:middle
For each transaction
you want to check

00:21:20.216 --> 00:21:22.096 A:middle
and examine the transaction
state.

00:21:23.336 --> 00:21:27.206 A:middle
If the state is purchased it
means the transaction succeeded.

00:21:28.186 --> 00:21:32.076 A:middle
So, so far, you are accessing
the old style receipt

00:21:32.576 --> 00:21:34.116 A:middle
by calling the receipt property

00:21:34.116 --> 00:21:36.156 A:middle
of the transaction
and this is changing.

00:21:36.886 --> 00:21:39.366 A:middle
Now, the new way to
access the receipt is

00:21:39.366 --> 00:21:42.946 A:middle
to call app store receipt
URL on your main bundle,

00:21:42.946 --> 00:21:46.366 A:middle
and this gives you
a URL to the receipt

00:21:46.366 --> 00:21:48.076 A:middle
in the [inaudible] system
and then you can load it

00:21:48.136 --> 00:21:50.776 A:middle
with your favorite
NS data methods.

00:21:51.286 --> 00:21:53.936 A:middle
So that's the only
change you have to do

00:21:53.986 --> 00:21:54.886 A:middle
to get to new receipts.

00:21:55.946 --> 00:21:58.066 A:middle
And once you have the
receipts, you want to verify it.

00:21:58.876 --> 00:22:01.236 A:middle
And again, you choose the level

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

00:21:58.876 --> 00:22:01.236 A:middle
And again, you choose the level

00:22:01.236 --> 00:22:02.756 A:middle
of security you want
to implement.

00:22:02.976 --> 00:22:05.156 A:middle
You can do it as simple as you
want or as strong as you want.

00:22:05.956 --> 00:22:09.956 A:middle
You can verify on the device,
-- that's the Mac or the phone,

00:22:10.106 --> 00:22:11.876 A:middle
or you can verify
on your server.

00:22:12.626 --> 00:22:14.736 A:middle
And if you're the kind of
extremely cautious person,

00:22:14.806 --> 00:22:15.856 A:middle
you can check on both, as well.

00:22:17.256 --> 00:22:20.576 A:middle
So, first option evaluating
the receipt on the clients.

00:22:21.006 --> 00:22:21.906 A:middle
It is the preferred method.

00:22:21.906 --> 00:22:25.256 A:middle
It is the exact same validation
as you have been doing iOS X.

00:22:25.406 --> 00:22:26.586 A:middle
It is exactly as secure.

00:22:27.396 --> 00:22:31.116 A:middle
And because in-app purchases
have receipts all the time,

00:22:31.566 --> 00:22:33.576 A:middle
you can access the receipt
any time, even outside

00:22:33.576 --> 00:22:34.946 A:middle
of the purchase process.

00:22:35.276 --> 00:22:38.936 A:middle
So if you have a comics
application and user navigates

00:22:38.936 --> 00:22:41.556 A:middle
to a comic to read it, that
might be the right moment

00:22:41.556 --> 00:22:43.436 A:middle
to go check the receipt
for the comic to make sure

00:22:43.436 --> 00:22:44.886 A:middle
that the user actually
purchased the comic.

00:22:45.396 --> 00:22:47.826 A:middle
So you can do this any time
and because it's local,

00:22:47.826 --> 00:22:49.446 A:middle
of course it works offline.

00:22:50.836 --> 00:22:52.696 A:middle
Now the other solution is

00:22:53.646 --> 00:22:55.816 A:middle
to evaluate the receipt
on your own servers.

00:22:56.536 --> 00:22:59.816 A:middle
In that solution you want to
first open a secure connection

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

00:23:00.356 --> 00:23:03.326 A:middle
to your server and send a
receipt up to your server,

00:23:04.016 --> 00:23:07.136 A:middle
and then your server can turn
around and forward the receipts

00:23:07.136 --> 00:23:08.586 A:middle
to the Apple validation servers.

00:23:09.576 --> 00:23:12.226 A:middle
And what the evaluation servers
do is they crack open the

00:23:12.226 --> 00:23:14.956 A:middle
receipts and they return a
pay load, adjacent pay load,

00:23:15.076 --> 00:23:17.906 A:middle
easy two parts, that contains
all the fields of the receipts

00:23:18.316 --> 00:23:20.486 A:middle
and results go to tell you
oh that receipt is valid.

00:23:21.556 --> 00:23:23.766 A:middle
So then your server
can process that.

00:23:24.896 --> 00:23:26.556 A:middle
In addition, if you are dealing

00:23:26.556 --> 00:23:28.016 A:middle
with auto-renewable
subscriptions,

00:23:28.566 --> 00:23:30.616 A:middle
your server can send
a shared secret

00:23:30.786 --> 00:23:32.156 A:middle
to the Apple validation servers

00:23:32.776 --> 00:23:35.296 A:middle
and that will tell the Apple
validation servers that "oh,

00:23:35.696 --> 00:23:37.316 A:middle
if the transaction
auto-renewed --

00:23:37.646 --> 00:23:40.796 A:middle
I'm sorry if the subscription
was renewed then the Apple

00:23:40.796 --> 00:23:42.886 A:middle
validation server will
return the renewed receipt

00:23:42.886 --> 00:23:43.416 A:middle
to the server."

00:23:43.416 --> 00:23:45.026 A:middle
And that's very important

00:23:45.776 --> 00:23:48.536 A:middle
because that means the server
can manage the subscription

00:23:48.536 --> 00:23:51.126 A:middle
complete server side without the
device being involved anymore.

00:23:51.936 --> 00:23:55.076 A:middle
And if you are a newsstand
application it means the server

00:23:55.076 --> 00:23:57.336 A:middle
can determine which
issues to push to devices

00:23:57.916 --> 00:23:58.766 A:middle
so it's very convenient.

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

00:24:00.076 --> 00:24:03.936 A:middle
So again, you want to validate
the receipt of your server

00:24:04.846 --> 00:24:07.196 A:middle
and you own the secure connect.

00:24:07.266 --> 00:24:08.686 A:middle
You only keep it
secured as needed

00:24:09.086 --> 00:24:10.846 A:middle
so of course we recommend
you use SSL,

00:24:10.996 --> 00:24:12.546 A:middle
extended verification
certificates,

00:24:12.546 --> 00:24:14.896 A:middle
certificate pinning,
whatever you want to do

00:24:14.896 --> 00:24:16.606 A:middle
to ensure you're talking
to your own server

00:24:16.606 --> 00:24:17.896 A:middle
and the content hasn't
been tampered with.

00:24:19.156 --> 00:24:21.886 A:middle
As we saw it's great for
auto renewable subscriptions

00:24:21.886 --> 00:24:24.426 A:middle
because you can move all the
subscription logic server side.

00:24:25.176 --> 00:24:27.326 A:middle
But the downside is because
you're talking to a server,

00:24:27.326 --> 00:24:30.196 A:middle
you have to be online so the
application has to be aware

00:24:30.196 --> 00:24:33.976 A:middle
that if it's offline it will
have to deal with the case.

00:24:34.136 --> 00:24:39.336 A:middle
Now, what you should absolutely
never do is check the receipt

00:24:39.606 --> 00:24:41.666 A:middle
from your application directly

00:24:41.666 --> 00:24:43.106 A:middle
against the Apple
validation servers.

00:24:44.506 --> 00:24:44.996 A:middle
Why is that?

00:24:45.816 --> 00:24:48.386 A:middle
Well, you don't own both
ends of the transaction --

00:24:48.386 --> 00:24:50.776 A:middle
of the connection so you can't
make that connection secure,

00:24:51.326 --> 00:24:52.226 A:middle
that means you can't trust it.

00:24:52.356 --> 00:24:55.996 A:middle
And if you're dealing with
subscriptions then you will have

00:24:56.046 --> 00:24:58.216 A:middle
to embed your shared secret
into your application,

00:24:58.526 --> 00:24:59.326 A:middle
which is kind of fragile.

00:24:59.796 --> 00:25:01.436 A:middle
And you want to send
it across a connection

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

00:24:59.796 --> 00:25:01.436 A:middle
And you want to send
it across a connection

00:25:01.436 --> 00:25:02.606 A:middle
that you really know
you can trust.

00:25:03.086 --> 00:25:06.166 A:middle
So that's two, actually
three reasons not to do this.

00:25:07.436 --> 00:25:11.876 A:middle
And again, validating receipt
is not very hard, but you have

00:25:11.876 --> 00:25:13.426 A:middle
to get it right and
there's a bunch of APIs

00:25:13.426 --> 00:25:15.296 A:middle
and tools you can use
to help you with this.

00:25:15.806 --> 00:25:18.216 A:middle
So again, I'm going to refer
you to the session in Presidio

00:25:18.216 --> 00:25:20.826 A:middle
at 2:00 PM to learn all
the, you know, ins and outs

00:25:20.826 --> 00:25:21.656 A:middle
of receipt validation.

00:25:23.656 --> 00:25:26.976 A:middle
All right, so we have determined
that the receipt is valid

00:25:28.296 --> 00:25:29.886 A:middle
and now it's time
to deliver the goods

00:25:29.886 --> 00:25:31.016 A:middle
because the user paid for them.

00:25:31.656 --> 00:25:33.436 A:middle
So there's five choices here.

00:25:34.146 --> 00:25:36.356 A:middle
If you just have to unlock
something in your application

00:25:36.356 --> 00:25:39.286 A:middle
like a weapon, then just
unlock it, that's very easy.

00:25:40.136 --> 00:25:44.726 A:middle
Now, if you want to download
digital content then you have

00:25:44.726 --> 00:25:45.946 A:middle
four APIs you can use.

00:25:46.326 --> 00:25:49.286 A:middle
You can use host In-App
purchases as we saw earlier.

00:25:50.126 --> 00:25:52.176 A:middle
We can use newsstand
kit for periodicals.

00:25:53.046 --> 00:25:56.016 A:middle
In iOS 7 we're adding a new
API to download contents

00:25:56.086 --> 00:25:59.216 A:middle
in the background and you
can also use the legacy

00:25:59.216 --> 00:25:59.916 A:middle
classic downloads.

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

00:26:00.796 --> 00:26:02.276 A:middle
So first, host In-App purchases.

00:26:02.936 --> 00:26:04.556 A:middle
They are just regular
In-App purchases

00:26:04.766 --> 00:26:06.326 A:middle
with content associated.

00:26:06.776 --> 00:26:08.196 A:middle
So it comes from
the Apple servers.

00:26:08.656 --> 00:26:11.326 A:middle
That's great because if the
application becomes an overnight

00:26:11.376 --> 00:26:15.196 A:middle
hit, which I honestly wish it
would happens, you won't have

00:26:15.196 --> 00:26:19.316 A:middle
to scramble to buy servers and
bandwidth overnight and try

00:26:19.316 --> 00:26:21.726 A:middle
to kind of, you know, face
all the server downtime

00:26:21.726 --> 00:26:24.546 A:middle
and these issues because
Apple will serve these In-App

00:26:24.546 --> 00:26:26.076 A:middle
purchases, these
host In-App purchases

00:26:26.076 --> 00:26:27.666 A:middle
and we'll scale them
necessarily.

00:26:29.486 --> 00:26:31.426 A:middle
And also because they're
downloaded through StoreKit

00:26:31.786 --> 00:26:34.776 A:middle
and StoreKit's a background API,
they will continue downloading

00:26:34.846 --> 00:26:35.706 A:middle
in the background, as well.

00:26:36.716 --> 00:26:38.486 A:middle
And they are in-app purchases
so they go through review.

00:26:39.236 --> 00:26:41.306 A:middle
And there's one limit to those.

00:26:42.046 --> 00:26:43.296 A:middle
It's that you can only have --

00:26:43.626 --> 00:26:46.466 A:middle
I mean each In-App
purchase can only be

00:26:46.466 --> 00:26:47.766 A:middle
up to two gigabytes in size.

00:26:47.896 --> 00:26:50.976 A:middle
You can have as many products as
you want, but each of them has

00:26:50.976 --> 00:26:54.126 A:middle
to be -- is limited
to two gigabytes.

00:26:54.276 --> 00:26:57.966 A:middle
So quick overview how the API
works so you can know what

00:26:57.966 --> 00:27:00.096 A:middle
to look for in the
future, when you get --

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

00:26:57.966 --> 00:27:00.096 A:middle
to look for in the
future, when you get --

00:27:00.516 --> 00:27:04.296 A:middle
when you're payment of
server fires with updates

00:27:04.296 --> 00:27:07.806 A:middle
to transactions, if a
transaction is associated

00:27:07.806 --> 00:27:09.306 A:middle
with a host In-App purchase,

00:27:09.786 --> 00:27:11.736 A:middle
the transaction will have
an array of downloads.

00:27:12.686 --> 00:27:15.736 A:middle
And to start them you can
just tell the payment cues

00:27:15.736 --> 00:27:17.106 A:middle
to start the downloads
with this array,

00:27:18.326 --> 00:27:19.716 A:middle
and then the downloads
will start,

00:27:19.906 --> 00:27:23.936 A:middle
and as they progress your
payment queue server will fire

00:27:23.936 --> 00:27:25.456 A:middle
with update downloads.

00:27:26.236 --> 00:27:28.176 A:middle
And each of these
download objects

00:27:28.176 --> 00:27:30.676 A:middle
in the array you
will find a progress,

00:27:31.326 --> 00:27:35.006 A:middle
you'll find the time
remaining, you'll find the state

00:27:35.506 --> 00:27:37.016 A:middle
and if things go wrong,
you'll find the error.

00:27:38.396 --> 00:27:43.636 A:middle
When the state reaches download
state finished then you can

00:27:43.636 --> 00:27:46.776 A:middle
access another property called
content URL that tells you

00:27:46.776 --> 00:27:47.666 A:middle
where the file landed

00:27:47.666 --> 00:27:48.976 A:middle
in the file system
so you can access it.

00:27:51.166 --> 00:27:52.216 A:middle
Now, if you're dealing

00:27:52.216 --> 00:27:53.706 A:middle
with periodicals you
have another option.

00:27:53.706 --> 00:27:56.066 A:middle
You can use Newsstand
Kit downloads.

00:27:56.596 --> 00:27:59.386 A:middle
Newsstand Kits downloads
from your own server

00:27:59.386 --> 00:28:02.516 A:middle
to your application
in the background

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

00:27:59.386 --> 00:28:02.516 A:middle
to your application
in the background

00:28:02.666 --> 00:28:04.526 A:middle
and gives you a fine-grain
control

00:28:04.526 --> 00:28:05.996 A:middle
of the credentials
and authentication.

00:28:06.656 --> 00:28:09.086 A:middle
And the bonus that
Newsstand Kit offers is

00:28:09.086 --> 00:28:12.126 A:middle
that when the download finishes,
the application gets woken

00:28:12.126 --> 00:28:16.666 A:middle
up so it has a chance to look
at the file and updates its icon

00:28:16.666 --> 00:28:18.546 A:middle
in the Newsstand folder
to be the latest cover.

00:28:20.276 --> 00:28:22.156 A:middle
So again, high level
overview of the API.

00:28:22.936 --> 00:28:24.816 A:middle
It all starts with a
Newsstand Kit library.

00:28:25.976 --> 00:28:27.556 A:middle
And when you want to
download something,

00:28:27.716 --> 00:28:30.766 A:middle
you want to first add a
Newsstand Kit issue with a name

00:28:30.766 --> 00:28:32.866 A:middle
and a date that you can get
from the direct response.

00:28:34.186 --> 00:28:36.076 A:middle
Then you want to
wrap the download URL

00:28:36.156 --> 00:28:37.556 A:middle
into an [inaudible]
recall subject.

00:28:38.166 --> 00:28:40.336 A:middle
And with this subject, you
can create Newsstand Kit asset

00:28:40.406 --> 00:28:41.086 A:middle
download object.

00:28:41.926 --> 00:28:44.746 A:middle
So if you followed the
library contains the issues

00:28:44.746 --> 00:28:46.606 A:middle
and the issues contain
Asset downloads.

00:28:47.626 --> 00:28:50.216 A:middle
So when you're ready to
download, you can just scroll

00:28:50.216 --> 00:28:53.566 A:middle
down to the delegates on the
download, and this will begin

00:28:53.566 --> 00:28:55.736 A:middle
to download and this make
your object the delegate,

00:28:56.706 --> 00:28:59.576 A:middle
so it will get informed
whenever that makes progress

00:28:59.576 --> 00:29:00.346 A:middle
or finishes downloading.

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

00:28:59.576 --> 00:29:00.346 A:middle
or finishes downloading.

00:29:02.376 --> 00:29:06.136 A:middle
So we mentioned that
Newsstand Kits was downloading

00:29:06.136 --> 00:29:06.706 A:middle
in the background.

00:29:06.886 --> 00:29:08.596 A:middle
So potentially the
application could exit

00:29:08.596 --> 00:29:10.236 A:middle
and then launch again.

00:29:10.806 --> 00:29:13.116 A:middle
So the question is how does
the application reconnect

00:29:13.266 --> 00:29:15.166 A:middle
to downloads that have been
progressing in the background.

00:29:16.306 --> 00:29:19.386 A:middle
Well, the Newsstand Kit library,
again, is the starting point.

00:29:19.936 --> 00:29:21.566 A:middle
It keeps -- it maintains
for you,

00:29:21.566 --> 00:29:25.216 A:middle
a list of the downloading assets
so you can access this list

00:29:25.216 --> 00:29:27.636 A:middle
when you launch your application
and for each of those,

00:29:27.966 --> 00:29:29.986 A:middle
we call the same method,
download with delegates.

00:29:30.446 --> 00:29:32.506 A:middle
This will reconnect
you to download,

00:29:33.176 --> 00:29:34.366 A:middle
make your object the delegate,

00:29:34.556 --> 00:29:36.526 A:middle
and all the delegate
methods will fire exactly

00:29:36.526 --> 00:29:38.976 A:middle
as the application and never
go into the background.

00:29:39.756 --> 00:29:43.386 A:middle
So it's very simple, but
it's only for periodicals.

00:29:44.036 --> 00:29:46.946 A:middle
Now, in iOS 7 we've
added a new API

00:29:47.396 --> 00:29:48.376 A:middle
to download in the background.

00:29:49.036 --> 00:29:52.376 A:middle
So it's only iOS, it lets you
download from your own servers.

00:29:53.046 --> 00:29:54.446 A:middle
It lets you download
in foreground

00:29:54.446 --> 00:29:57.296 A:middle
and in the background, and you
can control the authentication

00:29:57.296 --> 00:29:57.976 A:middle
pretty precisely.

00:29:59.076 --> 00:30:01.756 A:middle
And an added benefit
is its power efficient.

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

00:29:59.076 --> 00:30:01.756 A:middle
And an added benefit
is its power efficient.

00:30:02.046 --> 00:30:04.036 A:middle
So as long as the application
is in the foreground,

00:30:04.456 --> 00:30:05.466 A:middle
then the content is urgent,

00:30:05.536 --> 00:30:06.866 A:middle
we'll get it as fast
as possible.

00:30:06.866 --> 00:30:09.596 A:middle
But if the user backgrounds
the application,

00:30:09.716 --> 00:30:11.636 A:middle
then maybe that content
isn't that urgent anymore,

00:30:12.056 --> 00:30:14.056 A:middle
so iOS will use its
best judgment

00:30:14.116 --> 00:30:16.006 A:middle
to find the appropriate
moments to download this

00:30:16.006 --> 00:30:19.876 A:middle
without draining the battery.

00:30:20.376 --> 00:30:23.606 A:middle
So again, a high level
overview of the API.

00:30:24.106 --> 00:30:26.166 A:middle
To initiate the download,
you first want

00:30:26.166 --> 00:30:28.886 A:middle
to create an NSURL session
configuration object

00:30:29.596 --> 00:30:32.636 A:middle
and we have a factory method for
this that creates one for you

00:30:32.636 --> 00:30:34.616 A:middle
that is pre-configured to
continue in the background.

00:30:35.686 --> 00:30:37.696 A:middle
And all you give it is an
identifier that's going

00:30:37.696 --> 00:30:39.126 A:middle
to be very useful
for reconnecting

00:30:39.206 --> 00:30:40.456 A:middle
when the application
launches again.

00:30:41.866 --> 00:30:44.026 A:middle
And then the real
object you want

00:30:44.026 --> 00:30:47.186 A:middle
to create is an NSURL session
and you can create this

00:30:47.186 --> 00:30:48.226 A:middle
with a configuration object.

00:30:49.016 --> 00:30:50.636 A:middle
You give it your
object as a delegate

00:30:51.336 --> 00:30:52.686 A:middle
and you can give
it the delegate cue

00:30:52.796 --> 00:30:55.256 A:middle
so that you know what cue the
delegate methods will fire on,

00:30:55.406 --> 00:30:56.966 A:middle
very convenient for
multithreading.

00:30:58.276 --> 00:31:01.626 A:middle
So again, you want to wrap your
URL into a URL request object

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

00:30:58.276 --> 00:31:01.626 A:middle
So again, you want to wrap your
URL into a URL request object

00:31:02.296 --> 00:31:06.206 A:middle
and you want to create an
NSURL session download task.

00:31:07.076 --> 00:31:09.286 A:middle
That's an object that as
soon as you create it,

00:31:09.536 --> 00:31:11.976 A:middle
will start downloading into
temporary file location.

00:31:13.076 --> 00:31:15.556 A:middle
And because you are
the delegates,

00:31:16.056 --> 00:31:18.366 A:middle
your delegate methods will fire
every time there's progress

00:31:18.436 --> 00:31:21.806 A:middle
so didWriteData is the right
place to compute the progress

00:31:21.806 --> 00:31:22.816 A:middle
and display to the user.

00:31:23.516 --> 00:31:26.606 A:middle
When the download finishes
you'll get didFinishDownloading

00:31:26.606 --> 00:31:29.226 A:middle
to your URL and this
will give you the URL

00:31:29.226 --> 00:31:31.436 A:middle
of the place the
download [inaudible] in.

00:31:31.856 --> 00:31:35.286 A:middle
Usually the first thing you want
to do there is access the file

00:31:35.286 --> 00:31:36.376 A:middle
and copy to a safe place.

00:31:36.906 --> 00:31:40.626 A:middle
And again, this application
downloads in the background

00:31:41.126 --> 00:31:44.356 A:middle
so you have to be able to
reconnect to the downloads,

00:31:44.886 --> 00:31:47.886 A:middle
and it's very easy
with this application.

00:31:48.476 --> 00:31:51.286 A:middle
It happens at the UI
application delegate level.

00:31:51.286 --> 00:31:53.486 A:middle
So the UI application
protocol go to new method

00:31:54.166 --> 00:31:55.456 A:middle
and your application delegates.

00:31:55.876 --> 00:31:57.776 A:middle
When the application
launches, we'll get called

00:31:57.816 --> 00:32:00.226 A:middle
with handle events with
background URL session.

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

00:31:57.816 --> 00:32:00.226 A:middle
with handle events with
background URL session.

00:32:00.946 --> 00:32:02.576 A:middle
This will give you the
identifier for the session

00:32:02.576 --> 00:32:04.086 A:middle
that just -- that you
have to reconnect to

00:32:04.586 --> 00:32:05.516 A:middle
and a completion handler.

00:32:06.606 --> 00:32:10.506 A:middle
So you want to use the same
code to recreate the session

00:32:11.006 --> 00:32:12.446 A:middle
and this will reconnect
you to the session.

00:32:12.446 --> 00:32:14.276 A:middle
And because you passed
your objects

00:32:14.326 --> 00:32:16.986 A:middle
as delegates your delegate
methods will start firing again

00:32:16.986 --> 00:32:19.766 A:middle
exactly as if the
application had never been put

00:32:19.766 --> 00:32:22.096 A:middle
in the background -- so very
convenient, very simple.

00:32:23.236 --> 00:32:25.946 A:middle
Once all the delegate
methods are finished firing

00:32:25.946 --> 00:32:28.926 A:middle
and you finish processing and
updating the UI and do all

00:32:28.926 --> 00:32:31.256 A:middle
that you have to do, you only
call the completion handler.

00:32:31.846 --> 00:32:35.096 A:middle
So for now the best thing you
can do is store it somewhere

00:32:35.096 --> 00:32:38.336 A:middle
so you can use it later.

00:32:38.586 --> 00:32:41.606 A:middle
So we just scratched
the surface of the API

00:32:41.606 --> 00:32:43.386 A:middle
and it has many more
bounties to offer.

00:32:43.796 --> 00:32:44.836 A:middle
So if you want to know more

00:32:44.836 --> 00:32:47.846 A:middle
of this API download new
background then you're welcome

00:32:47.846 --> 00:32:51.496 A:middle
to watch a session about the
Foundation Networking session --

00:32:51.496 --> 00:32:53.326 A:middle
the video from the session
that happened yesterday.

00:32:53.886 --> 00:32:58.856 A:middle
And finally, you can keep
using the legacy download APIs,

00:32:59.416 --> 00:33:00.476 A:middle
but it's not a good idea,

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

00:32:59.416 --> 00:33:00.476 A:middle
but it's not a good idea,

00:33:00.476 --> 00:33:04.436 A:middle
actually because when the
application gets backgrounded,

00:33:05.016 --> 00:33:08.886 A:middle
the download stops so
that means you know this.

00:33:08.886 --> 00:33:11.596 A:middle
Your user is stuck
looking at a progress bar

00:33:11.926 --> 00:33:13.726 A:middle
and user is afraid
to exit the app.

00:33:13.726 --> 00:33:14.886 A:middle
User's afraid to do anything

00:33:14.886 --> 00:33:15.856 A:middle
because it will stop
the download.

00:33:16.336 --> 00:33:18.106 A:middle
So it's not the best experience.

00:33:18.886 --> 00:33:21.246 A:middle
Now of course some applications
use begin background task

00:33:21.376 --> 00:33:23.636 A:middle
and they use it to get
some background time

00:33:23.636 --> 00:33:24.576 A:middle
to finish downloading,

00:33:25.246 --> 00:33:27.896 A:middle
but it was never meant
for doing downloads.

00:33:28.236 --> 00:33:29.356 A:middle
In fact, in iOS 7,

00:33:29.526 --> 00:33:31.906 A:middle
begin background tasks
has changed semantics.

00:33:32.466 --> 00:33:34.456 A:middle
It no longer prevents
the device from sleeping.

00:33:35.226 --> 00:33:38.356 A:middle
So you will get your 10 minutes,
but maybe not right now.

00:33:38.816 --> 00:33:42.026 A:middle
Maybe you'll get them when the
iPod touch has left the home

00:33:42.026 --> 00:33:43.446 A:middle
and has no Wi-Fi
connection anymore.

00:33:43.796 --> 00:33:46.976 A:middle
So for downloads, not
a very good experience.

00:33:47.636 --> 00:33:50.926 A:middle
So we recommend that you
use the other options now

00:33:50.926 --> 00:33:52.316 A:middle
that we have really
good options.

00:33:52.956 --> 00:33:58.056 A:middle
And finally you have
the [inaudible] assets

00:33:58.446 --> 00:34:00.186 A:middle
and the final step is to
finish this transaction.

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

00:33:58.446 --> 00:34:00.186 A:middle
and the final step is to
finish this transaction.

00:34:00.386 --> 00:34:01.206 A:middle
Again, not change here.

00:34:01.936 --> 00:34:02.986 A:middle
You have to finish
the transaction

00:34:02.986 --> 00:34:04.846 A:middle
by calling finish transaction.

00:34:05.826 --> 00:34:10.596 A:middle
And it's the right thing to
do, but if you don't do it,

00:34:10.746 --> 00:34:11.496 A:middle
it's actually terrible.

00:34:11.576 --> 00:34:14.366 A:middle
If you don't do it, the end
finish transactions will stack

00:34:14.366 --> 00:34:15.786 A:middle
up and you have all this backlog

00:34:15.786 --> 00:34:18.806 A:middle
and every time you launch your
application StoreKit will notify

00:34:18.806 --> 00:34:21.716 A:middle
your payment queue server
every single application launch

00:34:21.716 --> 00:34:23.356 A:middle
of every single unfinished
transaction,

00:34:23.786 --> 00:34:25.246 A:middle
and this slows down your app.

00:34:25.636 --> 00:34:29.176 A:middle
So, for the user's -- user's
stuck waiting, it's not great,

00:34:29.916 --> 00:34:31.846 A:middle
but also StoreKit will
have to talk to the server

00:34:31.846 --> 00:34:32.926 A:middle
to confirm the transactions.

00:34:33.346 --> 00:34:36.806 A:middle
So if user is on cellular
you will incur some cellular

00:34:36.806 --> 00:34:37.505 A:middle
data consumption.

00:34:37.755 --> 00:34:40.696 A:middle
So there's no point
in doing this.

00:34:40.735 --> 00:34:43.206 A:middle
So it's very simple to just
finish the transactions.

00:34:43.686 --> 00:34:48.755 A:middle
And that concludes the in-app
purchase process overview.

00:34:49.956 --> 00:34:53.476 A:middle
So there's one best
practice I'd like to mention.

00:34:54.176 --> 00:34:57.056 A:middle
To get your delegate
method's goal you have

00:34:57.085 --> 00:34:58.286 A:middle
to install the payment
cube server.

00:34:58.516 --> 00:35:01.086 A:middle
And you guys are already
doing this, but don't wait

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

00:34:58.516 --> 00:35:01.086 A:middle
And you guys are already
doing this, but don't wait

00:35:01.326 --> 00:35:03.046 A:middle
to make a purchase
to install it.

00:35:03.046 --> 00:35:05.166 A:middle
You have to do it right when
the application launches

00:35:05.796 --> 00:35:08.146 A:middle
because as soon as the
application launches,

00:35:08.236 --> 00:35:10.906 A:middle
it may receive transaction
any time.

00:35:11.746 --> 00:35:13.636 A:middle
Classic example,
you try to make a --

00:35:13.636 --> 00:35:17.576 A:middle
you try to make a transaction
and you lost the connection.

00:35:18.136 --> 00:35:19.886 A:middle
So transaction will
have completed

00:35:19.946 --> 00:35:21.876 A:middle
when the application
was not running anymore.

00:35:21.876 --> 00:35:23.706 A:middle
So the next time you launch it,
you will find the transaction.

00:35:23.706 --> 00:35:24.826 A:middle
You should process
it; otherwise,

00:35:24.826 --> 00:35:26.026 A:middle
the user has lost some content.

00:35:27.176 --> 00:35:30.336 A:middle
The user might have received
a gift code and redeemed

00:35:30.336 --> 00:35:31.766 A:middle
that gift code inside
the app store.

00:35:32.376 --> 00:35:33.956 A:middle
And when the user
launches the application,

00:35:33.956 --> 00:35:36.966 A:middle
they expect that gift to be
there so you have to process it

00:35:36.966 --> 00:35:38.346 A:middle
as soon as the application
launches.

00:35:38.916 --> 00:35:42.296 A:middle
And if you do periodicals then
when you launch the application,

00:35:42.666 --> 00:35:44.436 A:middle
the subscription might
have renewed and you want

00:35:44.436 --> 00:35:45.236 A:middle
to take this into account.

00:35:45.846 --> 00:35:47.676 A:middle
So as soon as you
get app, you know,

00:35:47.786 --> 00:35:49.426 A:middle
as soon as you get app
did finish launching,

00:35:49.846 --> 00:35:54.896 A:middle
it's the right moment to
install the payment cube server.

00:35:54.896 --> 00:35:58.096 A:middle
And finally, for real,
restoring in-app purchases --

00:35:58.626 --> 00:36:01.336 A:middle
nothing changes except
the API you call

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

00:35:58.626 --> 00:36:01.336 A:middle
nothing changes except
the API you call

00:36:01.336 --> 00:36:02.926 A:middle
to get the receipt
so no change here.

00:36:04.976 --> 00:36:08.206 A:middle
And that wraps our kind
of quick over flight

00:36:08.206 --> 00:36:10.346 A:middle
of the in-app purchase process.

00:36:11.216 --> 00:36:15.756 A:middle
Now I'd like to discuss and
demystify the test environment

00:36:15.756 --> 00:36:17.696 A:middle
because it's something
that's a very powerful tool.

00:36:17.696 --> 00:36:18.746 A:middle
It's something you
should really use

00:36:18.746 --> 00:36:20.856 A:middle
to make sure your in-app
purchases behave correctly.

00:36:20.976 --> 00:36:25.686 A:middle
So today I'm going to call
it SendBox, but it's not

00:36:25.686 --> 00:36:27.176 A:middle
to be confused with
the other SendBox,

00:36:27.226 --> 00:36:30.546 A:middle
the one that limits access to
your application resources.

00:36:30.996 --> 00:36:33.936 A:middle
So SendBox today means the test
environment of the app store.

00:36:34.446 --> 00:36:37.656 A:middle
So the app store has a
production environment

00:36:38.506 --> 00:36:40.586 A:middle
and its evil twin, the SendBox.

00:36:41.486 --> 00:36:43.486 A:middle
So when the application
is talking

00:36:43.486 --> 00:36:46.656 A:middle
to the store they can be
talking to either the SendBox

00:36:47.536 --> 00:36:49.156 A:middle
or the production store.

00:36:49.966 --> 00:36:53.386 A:middle
How do you determine
which one is very simple?

00:36:53.836 --> 00:36:55.926 A:middle
It's based on the
certificate that was used

00:36:56.016 --> 00:36:57.576 A:middle
for signing your application.

00:36:58.276 --> 00:37:00.276 A:middle
So when you develop your
application it is signed

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

00:36:58.276 --> 00:37:00.276 A:middle
So when you develop your
application it is signed

00:37:00.276 --> 00:37:01.456 A:middle
with the development
certificate.

00:37:02.196 --> 00:37:05.396 A:middle
So the OS would point
your application

00:37:05.556 --> 00:37:07.956 A:middle
to the production store
-- sorry, to the SendBox.

00:37:08.496 --> 00:37:10.156 A:middle
Development hit SendBox.

00:37:10.796 --> 00:37:12.396 A:middle
Now, if your application
is signed

00:37:12.906 --> 00:37:14.556 A:middle
with app store certificates

00:37:15.056 --> 00:37:16.516 A:middle
and the only way
this could happen is

00:37:16.766 --> 00:37:19.286 A:middle
if the user downloads the
application from the app store,

00:37:20.236 --> 00:37:22.896 A:middle
then the OS will point it
to the production store.

00:37:23.906 --> 00:37:25.876 A:middle
And if you're ever unsure
because you've messed

00:37:25.876 --> 00:37:28.646 A:middle
up some accounts or something,
just make internet purchase

00:37:29.456 --> 00:37:32.526 A:middle
because you'll hear this dialog
and if you see this line,

00:37:32.946 --> 00:37:34.486 A:middle
it means you're hitting
the SendBox.

00:37:35.656 --> 00:37:37.236 A:middle
So what's the main difference?

00:37:38.296 --> 00:37:41.096 A:middle
First of all, the SendBox does
not charge you, which is great

00:37:41.096 --> 00:37:42.486 A:middle
because you want to test
as much as possible.

00:37:43.066 --> 00:37:46.296 A:middle
And -- yeah, you can laugh.

00:37:46.916 --> 00:37:52.046 A:middle
And if you get a SendBox
receipt is it not backed

00:37:52.106 --> 00:37:55.196 A:middle
by a financial transaction,
therefore, it will not validate

00:37:55.376 --> 00:37:57.926 A:middle
against the production
store validation servers.

00:37:58.946 --> 00:38:00.576 A:middle
So you can feel free
to use the SendBox.

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

00:37:58.946 --> 00:38:00.576 A:middle
So you can feel free
to use the SendBox.

00:38:00.646 --> 00:38:02.366 A:middle
These receipts will not
validate against production.

00:38:03.726 --> 00:38:06.286 A:middle
And if you want to implement
the Volume Purchase Program,

00:38:06.716 --> 00:38:09.086 A:middle
then we mentioned that the
receipt will contain new fields.

00:38:09.626 --> 00:38:11.916 A:middle
And we have API in the SendBox

00:38:11.916 --> 00:38:15.236 A:middle
to request a receipt that's
either expired or revoke

00:38:15.686 --> 00:38:17.996 A:middle
so that the application
can test how it behaves

00:38:17.996 --> 00:38:19.486 A:middle
when licenses are
expired or revoked.

00:38:20.236 --> 00:38:22.946 A:middle
And of course, if you get a
revoked receipt from SendBox,

00:38:22.946 --> 00:38:25.606 A:middle
iOS will not prevent your
application from launching.

00:38:25.606 --> 00:38:28.946 A:middle
Otherwise, you could
never test your code.

00:38:29.166 --> 00:38:31.956 A:middle
And the final thing to
know about SendBox is

00:38:31.956 --> 00:38:36.126 A:middle
that it makes time
fly faster, for real.

00:38:36.446 --> 00:38:37.756 A:middle
This is great if you
do subscriptions.

00:38:38.196 --> 00:38:42.526 A:middle
The rule of thumb is that
one year becomes one hour,

00:38:43.246 --> 00:38:45.316 A:middle
so a yearly subscription
renews every hour

00:38:46.006 --> 00:38:48.966 A:middle
and it will renew six
times, and stop renewing

00:38:49.676 --> 00:38:52.326 A:middle
so you can test your code
for renewing subscriptions

00:38:52.736 --> 00:38:55.096 A:middle
and you can test your code when
a subscription stops renewing.

00:38:57.096 --> 00:39:01.976 A:middle
So in practice, that means
you have to first log

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

00:38:57.096 --> 00:39:01.976 A:middle
So in practice, that means
you have to first log

00:39:01.976 --> 00:39:04.276 A:middle
into Access Connect,
create a test user,

00:39:04.956 --> 00:39:06.916 A:middle
test users are not valid
in the production store,

00:39:06.916 --> 00:39:09.176 A:middle
there are two different sets,
it's a source of confusion.

00:39:09.176 --> 00:39:10.376 A:middle
Its two different sets of users.

00:39:11.196 --> 00:39:12.666 A:middle
Then you want to
create a product.

00:39:12.666 --> 00:39:16.246 A:middle
You want to build your app
and you want to sign it.

00:39:16.326 --> 00:39:18.726 A:middle
And on the Mac there's
one extra step.

00:39:18.776 --> 00:39:21.156 A:middle
On the Mac you have to
launch the application once

00:39:21.156 --> 00:39:24.806 A:middle
from the finder, and when the
application detects there's no

00:39:24.806 --> 00:39:26.736 A:middle
receipt and exits
with the magic code,

00:39:27.236 --> 00:39:30.386 A:middle
the finder will intercept this
magic code and fetch a receipt

00:39:30.386 --> 00:39:31.746 A:middle
for the application
and relaunch it.

00:39:32.346 --> 00:39:35.086 A:middle
That is how you get a receipt
on the Mac the first time.

00:39:35.086 --> 00:39:36.636 A:middle
If you launch the
application from Xcode

00:39:37.076 --> 00:39:38.826 A:middle
and the application
exists with a magic code,

00:39:39.166 --> 00:39:41.416 A:middle
the Xcode will just like
intercept this and submit,

00:39:41.416 --> 00:39:42.236 A:middle
and nothing will happen.

00:39:42.416 --> 00:39:43.686 A:middle
So launch the first
time in the finder.

00:39:43.806 --> 00:39:45.276 A:middle
That's a very frequent,
you know,

00:39:45.276 --> 00:39:46.906 A:middle
kind of head-scratching case.

00:39:47.466 --> 00:39:48.266 A:middle
And that's all you have to do.

00:39:48.516 --> 00:39:50.946 A:middle
Next thing is just buy
products, as much as you can.

00:39:51.966 --> 00:39:57.936 A:middle
So, to summarize, when you're
developing the application is

00:39:58.106 --> 00:39:59.976 A:middle
signed by your development
certificate.

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

00:40:01.516 --> 00:40:03.736 A:middle
So the OS will point
it to the SendBox

00:40:04.606 --> 00:40:07.056 A:middle
and you can get a SendBox
receipt and forward it

00:40:07.056 --> 00:40:08.546 A:middle
to your own test server.

00:40:09.156 --> 00:40:11.476 A:middle
And your test server
will let you get

00:40:11.476 --> 00:40:13.346 A:middle
that receipt against
the SendBox.

00:40:13.826 --> 00:40:15.886 A:middle
So, things just work.

00:40:16.976 --> 00:40:19.786 A:middle
Once the application is live
in the store, it is signed

00:40:19.786 --> 00:40:23.016 A:middle
by the store so if the
production application,

00:40:23.186 --> 00:40:24.496 A:middle
you will hit the
production store.

00:40:24.876 --> 00:40:26.136 A:middle
You will get production
receipts,

00:40:26.136 --> 00:40:29.086 A:middle
you will form those production
servers and you'll validate

00:40:29.086 --> 00:40:30.976 A:middle
against the production
store, everything works.

00:40:32.076 --> 00:40:34.126 A:middle
Now there's one case you
really have to be aware

00:40:34.126 --> 00:40:36.256 A:middle
of because it affects
app review.

00:40:36.766 --> 00:40:39.186 A:middle
During app review,

00:40:39.426 --> 00:40:40.806 A:middle
your application
comes from the store.

00:40:40.906 --> 00:40:41.996 A:middle
So it is production signed.

00:40:42.716 --> 00:40:46.246 A:middle
But the reviewers don't want
to charge anyone for reviewing.

00:40:46.296 --> 00:40:48.006 A:middle
So they will point the
application to SendBox.

00:40:48.796 --> 00:40:51.976 A:middle
So your production application
might get a SendBox receipt

00:40:52.466 --> 00:40:55.266 A:middle
and forward it to your
own production servers.

00:40:55.866 --> 00:40:57.266 A:middle
And if the server
tries to validate

00:40:57.266 --> 00:40:59.906 A:middle
that against the Apple
production validation servers,

00:40:59.906 --> 00:41:02.476 A:middle
it will fail, and you
don't want this to fail

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

00:40:59.906 --> 00:41:02.476 A:middle
it will fail, and you
don't want this to fail

00:41:02.476 --> 00:41:03.546 A:middle
because this will
fail at review.

00:41:04.446 --> 00:41:08.576 A:middle
So, what we recommend to do, is
to have your service first try

00:41:08.576 --> 00:41:11.086 A:middle
to validate the receipts in
the production environments

00:41:11.426 --> 00:41:14.726 A:middle
and if it fails with
the area code 21007,

00:41:14.936 --> 00:41:18.596 A:middle
pretty easy to remember,
then you want to turn back,

00:41:18.596 --> 00:41:21.406 A:middle
and fall back, and hit the
SendBox validation servers.

00:41:21.866 --> 00:41:26.516 A:middle
And if you do this, you'll
pass the review easily.

00:41:26.516 --> 00:41:29.726 A:middle
So, talking about the app
review, I'd like to finish

00:41:29.726 --> 00:41:33.196 A:middle
with some feedback from the app
review team but make no mistake,

00:41:33.646 --> 00:41:35.326 A:middle
we want your application
to pass that review.

00:41:36.046 --> 00:41:37.416 A:middle
We want them to be in the store.

00:41:37.796 --> 00:41:40.936 A:middle
We want them to have a great
user experience and we want them

00:41:40.936 --> 00:41:43.586 A:middle
to have a consistent user
experience especially

00:41:43.586 --> 00:41:44.756 A:middle
when transactions are involved.

00:41:44.756 --> 00:41:46.446 A:middle
You want that to be
super clear to the user

00:41:46.446 --> 00:41:47.696 A:middle
so they all have
to be hit the same.

00:41:47.696 --> 00:41:49.746 A:middle
If they don't be hit the
same, then the use --

00:41:49.746 --> 00:41:51.736 A:middle
the user's going to be confused.

00:41:51.736 --> 00:41:53.416 A:middle
They'll be confused,
they'll like hesitate,

00:41:53.416 --> 00:41:55.006 A:middle
they'll be fearful and
that's something we'd

00:41:55.006 --> 00:41:56.056 A:middle
like to leave the
to competition.

00:41:56.726 --> 00:42:01.366 A:middle
So the first thing you have to
do is have a restore button.

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

00:41:56.726 --> 00:42:01.366 A:middle
So the first thing you have to
do is have a restore button.

00:42:02.036 --> 00:42:05.226 A:middle
If you have non-consumables, you
want to have a restore button.

00:42:05.786 --> 00:42:08.466 A:middle
If you don't and the user
restores the application

00:42:08.466 --> 00:42:10.346 A:middle
to new device, they have no way

00:42:10.346 --> 00:42:12.236 A:middle
of restoring the
content they paid for.

00:42:12.666 --> 00:42:13.656 A:middle
So they have lost content.

00:42:13.856 --> 00:42:15.086 A:middle
It's a terrible user experience.

00:42:15.426 --> 00:42:16.506 A:middle
So if you don't have
a restore button,

00:42:16.976 --> 00:42:18.246 A:middle
the application will
get rejected.

00:42:20.406 --> 00:42:23.436 A:middle
And another misconception,

00:42:24.026 --> 00:42:26.646 A:middle
restoring purchases
is a free process.

00:42:26.866 --> 00:42:29.606 A:middle
You get a new device, you
install the application,

00:42:29.606 --> 00:42:30.496 A:middle
restore the purchases.

00:42:31.196 --> 00:42:33.366 A:middle
It's free; it's to
get your content back.

00:42:33.796 --> 00:42:37.086 A:middle
The purchase process is to get
new content and pay for it.

00:42:37.346 --> 00:42:38.556 A:middle
It's really different processes.

00:42:39.156 --> 00:42:41.156 A:middle
And you want this to be
very clear for the user

00:42:41.676 --> 00:42:43.216 A:middle
and so they have to
be separate buttons.

00:42:43.366 --> 00:42:45.006 A:middle
No need to merge them.

00:42:45.946 --> 00:42:48.436 A:middle
If you are a news stand
application, as we mentioned,

00:42:48.436 --> 00:42:51.086 A:middle
you can give an incentive
for people

00:42:51.086 --> 00:42:52.056 A:middle
to share their personal data.

00:42:52.586 --> 00:42:54.076 A:middle
So you will receive
personal data,

00:42:54.636 --> 00:42:56.926 A:middle
so to make sure you
treat this properly,

00:42:56.926 --> 00:42:59.326 A:middle
you have to have a
privacy policy and you have

00:42:59.376 --> 00:43:00.616 A:middle
to feel your [inaudible]
connects.

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

00:42:59.376 --> 00:43:00.616 A:middle
to feel your [inaudible]
connects.

00:43:01.396 --> 00:43:03.096 A:middle
Otherwise, this is an
automatic rejection.

00:43:03.976 --> 00:43:05.896 A:middle
Also you want to
make it very clear

00:43:05.896 --> 00:43:07.286 A:middle
to the user what
they subscribe to,

00:43:07.556 --> 00:43:08.906 A:middle
even before they
purchase the app,

00:43:09.466 --> 00:43:11.666 A:middle
so you want to put the
subscription information

00:43:11.666 --> 00:43:13.076 A:middle
directly into the
marketing text.

00:43:13.536 --> 00:43:15.546 A:middle
We have a schedule in the
application store guidelines

00:43:15.596 --> 00:43:16.456 A:middle
that you can use for this.

00:43:18.056 --> 00:43:21.906 A:middle
And free subscriptions
-- it's okay to use them.

00:43:21.906 --> 00:43:24.746 A:middle
In fact, we love them but
they are for free stuff.

00:43:25.336 --> 00:43:28.536 A:middle
They should not be used as a
way to get people to subscribe

00:43:28.536 --> 00:43:30.466 A:middle
to a temporary promotion and
then you raise the price.

00:43:30.466 --> 00:43:32.806 A:middle
In fact, if you try to
do this, it will fail

00:43:32.806 --> 00:43:34.246 A:middle
because the moment
you raise the price,

00:43:34.596 --> 00:43:35.806 A:middle
the store will stop renewing

00:43:35.806 --> 00:43:38.026 A:middle
because the users haven't
agreed to the new price.

00:43:38.626 --> 00:43:40.666 A:middle
So, free subscriptions
are for free publications.

00:43:41.686 --> 00:43:42.976 A:middle
And even though they're free,

00:43:43.716 --> 00:43:46.356 A:middle
that doesn't mean you
can auto enroll the user

00:43:46.356 --> 00:43:49.526 A:middle
or subscribe the user because
the user still should be

00:43:49.526 --> 00:43:51.736 A:middle
in control of the content
that goes into the devices.

00:43:52.156 --> 00:43:53.276 A:middle
So even a free subscription,

00:43:53.276 --> 00:43:54.946 A:middle
they should have a
subscribe button.

00:43:55.996 --> 00:44:00.606 A:middle
And in Newsstand, it is
totally okay, in fact it's great

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

00:43:55.996 --> 00:44:00.606 A:middle
And in Newsstand, it is
totally okay, in fact it's great

00:44:00.606 --> 00:44:02.516 A:middle
if you offer the
users the option

00:44:02.516 --> 00:44:04.386 A:middle
to purchase individual
issues of the magazines.

00:44:05.216 --> 00:44:08.096 A:middle
But you also have to have
the option to subscribe

00:44:08.096 --> 00:44:10.766 A:middle
to the magazine because that's
what Newsstand is all about.

00:44:10.766 --> 00:44:13.186 A:middle
It's having content magically
delivered to your device

00:44:13.186 --> 00:44:14.616 A:middle
when you -- and it's
there when you wake up.

00:44:17.176 --> 00:44:19.106 A:middle
So if you are not
a Newsstand app,

00:44:19.456 --> 00:44:20.876 A:middle
but you do auto renewal
subscriptions,

00:44:21.296 --> 00:44:22.936 A:middle
it's almost the same case.

00:44:22.936 --> 00:44:24.756 A:middle
You might be exposed to
personal data so you have

00:44:24.756 --> 00:44:28.006 A:middle
to have your privacy policy.

00:44:28.006 --> 00:44:30.416 A:middle
You have to give
the users an idea

00:44:30.416 --> 00:44:31.666 A:middle
of what they're going
to be subscribing to.

00:44:31.666 --> 00:44:33.756 A:middle
So you have to put the
subscription information inside

00:44:33.756 --> 00:44:34.456 A:middle
the marketing text.

00:44:35.836 --> 00:44:37.986 A:middle
And you have to think
about what happens

00:44:37.986 --> 00:44:39.156 A:middle
to the user if they subscribe.

00:44:39.586 --> 00:44:42.636 A:middle
So when the user subscribes,
you know, they pay some money.

00:44:43.306 --> 00:44:44.166 A:middle
They should get something.

00:44:44.466 --> 00:44:46.016 A:middle
The latest issue
should become downloaded

00:44:46.126 --> 00:44:47.266 A:middle
or even downloaded
automatically.

00:44:47.866 --> 00:44:50.306 A:middle
But what you shouldn't do
is have the user subscribe

00:44:50.306 --> 00:44:51.166 A:middle
and then nothing happens.

00:44:51.376 --> 00:44:54.516 A:middle
They should get some content.

00:44:55.386 --> 00:44:57.406 A:middle
Again, paid subscriptions,
they're totally fine

00:44:57.796 --> 00:44:59.096 A:middle
but they're offered
paid contents.

00:44:59.096 --> 00:45:00.606 A:middle
You can't ask the user to pay

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

00:44:59.096 --> 00:45:00.606 A:middle
You can't ask the user to pay

00:45:00.646 --> 00:45:02.256 A:middle
for things he could
get for free otherwise.

00:45:03.316 --> 00:45:06.216 A:middle
And apps that do
services, professional apps,

00:45:06.606 --> 00:45:08.606 A:middle
they usually -- they
should use their flexibility

00:45:08.696 --> 00:45:09.956 A:middle
of non-renewing subscriptions.

00:45:10.906 --> 00:45:12.696 A:middle
And talking about the
non-renewing subscriptions,

00:45:13.046 --> 00:45:16.496 A:middle
it is okay to ask
user to register

00:45:17.186 --> 00:45:18.116 A:middle
but it should be optional.

00:45:18.546 --> 00:45:21.086 A:middle
That is, users can use
your app and if you want

00:45:21.086 --> 00:45:22.486 A:middle
to track them, offer
to register.

00:45:22.566 --> 00:45:24.106 A:middle
They can register if they
want to, that's great.

00:45:24.866 --> 00:45:27.996 A:middle
Don't make it compulsory unless
your application has features

00:45:27.996 --> 00:45:31.296 A:middle
that users can only
get through accounts --

00:45:31.296 --> 00:45:32.266 A:middle
you know, through
their accounts.

00:45:32.786 --> 00:45:37.476 A:middle
And the final word
is about purchases.

00:45:38.856 --> 00:45:42.186 A:middle
They just must work because
the app review team will make

00:45:42.186 --> 00:45:43.846 A:middle
purchases and if the
purchases don't work,

00:45:43.846 --> 00:45:44.966 A:middle
they can't approve
the application.

00:45:45.506 --> 00:45:46.746 A:middle
So purchases have to work

00:45:47.116 --> 00:45:48.596 A:middle
and that's why we have
this test environment.

00:45:48.596 --> 00:45:50.656 A:middle
That's why we ask that
you test your purchases

00:45:50.656 --> 00:45:51.496 A:middle
as much as possible.

00:45:52.416 --> 00:45:58.736 A:middle
And the best way to pass app
review easily is also the best

00:45:58.736 --> 00:46:01.916 A:middle
way to get good user feedback
and read reviews and loyalty.

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

00:45:58.736 --> 00:46:01.916 A:middle
way to get good user feedback
and read reviews and loyalty.

00:46:02.506 --> 00:46:05.246 A:middle
And it's also the best
way to get great sales is

00:46:06.286 --> 00:46:10.576 A:middle
to have a clean, easy
to understand, simple,

00:46:10.576 --> 00:46:13.146 A:middle
entertaining, pleasant,
and above all,

00:46:13.146 --> 00:46:15.076 A:middle
rock solid user experience.

00:46:15.136 --> 00:46:17.206 A:middle
And that's all I
have for you today.

00:46:18.116 --> 00:46:21.296 A:middle
So if you have any
questions, feel free to talk

00:46:21.296 --> 00:46:23.106 A:middle
to our evangelist Paul Marcos.

00:46:23.806 --> 00:46:26.056 A:middle
We have updated the
Commentator Developer websites

00:46:26.606 --> 00:46:29.076 A:middle
and the Apple Developer Forum
are a good place to ask --

00:46:29.236 --> 00:46:30.906 A:middle
look around and ask
a bunch of questions.

00:46:32.376 --> 00:46:32.796 A:middle
That's it.

00:46:32.796 --> 00:46:33.976 A:middle
Thanks for using StoreKits.

00:46:34.516 --> 00:46:41.516 A:middle
[ Applause ]

00:46:42.016 --> 00:46:46.606 A:middle
[ Silence ]