Apple’s annual developer conference took place last week, and it was a doozy. The enterprise-focused announcements were tremendous, especially when compared with previous years.

I’m going to summarize here the most important announcements for enterprise. This focuses on iOS (and iPadOS), and more or less ignores macOS and tvOS. For a more consumer-focused summary of what’s new, I recommend this summary produced by 9to5mac.

Much of what’s in this document comes from two videos, which are available to the public:

• What’s new in Managing Apple Devices – https://developer.apple.com/videos/play/wwdc2019/303/
• App Distribution – From Ad-hoc to Enterprise – https://developer.apple.com/videos/play/wwdc2019/304

Oh, and iOS 13 is coming out “this Fall” — that usually means mid-to-late September. It will require iPhone 6S or newer, iPad Air 2 or newer, or the iPod touch 7 that was released two weeks ago.

Big Ideas

• iPadOS
• User Enrollment
• Managed Apple IDs
• Custom Apps
• Single Sign-On Extension
• New Documentation Repository
• Miscellany

Introducing iPadOS

The iPad was formerly part of the iOS family, but is now going to have its own brand as iPadOS.

iPadOS 13 delivers several desktop-like features: multiple windows, mouse support, and a “desktop browsing experience.” That last bit is accomplished by having Safari for iPad report a user-agent of “Mac”. Note: Apple noted that this change may break MDM enrollment methods that rely on user-agent to present the enrollment process.

Under the hood, iPadOS is still iOS, of course. At the moment, Apple’s developer documentation makes no mention of iPadOS at all, as it’s still called iOS. That may change in the future, but for now, I think it’s OK to think of iPadOS and iOS as two flavors of the same ice cream.

User Enrollment vs. Device Enrollment vs. Automated Device Enrollment

“User Enrollment” is Apple’s new method to support BYOD users. It’s a really huge leap for iOS, and it’s bound to make certain industry observers a bit happier with Apple.

Let’s review the different enrollment methods Apple devices support.

• Device Enrollment is a new name for the way we’ve been enrolling devices since the beginning of the iPhone era.
• Automated Device Enrollment — what we usually call “DEP” — is when devices must be tagged by a reseller, then we use Apple Business Manager to associate these devices semi-permanently to our MDM servers.
• User Enrollment is not a rebrand; it’s an entirely new MDM enrollment method introduced with iOS 13.

	Device Enrollment*	Automated Device Enrollment	User Enrollment
Introduced	iOS 3	iOS 7.1	iOS 13
Device Ownership	Any, non-DEP	Institution, DEP-enrolled	User
Enrollment Method	User self-installs profile from MDM	Integrated into Setup Process	User self-installs profile from MDM
Supervised	No*	Yes	No
Enrollment requires Managed Apple ID	No	No	Yes
User may remove management	Yes	No	Yes

*Apple Configurator may be used to supervise non-DEP devices with “Device Enrollment,” but this is relatively uncommon in 2019.

“Device Enrollment” and “Automated Device Enrollment” are confusingly similar names, but the names make some sense when you start comparing them against the new “User Enrollment.”

	Device Enrollment*	Automated Device Enrollment	User Enrollment
MDM can read serial number, IMEI, and other device IDs	Yes	Yes	No
MDM can erase device	Yes	Yes	No
User data is commingled with managed data	Yes	Yes	No
MDM can require a passcode	Yes	Yes	Yes
MDM can clear passcode	Yes	Yes	No
MDM can require a really complex passcode	Yes	Yes	No
Per-App VPN	Any domain	Any domain	Corporate only
MDM can list apps	All apps	All apps	Managed apps only
MDM can take over management of a user-installed app	Yes	Yes	No
MDM can collect device logs	Yes	Yes	No

User Enrollment is designed to make MDM easy for employees to install and easy for employees to trust. User Enrollment literally creates a partition between work and life. The enrollment process creates a separate file system on the device, with new encryption keys. Work accounts, contacts, keychain, files, and apps are stored on this “work” file system, apart from the user’s personal data. If the user removes the MDM management profile, iOS destroys the work partition and all the work data on it.

This is going to be a really big deal. It’s a lot of work for your MDM vendors too. It will be interesting to see how this is implemented “Zero Day,” which should be around September.

Here come Managed Apple IDs

The key to making user enrollment work is a new identifier, called a Managed Apple ID. Managed Apple IDs have been used for a few years with Apple School Manager, and now they are coming big time to Apple Business Manager.

A Managed Apple ID looks like an email address, but it is almost NEVER an email address. It’s a user identifier used within Apple. And like other Apple IDs, it must be unique within Apple’s universe. For example, Apple recommends Managed Apple IDs for schools that look like this: scottmiller1@appleid.myschool.edu. Look at that weird “@appleid.” in there. That’s not a subdomain, it’s just some text inserted within the string to make sure this identifier is unique.

This system already exists within Apple Business Manager today, because that’s how you log into Apple Business Manager.

Managed Apple IDs are critical to the data separation model of User Enrollment. I’ll have two partitions on my iOS device; the “personal” one may be using the “normal” Apple ID me@groundctl.com or something more personal, the “work” partition will use the Managed Apple ID me@appleid.groundctl.com. Each of these Apple IDs will have its own set of associated apps and its own iCloud file storage.

