了解 ManagedApp 框架

Hi, I’m Bob Whiteman, Senior iOS Device Management Engineer. It’s my pleasure to share with you, a new framework to make apps in managed deployments easier to use and more secure.

Organizations around the world use Apple devices in offices, stores, and schools. People use them to learn, teach, work, and create.

The apps running on these devices make all this possible.

Organization administrators use device management services to make sure their people have the apps they need to succeed.

People rapidly become experts in using their organization’s apps.

But they generally set up those apps just once, so that’s a daunting new experience.

They may need to enter a server, username, password, and second factor authentication code.

Then they must go into the app’s settings and customize them to match their organization’s requirements. There’s several steps, and if any problems or mistakes occur, well, it rarely ends well. They may give up on using the app from frustration.

If they contact support, that wastes time and increases support costs for the organization. That organization may even decide to drop support for the app. As an app developer, you can try to improve this experience, but that requires a lot of effort that isn’t part of your app’s core functionality.

Consider all that you would need to build to make this a seamless experience.

You implement federation with the organization’s identity provider. You build and operate a configuration website so the administrator can specify configuration that it delivers to apps running on their devices.

You integrate with the organization’s certificate authority and authentication infrastructure so your app can communicate with the organization’s servers.

You publish custom variants of your app to provide the branding and custom features that some organizations require.

What if you didn't need to do any of that? Let’s eliminate this complex setup experience.

Now the app can be pre-configured for that organization, for that device, and for that person. There’s no need for a setup process at all. Right from the first launch, the app is ready to use. First impressions of the app are much better, so it gets more use.

Administrators are more willing to deploy it because their people like it and support costs are minimized.

So how can we make this possible? I’m pleased to present ManagedApp framework.

ManagedApp framework can automatically configure managed apps and their extensions.

Apps can use it to authenticate devices and streamline user authentication.

And using the framework helps apps meet high security requirements for data security and access control.

To accomplish this, ManagedApp framework allows the administrator to provide custom app configuration and to provision passwords, certificates, and identities.

It can work with other device management technologies like extensible single sign-on, managed device attestation, and enrollment single sign-on.

ManagedApp framework can deliver four types of data. App-specific configuration is arbitrary data that a particular app supports. This includes the settings, options, and small assets that are meaningful for that app.

The other three types are secrets: passwords, certificates, and identities.

Identities can be PKCS #12 files, SCEP identities, or ACME identities.

And ACME identities support hardware-bound keys and attestation.

All these data types are stored securely and only provided to the managed apps or extensions that the administrator specifies.

ManagedApp framework is available in iOS 18.4, iPadOS 18.4, and visionOS 2.4.

It requires the MDM server to manage the app using declarative device management. It works from the moment it installs the app, or when it takes over management of an already installed app. It works with all MDM enrollment types. It supports most app extension types, though it doesn’t work with extensions that run in a very restricted environment. For instance, a keyboard extension is unable to use ManagedApp framework unless it is granted full access. In this session, I’ll describe the development and deployment workflow, explore some of the scenarios where this framework is useful, dive into some code, and then offer some best practices.

First, how does this work? We start with a device that is managed.

The administrator uses an MDM server to send management commands and queries to the device using the MDM protocol.

The administrator manages the app, and this usually installs the app.

As part of managing the app, the administrator specifies the configuration and secrets that the device should make available to that app and its extensions.

When the app launches, it asks ManagedApp framework for its configuration and secrets, and the framework hands a copy to the app.

The app immediately applies the configuration and uses the secrets as appropriate.

Any time after that, the administrator can update the configuration or secrets. If the app was running at the time, the framework notifies the app, which immediately applies the updates.

But before any of that happens, you as the app developer must write the application.

You write a decoder for the configuration and write the code to apply the configuration and use the secrets.

Then you write and publish a specification that tells administrators how to configure your application.

This specification details what keys and values the app supports in its configuration, what those control, what secrets the app expects, and how they’ll be used.

This is what makes me so excited about this framework. The configuration isn’t specified by Apple or a protocol or an MDM server.

That would make it generic across all apps and not very useful.

Instead, you as the app developer specify how your app can be configured. This opens up a broad horizon of new opportunities. You know your app better than anyone. You can provide the most powerful, useful, and innovative ways to configure your app, to supercharge it for organizations.

ManagedApp framework isn’t a solution. It’s a platform where you can easily build your solution.

With that in mind, let’s look at some of the scenarios where we think ManagedApp framework is especially useful.

And there’s so many scenarios where we can put it to use. Securely provide credentials to a third-party browser. Customize an in-house app for the person’s role.

Configure a Safari extension.

Secure communications between device management service and its management app.

I'll go into more detail on three of these scenarios, and I'll start with licensing.

Often, an app developer needs a way for their app server to attribute requests to the correct customer.

A common solution for this is a license token.

When the organization licenses the use of the server, the developer issues that organization a unique license token.

The administrator uses MDM to distribute that license token to all instances of the app used by their organization. Then when the app makes a request to the server, it includes the license token in the request.

