What's new in managing Apple devices

♪ Mellow instrumental hip-hop music ♪ ♪ Nadia Hussein: Welcome to WWDC! I'm Nadia, and my colleague Graham and I are so thrilled to tell you about all the new device management features we have for macOS Ventura and iOS and iPadOS 16. In the world of device management, it's our shared responsibility to enable employees to thrive in the workforce and increase student-teacher productivity. We're continuously developing the tools and technology to help foster this collaboration. And with macOS Ventura and iOS and iPadOS 16, there are many great enhancements and features, some of which we'll cover in this session. But first, I'd like to briefly highlight a few of the additional sessions where you can discover even more about the enterprise and education space. During WWDC 2021, we introduced declarative device management, a new paradigm for device management that makes devices more autonomous and proactive, while allowing servers to be lightweight and reactive. This year we are expanding declarative device management with new platform support and new features. Be sure to watch the session, "Adopt declarative device management." Apple Business Essentials is one complete subscription that seamlessly brings together device management, 24/7 support, and cloud storage. With Apple Business Essentials, small businesses can easily manage every iPhone, iPad, Mac, and Apple TV every step of the way. Check out the session, "Explore Apple Business Essentials" to learn more. Managed device attestation is a new security feature that uses the Secure Enclave to provide strong assurances about a client device, such as its identity and software version. Attend the session, "Discover Managed Device Attestation" for additional information. In this session, we're going to discuss new capabilities with Apple Configurator; identity technologies across platforms; protocol modifications to macOS Ventura, iOS and iPadOS 16; and an exciting change to how we provide documentation. Let's start with Apple Configurator. At WWDC 2021, we announced Apple Configurator for iPhone. Education and enterprise customers love having this solution to take advantage of automated device enrollment for all of their Macs. Apple Configurator for iPhone makes it easy to add a Mac purchased outside of the normal channel to their organization in Apple School Manager or Apple Business Manager. In Setup Assistant on a Mac, simply hold your iPhone running Configurator over the animation. The Mac will then connect to the internet and add itself to your organization. Version 1.0.1 brought new, explicit support for taking advantage of existing network connectivity if available on the Mac. And we are excited to announce that with iOS and iPadOS 16, Apple Configurator for iPhone can now also add iPhone and iPad devices to your organization. This works just as you expect, just like adding a Mac. It's a great new alternative to the version of this feature in Configurator for Mac, which requires connecting each device via USB to the Mac running Configurator. A key difference for iOS and iPadOS is which pane in Setup Assistant you scan. On iOS and iPadOS, that's Wi-Fi, but on macOS, it's country or region. And remember, any device that requires interactive activation, such as activation lock or cellular carrier activation, must be handled manually before adding it to your organization, just like Configurator for Mac. Devices running iOS or iPadOS 16 can be added using the version of Apple Configurator for iPhone currently in the App Store. Now, lets cover identity management for business and education. We know identity management is important for the industry and it's a key priority for Apple as well. It enables our users to have a cohesive experience, while ensuring security of their data.

