Configuring native apps

Native macOS apps – that is, applications uploaded manually as .pkg or .dmg – can be pre-configured in Relution. However, the intended path differs from the one for apps from the App Store. The decisive factor is the source of the app, as it determines which method is available.

The app source determines the configuration method #

The Managed App → policy configuration requires the app to have been installed through a channel managed by Apple. macOS only applies it to apps installed from the App Store or via Apps and Books (VPP in the portal). For these apps, the operating system handles the assignment of the configuration to the app based on the bundle ID.

For native apps, this mechanism does not take effect, because they were not installed through the managed App Store channel. Although they can be selected in the Managed App configuration in the portal, the configuration has no effect on them. The configuration of a native app must therefore be transmitted as a payload via the Apple Configurator 2 Configuration → policy configuration.

Configuring native apps via Apple Configurator 2 #

Which keys and values are supported in the payload (property list) is specified by the respective app vendor. The setup is done in a few steps:

1. The native app is first provisioned as usual so that it is installed on the target devices (see Install native macOS apps →).
2. The desired app configuration is assembled as a .mobileconfig file (see the recommendation below).
3. An Apple Configurator 2 configuration is added to the policy, a Name is entered, and the complete .mobileconfig file is uploaded via Select .mobileconfig file. Its content is then shown in the Payload content field and can be adjusted there if necessary.
4. The policy is published and assigned to the affected device groups.

A .mobileconfig file may contain only one configuration type (payload type) in PayloadContent; additional certificate payloads are allowed. If the file contains several types, for example settings for several apps, the configuration cannot be saved. A separate Apple Configurator 2 configuration is therefore created for each app. If the file contains several payloads of the same type, only the first one is transmitted. Further requirements for the file are described in the Apple Configurator 2 Configuration → article.

Recommendation: create the payload with the iMazing Profile Editor #

Writing a payload manually is error-prone. For convenient creation, the third-party tool iMazing Profile Editor is recommended. It allows the configuration to be assembled through a graphical interface, without writing the underlying property list by hand.

The procedure is as follows:

1. In the iMazing Profile Editor, the desired settings for the app are set via the interface.
2. The result is exported unsigned as a .mobileconfig. Relution reads the file as XML; signed profiles cannot be saved.
3. The complete .mobileconfig file is uploaded to the Apple Configurator 2 configuration in Relution.

The payload can also use the placeholders provided by Relution (e.g. ${user.email}) to fill in the configuration on a per-user basis. The available placeholders are shown below the configuration form and are replaced when the configuration is transmitted to the devices, see Advanced placeholders →.