iOS Configuration and APIs for Kiosk and Assessment Apps

Good afternoon everybody. Hello to everybody who's still here.

I'm Steve Hayman. I'm a consulting engineer from Toronto, Canada. Any Canadians here? Good. How's it going, eh? I'd like to say hello to those of you who are still here late on Friday afternoon. And to everyone who's watching the video in the future, hello people in the future with the flying cars and everything. I'm very excited to see what that turns out to be.

But today we have the thrilling topic of iOS Configuration and APIs for Kiosk and Assessment Apps.

What are we talking about? We're talking about locking an iPad to a single application.

We're going to talk about different ways that you might do that. Some of them are manual processes.

Some of them are programmatic.

But let me show you a couple of examples of what we're talking about right now.

So here's my iPad.

Here's one thing you can do.

Anybody can do this on any iPad. Anybody can go to Settings, General, Accessibility, way down at bottom, Guided Access. And if you turn this on, it is now possible to lock an iPad, any iPad, to any arbitrary application. A lot of parents and teachers do this before they turn over their iPad to their child. For instance, if your child was very interested in maps, you could launch Maps, and then since Guided Access is on, you can triple tap, one, two, three times, on the Home button, and supply a pass code. A very secret pass code. No guessing. . And now I can hand the iPad to my geography-obsessed child, and they can play with Maps all day long, but they can't touch the Home button.

They can't get out and start messing with my stuff, until I triple tap the Home button again, one, two, three, and put in the pass code.

So this is Guided Access. This is an accessibility technology from Apple that's been around for a long time. It's a basic way to lock an iPad to any application that you want. That's one way, but I want to show you another way. We're all developers. Let's talk about a programmatic way to do this.

I have a testing application on here that you might see in a school for administering standardized tests.

And in schools, we are a little bit concerned about letting students touch the Home button, and fire up Safari, and go to Wikipedia during the test. We don't really want that happening.

So an application like this one, when I tap Start Test, we're not locked right at the moment. I can still hit the Home button.

But once I touch Start Test, this particular app is set up to lock iOS on demand, at the moment I touch that button. You get a little panel here that says, "Do you want to confirm app self lock?" And if I say yes, the test begins.

The Home button is now locked. It was locked by some code that I'll show you at exactly this point.

And I can't cheat in the test. I can't hit the Home button to get out. I can submit my answer here, Ottawa. And at the moment I hit Submit, this particular app unlocks iOS. So there's a function we're going to tell you about that turns the locking on and off. So now I'm back to a point where I can hit the Home button.

So those are two different approaches. One of them a fairly manual approach, Guided Access, walking around and actually triple tapping on a device. And then the other one is a programmatic approach, which I think you would agree is a little more flexible.

Those are two ways. I'm going to talk about four ways that you might lock an application. One that we just saw was Guided Access. This is a great technology for keeping a child, for instance, focused on a certain task.

You can lock your child into Swift Playgrounds and not let them out until they can explain the difference between a struct and a class, for instance. Whatever scenario you want, you can lock a child to a particular application.

There's another technology you'll often see in Kiosks, single app mode. This is useful to keep the iPad pretty much permanently locked to a particular application.

You've probably seen this if you've gone to an Apple store. There's some iPads on display that are permanently running an information application, and you can't get out.

But there are two techniques available to programmers. The first is called autonomous single app mode.

Picture a situation where you have a medical clinic, and the nurse is using an application with confidential information on it, and then a patient arrives. You'd like to hand them the iPad to check in and have it locked during that little transaction and have it unlocked when you get it back so that they can't hit the Home button and mess around during one section of your application.

That's called autonomous single app mode. It's a single app mode where locking takes place, but it's autonomous, because it's your application that decides when the right time is.

And there's a fourth mode specifically designed for the education community for people building standardized test applications, automatic assessment configuration.

