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.

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.

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 #

The uninstallation path depends on the package format:

• Apps installed via a .pkg can be uninstalled again through Relution. This requires a stored detection rule that uniquely identifies the app. The uninstallation is triggered via an Uninstall app action on the affected devices or groups.
• Apps that were copied as an application to /Applications via a .dmg cannot be removed directly through Relution. Here, the uninstallation is done exclusively via a script.

For .dmg apps as well as for cases without a detection rule, the uninstallation is implemented via a script that quits the app and removes the associated directories. Such a script is distributed specifically to the affected devices or groups via an action.