Transcript
[ Music ]
>> Good afternoon.
My name is David O'Rourke.
Thank you
[ Applause ]
I think we're at the midpoint
of the conference this week.
How's it going for everyone?
Been worth your time?
I was told something just
before coming on stage
so that there was no pressure.
But apparently you've
all hit favorite
on this presentation
a bit too much.
And so thank you for that,
I hope it's worth your time,
and I think it is
because we put a lot
of work putting this together.
I want to set some expectations
for this presentation.
We will be going
over best practices.
This is going to
be an easy session
for you guys to listen to.
You can put your laptops
down, there's not going
to be a lot of sample code.
This session is to inspire
you as to where to invest
in your future app so that you
can improve the marketability
and approachability
of your application
for as many markets as possible.
The two markets we're focusing
on for this presentation will
be business and education.
So spoiler, there's
going to be a lot
of us going over Shared iPad.
So let's get started,
we'll go into the agenda.
We're going to talk about
modern app design practices,
what some sorts of things
customers can be looking for.
We're then going to branch
out to a quick overview
of the Shared iPad.
How does it work
behind the scenes?
What affect does this
have on your app?
What technologies do
you need to adopt?
That's my third bullet.
And there are some
specific technologies
that we'll be recommending,
and fortunately for you many
of those technologies have been
gone over after this session
or later in the week, so you
can come out of this talk
and go directly in to
hearing the gory details
if you're inspired
to modify your app.
And there's some
new opportunities
to enhance your app, one
that I'm particularly excited
to enhance your app, one
that I'm particularly excited
about at the end of
the presentation,
and I think you will be
too because it will again,
offer you a greater opportunity
for your app to be used
in ways you never anticipated.
So let's talk about
modernizing your application.
This is kind of a bedrock
expectation for customers.
We talked to a lot of customers,
they give us a lot of feedback.
It's really strange
when they come up to us
and say why doesn't such
and such an app use
this Apple technology?
So I just want, this is not a
deep insight, but I just want
to remind you guys, you
need to stay current,
you need to stay fresh because
the customers are downloading
other apps from other developers
that have that technology
and then it kind of
provides a discontinuity
or a bad comparison if your
app isn't using the latest
and greatest that Apple offer.
I don't think I need to speak
to any of the developers
in the room, that's why
you're all here a WWDC to find
out what's new, but as a
general ecosystem issue,
staying current has benefits
for you and your customers
and is an expectation
of your customers.
So some example technologies,
by no means the complete list
of technologies that
you could adopt.
Auto Layout, this is still a
relatively new technology it's
Auto Layout, this is still a
relatively new technology it's
been in several iOS
releases now.
But this really helps you
produce a universal app binary
that can work on an iPhone and
an iPad and it helps with a lot
of layout rotation just a whole
bunch of things get taken care
of for you by Auto Layout
if you invest the time.
It even helps with
left to right.
I used to manage contacts
for the desktop and we moved
to Auto Layout and we got
left to right to free,
which was a longstanding,
or right to left,
or the different language
directions for free,
which was a longstanding request
for the desktop contacts app.
So, auto layout has helped
us, it's helped us internally,
it will help you guys.
Accessibility.
I was actually talking
with a former co-worker
just before lunch,
make sure you have accessibility
in your application.
This helps people that couldn't
otherwise use your application.
And they get quite
emotional when they can see
that they can finally use an
app because you're offering apps
to a person that may not
have been able to do anything
with it prior to doing this.
There's some excellent
accessibility labs later this
week if you'd like
to look into it.
week if you'd like
to look into it.
Swift. This is the newest
most secure, fastest runtime.
If you aren't looking at Swift,
looking how to adopt Swift,
go to the Swift labs this week.
I think you'll be impressed.
I'm impressed with the
language, it's truly stunning.
I shouldn't have to tell
this audience to adopt Swift,
but it's again another
newer technology
that you should really be
looking at investing in.
AirPlay, particularly
in the education
and business environment,
conference rooms,
big screens behind
the presenter.
People want to share content.
If there's room for
your application
to directly adopt
AirPlay, do so.
If you can just make your app
look more interesting when it's
on AirPlay, maybe being able to
hide certain onscreen elements
when you're sharing
to a conference room.
Thinking about AirPlay as, or
a big screen as a destination
for your application,
you might want
to modify the UI a
little bit or have a mode
that the user can
put something into.
Or you just directly
project AirPlay.
And finally 3D Touch.
This is perhaps the newest
technology, newest hardware.
This is perhaps the newest
technology, newest hardware.
A lot of opportunity
to accelerate.
I use my 3D Touch
on a daily basis.
It really has made the
OS quicker, snappier.
And whenever I run into
an app, I push hard,
and there isn't you
know anything happening
when I push hard it's a bit
of a discontinuity and it kind
of throws me off my rhythm.
So look into that.
Again, I want to emphasize,
these are not the complete set
of technologies, these are
just some examples of some
of the newest technologies that
some apps may be lagging behind
and this will impact
your ability to market
and sell your app into
business and education.
So let's talk about a feature
that I have a lot to do with
and actually was able to with
a fabulous team putting it
together iOS 9.3
introduced the Shared iPad.
This is a huge game changer
for you as developers
and for education in
that we can deploy iPad,
the best mobile platform,
into schools
and they can now have
multiple students share
and iPad throughout the day
and for different classes.
This offers a huge market for
the developers in the audience,
This offers a huge market for
the developers in the audience,
because if you can make
your app work better
in a Shared iPad
environment, you're going
to have schools licensing
your app in quantities
that had previously been
inconceivable to you.
So let's talk about Shared iPad.
It's introduced with iOS
9.3, it obviously continues
to be supported with iOS 10.
And the major goals was to
allow schools to buy a cart,
how many people have
seen iPad cart?
They're kind of cool.
I saw one for the first
time about 18 months ago.
They load 60 iPads into a little
cart, they roll it into a room
and the students pull the
iPad out, they use it,
they put it back and then the
cart rolls to a different room.
A feature that was missing
until iOS 9.3 was the ability
for the students to have
a personalized experience
on each one of those iPads.
With Shared iPad they
can now have that
and that makes the cart
much more effective.
Lots of schools buy
fewer pieces of hardware
and spend more money
on the software.
I want to repeat that
they can spend more money
on your software because
they're buying fewer pieces
of hardware from us [applause].
So, the way you log in is
using a new Apple ID called a
So, the way you log in is
using a new Apple ID called a
managed ID.
This is Managed by the school.
They set their own user
list, they bind devices
to their organizations.
And only their accounts
can log onto the iPads.
It's really cool.
If you didn't go to Todd's
session before my session,
I recommend you review
it with the video source.
He talks a lot more
about Managed Apple IDs.
And finally, and
probably the thrust
of this presentation is a Shared
iPad use environment requires
the data be a Cloud.
So we've got the cart,
everyone understand the cart?
Student rolls the
cart in on Monday,
pulls out an iPad, they use it.
Well Tuesday when the cart pulls
in they may not pull
out the same iPad.
If their data's not
been pushed to the Cloud
by your application, they won't
have the experience they had
on Monday.
They'll have a new iPad
experience on Tuesday
and that will depress them.
So we're going to talk a lot
about what technologies
Apple offers
and how Shared iPad works.
So first of all let me
give you a quick overview.
Again, I recommend you
review Todd's session.
There was a live demo of this.
I have some static slides
showing what a login looks like.
So a student pulls an
iPad out of the cart,
they see their grade, the
student that I'm going
to be demonstrating is
Mia, she's a fourth over,
fourth row down on the bottom.
Spent a lot of time with Mia
the past few weeks putting these
slides together.
So Mia taps on her picture,
Mia provides her passcode.
After she's satisfied that she
entered the correct passcode,
the iPad gets ready for her.
If she's used this iPad
before this screen is up there
for a far shorter
period of time.
If she's going to use the
iPad for the first time,
this might take a little
longer as it downloads data
from the cloud to get her ready.
When it's done downloading
data form the Cloud,
or the initial setup
data, Mia uses the iPad
for the entire class session.
She uses Pages, she uses Garage
Band, and she works with it
as her iPad for the
entire session.
When Mia's done, Mia logs out.
This is the opportunity that
the iPad has to push the data
up to the Cloud for any data
that wasn't being pushed
to the Cloud during the session.
And so we're going
to talk a little bit
about what technologies
Apple offers to do that.
So, all of Mia's data has to be
in the Cloud for this to work.
Mia's using a different iPad
possibly from class to class.
My kids have six periods a day.
They might start in
science then go to math.
There might be a different cart
in each one of those classes
and so therefore their data
has to be in the cloud for each
of those iPads to be useful.
Even if they use the same
iPad throughout the course
of the day, or throughout
the course of a week,
the data may be purged by
the iPad because it may need
to expunge users from the iPad
to make room for new users
to log in throughout
the course of the week.
So, iOS provides four core
technologies that I'll be going
over later that you can
adopt, and be telling you
about a fifth technology
that you should be adopting
if you don't use any of
the iOS Cloud technologies.
But let's go over first a
review of the iPad expectations.
So, I get a lot of questions
about this from engineers,
both internally and
here at the conference,
both internally and
here at the conference,
we've been talking to people.
So what is Shared iPad?
Plain and simple,
it's a user switching.
So we are not allowing
multiple users to be logged
onto the iPad simultaneously.
There's only one active user
session at any given time.
For user to log into the
iPad another user has
to log out of the iPad.
So it's really user switching.
What do you as an
app developer see?
You see a single use device.
You do not know you're in
a Shared iPad environment,
you don't need to know you're
in a Shared iPad environment.
Nothing has really changed for
you as an application developer.
You don't need to participate
in this, you don't need
to do anything custom,
other than move your
data into the Cloud.
Signing out is the
moral equivalent
of powering the iPad down.
So your app has shut down, it's
not running in the foreground.
It's just like a
non-shared use iPad
when the user turns
the iPad off.
So if your app works well
between power cycles,
your app will work well in
a Shared iPad environment
as users log in and log out.
User data is cached
on the device.
Internally we started
educating people,
it's like volatile
cache, it's not volatile
when the user's logged
in, it's volatile
after the user's logged out.
So the data may be expunged
off the iPad at any given time,
but while you're logged
in it's a single use iPad.
The data's not going
to disappear
out from underneath you.
And caching has some obvious
benefits for performance.
It works for offline,
these iPads we expect
to be taken on field trips.
And the data will be purged by
iOS when iOS deems it necessary.
So we want you to move your
data to the Cloud so that Mia
as she's visiting different
iPads throughout the course
of the day and different iPads
during the course of the week
and the school year has
a consistent experience
on all the different devices.
The iCloud technologies
that we make available,
or some of the four key
technologies we make available
are CloudKit, iCloud Drive
NSUbiquitousKeyStore, KeyChain.
are CloudKit, iCloud Drive
NSUbiquitousKeyStore, KeyChain.
And as an adjunct NSURLSession.
We'll talk about why that's
on the list here later
in the presentation.
So, you're convinced, there's
a huge market for Shared iPad,
when should I flush my
data, when should I do the,
well the goal is for
you to flush the data
to the Cloud while your app
is still in the foreground.
So as Mia's making changes,
you're writing changes
to the CloudKit, okay you're
updating your Cloud document,
you're doing whatever's
appropriate for that.
You can sync data
during log out,
and you should sync data before
you receive the application will
resign active event.
But, generally we don't want
to put all the data syncing
up on the logout, it will
take the logout too long.
So you should be syncing
while your app's up to date.
You shouldn't be batching
this up to do it later
because you may not get
later if Mia logs out.
There is, if you adopt the
iOS technologies for CloudKit,
Cloud Drive,
NSUbiquitousKeyStore, KeyChain,
Mia's data can be synced even
when Mia's not logged in.
But, we prefer her to exit
clean with no dirty data.
But, we prefer her to exit
clean with no dirty data.
So let's talk a little
bit about CloudKit.
CloudKit was introduced
in I believe iOS 8,
correct me if I'm wrong.
You can sync data, it's
taken care of automatically
and something that's very
important that you adopt,
if you adopt CloudKit
is LongLivedOperations.
These are a subclass
of CKOperation Classes.
The link to the developer
documentation is on screen.
This is important
if you want CloudKit
to sync your data while the
app is not in foreground.
Now, we 've had this feature
and this wasn't unique
to Shared iPad, but we've
leveraged this feature
to also be the mechanism
by which we sync data
when Mia's no longer
logged onto the device.
So if you most your
CloudKit documents
onto LongLivedOperations,
you can get your data
to sync using CloudKit even
when your app's not running,
or in the foreground, or even
when Mia's no longer logged in.
So, if you're going to adopt
CloudKit and you're going
So, if you're going to adopt
CloudKit and you're going
to use CloudKit, I highly
recommend you invest and work
with the CloudKit engineers
while you're here this week,
to understand
LongLivedOperations,
adopt LongLivedOperations, and
make your application compatible
with LongLivedOperations.
Cloud Documents is perhaps
the easiest API to adopt,
for document-based applications
like Keynote or Pages.
There's very little
you need to do,
every managed IP
has an iCloud drive.
iCloud drives automatically
sync.
If you are already a
document based application,
you're good to go for education,
you've done everything
you need to do.
And Mia will have all of your
documents for your app available
on every device that she visits.
So it's simple and easy.
If you're a document-based
application this is the
preferred way to go.
Both of these texts
are sync on demand.
And this is really,
really important.
Mia could have several
gigabytes worth of data stored
in CloudKit, but she
will only page the data
onto the device that
she accesses.
So the device does not have
to download all 2 gigabytes
So the device does not have
to download all 2 gigabytes
of Mia's Cloud data in order
for her to use your app,
if your app's only accessing
a few megabytes' worth of data
that you stored in Cloud data,
only your app data would
be pulled onto the device
when your app is launched on
that device for the first time.
So it's very efficient, and if
you think about this at scale,
average US classroom has
30 to 40 students in it,
you've got 30 iPads
all fetching data.
If they all fetch the full 2
gigabytes when they logged on,
it would be relatively hard
for most schools' network
connections to handle that.
So these are the best
[inaudible] technologies,
they only cache the data you
use, the data stored locally.
They're really, really
world-class Cloud technologies
that you can integrate into
your app and get your app
into these important markets.
And CloudKit is suitable
for large datasets.
I don't know what the
definition of large is,
I would recommend you work
with the CloudKit folks to find
out if your dataset's too large.
I don't think they recommend it
for use of iMovie, but maybe.
Maybe for smaller
datasets it would be fine.
I specifically got this quote
from the CloudKit lead engineer,
I specifically got this quote
from the CloudKit lead engineer,
this is in contrast to
the next technology that's
on the next slide, which is
NSUbiquitousKeyValueStore,
which is meant for
smaller datasets.
So I don't think you need to,
unless you're doing a
video editing application,
I don't think you need
to worry about the size
of the dataset you're
putting in the CloudKit.
That doesn't mean
that you can run amuck
and do really silly
things for performance,
but most applications that
are going to store data
that are reasonable, CloudKits
are perfectly suitable for that.
Let's talk about
NSUbiquitousKeyValueStore.
To use this requires
an entitlement.
It's a drop-in replacement
for NSUser default.
So if you're already
using NSUser defaults,
you're already good to go, it
should be fairly easy for you
to transition to
NSUbiquitousKeyValueStore.
And NSUbiquitousKeyValueStore
the data is stored in the Cloud,
so your app launches, it
stores key values pairs
in the NSUbiquitousKeyStore,
your app quits, it relaunches,
it gets the data
back from Cloud.
Your app on a different
device will get the same,
essentially NSUser
default package
when it launches on
the other device.
It's modelled on
NSDictionary and again talking
It's modelled on
NSDictionary and again talking
to the CloudKit engineering
team,
who originally did
NSUbiquitousKeyStore,
moved on to CloudKit,
smaller payload only please.
This data is not
fetch on demand,
it is fetched during log in.
And we just really
anticipate this
for some lighter weight datasets
used within your application
that are more appropriate
for an NSDictionary.
If you put it in
a NSDisctionary,
put it in an
NSUbiquitousKeyStore,
if it's too big to put it into
an NSDictionary, you might want
to put it into CloudKit.
So, as I mentioned data fetch
is part of the account sign on.
There is a side effect of this,
and we're going to be talking
about later in the presentation,
which is this also prepares
your app to be managed
by application management,
which is the simplest summary is
to talk about deploying
applications in scale.
If I'm an IT administrator
about to deploy 1000 iPads
at a major Fortune 500 company,
and I want to have your app set
up under default circumstance
for the day 1 that I deploy it,
they do it through
application management.
And we'll be talking about
that later in the presentation.
Essentially you can get an
initial application state
Essentially you can get an
initial application state
distributed to all of the iPads
via NSUbiquitousKeyValueStores.
So, I want to think
of a couple use cases
for NSUbiquitousKeyValueStore
value
or NSUbiquitousKeyValueStore,
that is a mouthful.
The biggest thing
is is let's think
about Mia visiting an iPad,
day 1 of a new school year.
She launches your app, your
app has some setup data.
You want to pick
her favorite color,
maybe have her pick a
picture for her Avatar.
You don't want her
encountering that on every iPad
that she uses throughout
the year.
So an idea use case for
NSUbiquitousKeyValueStore is
to story your app's
initial setup data.
That way as your app is
run on different iPads,
Mia's initial preferences
for your app have been saved
in NSUbiquitousKeyValueStore
and she does not see the
application setup every time she
encounters a new iPad.
An example of places where
we use internal of Apple is,
I'm told by the Stocks
team and the Weather team,
we use NSUbiquitousKeyValueStore
to store the ticker,
we use NSUbiquitousKeyValueStore
to store the ticker,
list and we use it to
save all the locations
for where you save in Weather.
Keychain. How many people
are using the Keychain
in their application?
Quite a few.
I have excellent news
for you, you're done.
You need do nothing, you can
tune out for the next couple
of minutes and check email.
You don't need to
do anything else.
You're already good to go.
Every Managed Apple
ID has a Keychain
and that Keychain is synced to
every device that they log into.
Obviously the Keychain is
there for secure user data.
And so it's the same API,
same user conventions,
in fact you as an app
cannot tell the difference
between a Shared iPad Keychain
and a normal iCloud Keychain.
Same API, same usage pattern.
A couple of minor things.
Some people do some rare
application store device only
data on the Keychain.
There is no such thing
as device only data
on a Shared iPad Keychain
and we recommend you
only store per user.
and we recommend you
only store per user.
And you must set the exportable
flag or the share flag,
otherwise your data will not
be shared up to the thing.
But you should be
storing user credentials,
or user sensitive
information in the Keychain,
you should not be using the
Keychain to store bulk data.
It's kind of the same rules
as NSUbiquitousKeyValueStore.
Don't use it to store bulk data.
If you want to store secure
bulk data, come to the labs,
we can suggest some
different approaches
that will solve that problem.
But yeah, if you're already
using the Keychain, good.
If your app has user
sensitive data
that should probably
be behind a password,
or a little more secure than
just putting it in a data store
like CloudKit or
NSUbiquitousKeyValueStore,
start putting it in the
Keychain, it's easy to adopt.
It makes the data secure and
makes it highly portable.
Finally, on the Cloud
technologies to adopt,
how many of you already have
your own Cloud technologies
that you're using
rather than CloudKit.
I see quite a few.
Very good.
You need to make sure that
either your code or the code
You need to make sure that
either your code or the code
that you're using
uses NSURLsession.
NSURLsession is the
preferred option
for doing all networking on iOS.
And it should be using it
because it does so much for you.
I've been at Apple
quite a while.
I don't want to say how
long, I think a little longer
than Todd has from
the previous session.
It does so many things for you
that you don't even
know that it does.
It does IPv6, it does all the
metricing, and controlling,
and accounting, it
does data throttling,
seamless network transitions.
And, I didn't even
know about this
until I was putting
this slide together,
Cisco Fast Lane support.
How many people know
what that is?
Yeah it's a quality
of service thing
that allows network
administrators
to prioritize network traffic.
And if your app is not
using NSURLsession you have
to do that all yourself.
That's time you're going
to spend learning something
where NSURLsession's
already done that.
So, if you're not going to
use CloudKit, you're not going
to use iCloud Drive, you're
not going to use the Keychain,
and you're not going to use
NSUbiquitousKeyValueStore,
but you're motivated to move
your app into the Cloud,
make sure that the frameworks
you're using, or the frameworks
that you're writing
are using NSURLsession
for all of the networking.
And you will pick a best
of breed network behaviors,
robustness, and resiliency.
So, like the LongLivedOperations
in CloudKit, another advantage
of moving to NSURLsession is
let's go back to user switching,
your app's not in
the foreground.
Your NSURLsession pass are not
running unless you've marked
them as background, or adopted
background configuration.
So, you have your own Cloud
technology, you're not
yet on NSURLsession, but you're
going to move onto NSURLsession.
When you do so you can review
the developer documentation
that talks about how to make
your NSURLsession data run
in the background.
And this has two advantages
to you as an app developer.
Advantage number one, your
data can continue to sync
to your proprietary Cloud store
when your app is not
in the foreground.
And advantage number two, your
data will sync when Mia's logged
out and isn't even
active on your platform.
out and isn't even
active on your platform.
So if you're not using
NSURLsession, start.
And when you do start
using NSURLsession,
review for background
usage and make sure
that your app can sync data
when it's not in the foreground
or the user isn't even active.
So, let's review.
By now I think I should have
convinced you Cloud based data
is essential for your app in
the new Shared iPad environment,
which we introduced
with iOS 9.3.
This is a huge market worldwide.
We know that it's being
used in Australia.
We know it's being
used it he US.
It's rolling out to Europe.
This allows Managed Apple
IDs to move between devices,
and we want that to be
as seamless an experience
as possible, and you as the
app developers have a role
to play there in getting
your app data into the Cloud.
Apple feels, and I believe we
provide a complete solution.
If you don't have any
of this working yet,
there's nothing you
need to wait for.
iOS has all the baseline
technologies you need
to move your data
into the Cloud.
If you don't feel that way,
come to the lab we'll
try to help you out.
come to the lab we'll
try to help you out.
If you're doing your own
networking of any kind,
Cloud based or otherwise,
please use NSURLsession.
A huge amount of
advantages for you
in adopting those technologies.
And you pick up a whole
bunch of functionality.
And again we don't talk
about future features,
like Pod in this session,
but we're not done
with NSURLsession.
As we need more networking,
it's all going to get rolled
into there, and apps that are
already on it are just going
to ride that wave
onto the next round
of feature improvements
to NSURLsession.
So, in addition to the Cloud,
there's some additional
considerations
for Shared iPad that
you need to do.
And this is more about
changing your thinking and less
about specific technologies
you need to adopt.
First of all, there's
data separation
between user accounts.
Now that should seem obvious, or
some people might be going duh,
but I want to talk about
that, because some apps,
iOS 9.3 is the first release
of iOS' for shared users,
and well that's 9 versions of
iOS prior to that that didn't,
and so some apps needed
to support shared users.
And they kind of wrote
their own little user picker
And they kind of wrote
their own little user picker
within their app.
So the first thing is, is we
have true data separation.
Mia cannot see Liam's data
and Liam cannot see Mia's
data while they are active
on the device.
Therefore, this is now a tool
you can use as an app developer,
to where you no longer need
to have your own app
or multi-user picker.
There are some applications out
there than when you launch it,
it says are you Mia
or are you Liam,
and you can set multiple
user data.
I think the time
has passed for that.
So if you are doing a
multi-user application,
your app should just run on a
single device, it should run
within the shared user mode
and you'll get data separation
for free and you can retire
the code that's doing that sort
of multi-user management.
And that avoids comingling
data between Liam and Mia,
which is sometimes a
potential privacy issue
if two different students
could see each other's data.
Shared iPads have quotas.
Todd had an excellent animation,
I forgot to rip it off
for my presentation,
my apologies.
iPads will enforce quota.
Now there are two types
of quotas on an iPad.
Now there are two types
of quotas on an iPad.
There's the number of accounts
that can be on a Shared iPad.
That's like six, eight or ten.
And there's the amount of data
that can be stored per account.
Why does this affect
you, as you developers,
well you will be
getting new errors
out of any file system
operations you do.
There's the EDQUOT error,
treat it the same as ENOSPC.
So, instead of getting this
full, you'll get quota errors.
If your app has recovery
mechanisms you have to do
when you're out of disk
space, treat them the same.
But this is a new error code
that you might see more
frequently when running
in a Shared iPad environment.
Another technology that's
really, really interesting
in the case of Shared iPad
is On-Demand Resources.
If your app has On-Demand
Resources, or has assets
that you haven't moved into
Apple's On-Demand Resources
but that you download On-Demand.
If you're downloading them
into the user directory,
and you're on an iPad with eight
users, you've now duplicated
that app resource eight times.
Not only that, you've downloaded
the resource eight times
and that's burdened
the school's network,
multiply that times 30 iPads,
you've now downloaded
that 240 times.
So you really should
consider moving
to using On-Demand Resources.
If your app moves to
On-Demand Resources,
you will only download an
On-Demand Resource once
per device.
It will be downloaded
for all users, current
and future on that device.
And more importantly it will
not be deleted or purged
when a particular
user's account is purged
by the operating system to
make room for new users.
So if you have large
resources, or you have just
in time resources, or
you thinned out your app,
and you're downloading those
resources later, adopt ODR
and you will get the resources
you need onto the iPad just
when you need them and you
will minimize the amount
of impact you've had on that
iPad both local storage,
the user's quota, and the
school or institution's network.
So this is again a
screenshot form the developer
documentation, talking
about On-Demand Resources.
I have it at the end of
the slide, but I'm going
to give you a preview.
I think Thursday is
On-Demand Resources In-Depth.
I think Thursday is
On-Demand Resources In-Depth.
Highly recommend you attend that
session if you have large assets
that you want to get out of your
app bundle and not download it
into a user directory.
Remote notifications.
Again, the iPad story and the
shared environment is a little
different here than it has
been previously, but not much.
Notifications work the
same as a single user iPad.
So how does the Shared
iPad work?
It works like a single-user
iPad, but logging in is
like powering up the
iPad and logging out is
like powering down the iPad.
You won't get notifications
until an iPad's logged in.
And you won't get notifications
if an iPad's logged
out or powered down.
Same exists for log
in and log out.
So this is very much like your
app being turned on and off
on the device when the device
is powered up or powered down.
Remote notifications will not
be primed if your app runs
at least once per device.
So if Mia has only encountered
the device for the first time,
and your app relies on
push notifications working,
and your app relies on
push notifications working,
or remote notifications
working, unless she's run
that app least once
on that device,
she will not see
the notifications.
This is just like a non-Shared
iPad, but I think it's going
to come up more often because
changing devices is now
so much more easy for Mia.
And signing out is like
powering off as I said earlier.
You will not receive
remote notifications.
Why did we include a
whole slide about this?
I think there's some apps
out there that may not work
as fluidly or as
smoothly as you might want
without push notifications.
So if you have work flows
or use cases in your app
that really rely on
remote notifications
to trigger something,
something like that.
Think it through
evaluate your app,
and see what changes
you can make.
Because as Mia's moving
from device to device,
she may not get the push
notifications until she thinks
to run your app for
the first time.
And if there's something you
can do to help her with that,
or even just document for the
administrators making deployment
decisions about your app,
this will be very helpful.
So review your usage of
remote notifications and think
So review your usage of
remote notifications and think
about how well your app would
work if Mia's been working
on an iPad on it for
say a whole week.
And then she suddenly gets a new
iPad, will your app work as well
until she launches
it the first time.
Managed Apple ID's.
So this is a new
type of Apple ID.
It's set up by the institution.
The institution controls
the names,
the institution controls the
password, but there's also a set
of different capabilities
associated
with the managed iPad.
The most important that
it has is there are no
commerce features.
There are very few
schools, very few schools
that want the students
purchasing music
on their credit card when
they deploy their application.
So we've turned off the
commerce application,
the commerce and
stuff like that.
The impact for some developers
is I have seen some applications
put functionality
behind a pay wall
or put functionality
behind an in-app purchase.
Schools aren't going to want
to license an application
like that.
They're going to be
deployed into an environment
where the individual Apple
IDs don't have any commerce.
There's no credit card
bound to the account,
There's no credit card
bound to the account,
your app cannot function
in that environment.
Now, I'm not saying
that you should do this
for your general app, you may
need to do a different app
for schools that you license
that don't require in-app
purchases just for it
to be fully functional.
And you should adjust
your licensing
and pricing appropriately.
But the app itself that the
school deploys should be
fully functional.
So don't want for
commerce activity
to happen before your
app is fully functional.
Also check for specific
frameworks
and features that you need.
Just don't assume that because
they have an iCloud identity
that they have everything.
We've combed through
the operating system
and where things are disabled,
those frameworks will
return appropriate errors.
A concrete example is StoreKit.
If you use StoreKit and you
try to use it while logged
on as a Managed Apple ID,
you will get an appropriate
error telling you StoreKit's
offline or unavailable.
So, don't assume
it's all or nothing,
if I have this then I have
all these other services.
Start checking for
individual frameworks
to be present that you need.
If those frameworks
were to return an error,
how would your app behave
and thank that through
how would your app behave
and thank that through
for this type of use case.
Generally, you can follow the
existing practices you've been
following if you're
already compatible with VPP,
which is Volume Purchase Plan,
and device based licensing.
If your app conforms
to VPP licensing
and device based deployment,
you're already most
of the way there, if not
all of the way there.
But for developers that don't
know about VPP and don't know
about device based licensing,
work with us in the labs,
we can bring you up to speed.
This will make your app
more approachable and open
up new markets for you.
And finally a quick shout
out to web developers.
We gave this a lot of thought.
So there is a Keychain.
I love the Safari AutoFill
feature that saves passwords
and syncs them in
the iCloud Keychain,
it made it just hugely
useful when we deployed that.
But we're thinking Mia
logging on to a Shared iPad,
and then logging on
to a personal account,
we may not want that
password saved
in the keychain where
it's stored.
So we've given schools
the ability
So we've given schools
the ability
to list what particular
websites they want
to save passwords
for in the Keychain.
Now, consider moving
it to a native app.
This is overwhelmingly
the best solution.
And the solution that
our customers expect
and your customers expect.
If, however, you remain
a web-based developer
and web-based content,
at a minimum there's some
documentation update you might
want to remind your customers
to add your domain name
to the Safari domain whitelist
so that as the students set
up your site for the first
time, Safari will prompt them
to save their password,
and it will get saved
into their Managed
Apple ID Keychain.
And then the next time they
visit a different iPad and log
onto your website,
they won't have
to provide their
credentials a second time.
If you do not list your
website or your domain
on this domain whitelist,
Mia would be forced to log
in every time she
encounters a new iPad
and that would be a
frustrating experience
for Mia and the school.
At a minimum there's a
documentation update.
At most, maybe use this as a
notice that it might be time
to consider moving your app
to be native on the platform.
to consider moving your app
to be native on the platform.
I've been talking
about Shared iPad.
I've been talking
about business.
I've been talking about the
new markets that this opens up.
But I'm also going to point out,
there's nothing here that's
unique to Shared iPad.
My assertion is is that while
Cloud based data is required
for Shared iPad to
work functionally,
all of your users will benefit
from moving your
app to the Cloud.
My wife, just two weeks
ago face planted her iPad.
We took it to the Genius
Bar, they fixed it.
She got a new iPad, she
started setting up her apps.
The apps that didn't
get Cloud data,
didn't get reinstalled
on her app.
She just didn't have time.
And it makes it easy for
them to change devices.
So these changes that
you're going to invest
in are not just investing
for Shared iPad.
This will make it better
for all of your users.
All of your users
have Cloud data.
All of your users
have iCloud documents.
All of your users
have Keychains.
All of your users have
NSUbiquitousKeyStore.
Moving your application
data into the Cloud is going
Moving your application
data into the Cloud is going
to make it better for
your entire ecosystem.
And in addition to that
make it more suitable
for education and business use.
So business also
favors the Cloud.
They change devices, they change
employees, they hand new devices
to a different employee
on Monday
than was using it on Tuesday.
If you can make it more rapid
to set up your account and have
that employee's data
online and accessible
on that iPad sooner rather than
later, businesses are going
to consider your app a favorite
choice for them to deploy.
So, my argument is the
Cloud's a long term trend.
If you haven't considered
moving your data to the Cloud,
this might be the year
that that's finally no
longer a tenable position.
If you're already on the Cloud,
review your usage and make sure
that everything is working
well, because we just opened
up a huge new market for
you with Shared iPads.
So you've done all this, you've
moved your user secure data
into the Keychain, you've used
CloudKit to store the bulk data,
because you're not using
NSUbiquitousKeyStore for that.
You've used NSUbiquitousKeyStore
to store your apps
initial settings.
And you took all your custom
networking you moved it
up onto NSURLsession.
You moved up background
tasks for it so that it runs
when your app's not
in the foreground.
Now you need to test it.
Make sure that it
all actually works.
So here's some high-level
recommendations
on how to test for the app.
And there are basically three
methods of testing that all boil
down to the same method, but
we'll go through them one by.
Two devices.
iPad a, iPad b.
You install your app on iPad
a, set up an iCloud identity.
Run your app.
Go through the cycle
of storing your data.
Maybe your stock app, you
store your ticker information,
you do all of that
sort of stuff.
Wait for it to sync.
Launch iPad b, log onto the same
account, launch your application
and see if your data
shows up on iCloud b.
If not commence the
debugging cycle.
If it does work,
great, you're done.
And that will allow you, so
basically two different devices
with the same iCloud identity is
all you need to test to verify
that your app's working in
a Shared iPad environment.
that your app's working in
a Shared iPad environment.
If you don't have two devices,
or you just don't want to bother
with two devices, you can
do the same sort of testing
by adding your app,
setting up all the data,
waiting for the app to sync
the data, delete the app
and add the app back
to the device.
That will pull all
of the data back.
That will pull the
NSUbiquitousKeyValueStore,
the CloudKit, the
Cloud documents.
All of that data will come back.
If all of that data comes back,
again you can check off the box
that says you've moved
your data to the Cloud.
In an extrema case,
and most of you
in the audience realize
this is just a variation
on these things.
If you really want to know
that you've really nailed this,
you can erase the iPad
between testing sessions.
I don't think that's necessary,
but I just put it
here for completeness.
That's really kind
of the acid test.
Set up your iPad get a
whole bunch of data in it.
Trust that your Cloud
is working,
trust that Apple stored the data
for you, blow the device away,
set it up from scratch again.
Does all your data come back?
You're in great shape.
If your app can pass
that sort of test,
you have nailed the Shared iPad
case and made things better
you have nailed the Shared iPad
case and made things better
for your consumer users.
So verify all of your
app's functionality.
Verify there's no data loss.
Verify offline works.
So put the iPad into
airplane mode and verify
that your user CloudKit,
that all the data syncs later
when you take it out
of airplane mode.
Verify your app never asks you
for the setup screen again.
A very simple test.
Install your app, run
through the setup screen,
delete your app,
relaunch your app.
Do you get the setup screen?
Not done yet.
So testing's important.
Moving into the Cloud's
a very big deal.
Once it's there I think
you'll be very satisfied
with the results and
here's some help.
If you want more help
or more assistance,
again there's a lab
right after this.
We'll all be there to
answer questions for you.
This was a plea, we
had a lot of this
from the internal developers.
Log out actually tries
to do an orderly shutdown
of everybody's app.
If you're leaking UI background
tasks, logout can't complete.
And this is upsetting to people.
Liam can't log in until Mia's
logout session is finished.
Liam can't log in until Mia's
logout session is finished.
If you're leaking
UI background tasks,
your app cannot be terminated.
It will eventually time out.
It will eventually be killed.
But that's not good for anybody.
So make sure you're not
leaking UI background tasks,
because those will block logout.
So, that's the technologies
you need to adopt
and the changes you
need to make.
And all of these changes make
it better for Shared iPad
and business use
case, but they're kind
of the bare minimum changes
you need to be useful
in those environments.
The work that you're
going to do is also useful
for even your consumer use case.
So the good news is is this
sort of investment is not just
for education and business, it's
also for your consumer use case.
And it will become baseline
for your application.
Now there's opportunities to go
beyond the minimum requirements
of putting your data in the
Cloud and you can really,
really have your app be world
class and be a preferred choice
for potential licensers.
Like going beyond just adopting
the Cloud and adopting some
of the newer technologies
this year.
The first and most exciting
technology, how many people were
in the session before
this with Todd?
Oh, good. A good number,
the classroom app,
one of the most exciting apps.
It's kind of silly but it's
really kind of cool to be God
and sit up there with
the Classroom app
and control an entire lab
form an iPad is really,
really kind of very powerful.
And one of the key technologies
that Classroom app
leverages is Universal Links.
Universal Links is
not new with iOS 9.3,
it was introduced with iOS 9.
And it provides a
feature that allows you
to share external links back to
your application off the device.
It also enables sharing
and searching inside
your app on the device.
It's a huge advantage for
you to adopt Universal Links.
What's new this year is we've
built on Universal Links
as a basic understanding that
a lot of apps support this.
And universal links is
one of the key features
that Classroom leverages
to guide your app,
or control your app while
in a classroom situation.
or control your app while
in a classroom situation.
So if your app supports
Universal Links,
a teacher anywhere in the world
can decide your app is the
coolest app in the world, and
she can integrate your app
into her course curriculum.
And she will then use that
with the Classroom app
to use your app during
the session.
This will make your app world
class and the most desirable app
in the App Store for
the school to license.
If you can't use Universal
Links, it will make it harder
for a teachers to integrate
your app into their curriculum
and harder for them to use
it with the Classroom app.
And therefore this is an
opportunity for you to surprise
and delight your customers
in that your app
will work really well
in a classroom situation.
But the key to this
is Universal Links.
And just like the Cloud stuff
this is beneficial for your app
in or out of a shared
use case environment,
but this is more
evidence that we're piling
on these core technologies
to make your app
as useful as possible.
Another new feature
with iOS 9.3.2,
some app developers do automatic
assessment apps, these are apps
that do standardized testing
or assessment of a student.
They put it in full screen
mode, they lock it down.
They put it in full screen
mode, they lock it down.
We've made some changes to
make this more accessible.
The biggest change
is you can now be
in automatic assessment app
without being on
a supervised iPad.
You get an entitlement for
this, you can request it.
And in particular you
can now call an API
to request different
keyboard features.
Like you may not want a spelling
app allowing auto correction
happening while the
student is being assessed
for their spelling test.
So apps can now drive this.
They can request an
entitlement for this
and more importantly
it's no longer restricted
to just shared, or supervised
iPads it can run on any iPad.
And so if you're an
assessment-based application
or were considering being an
assessment-based application,
iOS 9.3.2 has opened up
more opportunities for you.
Again come to the lab, we
can give you more details.
But that's part of iOS 9.3.2.
Managed App Configuration.
This was introduced with iOS 7
and basically what this
does is allows administrator
to blast initial app settings
out to thousands, or hundreds,
or tens of thousands of iPads
so that every app starts
or tens of thousands of iPads
so that every app starts
in an initial configuration.
It's really simple to adopt.
There's just an additional
key in your NSUser defaults.
If you see that key,
the key points
to an app specific
dictionary that you,
as the developer, control.
And the administrator who set
up those things will provide the
default dictionary for your app.
The problem was is
there was different ways
that MDM vendors chose
to send this information,
configuration this information
on how to package it.
So new for this year is there's
a community, not affiliated
with Apple, but we're
a participant,
where all the various MDM,
Mobile Device Management server
vendors are standardizing
the payloads.
The standardization
efforts documented
at the URL you see
here on the website.
The biggest advantage is you
can now have a single app
that supports multiple
MDM vendors.
And as I was researching
this presentation and I'm new
to the device management realm
within the past 18 months.
I was surprised to find
out that this was the case.
So right now there's an app
in the App Store, today,
we're not making this up,
that has this many SKU's.
we're not making this up,
that has this many SKU's.
Now what I can tell you is
they're not using auto layout
so that's why they
have a different screen
on iPhone and an iPad app.
But the six that you
see, and you see each one
of these six icons represents
a different MDM server
that they have to support.
So, as you can imagine
this is a bit
of a nightmare for
them to maintain.
So by moving onto the new app,
the managed application
consortium, they should be able
to turn their apps
from this into this.
They can have one
version for the phone
that supports all
the MDM vendors
and they can have one
version for the iPad
that supports all the MDMs.
So that would be a
huge advantage alone.
If they move onto Auto
Layout and use all
of Apple's latest technologies,
they should be able to do this.
That would be one
SKU in the App Store
that supports all the
different screen sizes
and also can be managed from all
of the major MDM server vendors.
So if you're going to
go into this market
and you want your
app to be managed
through application management,
look into the new consortium,
work with them and learn
to adopt what they've got.
So, in conclusion, along with
Shared iPad, I hope to leave you
with a message that regards
to what market you're selling
into the iOS ecosystem is rich,
it's vibrant, it's profitable,
it's open to everybody.
But it's also very demanding
in that customers expect a lot.
They expect Auto Layout,
they expect the flexibility,
they expect you to be on Swift,
they want AirPlay,
they want 3D touch.
And this year, new right
over here, SiriKit.
So that's another technology.
What can your app do with Siri
that could be revolutionary
in an educational
business environment
for you to adopt SiriKit?
So keep your app fresh.
Keep your app vibrant.
Adopt the cloud technologies.
And what you're doing is
making your app better
for your consumers and
better for business use
and institutional use, and
in particular, education.
So, I appreciate your time.
I've really enjoyed
speaking to you.
I'll be happy to
answer questions
in the lab later
if you have any.
I have co-workers there and
I have some guidance for you.
So there will be
links, any links found
in this session will
be at this link.
And here's a little roadmap of
either stuff to review on video
if you've already missed it,
or stuff that's upcoming.
So we've got What's New in Apple
Device Management, you're going
to have to review that on
video if you didn't see it.
Improving Existing Apps
with Modern Best Practices.
This is at 3 p.m. immediately
following this session.
So this will be a
more in-depth view
of the best modern
implementation techniques
for apps.
Optimizing the use of On-Demand
Resources is happening Thursday.
Extending your App with SiriKit
is happening on Thursday.
What's New in CloudKit,
Thursday.
CloudKit Best Practices.
If you're going to move your app
into the Cloud these are
the engineers that are going
to tell you in gory
detail how to do it.
Again, thank you for your time,
and I appreciate you attending.
[ Applause ]