Good afternoon. How are you doing? Welcome to Session 301: Extending your Apps for Enterprise and Education Use. My name is Dave Rahardja and I'm up here with Victor Alexander. So as you know, the use of iOS in the enterprise is growing at a phenomenal rate. There's great momentum in the enterprise to adopt the devices that people love so much and that allows them to do so many things that they couldn't do before. From everything, from retail to corporations, to medical, to education, even inside airline cockpits, iOS devices are everywhere you go.

A large part of the success is of course due to the elegant design of iOS devices, the great management capabilities of iOS itself, data security that's built into the device and a host, a lot of things that people love about the device carry over into the enterprise use.

But much of the success is thanks to developers like you that develop apps that allow the enterprise to do things that they couldn't before. Apps in the App Store, in the custom B2B store and in-house apps that are developed by the enterprise themselves. So during this hour, I'd like to talk to you about how you can make your apps more attractive to the enterprise so you can take advantage of the growth in this industry.

And I'm going to do that by highlighting four major areas that you can implement in your apps to do this. They are: authentication, networking, data security, and management. And, of course, this is an incomplete list of making an app that would be attractive to the enterprise. Of course, your apps have to provide a solution that they're looking for.

Of course, your apps have to have a great user experience and those things are a given. But these are the things that we're going to focus on that will let you add that little bit of extra so that your apps stand out from the crowd in the enterprise market.

So, let's start up with authentication. Authentication is, of course, very important in the enterprise. When someone logs into your app, you have to know that this person is who they say they are. So, iOS has built an, of course, a great authentication tool if you are an in-house developer or if you're an App Store developer that has developed a suite of apps and we call that shared keychain. Now, that way shared keychain works is that if you're a developer and you have multiple titles or multiple apps that are deployed on a single device, those apps share the keychain or could share the keychain.

This allows you to sign into one app and reuse the sign-in in a second app and it's very convenient because users don't have to keep signing in every time they switch their apps. And for in-house developers, this is a great solution because all your in-house apps can be signed with the same shared keychain with the same ID and you can implement this in your own Apps.

But what happens if you want to mix and match? So, if you're an enterprise and you say, "Hey, that's a great App Store app." You want to pull it in, it supports my authentication model, but you can't really share the keychain. So now, you end up having to log in twice depending on which app you have. So, new in iOS 7, we are introducing Single Sign-On.

Single Sign-On takes the burden of authentication and places it inside iOS. So, let's take a closer look at this. In iOS 7, Single Sign On is built on top of Kerberos. This is a very popular authentication scheme as you know inside the enterprise. You can grant access to your Single Sign On accounts to specific apps only. And of course, the passwords are never stored inside the Apps but they are managed by iOS.

As an app developer, this is what you have to do. Oh and by the way, for every one of the topics that I'm going to talk about, I'm going to talk about it from three different perspectives. I'm going to present to you what iOS brings to the table.

And then, I'm going to talk like I do here about what you as the app developer can do to take advantage of the service. And then, I'm also going to talk about it from the IT integrator's point of view to tell you what you need to be aware of when you want to deploy this feature in your enterprise and what to look for when you are trying to find the next great app to deploy in your enterprise, what kind of features you're going to look for. So keep that in mind. So Single Sign On. As an app developer, I have great news for you. You have no co-changes required if you use NSURLConnection.

If you don't use NSURLConnection, the way you take advantage of Single Sign On is to use NSURLConnection. So that's-- so we built this into the NSURLConnection mechanism. You can also use NSURLSession which is the great new API that we're introducing in iOS 7. So, the only change that you will see as a developer is when you access a resource that has been configured it to be managed-- to use Single Sign On authentication, you will not receive this callback: the willSendRequestFor AuthenticationChallenge callback.

So, what you'll do is you'll make a request, you will not see an authentication, iOS will prompt the user to enter their credentials. If it's successful, your request will just complete, it will just succeed. If not, then it'll just fail. So, your app probably already works with Single Sign On.