This is for students taking a high stakes test, and it locks the iPad, but it also disables some additional features, like spellchecking, and auto correct, and Siri that you would not want a student to be using on a test. We're going to talk about these four scenarios. They each have different technical requirements.

Guided Access really just works on any iPad at all. Anybody can walk up, and turn it on, and triple tap to enable it. It's a very widely available technology.

Single app mode that you would see with Kiosks, this is something that only works on a managed and supervised device. So it won't work on the run-of-the-mill, bring your own iPad from home. It works only on a managed device, and it requires support from MDM and from the system administrator. Somebody has to designate exactly which apps, exactly which single app, we're going to lock right now.

Autonomous single app mode, much more flexible.

It still requires supervised devices, and it requires the administrator to white list specific applications, but now it means that the iPad can decide. Your app can decide when to turn the locking on and when to turn it off.

And finally, the last one, automatic assessment configuration, is the best for assessment developers because it locks the iPad and it also disables a whole variety of features that creative students might use to enhance their ways to answer questions on a test. That automatic assessment configuration requires a special entitlement that you can apply from Apple, but once you've got that entitlement, your app can lock any device, whether it's managed or not.

So locking an iPad programmatically.

Several different ways.

Guided access, we saw a moment ago, is a great way to focus a child on a particular task, and it has some obvious advantages. Anybody can set it up. It's very easy to set up.

And a couple of concerns. It's not a particularly scalable way to do anything, because you have to walk around and actually touch every iPad. If you have hundreds of students who are about to take a test, someone would have to walk around and touch the Home button three times on each of the 100 devices. That doesn't scale very well, plus you have to manage a pass code. So it's great for some situations, but not others.

Single app mode that you might do with a kiosk brings a level of remote control to this process.

If you have iPads where there's only one application that you might ever want to run, maybe something that displays train schedules or conference room reservations, an admin can push a command to a managed iPad to lock it right now to that application. In fact, you can lock hundreds or thousands of applications of iPads simultaneously.

Here's what it might look like.

Let's suppose you have some sort of a tourism kiosk, and you want your iPad to run this application only.

An administrator using an MDM tool, which specify that your application is the one that's allowed to do single app mode, and then the moment they push this configuration out, the iPad immediately launches that app, and it stays in that app.

If you reboot the device, it goes back to the kiosk application again. This is a good way to pretty much permanently lock an iPad to a particular application. The way you get out of this is to push a new command from the Admin Console to remove this single app mode setting.

Very useful to lock thousands of devices simultaneously and more or less permanently, but it does require IT involvement. We have seen situations where people have forgotten to unlock the iPads via this technology. If you were a school, and you locked all the iPads to the math test, and you forgot to unlock them, now nobody can do anything until you remember to push out that next command.

It does require a supervised device managed by MDM, and I would say the main downside to this is that developers really have no control.

When you lock with single app mode, the device immediately locks, we're stuck in that application. Not very . Wouldn't it be interesting if -- wouldn't it be great if, as a developer, you could control exactly when that locking happened? Like, for instance, if you had a medical practice like this, with a patient management application full of confidential information, when the patient arrives, wouldn't it be great if you could hand them the iPad, touch that button, and know that the iPad is locked, the Home button does not work while we are on this screen.

And then once the patient fills in all their information, they might touch Check In, hand the iPad back to me, and now it could be unlocked, and we would regain full control.

Wouldn't it be great if clicking that button right there, right there, wouldn't it be great if clicking that button right there turned locking on? Yeah! Yes, yes, you're right. It would be great. Wouldn't that be great? What about this side? This side, you think that would be great? Yeah. Yeah, it would be kind of cool, wouldn't it? Well, you know what, have we got a function for you. Well, as a matter of fact, that would be great, and we do have a function for you. . And here it is.

UIAccessibilityRequest GuidedAccessSession.

Nice, easy-to-remember function. UIAccessibilityRequest GuidedAccessSession.

That turns locking on and off.

