Best Practices for Building Apps Used in Business and Education
Even consumer-focused apps are used by people in business and education. See how minor changes can fine tune your app to meet the needs of these large organizations. Learn best practices for synching user-specific content on Shared iPad and how to add deep-link support for Classroom app, authentication integration via Touch ID, AppConfig driven customization, and much more.
[ Music ]
My name is David O'Rourke.
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
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
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.
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.
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.
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,
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
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
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
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,
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.
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.
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
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
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
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,
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
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
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
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,
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 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.
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.
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.
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
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.
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
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.
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.
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,
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
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
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,
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
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
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
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.
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
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.
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.
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
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.
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.
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.
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
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 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.
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
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.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.