For IT integrators, the way you configure Single Sign-On is using a configuration profile. So as you know, configuration profiles is the-- is the way that we manage settings and accounts on iOS. Inside the configuration profile, you can define a Single Sign-On payload, define the account, you know, the realm. And define the app bundle IDs that you are going to allow into this system, into the Single Sign On account, you can also define URL prefixes. So, when you go to Safari and you hit the URL prefix, it will trigger Single Sign On.

So, that's what new in Single Sign On and authentication on iOS. Next, we're going to talk about networking. So the networking environment in an enterprise is maybe a little different from the environment at home. Generally, iOS has great support for enterprise networking. It has great SSL and TLS or TLS Support and we, of course, allow MDM to install certificates, certificate chains and such if you have you have your own self-signed certificates.

Then, we also have proxy support both per SSID and Global Proxy, and we support enterprise Wi-Fi 802.1X, WPA, WPA2, and we support virtual private networks. And VPN tunnels the traffic from your iOS device into the enterprise, into the intranet. All right, something new in iOS 7, we're introducing per-app VPN. So, what's this? Here is what this conceptual-- a conceptual model of what per-app VPN does.

So, let's say you have two apps that the enterprise has installed: app one and two, and you have an app that the user installed on their own device. Let's say this is a "bring your own device" scenario, the user installs their own device-- their own app on the App Store. Per-app VPN allows you to specify that apps one and two go to the VPN into the corporate intranet and not app three. App three that the user installed does not get access to the intranet. So that's what it is conceptually.

This limits VPN access to only the apps that the enterprise has installed, specific Apps. It enhances both security and privacy. So, security because you are not exposing your intranet to apps that the user may have installed from the App Store on their own. That's better than system wide VPN.

And privacy, because your user's personal traffic to the internet does not go through your enterprise network, all right? I knew you'd like that. All right, so per-app VPN for app developers, what do you have to do to take advantage of this great feature? Nothing, your app already works. It works transparently, you don't have to change a thing, this is my favorite slide, it's great.

For IT integrators, what do you have to do to install this-- to configure this feature? You need support from your VPN plug-in. Now, these are the same VPN plug-ins that you probably already use from your third party VPN vendors. They need to have a plug-in that supports the notion of per-app VPN.

Once that plug-in is installed, you then configure the VPN account with a configuration profile through MDM and then you use MDM to tag which apps are allowed to use that VPN connection. More things about networking? If you are developing without using NSURLConnection, you'll see a pattern here by the way. If you don't use NSURLConnection or NSUrlSession, you must-- you need to be aware of the presence of proxies inside the enterprise.

If you are using NSURLConnection or the new NSURLSession, we take care of that for you, you have to-- don't have to worry about it. But if you're using say, CFSocketStream or UNIX level sockets, you need to be aware of that. Read the API, you probably need to move some data structures around to take care of the presence of proxies in your path. And as a final note and this is not just for enterprise, this is just good practice for an app developer. Be conscious of your app's cellular data usage.

In iOS 7, we've enhanced multi-tasking so that your app can be woken up at particular intervals or when a push notification comes in. This is great for you to update the status of your app but you need to ask the question, "Should I be doing this over cellular?" If you're going to update a large amount of data, maybe you should defer it to when the user brings the app to UI foreground or when you are in Wi-Fi.

So, in an enterprise, it is especially attractive if your app knows how to behave itself and limit the consumption of cellular data. And the way you do that is you tag your URL request with this property, allowsCellularAccess equals no and that-- really, that's it and that request will not go out over cellular, very simple. So, that's a short session on networking in the enterprise. Next stop, data security.

So, data security is very important in the enterprise. One of the things that you'll notice when you develop apps for the enterprise is the enterprise is really, really concerned about the security and privacy of their data. And here are some things that are available to you in iOS already. So, built into iOS, we have a great data protection model.