Here's another function. Is Guided Access Enabled? It's a Boolean. Is it on or off? You can check. And there's a notification you've asked for. You can be alerted when the status changes. But mostly, there's this function here, UIAccessibilityRequest GuidedAccessSession. This is the key.

If your device and your application are set up the right way, and there is some setup required, then your app can call this function lock the iPad right now, and it can call it again to unlock. And let me underline that. If the iPad and your application are set up the right way, this is a powerful function that is not available to all applications.

Adding the code is important, but there's some other steps you actually have to do. So speaking of code, let's see some code. You would call this function to start a locking session.

You would pass it either true or false. Do you want to lock? Do you want to unlock? And you would also give it a completion handler that would be called when your request completes. It can take a second or two for the locking to take effect, so you pass a completion handler, and your completion handler gets a Boolean parameter that indicates whether the request succeeded or not.

It's possible that the request could fail, and so you want to actually check that. But if all goes well, you can check if the request succeed and now do something with the confidence that the iPad is locked at this point, and the Home button is disabled.

So in our hypothetical medical example, let's suppose we have a function like this that loads New View Controller with a patient check-in screen on in.

you could wrap that in code like this, and then that transition would only happen if the device had been locked successfully.

Then when the patient is done, you've got some other function that transitions back to the main screen, you would put something like this in here. You would say UIAccessibilityRequest GuidedAccessSession false, and that's a request to turn off at app lock at that point.

There's another one you can call. Is Guided Access enabled, true or false? You can do some extra checks.

You can check at any time whether you're currently in a locked state or not.

There's also a notification, UIAccessibilityRequest GuidedAccessStatusDidChange, and you can register for this, and your app can be notified anywhere as the status turns on and off.

So all this technology taken together is called autonomous single app mode, ASAM.

It's like single app mode, but it's autonomous, because your app can control exactly when the locking and unlocking takes place. You can lock just part of an application. Now for this to work, iPads do need to be set up in a particular way. Let's talk about the requirements. The first requirement, you have to write the code. You have to call that function.

Second requirement, the devices have to be supervised, which is a sort of extreme form of iOS management.

And thirdly, your app needs to be white listed by the MDM administrator. The administrator can grant permission to call this function only to certain applications.

So here's what an admin would do. In an MDM tool, there's a place where you can mark which applications are allowed to enter and exit single app mode.

Only the applications on this list will allow that function to work. So you'd list exactly which apps are allowed to use it here. And remember, this only works on supervised iPads, not iPads that people are bringing from home. Ultimately, this converts to a particular key and value in a configuration profile. The bundle IDs of all the apps that are authorized to do this, that's transmitted to the device.

And once that configuration is set up, your app can actually call that function and turn the locking on and off, and you have control. It's autonomous single app mode. You can prevent people from accidentally getting or deliberately getting out of the application.

However, there are a couple of issues. It does require an MDM managed and supervised device, and the IT department has to specifically white list your application, grant it permission.

And all this is really onerous in some situations. It's ideal for the patient check-in scenario or the scenario with the bank where the mortgage specialist is handing you the iPad to fill in your information. We want to lock it right then. It's great for that kind of scenario, but it's not really robust enough for assessment, for testing.

Testing has its own set of requirements. If you're delivering a test to a large group of students, it's a kind of a high-stakes scenario. Not only are the students going to be judged on their knowledge, but the teacher and the school are going to be judged on the results as well. So it's important that we deliver a test in an application with the highest possible integrity.

We don't want students cheating. That's what we're talking about here. We want to make it hard for students to cheat.

These three technologies are useful in other scenarios, but not in an assessment scenario, because they leave certain features running, like spellchecking and then the dictionary lookups and so. Those are still running in these other scenarios, and you wouldn't want that in a test.

So Apple recommends automatic assessment configuration as the method that a test builder should adopt.