As the ABM admin, you do not need to create these yourself. This fall, Apple will allow synchronization between Apple Business Manager and Azure Active Directory, to automatically create Managed Apple IDs for all your directory users on the fly. So you are going to have a LOT of Managed Apple IDs in your future. And federated authentication means your users will be able to sign in using their Active Directory password.

In-House and Custom Apps

We all know about App Store apps, and most of us know about In-House apps. Some of us are also familiar with B2B apps. B2B Apps were initially developed as a way for 3rd party apps developers to privately sell their apps to businesses. Over the years, Apple expanded this system to allow free apps as well as paid, and to allow businesses to use their own B2B apps.

This Fall, Apple is renaming B2B Apps to “Custom Apps” and inviting schools to use this system too. What’s more, Apple is strongly encouraging migration from In-House apps to Custom Apps. Custom Apps don’t expire every year, you don’t need a special Apple Enterprise Developer Program, you can use TestFlight, and you can use Auto Update features and content caching infrastructure. Like App Store apps, Custom Apps are reviewed by Apple before publication.

In fact, it appears that Apple has removed references to the Apple Enterprise Developer Program from their website, although the pages can be found if you look hard.

Apple posted an entire video describing the differences, so if you leverage the Developer Program, I recommend you view this video.

Single Sign-On Extension

This was my favorite new feature, and I plan to say much more about it over the next months.

First, a short digression. You probably have heard about Sign In with Apple, the new privacy-focused iOS 13 sign-on service that will soon be everywhere on iOS and on the web. It looks like this is going to be a winner for Apple and for users and for users. Apple made sure that this new feature would be easy on developers. Only a few lines of code are required to  add Sign In With Apple to apps.

But enterprises aren’t going to use Sign In with Apple, because enterprises actually do need a federated identity to function. Here is where Apple did something else really smart with iOS 13. The authentication framework used for Sign In with Apple — the one that’s easy for developers to implement — can also be extended to work with ANY single sign-on system. With almost the same few lines of code, app developers can add true enterprise Single Sign On to their apps.

App developers don’t need to learn about SAML or OAuth or Kerberos, even. That functionality comes from third party SSO developers who create app extensions. Expect these to come in the next few months from VMware, Ping, Okta, Duo, etc.

And neither the app developer nor the SSO developer needs to know about YOUR enterprise infrastructure. The SSO configuration comes from yet a third place, as a new config profile pushed by your MDM.

All this comes together to bring safe and scalable SSO to enterprise apps. Apple’s built some really interesting passwordless systems, with separate options for consumer and enterprise. With these new tools perhaps app developers will finally get on board to bring SSO to mobile devices.  

New Documentation Repository

It’s sometimes been hard to track down the latest documentation and standards for Apple Device Management. Now the documentation has a new home, and it’s pretty darn good. It lives within the Apple Developer site, among the rest of the Apple SDK documentation:

https://developer.apple.com/documentation/devicemanagement?changes=latest_minor

The best part of this system is a built-in “diff” for highlighting the latest changes. (OK, it’s a little weird to refer to iOS versions by their Xcode versions, but we can’t have everything right?)

Miscellany

DEP Changes:

• When enrolling a device with DEP, the user sees a “Remote Management” page that usually prompts for username and password. In pretty big news, starting with iOS 13 you can customize this enrollment page with your own logo and colors and text. I think this also allows for “modern authentication” during DEP-based MDM enrollment. That’s Apple’s term for anything that’s not just user and password. Apple did not show demos of this though.
• DEP devices are now ALWAYS supervised and enrollment is now ALWAYS mandatory. This is a change that Apple warned us about previously, so it shouldn’t be a surprise.
• The allow_paring DEP key is deprecated; use the config profile restriction instead. Personally I think this is great. This key has always confused my customers.
• There are new keys to skip the Welcome screen and Dark Mode screen. There are also keys to skip language screens, but it isn’t clear to me what these are for.
• The legacy DEP portal, deploy.apple.com, will be retired at the end of this year.

Content Caching: Apple allows any Mac to be a caching service for App Store and iCloud content. This relatively unknown feature can be a huge benefit to most organizations who have even a small number of Apple devices. In iOS 13, the caching server can be indicated as mandatory, so devices never use the WAN for downloads.

AppleSeed for IT: AppleSeed for IT is the somewhat-secret program to get prerelease software, test plans and IT-focused RELEASE NOTES for new iOS and macOS software. Apple is now opening AppleSeed for IT to everyone with a managed Apple ID. Of course, this means just about everyone with an iPhone and a job.

Config Profile Changes: There are many changes to config profile keys in iOS 13. But instead of me listing them, you can see the changes directly yourself.

One item to call out: Finally, supervision is required for legacy restrictions (app installation, app removal, block FaceTime, block Safari, iTunes, Explicit content, iCloud documents and data, Multiplayer gaming, Add Game Center friends). BUT there’s a transition period, and an iOS upgrade won’t break anyone. New devices, or backup and restore of an old device, will enforce the new standards.

Conclusion

To summarize, there’s a lot to digest here, and I didn’t even try to cover macOS 10.15. In 15+ years of WWDCs, I’ve never seen Apple introduce this much for the enterprise. I’m excited! Aren’t you?