There are three main data protection classes in iOS, just to review. There are some subtle variations on these, but basically, there are three classes that you can choose from. These classes can be applied to files that you write to flash. So you have none which is none, they're not data protected.

You have complete with authentication which protects the data in an encrypted fashion until the user enters their passcode for the first time after a restart. And complete, which will protect your data as long as the phone is locked. So when the user locks the phone again, it gets protected. Let me illustrate that. So, after the device has restarted, none is readable, the others are encrypted, unreadable by your apps.

When the user enters their passcode, then all the classes become available for reading and writing. When the user locks the device again, that complete class gets locked while the others remain unencrypted. So, keep that in mind, this is the model that you can choose from and you can start to see that this is a good way of binning your data to see which kind of sensitivity does the enterprise have about that particular file and for you to choose which class you want to choose from.

So, but there's one thing new in iOS 7 that we're really proud of. We are improving the data security of all apps in iOS 7 across the board, even App Store apps. All App Store apps and enterprise apps that are installed in iOS 7 automatically receive the complete until first authentication class, the second class.

What this means is that for the enterprise, for the IT integrators of the enterprise, you can now feel confident that when you install an app from the App Store even, that that data has some-- has a greater level of protection in iOS 7 than it did in iOS 6. And we do this across the board and there's no change required for most of the apps.

Also, you may be aware or not that starting from iOS 6, we have FIPS 140-2 certification. This is a government certification that certifies the integrity of our crypto, CoreCrypto algorithms and we're really proud of this. So, for app developers, what do you have to-- what can you do to enhance your data security? Well, use the protection complete class when appropriate. Ask yourself the question, if somebody were to be able to read this file off a disk-- off the disk, will that make my enterprise customer happy or not? And if the answer is no, then please consider using the File Protection Complete Class.

There is a small wrinkle when you do that, of course, when the device is locked and your App gets woken up by multi-tasking, you can't actually write to your database because it's unreadable and unwritable. And as I said, there are some variations to this theme but in general you will be woken up and then you'll discover that you can't write to the files that you need to write. So, at this time, consider what your options are. First of all, you can always write down the fact or write to disk the fact that there is an update and the next time the user launches the app in UI foreground, device is unlocked, go fetch the update.

Or you can create a side buffer file of maybe the second protection class, you know, complete until first user authentication to buffer your data. And then, write that over to the protected data base when your App goes to foreground. But of course, the question you ask there is, should I be doing that with this data? And if the answer is no, then just write the fact that you are-- that you need to do an update when the app comes back to foreground and do it when the app starts back up.

The keychain has an additional attribute that you can place on the data security of each item. You can assign an app-- a data security attribute per keychain item by the way, the same classes that you have up there with an additional feature in there. If you'll notice, the attribute here says accessible after first unlock this device only in the end.

This helps you to secure credentials, private keys, passwords or whatever from getting backed up off the device and restored to another device. Right? The fact that your keychain items are backed up and restored as a great convenience for end-users because you don't have to log in again. But for the enterprise, you should ask the question, if a user logs into this device which may be managed by the enterprise, is it appropriate for that login to transfer to another device that the user owns that may not be managed, right? So in many cases, the answer is no, and you need to put this attribute on the keychain items to prevent backup and restore from taking that credential out of that device.

And finally, iCloud Document Sync. Now, iCloud Document Sync is another feature that users love but this becomes a problem for enterprise data because sensitive enterprise data may leak out into the cloud and into other unmanaged and unprotected devices. So, the enterprise does have a restriction to disable iCloud document sync across the whole device. And it would be better if there was a way to disable iCloud Document sync in your app only so that the user doesn't have to turn off document sync across the board.

So, consider adding a-- the capability of storing your documents in your local documents folder instead of the iCloud document folder when your app is configured for enterprise use. But, how do you configure your app for enterprise use? You certainly don't want to put a UI switch to let users turn off this feature. Well, there's a great way of doing that and I'll talk about it a few slides down so hang in there.