What is it? Well, assessment apps have unique challenges. That are a whole lot of very useful features on iPad that are not appropriate when a test is actually running. In order to protect the integrity of the test, we're going to want to disable things like copying and pasting from outside the test into the test. We're going to want to disable, obviously, other applications. But we're also going to want to disable spellchecking on an English test, and we're going to want to disable the built-in dictionary. So you need to be able to disable certain hardware features to run a secure test, and you might not have considered this, but you also need to disable sharing off the iPad. We can't have a student copying all the questions and using the Share menu to ship them off to another iPad of another student outside. We need to turn off that universal clipboard as well. In fact, we need to turn off a whole lot of things.

You really do need to turn off all these features like this to run a safe and secure test.

This combination of locking iOS, as I showed you before, plus automatically disabling all these features is called automatic assessment configuration.

Now AAC, automatic assessment configuration, works just the way I showed you with ASAM. It's the exact same function. You call a function true to lock, false to unlock. You check the status.

Exactly the same process right there.

But in addition, the moment you lock with this function, all these features are going to be automatically disabled for the duration of your test, and when you call the unlock function, they're all enabled.

There is a requirement here.

This works on any iPad, whether it's managed or not, but it's a pretty powerful technique, so you need to have a special entitlement in your application before that request will succeed.

Technically, the request is called com.apple.developer. edu-assessment-mode.

You need to apply to Apple for this entitlement, and once you have it, your application will be able to lock and unlock with no need for a supervised device and no need for white listing.

Your app needs to be built with a profile that includes this special entitlement.

And once it locks, well, how does it unlock? Well, the device is locked. Normally, it would unlock, because at the end of the test, you would call the function that says false, time to end our session, the student has submitted the answers.

But the iPad also unlocks if the user reboots it. This isn't like single app mode where we permanently keep you in a device.

It's a temporary single app mode.

And it also unlocks after eight hours.

This is a -- if you are administering a particular long test, you might want to be aware of this. You will get a notification that the locked status has changed, and you could take that opportunity to lock it again.

Let me know if you're creating a test that takes eight hours to finish. I do not want to write that particular test.

But what people see when they're doing this is this. This is a sample application. There's sample code associated with this session that you can download. Two buttons that turn locking on and off.

This app was built with the right entitlement, and there's a text field where you can try typing to see if spellchecking works, and there's a log of what happens. When you tap the Enable App Lock here and call that function I've been talking about, this panel is automatically displayed. The gives the user the opportunity to say yes or no, they are willing to enter the lock session.

And if they tap yes, a banner automatically appears at the top that says your iPad is now locked, and it's going to unlock after eight hours or when you finish the test, and then that goes away after five seconds.

Now the iPad is locked until such time as somebody runs, calls the function to unlock. In this demo app, tapping the red button calls the unlock function, then you get another banner across the top. "Your iPad is no longer locked." In between the green and the red, the Home button was successful disabled, and this is a pretty simple sample application. Just two buttons with two action methods. One calls the function with true to lock. The other one says false to unlock. Let's talk about some of the considerations in here. It's pretty good that the apps can lock and unlock themselves, and it's great for assessment, that all these other features, like spell check, are automatically turned off in addition to the locking. You, the developer, have control, and this doesn't require a managed device. In a school situation, this will work on a device the student brings from home.

However, you do need this particular app entitlement in your application, and this entitlement is only for assessment developers.

How would you implement this in your app? Well, the first step is to actually apply to Apple for this entitlement, which will be granted to assessment developers but not to anybody else, and then you build a provisioning profile that includes that entitlement, and build your app with that profile.

The way you ask for this entitlement is to submit a tech support incident, and tell us, tell Apple that you would like the education assessment mode entitlement.

And then once that's been granted to you, you can go to the developer portal and build a new profile that includes that entitlement. You will only see this selection here if you've been granted the entitlement, and you can now build a provisioning profile that has this special entitlement in it. Don't forget this step. It's not enough for Apple to grant you the entitlement. You have to create a profile that has it embedded, and download it, and use it in Xcode.