And now the server knows to attribute that request to the correct organization.

This introduces a security concern. The organization must protect this token as it is stored and passed around.

If someone outside the organization obtains the license token, they could use the server and the organization pays for it. Developers and administrators could use the ManagedApp configuration feature to distribute this token to managed devices. However, ManagedApp framework is designed to protect the configuration from extraction or manipulation. More importantly, ManagedApp framework provides a better option than a license token, and that’s a license key. ManagedApp framework can provision a cryptographic identity for licensing purposes, which is more secure than a token. The administrator provisions a cryptographic identity on the device, with its certificate issued by the organization or the app developer.

The private key is generated on the device and never moves from there, which is more secure than transmitting tokens throughout the architecture. The old ManagedApp configuration feature doesn’t support license keys. ManagedApp framework is more secure, supports identities, and supports app extensions. If your app uses ManagedApp configuration, you should move to ManagedApp framework.

Next, let's investigate VPN extensions.

The ManagedApp framework is especially useful for VPN extensions.

A VPN server requires strong authentication, ensuring the device is part of the organization, and authorized to connect to the network.

The architecture is very similar to the previous scenario, but the identity is provided to a VPN extension rather than an app.

ManagedApp framework can provide the strongest kind of authentication material that Apple supports. Using Managed Device Attestation, the administrator provisions an attested hardware-bound key for that specific device.

ManagedApp framework makes it available directly to the VPN extension and only that extension. It uses that identity to authenticate to the VPN server. This thwarts many of the potential threats that worry VPN administrators. Our last scenario is an identity provider.

An identity provider uses extensible single sign-on to facilitate signing in to federated accounts in apps and websites. It can also work with federated Apple accounts for account-based enrollment types. Each identity provider designs its own authentication protocol that usually uses manually entered credentials. Now with ManagedApp framework, an identity provider can also incorporate many other kinds of authentication material. This may be a hardware-bound identity for authenticating the device to make sure the sign-in is occurring on an authorized device. If the account is new, this could be an initial temporary password for first-time authentication.

It could be a token or identity that binds the sign-in to the organization. Or really, this can be whatever kind of secret the identity provider needs. ManagedApp framework supports them all. If the identity provider supports enrollment single sign-on, configuration and secrets are available during enrollment as well. I hope you have a sense of the many ways ManagedApp framework can power managed apps. It’s time to see how to implement it in your app.

The API of the ManagedApp framework is focused on delivering the configuration and secrets to the app as simply and securely as possible. The framework has four independent classes, one for each data type.

These first three provide the exact built-in data type that your app needs: a string containing the password, a SecCertificate, or a SecIdentity. The fourth one is a little different. ManagedApp configuration provider provides app-specific configuration. There's no built-in type for this. This is whatever data type the app needs. As the app developer, you define the structure of this data.

I’ll give one example of using configuration, then another using an identity. Finally, I’ll discuss publishing your app’s specification.

We'll start with the Landmarks app. We’ll make it configurable so it’s easy to use in a classroom.

The first step is to decide what the administrator can configure. This is the collections view in the Landmarks app. Let’s make it possible for the administrator to configure a new collection. This allows a teacher to collect the landmarks that students will use in an upcoming geography class.

In code, we start by writing a struct that represents everything that the administrator configured for an instance of the app. It has a read-only property for the managed collection. The properties type is an optional. This is because the app may not be managed, or the administrator may not have applied a configuration, or the administrator did apply a configuration, but it doesn’t include a managed collection. Most of your configuration’s properties will be optional or provide a default value.

When the ManagedApp framework receives a configuration from the MDM server, it needs to decode the over-the-wire format, so we make this struct conform to Decodable.

We specify a CodingKey for the collection.

Once we make the landmark collection class conform to Decodable, we could stop here and let the compiler synthesize an initializer for our configuration class.

However, most apps will need custom validation rules. So we’ll write an explicit initializer here.

And that's it for the configuration class. So how does your app receive this configuration? The API uses Swift concurrency, so we start by creating a Task.

Within that Task, we use the ManagedAppConfigurationProvider class in ManagedApp framework. The configurations method delivers configurations using an async sequence. The parameter you pass to the configurations method is the type of your configuration struct.

To start receiving configurations, you use a for await loop.

The async sequence yields an optional of your configuration type. So in this code, config’s type is an optional LandmarksManagedConfig.

Let’s see how these pieces work together by walking through the events that happen on the device.

First, the administrator creates an encoded configuration and sends it to the device, which stores it. When your app begins iterating the async sequence using a for await loop, the device passes a copy of the encoded configuration to your decoder method. That instantiates your configuration struct containing the properties your app needs. Finally, the framework yields that instance to the async sequence. Any time after that, if the administrator sends an updated configuration, the process repeats automatically. If the app isn’t managed, or if the administrator didn’t specify a configuration, or if the decoding failed, the sequence yields nil instead.