So, there's data security. Let's talk about management. When we talk about management on iOS, we generally talk about mobile device management protocol. This is a very powerful protocol that allows an enterprise to manage and administer thousands of iOS devices over the air. And some of the things MDM can do, it can set passcode and security policies, like you'd have to have a certain number of letters in your passcode and stuff like that.

It can install accounts including email, calendar, VPN, you know, Wi-Fi accounts, any-- all kinds of accounts. It can remotely erase your device and it can, of course, great news for you, install and remove apps over the air. Now, the accounts and apps that are installed by MDM are called Managed Apps, Accounts and Apps.

So things that are installed with MDM are Managed and the things that users install in the device are called Unmanaged. So, Managed Apps and Accounts. So in iOS 7, we're introducing another great way to manage the data inside your managed apps and accounts, we call it Managed Open In.

Managed Open In prevents the unintentional data movement between managed and unmanaged apps and accounts. Managed apps-- managed data stay inside managed apps and accounts and they don't leak out to the unmanaged ones. So, to show you a demo of this, I'm going to call Victor to show you a little demo of Managed Open In.

Great.

Thanks Dave. All right. So here, we have an iOS device which is running iOS 7 and it's being managed by the enterprise via an MDM server. You notice we have number of applications installed on this device. But specifically of note that the top of row of applications were ones that were installed by the enterprise via MDM, and the second row of applications were installed by the user, so we have a bit of a mix here.

So normally, when the user might say or do something like open up mail, tap on a message and view an attachment and want to send that attachment to another application. If we tap the share sheet, you'll notice that the list of applications here is the same as what we saw in the Home screen. Long list, we've got drop box present, a long list of apps and that might-- that might not be desirable in the enterprise.

So, since this email account is a managed Exchange account, we have the ability to enable Managed Open In. So, I'm going to go ahead and push that change down to the device, we'll give it a moment to actually take effect. And now, when the user goes back to the share sheet, what you'll notice is that there's a much shorter list of applications present, it's only those applications that were installed by the enterprise. Thus, limiting the user's ability to-- thus limiting the user's ability to try and send that attachment to a non enterprise-installed application and that is Managed Open In. Back to you Dave.

Thanks Victor. So, Managed Open In works with both apps and accounts. So, when you tap an attachment and there's an-- there's a mail action that you can tap on, when you tap on that mail action, if the attachment came from a managed account, the email accounts that you can choose to send it from are also filtered down to the managed accounts.

So, that's a-- that's a very cool feature, and it works with all kinds of accounts including mail and calendar attachment. So that's Managed Open In. Next up, a great new feature in iOS 7 called App Configuration and Feedback. So, what is this? This is a way to reduce your support calls, IT integrators, by configuring apps that you install.

And the way to do this is an MDM server can send a dictionary into a managed app to configure it. Now, the dictionary that you push down appears in the NSUserDefaults of that app, it's very convenient. And the feedback part of this allows an app to write something into the NSUserDefaults that can be read by the MDM Server to report-- to report back a status out of band, right? It's very simple. As an app developer here's-- here is all you need now.

This is very similar to what happens if you use a settings bundle. So, if you already have a settings bundle that allows the user to go to Settings and configure your apps, this is very, very similar to that. Excuse me. Your app needs to read the dictionary from a particular magic key: com.apple.configuration.managed, that's where the dictionary will appear that's pushed down by the enterprise.

When you write your feedback out, write it to com-- NSUserDefaults key com.apple.feedback.managed. And when the MDM Server queries your app, it will find your dictionary there. Listen to this notification, the defaults did change notification to be aware that the configuration has changed or that the server has read your feedback and erased it to make it nil. You can be aware of that by listening to this. And your app may not be running, of course, when you-- when the configuration changes or when the feedback is retrieved and erased from your NSUserDefaults.