Also, don't forget that you want to apply this to several different profiles. It's not enough just to put the entitlement in your development profile. You should put it in the distribution one, and if you've done it correctly, you should see here in Xcode, once you select a profile with this entitlement in it, you can touch that little info button, and you can see the entitlements that are built in here. That's the way to confirm that you're doing this right. If you see that magic string there, com.apple.developer.

edu-assessment-mode, you're good to go. You can now build an application that actually uses this technology.

When would you do it? Well, when you're ready to enter the test, you'd call the magic function with true, and when you're ready to get out of the test, you'd call it with false, and it's very important to check whether it worked or not, because there were some scenarios where it can fail. I'm going to try actually doing this. I'm going to try actually building something that they used this year. Take my life in my hands here. So you remember this testing application that I showed you before.

I have a secure version and an insecure version of it on this iPad. I'm going to show you the insecure version, just to highlight some of the problems that might come up in a test, then I'm going to change the insecure version into the secure version.

This is the insecure version of the test.

If I touch Start Test, I could do all kinds of cheating things.

I could look up Canada in the built-in dictionary. Oh, there's the capitol right there. It's Ottawa. That's pretty good.

Let's assume that we've blocked the Home button. Even if we've blocked the Home button, a lot of other stuff is possible. If I type my answer up here, O-T-T, I'm getting suggestions in the completion bar that happen to include the correct answer. You'd probably like to disable that in a test as well.

You should probably disable the share sheet. We do not want students sending the questions to their friends somewhere else. All this stuff needs to be disabled in addition to the Home button. I mean, my Home button's still working here. That's the first problem.

So I'm going to show you the code for this particular application here, and then we're going to try turning this into a secure version.

So this is really a "nothing app." I put no effort into this application at all. It's a couple of view controllers, and we touch the Start the Test button, and it loads another view controller right here. That's the time that we want to turn locking on.

There are, however, a few prerequisites that you have to do before you can do this locking dance.

First of all, you have to have a provisioning profile with the right entitlement in it. You have to have applied to Apple for this entitlement, and generated a provision profile that includes it.

I fortunately have done that, so I'm just going to change my code signing right here to use this provisioning profile, which I have previously downloaded, and it has the magic entitlement in it. I can verify that touching the info button right here, and you'll see that the com.apple.developer. edu-assessment-mode entitlement is buried in here. We're good. I can compile an app now that will use this particular entitlement.

That's step one.

Step two is that Xcode these days is particularly cautious, I'll say, and Xcode wants you to state exactly which entitlement this app needs to use right now by creating an entitlements file. It's not enough just to have the provisioning profile with the entitlement in it. You also need an actual entitlements file. I've made one of these here. Entitlements files are just keys and values like that.

So I'm going to add this. This is the awkward part of the demo. I'm going to add this entitlements file to my project, and I'm going to go to the build settings, my favorite part of Xcode, looking around at the build settings for the entitlements, and I'm going to tell it that I want to use that file, AAC.entitlements.

I'm specifying that that's my entitlements file specifying that, yes, I really do want to use education assessment.

All right. Now I think we're okay to go. Now I think we're okay to go. This is still an insecure test, because it's not making any effort to call the locking function, so I'm going to put that in. I'm going to put a lock around this present line right here. Here we go. Apple we have these little shortcuts ready to go. This is the block of code that I just pasted in. We're going to request a Guided Access session with the parameter true. True means lock, yes, now. And if it succeeds, we're going to do one thing. If it fails, we're going to do another thing.

So I'm going to move this line of code up into that if block up there.

By the way, if you take nothing else home from this session, command option left bracket moves lines of code up, and command option right bracket moves them down. This is the greatest thing.

Hey, oh, look at that fun.

Anyway, we is now put that inside this if statement. So we're going to request a lock, and if it succeeded , we're going to present the other view controller.

It's important to pair the locks with the unlocks. You have to have some way of unlocking the application. And in this particularly extremely simple app , I'm just going to do it here. Every time this main test picker view shows up on the screen, we're going to unlock.