Our goal for identity is for users to sign in once, and from then on, use that identity consistently across the operating system. We're working towards that goal, and there's a lot of technology that supports that, including the new features in macOS Ventura and iOS and iPadOS 16. For Federated Authentication, Apple Business Manager now integrates with Google Workspace as an Identity Provider. This allows users to leverage their work credentials as Managed Apple IDs for authentication to services on iOS, iPadOS, and macOS. And remember, use Directory Sync -- which we've formerly referred to as SCIM -- to create the user accounts as Managed Apple IDs automatically. Sign in with Apple can now be used at work and school with Managed Apple IDs. In apps that support Sign in with Apple, this will just work! If you want to control where users can sign in, you can choose to allow all apps or add apps to an explicit allow list in Apple School Manager or Apple Business Manager. Learn more in the session, "Discover Sign in with Apple at Work & School." Another notable identity management update is OAuth support. In iOS and iPadOS 15, we used a simple access token authorization mechanism to allow the MDM server to verify the identity of users. In iOS and iPadOS 16, we are adding OAuth 2 as another authorization mechanism. OAuth opens the door for MDM servers to support a wide variety of identity providers already using OAuth today. It also improves security via its refresh token mechanism, which allows a short-lived access token to be used in conjunction with a silent refresh that won't prompt the user for credentials. OAuth can be used with the existing account-driven user enrollment flow, but it provides an even better user experience when combined with a cool new feature. We call it Enrollment Single Sign-on, or Enrollment SSO. It's a new, faster method for personal devices to complete an MDM enrollment and access your organization's apps and websites with a single authentication. This builds upon a few existing technologies. iOS 13 introduced extensible SSO as a new way to configure SSO for an organization's apps and websites. And iOS and iPadOS 15 introduced Account-Driven User Enrollment, which allows users to enroll in MDM by just entering their email address in Settings. To make enrollment even better, we combined these two technologies together because we know BYOD devices are an important part of your deployment. Users start out by entering their email address in Settings. They are then prompted to download an app from the App Store. This app, which contains an Enrollment Single Sign-on extension, provides a native UI to perform the authentication steps. Because this is an app-based model, you can use any authentication technology you choose. As a user, sign in once. The app will then sign in to get you through the enrollment flow without having to sign in again. There are four main pieces required to bring Enrollment Single Sign-on to life. First, the app developer updates their app to support enrollment SSO. Next, MDM vendors federate MDM protocol client authentication with an identity provider. Then administrators set up Managed Apple IDs using Apple School Manager or Apple Business Manager and finally, configure the MDM Server to return a URL to the JSON document in the authentication response headers. Now that we've talked about what this feature does and who needs to do what, let's dive into the details. When the initial authentication challenge from the server is received, there will be an HTTP header present indicating that Enrollment Single Sign-on is available and should be used. That header's value will be a URL that the client will use to download a JSON document. The JSON document contains all the details the client needs to continue the enrollment. The value for the iTunesStoreID key must refer to the Enrollment Single Sign-on app to be used during enrollment. The AssociatedDomains keys are the same keys available in ApplicationAttributes and can be configured here as well. Finally, the ConfigurationProfile should be a Base64EncodedProfile that contains at least one Extensible SSO payload and may contain certificate payloads if needed. And we'll be shipping this feature for customers in a later release of iOS and iPadOS 16. If you are interested in developing an app that supports this feature, you'll need to apply for a new entitlement though the Apple Developer Program. However, you can start developing for this now using test mode. This is a special version of the Enrollment Single Sign-on process that allows you to test your app before it's even offered on the App Store. To get started with test mode, head to the Developer section of Settings and enable Enrollment Single Sign-on test mode. You'll then need to configure your authentication response with the new HTTP header and the corresponding JSON document. Then, in VPN and Device Management, start the enrollment process. During the enrollment, you'll be prompted to install the Single Sign-on app. You can install the app using any method available from Xcode to TestFlight or even Enterprise app distribution. After that, return to Settings and complete the enrollment. To use test mode, there is a different header required in the response and a modified JSON document. Here's an example of the JSON document for test mode. You'll notice the iTunesStoreID key has been replaced by the AppIDs key and the value of this key is an array of strings containing the App IDs that can be used for enrollment. Everything else remains the same. Next, let's explore Single Sign-on extensions. In 2019, we added Single Sign-On extensions to iOS 13 and macOS Catalina to enable identity providers to use SSO authentication for all the apps and websites for their users. When using SSO extensions, the user is prompted to sign in to the extension after they've unlocked the device, which means entering credentials twice. If an organization also uses the built-in Kerberos extension, the user may have to sign in again. In many cases, these are all identical credentials. Well, in macOS Ventura, we're introducing Platform Single Sign-On -- or Platform SSO -- to enable users to sign in once at the login window and then automatically sign in to apps and websites. Platform SSO makes tokens from the login available to third-party SSO extensions and also works with the built-in Kerberos extension. The first login authenticates with a local account password, which also unlocks FileVault encryption on the device. This enables the user to login when offline or when connected to captive networks. From then on, their identity provider password can be used for unlock. Additionally, Platform SSO supports the use of a password or a Secure Enclave backed key to authenticate with the identity provider. And regardless of the authentication method, the SSO tokens are retrieved from the identity provider, stored in the keychain, and made available to the SSO extension. Kerberos TGTs can also be retrieved, imported to a credential cache, and optionally shared with the Kerberos extension. If the identity provider password changes, Platform SSO will validate that new password with the identity provider on unlock. Platform SSO is a fully integrated protocol that is built using OAuth and OpenID and does not use web views for authentication. Platform SSO is the modern replacement for AD binding and mobile accounts. Note, it does not directly use directory services, or check with the identity provider for each unlock attempt. Instead, the identity provider is only called when the user is attempting to use a new password at unlock or to retrieve SSO tokens. Platform SSO also does not prevent logging in to the Mac based on the response from the identity provider. For that purpose, leverage MDM or alternative strategies to disable access. To take advantage of this feature, the identity provider needs to implement the SSO protocol and update their SSO extension, then ensure the extensible SSO profile is updated to support the new keys on managed devices. Find more implementation details in the Apple Platform Deployment guide. To recap, we've introduced integration with Google Workspace, Enrollment SSO, OAuth support, and Platform SSO, to contribute to a simplified sign-in experience. Identity management is an ever-evolving technology and we are just getting started. macOS Ventura brings many enhancements across OS updates, enrollment, and security. Let's start with software updates. macOS Monterey introduced fundamental changes to Managed Software Updates. My colleague Lucy covered this in the session, "Manage software updates in your organization," where we break down OS updates into three areas: test, deploy, and enforce. This year, we focus on even more additions to deploy and enforce. Historically, all OS Update commands would return a NotNow when sent while in Power Nap mode. To ensure a more consistent and robust OS Update deployment process, the device will now acknowledge and respond to ScheduleOSUpdate, OSUpdateStatus, and AvailableOSUpdate commands even when the device is asleep or in Power Nap mode. Since we also understand that sometimes administrators want an OS update as soon as possible, we've introduced a new key called "priority" sent via the ScheduleOSUpdate command. Accepting a string value of High or Low, it controls the scheduling priority for downloading and preparing the requested update. Sending the command with a High priority will mimic as if the user had requested the update themselves in system settings. Note that this key is only supported for minor OS updates. In macOS 12.3, we added even more admin visibility into the logs and reporting with the OSUpdateStatus command. DeferralsRemaining indicates how many notifications are left to prompt the user to update. MaxDeferrals reveals the total number of times a user is allowed to defer the OS update notifications. NextScheduledInstall is the date that the OS will attempt to install the update next. And finally, PastNotifications is the exact dates and times when the notification was posted to the user. All of these updates to the OSUpdateStatus command will be useful for administrators to have further clarity into the compliance of their users. macOS Ventura and iOS and iPadOS 16 are introducing a new mechanism to ship critical security fixes to users more quickly. It does not modify the firmware, and the user can also remove the Rapid Security Response if necessary. We are introducing two restriction keys for this. Use allowRapidSecurity ResponseInstallation to disable this new security response mechanism, and use allowRapidSecurity ResponseRemoval to block the end user from being able to remove a Rapid Security Response. Now, let's cover a couple enrollment changes. Automated device enrollment provides a streamlined process for the device to be unboxed, activated, and enrolled in the organization's MDM solution. In an upcoming release, after erasing or restoring a Mac, an internet connection will be required to go through Setup Assistant for devices registered to your organization in Apple School Manager or Apple Business Manager. Once the Mac is set up for the first time and connected to a network, the Mac is acknowledged as owned by an organization. If later on, for example, MDM initiates an Erase All Content and Settings or the device is restored with Configurator, then the network -- and therefore, device enrollment -- cannot be bypassed in Setup Assistant. Stay tuned with the AppleSeed for IT release notes for timing. The profiles command line tool has been a staple for MDM deployments, migrations, and reporting in admins' tool kits for many years now, and we have an update to how it works as of macOS Ventura. Profiles tool will start enforcing rate limiting on macOS. This will only be for organization-owned enrollment types and to the show, renew, and validate commands. Each command has a maximum of 10 requests per day from the server, and if that number is exceeded, the results will return cached information. When you don't want to use one of the 10 requests, the show command has a new, optional flag to return cached information. Refer to the profiles manual page for more detailed information. In each release of macOS, we continue to improve protection capabilities for our users. Here are a few upcoming security changes to be aware of. In iOS 10.3, we introduced a change in the default TLS trust policy for certificate payloads to enhance overall protection for our users. In a future release, we'll be bringing it to macOS, meaning manually-installed certificate payloads will no longer be trusted for TLS purposes, unless the user grants them that trust using Keychain Access. Note, we will still continue full certificate trust if it's a certificate embedded in an MDM profile, but be sure to update any workflows if it involves interactive certificate installation. Next, "Allow accessories to connect" on macOS aims to protect our customers from close-access attacks. Supported on portable Macs with Apple silicon, the initial configuration is to ask the user to allow new Thunderbolt or USB accessories, even when unlocked. Approved accessories can connect to a locked Mac for up to three days. If you attach an unknown accessory to a locked Mac, you will be prompted to unlock the Mac. From an MDM perspective, we understand this may impact enterprise and education workflows such as bulk provisioning or test taking. To address this, we are leveraging the same restriction offered on iOS and iPadOS for macOS. The existing allowUSBRestrictedMode restriction will allow wired accessories to always connect without any limitation. It provides authorization to bypass the requirement of user consent. Also remember, this inherently makes your user's system less secure, so please only use this restriction if you have a legitimate business need to do so. For other restrictions and payload modifications, such as the new allowUniversalControl and UIConfigurationProfileInstallation, be sure to check out the documentation. Thanks for listening to the exciting changes coming to macOS Ventura. Now I'm going to hand it over to Graham to talk about iOS. Graham McLuhan: Thank you, Nadia! I'm really excited to be here today to tell you about a ton of great new device management features in iOS and iPadOS 16. We know managing network traffic on devices is an important way to improve the security of your data. There are three main ways that you can manage traffic on Apple devices: VPN, DNS Proxy, and Web Content Filter. For many years now, we've offered per-app VPN -- and in fact, for user-enrolled devices, this is the only type of VPN available to MDM. In iOS and iPadOS 16, we're expanding our per-app offerings to include DNS Proxy and Web Content Filter. These features will be available on all enrollment types but we think they'll be particularly useful for user enrollment since this is the first time organizations can secure their app traffic in this way for BYOD. Configuring these new features is a two-step process that will feel very similar to Per-App VPN. Let's take a quick look at how it's done. First you'll need to add a new key value pair to each payload. In the Web Content Filter payload, ContentFilterUUID. And for DNS Proxy, DNSProxyUUID. There are a few things to be aware of with these keys. First, the values for these keys can be any arbitrary string. And second, when this key is added to the payload, it can only be installed via MDM. Now, we need to configure the apps to use these new features. Using either the InstallApplication command or the Settings command, add the same UUID to the attributes of the app that will use the per-app feature. In this example, we included both keys, but you can just include one or the other. A few additional details I'd like to point out. First, app developers don't need to do anything new! All existing DNS Proxy and Web Content Filter apps will just work. Second, you can have multiple DNS Proxies but you cannot mix system-wide and per-app proxies. And finally, for Web Content Filters, you can have up to seven per-app filters and one system-wide filter. Next, I'd like to talk about managing eSIMs. eSIM has become the new standard for carriers around the world, and over the last few years, we've added a number of MDM features to make managing eSIM easier than ever. We wanted to take a moment to talk about how MDM vendors can bring all these features together to make for a better experience. When we talk to organizations using eSIM, some of the primary tasks they are doing are provisioning new devices, migrating devices between carriers, and supporting users with requirements such as multiple carriers or traveling and roaming. To accomplish these goals, they need to query data from enrolled devices and provide that data to carriers. And second, they need the ability to install an eSIM on a device. Let's begin by discussing the device query and carrier data requirements. The DeviceInformation query is the easiest way to collect data from a device. And in iOS 12, the ServiceSubscriptions key became the one stop shop for collecting all data relating to cellular on iPhone and iPad. A few points you may find useful when looking at these responses. Devices that return two items in the ServiceSubscriptions support two active cellular plans. If the response contains an EID, it's an eSIM. Newer devices like iPhone 13 and iPhone SE (3rd generation) support dual active carrier eSIM profiles so it's possible to have more than one eSIM returned in the ServiceSubscriptions response. Note that the EID is unique per device. Starting with iOS and iPadOS 16, otherDeviceInformation queries that return data which also appear in the ServiceSubscriptions response are deprecated and will no longer be returned in a future version of the operating system. Now that we know how to get data from the device, let's take a look at what we need to give to the carrier. In general, they require four pieces of data to get an eSIM set up for a device: IMEI, EID, serial number, and phone number. Giving your admins the ability to generate reports containing all this data will make it easier for them to get up and running with eSIM. Let's pull this all together and review how eSIMs get provisioned. First, the MDM server uses the ServiceSubscriptions query to collect the required data from the device. Then, the admin will send that data to the carrier. And finally, the carrier will provision eSIMs for the device on their eSIM server. We can now shift our focus to getting the eSIM installed on the device. The carrier will provide the customer with a server URL where devices can fetch an eSIM using the RefreshCellularPlans command. The MDM server will send the RefreshCellularPlans command to the device which will initiate a request to the carrier's eSIM server and check if an eSIM is available. If it is, it will automatically download and install it without requiring any user interaction. The MDM server can then use the ServiceSubscriptions query to confirm that the eSIM has successfully been installed when the query returns a nonempty phone number. Now let's talk about a few key points that you should keep in mind. eSIM installation is a one-time operation and future requests to install an eSIM on the same device require the carrier to provision a new eSIM. To prevent users from accidentally removing their eSIM, use the allowESIMModification restriction. Also note that the RefreshCellularPlans command can install an eSIM when the restriction is installed. And finally, MDM could also remove the eSIM when erasing a device. To avoid this, be sure to set the PreserveDataPlan key to True when sending an EraseDevice command. We hope this information provides a more complete picture on how to manage and deploy eSIM. Now let's talk about some updates to Shared iPad. Shared iPad is a great way for education and business customers to use iPad in a one-to-many environment while still giving users a personalized experience. This year we've made a few changes that will make Shared iPad even better. First, we added ManagedAppleIDDefaultDomains to the SharedDeviceConfiguration Settings command. With this command, you'll be able to save users time entering their Managed Apple ID using the QuickType keyboard. Once the user starts to enter their Managed Apple ID, a typing suggestion for your domain name will automatically appear for the user to tap. The Settings command will accept a list of any size but only three will be displayed to the user. Next, we've made some changes to the requirements for remote authentication. Currently, Shared iPad requires remote authentication approximately every seven days. In iPadOS 16, Shared iPad will only use local verification for existing users on the device. If admins want to enforce remote authentication, they can set the OnlineAuthenticationGracePeriod key in the SharedDeviceConfiguration Settings command. This key will be an integer value that represents the number of days between remote authentications; a value of zero will require all logins to be remotely authenticated. Both the ManagedAppleIDDefaultDomains and OnlineAuthentication GracePeriod values can be retrieved via the DeviceInformation query. Finally, I wanted to help provide some clarity around Shared iPad quotas. The SharedDeviceConfiguration command is the best way to manage quotas on Shared iPad. There are two relevant keys that you can use to set quotas: QuotaSize and ResidentUsers. Regardless of which key you choose to set, ultimately the operating system is computing a storage quota. Let's take a look at an example. This iPad has 35 gigabytes of free space for user data. If I send the SharedDevice ConfigurationSettings command asking the device to set ResidentUsers to three, it will compute each user's quota to 11.67 gigabytes. Alternatively, if I ask the device for a quota size of 10 gigabytes, each user will have a quota of 10 gigabytes. If we have three existing users on the device and a fourth user tries to log in, one of the existing user's data will be removed from the device to create enough space for the new user. In the QuotaSize example, even though there was five gigabytes of free space still available, that would not meet the requirement for the fourth user, and therefore, one user still needs to be removed. Let's look at one more scenario where we see how the number of users can be adjusted on the device without changing the quota. When we started the scenario, we had 35 gigabytes of free space. Well, it turns out that 25 gigabytes of the total space on the iPad was taken up by apps and books. After doing a little research, I realized that there's a few apps on this device that aren't being used anymore. Now that I've trimmed down my app library, my device has an additional 10 gigabytes of free space -- meaning when our fourth user comes to log in, it no longer requires another user to be removed. Also, remember that as of iOS 13.4, as long as there are no cached users on the device, quota sizes can be adjusted at any time. Keeping these points in mind should allow you to ensure the best possible experience for your Shared iPad deployments. Let's wrap up our iOS and iPadOS updates with some MDM protocol and behavior changes that you should be aware of. Apple devices come standard with built-in accessibility features that let people experience everything that their device has to offer. Traditionally, each user needed to enable accessibility settings themselves. But in iOS and iPadOS 16, we're adding the ability for MDM to manage many of the most popular accessibility settings. These features include Text Size, VoiceOver, Zoom, Touch Accommodations, Bold Text, Reduce Motion, Increase Contrast, and Reduce Transparency. With all these options available, we believe admins can make devices in schools, restaurants, and hospitals more accessible for all users. Be aware that these settings are not locked after being set and a user is free to modify them to match their own unique preferences. The MDM server can also query these settings with the DeviceInformation query. Next, starting in iOS and iPadOS 16, you'll now be able to install applications during the AwaitDeviceConfigured state during Automated Device Enrollment. A few things to keep in mind. Is it is very likely at this stage no user will be signed in to the App Store, so we recommend using device-based app licenses. Unsupervised devices in Setup will still return a NotNow until they reach the Home screen. With this feature, you can now ensure a device has everything a user needs to get started before exiting Setup Assistant. As we continue to improve the security of our devices, certain data types become inaccessible before first unlock. Because of this, the CertificateList query will start returning a NotNow before first unlock. Once the user unlocks the device, the query will respond as normal until the device is rebooted. MDM developers, please ensure that your servers are able to handle a NotNow response for this query. And finally, we have an exciting update for Apple TV. Starting in tvOS 16, when you erase an Apple TV -- either from Settings or via MDM -- the remote will now remained paired. Combined with Auto Advance, this ensures that your Apple TVs are always refreshed and ready to go. In addition to everything that we've discussed today, there are even more changes that you can check out in our documentation at developer.apple.com. Speaking of documentation, at a previous WWDC, we brought the MDM documentation to its new home. This change brought more accurate and up-to-date documentation but also gave you the ability to highlight changes in a particular OS release. The reception to this documentation has been amazing and today I'm excited to tell you that we are making the source code that backs this documentation publicly available under the MIT Open Source License in the new device management project on Apple's GitHub page. Let's take a look at what you'll find when you arrive. There will be two folders: one containing all of the MDM documentation and one containing the new declarative device management documentation, as well as a README file and our license information. Inside the MDM folder, you'll find folders for checkin, commands, and profiles. And for declarative management, declarations, protocol, and status. When you dive into these folders, you'll find YAML files for each command, profile, or declaration. I'd like to highlight a few items to get you familiar with these files. First is the payload key. This key shows the request type for the MDM command. In this example, that's ProfileList, which returns a list of all profiles installed on the device. Next, supportedOS key gives you platform-specific information like operating system and version support, as well as things like if it requires supervision or if it works with user enrollment. Here we find the ProfileList key was introduced in iOS 4. The payloadkeys give you information about additional features the query offers. Each sub-key may include an additional supportedOS key that will override the values from the payload above. The ProfileList query was introduced in iOS 4, but the ManagedOnly feature wasn't added until iOS 13. The rest of the supportedOS information remains the same, meaning supervision is not required and the query works for user enrollment. In the case of the ProfileList query, it returns a response to the MDM server. The response keys detail this information. In our example, we can expect an array of dictionaries that describe each profile installed. Inside that dictionary, you will see key value pairs including things like PayloadUUID and PayloadIdentifier. This is just a quick example and you will find comprehensive details about the schema and the structure of the repository in the README. Now let's talk about some details. You will find data published back to the initial release of iOS 15 and macOS Monterey. From there, we publish new branches for each release and seed as needed, meaning that the iOS 16 and macOS Ventura documentation is up for you to check out right now. We think that there are a lot of exciting use cases for this new data and we can't wait to see what new tools or integrations you come up with! As you start to work with this data, please use Feedback Assistant to let us know how it's going. We've covered a ton of information today, so let's take a moment to recap. Apple Configurator for iPhone now adds iPhone and iPad to your organization, allowing you to more easily manage and deploy devices. For identity, Google Workspace integration, Enrollment SSO, and Platform SSO bring a more cohesive authentication experience. From there, Nadia told us about how macOS Ventura gives you more information to help you manage software updates for your fleet. Automated Device Enrollment gets better by requiring a network connection during Setup Assistant after erasing or restoring a Mac. And we wrapped up with some important security changes that will impact your deployments. In iOS and iPadOS 16, you can now manage DNS Proxy and Web Content Filter on a per-app basis. We explored the tools used to manage eSIM on iPhone and iPad. We discussed enhancements to Shared iPad, and finally, changes to the MDM protocol including the ability to install apps during Setup Assistant. Last, we hope that our new machine-readable documentation enables you to build new and exciting tools and integrations. Thank you for joining us and I hope you have a great WWDC! ♪