So, read the configuration every time your app starts up. Again, the same things that you've already done for Settings bundles, basically, the same idea. So, in order to show you how this works, I'm going to ask Victor to come back up here to give you a little demo.

Thanks Dave. So here, we have a sample application that was developed using app configuration and feedback and you'll notice at the top here, we've got a URL bar, we've got a success and failure values that were tracking. And in the center, we've got a UIWebView. And also at the bottom here, take note, we have a Cloud document sync switch. Maybe not something you might want to add to the UI of your app but for the purposes of our sample demo, I think it's appropriate to use.

So, you might notice at the top of the application, we have URL that might not work correctly. Let's start tap the go button here and see what happens. Our app is not quite working correctly, we got a failure there, no web page loads in the center, we've got a problem. This might be something your user hits if they want to load their login information for their enterprise app or help documentation and if we try and connect, we just keep hitting errors.

Wouldn't it be nice if we had a mechanism through which we could update that, reset it, correct it and get this app back into a working state? So since the URL value is something that I configured using app configuration, I could push down the change to that app to update the URL and see if we can get things working. So, I'm going to go ahead and push down that change, give it a moment for the device to receive it.

You noticed almost immediately, the URL bar updates, you noticed almost immediately the URL string updates with a much more valid looking URL and also note that the UI Switch is now disabled. So, we've done a couple of really powerful things here to get this app into a better state and let's see as a test here, I will tap, go and our webpage loads in the UIWebView as expected which is-- which is excellent.

Now, we have these-- so that's the configuration side of things, what about the feedback side of things? We've hit, you know, three errors on this app. It might be useful for the enterprise to find that out if users are having problems or issues and we can have the MDM to sort of pull that information from the apps and collect it and work with that data. Now, if I place a command to this app from the MDM Server to fetch that error information.

What we'll see here is that not only the failures but the success values were pulled out of the app, sent back to the MDM Server for evaluation by the IT Staff. But also, the values were set back to zero so that any future polls for that information can be clean and updated and evaluated between the last two times the information was pulled. And that is app configuration and feedback. Back to you Dave.

Thank you Victor. So app configuration and feedback, very simple feature, very powerful. For IT integrators, this is invaluable to configure the apps in your enterprise. You need to look for apps that support this. Now normally, you would send out apps to your users and then send them a email or something that says, "Hey, tap this, tap that, type this in, type that" and you get you know-- and you get support calls. With app configuration, you can prepare the dictionary for that app and send it to the users without their intervention. The first time they launch that app, it's already configured.

Let's take a closer look at what's going on under the-- under the covers here. So, I added this notification observer in viewDidLoad. You could add this view will appear or, you know, in your apps delegate or wherever it's appropriate for you handle the event. So, the first thing you notice is I added an observer for NSUseDefaultsDidChange, always add the notification observer before reading the values, so that you don't miss an update. And when that notification fires, what this app will do is it will call this readDefaultsValues method. And once that's done, I actually call the read defaults values method to read it at least once.

The readDefaultValues method does what you probably will do if you are using a settings bundle is to read that magic key, magic dictionary column.apple. configuration.managed, and then it picks apart the keys and the values from that dictionary. Notice that I validate the values here so I pick out the value under the key serverURL, make sure it's a string first.

This is not a very string validation but it's some kind validation before accepting the URL. If a URL is not found in the dictionary, make sure you provide a default value that is sensible even if it's nil. So, if that's not available, set it to something that is reasonable default.

So, for the feedback part, what I've-- what we've done here is to have a little feedback-writing piece of code inside the increment success and failures. So, every time the success and failure count is incremented, we create-- we try to read the feedback dictionary that already exists. If one doesn't exist, we create one, a mutable dictionary under that magic key com.apple.feedback.managed. We then write the value of the success count as a key under-- into this dictionary under a well-known key. In this case, successCount, and that's it. We just write it back to NSUserDefaults and it just sits there until the MDM Server picks it up. It's really simple.

