Install native macOS apps

Relution allows native macOS applications to be uploaded centrally to the App Store and distributed to managed Macs. The supported file formats are .pkg (installer package) and .dmg (disk image). Reliable, unattended distribution depends on the interplay of a suitable package format, a correct detection rule, and valid signing. The following sections describe these components in detail.

PKG and DMG compared #

The choice of package format determines how an app is installed and whether the process can be automated.

A .pkg is the more robust format for automated distribution, because the installation routine is contained within the package itself and can run silently in the background. Scripts inside the package can perform additional steps, such as creating configuration files.

A .dmg is a disk image. It is only suitable for distribution if it contains a single application (.app) that is copied to /Applications. Images with an interactive installation assistant or multiple items cannot be installed unattended.

One essential difference concerns the distribution channel: .pkg apps are installed directly via the MDM protocol, whereas .dmg apps are deployed via the Relution Companion. For the distribution of DMG apps, the Companion must therefore be available on the Mac.

Note: If an app is available both as a .pkg and as a .dmg, the .pkg is preferable for centralized distribution.

Add a native app in Relution #

Uploading is done via the app inventory, just like for other native apps.

1. In the menu under Apps → App Store, the app type Native app is selected via Add.
2. The relevant .pkg or .dmg file is selected and uploaded.
3. The app detail page is opened via Add details. The version name and – if required – the detection rule are entered there.
4. After specifying the desired Release status, the app is created via Save.

Version management and release status #

Native macOS apps also support release management: different versions of an app can be made available in parallel to different groups of people. For example, one version can be in productive use while a new version is tested by a selected group, without affecting the remaining users.

Each version goes through one of the following states:

• Productive: the version that is regularly distributed and installed via the Relution Agent.
• Development or Testing: states used for versions that are tested before going productive.
• Archive: state of a previous version that has been superseded by a newer productive version.

Testing a new version in parallel #

To test a new version alongside the existing productive version, it is uploaded via the New Version button and initially set to the Development or Testing state. Optionally, a Release Date can be set, at which the version automatically switches to the Productive state. Both versions remain visible in the app properties in the meantime; users with the appropriate permission can already view, install, and test the new version on endpoints.

Manual go-live #

As an alternative to an automatic switch via the release date, a version can be moved to the Productive state manually on the app detail page via the Productive button. An already productive version is then automatically moved to the Archive state.

Detection rule via the bundle identifier #

The detection rule tells Relution how to recognize the installed state of an app. For native macOS apps this is done via the Bundle Identifier (e.g. com.vendor.appname). This unique value is used on the device to check whether the app is already present and whether an installation is considered successful.

The most reliable way to determine the correct bundle identifier is via a Mac that is already managed:

1. The app is installed manually once on a Mac that is managed in Relution.
2. In the Relution portal, the device is opened under Devices → Overview.
3. On the installed apps tab, the app is located. The Bundle Identifier shown there is read off.
4. This value is entered as the detection rule on the app detail page.

Alternatively, the bundle identifier can be read directly on the Mac via the Terminal:

osascript -e 'id of app "App-Name"'

If the path of the application is known, the value can also be read from the package metadata:

mdls -name kMDItemCFBundleIdentifier -raw /Applications/App-Name.app

If the detection rule is to be determined before an installation, the contents of a .pkg can be inspected with a third-party tool such as Suspicious Package. Such a tool shows the bundle identifier in addition to the install paths and contained scripts, without the package having to be run.

Note: Third-party tools serve analysis purposes only. The authoritative bundle identifier remains the value reported in the Relution inventory after an installation.

Alternatives without a working detection #

For some native apps, Relution cannot reliably check the installed state – for example because no unique bundle identifier is available or the package places the app in an atypical location. In these cases, two options are available that work without a reliable detection rule:

• Provisioning via the Relution App Store: The app is made available to users in the Relution Agent and installed there manually. Because the installation is actively triggered, no automatic state check is required. Optionally, the app can be bound to a user or user group via the assignment as an app to be installed automatically (auto-deploy).
• Distribution via an action: An Install app action on selected devices or groups triggers the installation specifically. The install command is transmitted to the device and executed there, independent of a detection rule.

Signing and notarization #

macOS uses Gatekeeper to check whether software comes from a trusted source. Packages that are neither signed nor notarized by Apple may be blocked or require user interaction – which prevents unattended distribution.

• Signing: The package is signed with a valid Developer ID. This makes the origin traceable and rules out tampering.
• Notarization: The package has additionally been checked by Apple (notarized). Only then is it accepted on current macOS versions without a warning.

Whether a package is correctly signed and notarized can be verified on the Mac in the Terminal:

spctl --assess --type install -vv /path/to/App.pkg
pkgutil --check-signature /path/to/App.pkg

Note: If an installation fails silently only for individual packages, missing signing or notarization is one of the most common causes.

Troubleshooting via logs and device logging #

If an installation remains unsuccessful, the causes can be narrowed down via logging.

Device logging in Relution #

Device logging is enabled at the global level in the inventory via the devices and captures the communication between the server and the devices. Once enabled, commands such as the app installation are logged together with the device’s response and can be viewed in the portal. This makes it visible whether an install command has reached the device and with which status it was acknowledged.

Installation logs on the Mac #

In addition, the Mac’s system logs provide information about the installation process. The progress of a PKG installation is logged locally and can be evaluated in the Terminal:

tail -n 100 /var/log/install.log

For live observation during an installation, the live stream of the system log is suitable:

log stream --predicate 'process == "installer"' --info

These outputs reveal whether the package was unpacked, a script was executed, or the process was aborted by Gatekeeper.

Uninstallation #

Native macOS apps that were installed through Relution can also be uninstalled through Relution – both .pkg and .dmg apps. This requires a bundle identifier (detection rule) that uniquely addresses the app on the device. Without a valid bundle identifier, no uninstallation is triggered. As with installation, the removal runs over different channels depending on the format – .pkg via MDM, .dmg via the Companion – but the procedure in the portal is identical.

There are two ways to uninstall:

• Specifically via an action: The Remove app action on selected devices or groups uninstalls the app. In the device’s command history, the operation appears as <bundle identifier> uninstall.
• Automatically when the assignment no longer applies: When a previously auto-deployed app is removed from the App compliance, Relution can uninstall it automatically. However, this only takes effect if the option to remove automatically deployed apps is enabled in the app compliance configuration – otherwise the app remains installed on the device.

Apps without a bundle identifier, as well as apps installed manually – outside of Relution – cannot be removed through Relution. For .dmg apps, an available Relution Companion is additionally required; if it is disabled or cannot be used on the device, uninstallation through Relution is not possible. In these cases, the removal is implemented via a script that quits the app and removes the associated directories, distributed specifically to the affected devices or groups via an action.