This is an unlock call to that function. We're passing it false to say please try to unlock the device.

So we lock the device when we leave the test picker screen, and we unlock it when we come back to the test picker screen.

I think we're okay here.

Let's find out.

Try running this. And here it is.

So I'm going to choose the geography test, and I'm going to touch Start Test. That's when the lock code is invoked. I'll touch Start Test. now it's asking me. Now it's asking me the user to confirm that we like to enter single app mode for the duration of eight hours or until the test is over, and I'll say yes.

Now that I'm in the geography test, you'll see the banner at the top advising me that would like for the next eight hours or until the test is over. I can't look anything up here anymore. That had the look up button on it before. I could have looked up the answer in Wikipedia, but that's been automatically turned off.

My spell checking has been automatically turned off down here. we're really taking all the fun things out of the iPad here for the duration of this test here, just to ensure that we have a test with some integrity here. The capital of Canada is Ottawa. Alright. And when I touch the Submit button, we return to this screen, and ASAM is turned off with the other function I put in. now the Home button is now working. So the Home button was not working while we were in the test.

All those cheating services were not working either, and once we exited the test, everything was fine. I'm feeling kind of confident here. I want to try another test. I think I did okay in the geography test. Let's try another one here.

Spelling. I'm good at spelling.

So we'll lock as we go into the spelling test.

Here are my spelling words. What's that? Schnauzer. Schnauzer, okay. Can I have the definition of "schnauzer"? A medium or small-sized dog of a German breed with a closed wiry coat and heavy whiskers around the muzzle. Okay, I think I can spell that. Can I have it in a sentence, please? Get a load of that guy's schnauzer. All right, schnauzer. Let's see here. . S-C-H-N-A-U.

You notice I'm not getting any typing situations here.

Zed.

Zed, thank you. From Canada. E-R. . Hey, all right. I got that one right. I'm feeling kind of cocky. I want to try another word. I want to try another word. I got ten minutes left. I'll do a couple more words in the spelling test. What do you say? Let's try one more word in the spelling test. Syzygy. Uh-oh. What? Syzygy. Syzygy? Syzygy. Can I have the definition. A conjunction or opposition.

That's not really helping me. Syzygy. Can you use it in a sentence. Your spelling bee word is "syzygy." Okay. Man, I don't know. S-Y-Z-Y-G-Y. . Hey, all right.

One more, one more. I'm feeling pretty good here. One more, one more here. Let's try one here. Calfafa . What's that again? Calfafa. . Calfafa.

Jeez, I don't know that one. Can you use it in a sentence? Despite the constant negative press, calfafa. Calfafa. All right. C-O-U-- . Oh, I was spelling it the Canadian way, C-O-U. I'm sorry.

Anyway, I can't hit the Home button while this test is going on, because we requested a locked session. The moment I hit Submit, I'll transition back to that other screen, and I'm now able to hit the Home button as the test is over.

So it's that straightforward. . Thank you.

Oh, you're too kind.

So it's pretty straightforward to actually add this to your application once you have that entitlement. I've got to remind you. You've got to get that entitlement from Apple before the locking and the disabling is going to work.

Let's talk about a couple of other considerations.

I've mentioned that the request to lock might fail, and that's true in the ASAM model where you're deploying to a supervised device and also the AAC model where you're deploying to any device with the entitlement. The request to lock can fail, so you really do need to check that parameter.

In ASAM, it will fail if the device is not supervised and if the bundle identifier hasn't been set up properly. In other words, if the device is not being managed properly for your test, an ASAM request will fail. In AAC, it will fail if your app does not have this entitlement built in.

In both cases, it will fail if the user hit "no" on that button where -- that panel where they're asked if they want to lock or not.

But, and this is kind of weird, it will fail if the device is already locked. This is a little weird.

If you make the lock request twice in a row, the first one will succeed. You'll be locked. If you ask to lock again, the second one will fail, but you'll still be locked.