So, what can you use app configuration for? Well, settings and preferences of course. You can set your app UI settings from here, the same kind of things that you would set in your settings bundle but very useful thing to setup here: URLs. URLs are very, very powerful things to configure with the server and you can bootstrap a lot of things using URLs. And here is where you put the disable iCloud document sync switch. So, this allows you to disable iCloud document sync in an enterprise deployment situation without exposing a user facing UI.

Some things to note about this configuration, it is stored as file protection none just as the rest of your NSUserDefaults are. So, no passwords or private keys please. You need to document your dictionary keys, of course, so that the enterprise can configure your app. And specify what kind of data types and the valid value ranges that you accept. And validate all the types and values that you get. From your app's perspective, the enterprise server is an unknown third party. They are giving you a dictionary that-- that your app is supposed to ingest, make sure you validate the content.

And of course, keep it small, as anything that you put in your NSUserDefaults. You're going to read your user defaults every time your app starts up and every time it changes so keep it small. No documents or images or little sound files or things like that in there, put the URLs in there and read the assets when your app starts up.

Once again, a reminder, your app may not be running so read this every time. For feedback, what's useful to put in there? As you saw, errors and user statistics are very useful. Again, if your app can't talk to the server, they can't report that they can't talk with the server so this is a good place to put that information in. So I, you know, I can't reach that URL, here is an error.

Aggregate your reports. Do not log, because it will grow without bound and again, this belongs in your NSUserDefaults and it needs to be small. Document your dictionary keys so that the enterprise knows what to look for and keep it small. It goes into the same place that your-- all the rest of your defaults go in your NSUserDefaults.

Your app might not be running when the feedback is retrieved and very importantly, respect your user's privacy. Before you send up any personally identifiable information, things like location, things like that, be sure that you are legally allowed to do this and, of course, respect what the user expects your app to report and preserve the user privacy. Your users will thank you for that.

For IT Integrators, app configuration and feedback amounts to a couple of new MDM commands so what you need to do is to use these commands to configure your user's devices as early as possible. So, there is an extension to the app install command that allows you to add a configuration dictionary inside the app installation request.

So, do that if possible so that the first time the user taps on the app, it's already preconfigured. You can, of course, refresh the configuration as on an ongoing basis. And use the feedback service to detect configuration errors. All right, so that's app configuration and feedback. Next, fonts. We can now install fonts in iOS 7, they are installed using configuration profiles.

So as an app developer, this means that the font list may change as your app is running and you need to listen to this notification to detect that event. And of course, this also means that your app may have to deal with missing fonts, et cetera, all that fun stuff that comes with a system that has installable fonts.

One of the things about fonts in the enterprise is that you are very likely to encounter custom fonts in an enterprise because an enterprise will probably have a corporate identity font of some sort that they will install in every device. So, your app needs to be able to adopt to that and at least use the fonts that are installed to-- in your documents and et cetera. So, that's fonts.

Next, I want to highlight a feature that is very popular in certain industries in the enterprise and that's single app mode. So, you may not know this, but MDM can put certain devices into Single App Mode which means that the device will run one app and one app only.

This mode is very resilient you can restart the device and it would launch that app. The app can crash and it will just keep launching and just keep launching and crash again which is a good thing. You want this behavior because this makes it perfect for Kiosks, for point of sale like this, for exam taking, for example, or a whole host of different applications. So, this already an iOS but new in iOS 7, were adding an app-requested single app mode. So, what's this? Some of you already know what this is.

So, app-requested single app mode allows an MDM Server to pre-authorize a set of app bundle IDs to go into single app mode. So-- and all the app has to do is to call this API, so that first one you see up there, UI accessibility request guided access session that there is the parameter you can put in there to say yes or no and enter a session or exit a session. If successful, your app will be locked into a single app mode, all right? And when your app is done with it, they can call the same API again to get out with the-- with the Boolean false.

