Good afternoon. My name is David O'Rourke. Thank you

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.

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.

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 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, 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 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 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 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, 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. Very good. 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 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. 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, 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 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, 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 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. 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. 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 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. 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.