So you have to be careful about this in the setup of an assessment application. All those restrictions of disabling the dictionary and spell checking, those are only there if it was your app that actually successfully called that UIRequestGuidedAccessSession function.

If you were locked for some other reason, those restrictions are not going to be in place.

So it is a good practice to check. Before you try to lock the device, check if it's already locked.

Because if it already is locked, and you didn't do it, something is wrong. We're in an odd situation. Maybe somebody walked up and turned on Guided Access with the triple tap thing. If they did that, the restrictions are not going to be disabled properly.

So it's important that you actually check. Here's one way. You can check when the app is launched.

We suggest you wait for two seconds after app launch, because it takes a moment to lock everything, but you can check after app launch, call that Is GuidedAccessEnabled function. And if you are locked immediately after launch, something is wrong in your testing environment. You weren't supposed to be locked at this point.

For a test, you should stop at that point. You should not proceed with the test. Similarly, you should do a test before attempting to call the lock function. You should check that Guided Access is false, GuidedAccessEnabled is false before you try to lock. You want to make sure you're in the right state before you call the locking the function to ensure that not only is the device locked, but it's locked with the restrictions. Here's another consideration for a standardized test. Probably a good idea to clear the paste board coming in and leaving your test.

AAC automatically disables the universal clipboard for sharing to other devices, but you need to clear the built-in system paste board when the test starts to keep a child from copying the test in notes and then launching the app. You want to clear that out. You probably want to clear it on exit of the test as well, so they don't copy the questions and see it somewhere else.

Pretty straightforward to do that. You just set the items of the general paste board to an empty array.

You should probably consider disabling third party keyboards in an assessment app as well.

Third party keyboards are app extensions, and they're not blocked by AAC. You might have an application like this, where the student has installed another keyboard which actually some keyboards actually support searching right in the keyboard. You could search for the capital of Canada right there in the keyboard and get the answer. That's probably not a good keyboard to use in a test.

So as a developer of an assessment application, you can implement this function in your application delegate to allow or disallow specific types of extensions as they are being voted.

I would suggest just disallowing all of them, especially keyboards.

But disallow all extensions in a standardized test app. Remember, the goal is to take all the fun out of the iPad for the duration of the test, and then restore the fun when we're done.

Let me just review again the difference between these two techniques, because in software, they're exactly the same.

You call this same function, UIAccessibilityRequest GuidedAccessSession, and the effect is different, depending on how the devices and your app are set up.

The code is the same.

You call that function. In each scenario, the device is locked.

Remember though that in ASAM we have to be dealing with a managed and supervised device.

In AAC, we can deal with any device, so long as your app has the entitlement.

But the biggest difference is that AAC also turns off a whole bunch of other stuff for the duration of the locking session. So that is the technology you want to use if you're an assessment developer, to lock an application. Other developers may find that ASAM meets their needs, but AAC is specifically for assessment developers. So we talked about four ways to lock an app. Guided Access, lots of fun. Do that when you get home.

Lock your children into the SpongeBob Squarepants application so that they can't look at your mail, and then that's a nice easy end user sort of thing to do. Works on any device with any app.

Single app mode is good for kiosks, but it requires the administrator to push out a command to a fleet of managed supervised devices, and then they are pretty much permanently locked to the application. And then ASAM and AAC are the same software function with two different effects, depending on the setup.

Two different effects depending on whether your app has this entitlement and whether the devices are managed or not.

So there's a bunch of related sessions at the conference. I hope you enjoyed all the related sessions. I like that second one on heifers and HVAC. I think that's the air conditioning for cows. Oh, I'm reading that wrong.

HEIF and HEVC. A lot of our assessment developers deliver web content as part of their applications, so I think these are particularly relevant sessions for people to use.

But for more information and for -- including a sample application that demonstrates how all this works, please take a look at the website here for Session 760.

Thank you very much. Thank you for coming. I hope you enjoy the week. Thank you.