This is great for, for example, exams. So, you have an exam app, examination starts, the new student logs in, you got locked in, and the exam is over, it locks out. You can use the second API up there, is guided access enabled, to detect whether your app is in this mode. And you can use a notification to detect transitions between states.

So again, this state is very resilient, your app will get-- the device will only run your app until you exit. So, make sure you have an escape strategy in case your app crashes or the user powers down the device and starts back up again. Try not to lock the user into your app forever, but exit gracefully.

OK. So, that's single app mode. Next up, app revocation. In iOS 7 and OS X Mavericks, we are supporting a new model of volume purchasing based on app assignment. If you're not aware of this, it allows an enterprise to purchase an app license essentially, assign it to a user's device or a user on a iOS device and then later, revoke that license from that-- from that user and assign it to some other user.

So, what happens is your app may be installed on some user's device and then, the right to run that app may be revoked from that device. So, what happens then? When that happens, your app license "is going to expire." The iOS-- iOS will run the app. Well, first of all, iOS will tell the user that that app has been revoked and give them the opportunity to buy the app from the app store. And it will continue to run that app for 30 days.

At the end of the 30 days, iOS will no longer launch your app but instead, will launch an alert or show an alert that says you got to buy this app from the App Store to continue using it. The reason we give the grace period there is so that the user doesn't lose their data and to give them an opportunity to buy from the app store.

If you're checking for receipts already, the expiry date is on the receipt, so you might want to check with that too. There is the session on the receipt checking, I recommend it-- I recommended you go to that one and we'll cite that at the end of the presentation.

So, that's management. So, as you can see, iOS 7 brings a lot to the table in all of these fields and there's a lot that you can do, with very little effort in some cases, to extend you app just a little bit more, to make it very attractive to the enterprise. Now, I want to talk a bit about the philosophy that we have on iOS about enterprise apps.

There are many cases where an app developer who wants to put their app into the enterprise just wants to tag something on in the end. I'm just going to wrap my app in something, I'm going to add some library to it and it's going to make it all better.

It's going to make it secure and stuff like that. And we don't-- we encourage you to do something different, we encourage you to build the next generation of enterprise apps, right? And what that means is we would like you to build this-- the iOS features into your app. The iOS 7 features, they are like, you know, a Single Sign On, data protection, Managed Open In, configuration or feedback for app developers, of course.

Build this right into your app so that as iOS grows and additional features are added, your app is ready to go into the enterprise, to grow along with it. IT Integrators, I encourage you to look for apps that actually support these iOS 7 features inside their app natively and not just tacked on at the end. These are the apps that are going to serve your enterprise very well into the next decade.

So, to sum up, if you ask me, you know Dave, as an app developer, what three things can I add or do to my app to make it that much more attractive to the enterprise. I will say these three things. First, support app configuration and feedback. It's a very light-weight extension to your app that will greatly help the IT Integrators to deploy your app correctly and to save them a lot of support calls.

Next, use NSURLConnection and NSURLSession. These are your best bets to get an app into the enterprise and have it work correctly the first time, all right? I know in some cases, you can't, but if you can, please do use that. And finally, build in data protection and security into your app, don't leave it as an afterthought. When you write files to disk, consider what kind of data protection you're going to use. When you write items into the keychain, think about what the use cases might be in the enterprise.

All right, so for more information, our evangelist is Paul Marcos and here are two great pages on our Apple website for you to get started. So, if you're new to this enterprise app development world, there are some great articles and guides in both the business and educational sites. And, of course, the developer forums are a great help.

There are some related sessions that you are probably going to be interested in because they are prevalent here. The first is already gone passed 11:30 AM, Managing Apple Devices. If you haven't seen this session, this session covers all of the new features in mobile device management that we've added into iOS 7 and OS X Mavericks. So, please go view that video if you can. And the second one is equally important, it's how to use your-- how to check your receipts to protect your apps. So, thank you very much and see you at the labs. [Applause]