In short, your app doesn’t need to worry about any of these conditions. Whenever this sequence yields a value or nil, that is your app’s current managed configuration.

So all we need to do in the body of the for await loop is copy the value from the configuration into a managed collection property on the model data. Because the configuration may update at any time, the for await loop has no termination condition. Don’t worry, looping forever is not wasting resources. The body of a for await loop only executes when it yields a value.

Where should we start this task? It can potentially live anywhere in your application.

Typically, it’s in a method early on in the launch path of your app. For the Landmarks app, we’ll incorporate it into Model Data’s Load Collections method. Collections are loaded very shortly after launching the app. We add the Managed Collection to the view, and we’re done. This is what it looks like. The Collections view now has a Managed Collection section showing the title and landmarks that the administrator configured. And here's a bonus. The code that we already wrote is all we need to support updates. When the administrator changes the configuration, the view automatically updates to show the new landmarks.

Let’s move on to an example that uses identities. Suppose we want to allow the administrator to add many more landmarks.

We’ll have the app download the landmarks from an asset server. We’ll let the administrator specify the URL where the assets are hosted. This gives the administrator the flexibility to host the assets wherever they need. We can easily add an asset URL to the configuration we developed earlier. And we’ll allow the administrator to provision an identity that the app uses to authenticate itself with mutual TLS when connecting to the asset server. All three of the secret providers in the framework use this same pattern.

Each secret has a string identifier. There’s a method to look up the secret by its identifier. You choose the identifiers that your app supports. Most of the time, you can hard code the identifiers. If you want your app to be notified when the available secrets change, you can use an AsyncSequence. It yields an array of all the identifiers for secrets of that type that are currently provisioned. The AsyncSequence is also useful if your app supports a dynamic list of identifiers. When the Landmarks app downloads assets, it doesn’t need that extra complexity, so we'll just use a hard-coded identifier. The app makes a request using URL session. When you implement mutual TLS, most of the code involved is boilerplate. We’re only concerned with obtaining the identity, which is these lines in the middle. We used the ManagedApp identities provider and a hard-coded identifier to look up a sec identity.

If the administrator didn’t provide an identity, we cancel the challenge. And that's it. With just those few lines of code, our app got the identity it needed. We didn’t need to deal with properties of the key, a certificate signing request, or anything else involved in provisioning the identity. We just used the one that the administrator provisioned for us.

Our final task is to publish a specification that explains how an administrator can configure the Landmarks app.

We document the format of the configuration. A simple way to do this is to provide an example. Here is an example of the encoded format for the configuration. The over-the-wire format for configurations is a property list. The specification needs to document the details, such as the list of valid values for landmark IDs. If our decoder has custom validation, we also document the error codes it may generate so administrators can diagnose issues with the configurations they create. We document any secrets identifiers our app supports. For the Landmarks app, this is the hard-coded identifier we used earlier. We document that it is used to download assets, and this is a good place to document the expected format of the Landmark assets. We publish this information, typically in the form of a document or website that administrators can access. And we're done.

There’s some best practices to keep in mind as you develop your app.

Configuration is not intended for large movements of data. Think kilobytes, not megabytes. Instead, have the app download the data from a server and have the URL specified in the configuration, as we did earlier with the Landmarks app. Don’t keep secrets around any longer than necessary. Just look up the secret each time you need it. Not only is this a best practice for secure programming, it also ensures your app always uses the latest secret in case the administrator updated it. When designing your configuration, don’t just have a single switch for whether your app is managed, which changes multiple behaviors in your app. Instead, provide individual configuration options that each control one part of your app’s behavior. This offers administrators the most flexibility.

Consider forward and backward compatibility. When you release new versions of your app, you may add, change, or remove options in the configuration. It would be difficult for an administrator to provide different configurations to different versions of your app. To avoid this, ensure your decoder can handle older configurations and ignores new keys that it doesn’t recognize. This allows the administrator to provide one configuration to their entire fleet of devices. If your app currently uses the old managed app configuration feature, it’s time to transition away from that. During that transition, your app can support both features, with the ManagedApp framework configuration taking precedence. This allows an administrator to transition to ManagedApp framework without disruption. When you submit your app for review, the reviewer tries out the features of your app. If some of those features are only accessible when the app is managed and configuration or secrets are applied, that can make it impossible for the reviewer to review your app. There's a few ways to address this.

Consider adding a demo mode to your app, which shows off its functionality as if it had a configuration. This can also be useful for demoing your app to customers. Another option is to record a video of your app showing these features. You can submit that to App Store Connect under Notes for App Review. And be prepared to provide instructions and credentials that allow the reviewer to enroll their device with a device management service that configures the app appropriately.

Most of all, be creative. Think about how ManagedApp framework can make everyone thrilled by how easy it is to use your app. Talk to customers about what they want. Adopt the framework and migrate off of ManagedApp configuration. Please send us any feedback about the framework. And for more information about device management, check out the session, What’s new in managing Apple devices.

Thank you and have a great WWDC.