Native macOS-Apps installieren

Mit Relution lassen sich native macOS-Anwendungen zentral in den App Store hochladen und auf verwaltete Macs verteilen. Als Dateiformate werden .pkg (Installer-Paket) und .dmg (Disk Image) unterstützt. Für eine zuverlässige, unbeaufsichtigte Verteilung ist das Zusammenspiel aus passendem Paketformat, korrekter Erkennungsregel sowie gültiger Signierung entscheidend. Die nachfolgenden Abschnitte beschreiben diese Bestandteile im Detail.

PKG und DMG im Vergleich #

Die Wahl des Paketformats bestimmt, wie eine App installiert wird und ob sich der Vorgang automatisieren lässt.

Ein .pkg ist für die automatisierte Verteilung das robustere Format, da die Installationsroutine im Paket selbst hinterlegt ist und still im Hintergrund ausgeführt werden kann. Skripte innerhalb des Pakets können zusätzliche Schritte übernehmen, etwa das Anlegen von Konfigurationsdateien.

Ein .dmg ist ein Datenträger-Abbild. Für die Verteilung ist es nur dann geeignet, wenn es eine einzelne Programmdatei (.app) enthält, die nach /Programme kopiert wird. Abbilder mit einem interaktiven Installations-Assistenten oder mehreren Elementen lassen sich nicht unbeaufsichtigt installieren.

Ein wesentlicher Unterschied betrifft den Verteilkanal: .pkg-Apps werden direkt über das MDM-Protokoll installiert, während .dmg-Apps über den Relution Companion ausgebracht werden. Für die Verteilung von DMG-Apps muss der Companion daher auf dem Mac verfügbar sein.

Hinweis: Steht eine App sowohl als .pkg als auch als .dmg zur Verfügung, ist für die zentrale Verteilung das .pkg vorzuziehen.

Native App in Relution anlegen #

Das Hochladen erfolgt analog zu anderen nativen Apps über das App-Inventar.

1. Im Menü unter Apps → App Store wird über Hinzufügen der App-Typ Native App gewählt.
2. Die entsprechende .pkg- oder .dmg-Datei wird ausgewählt und hochgeladen.
3. Über Details hinzufügen wird die App-Detailseite geöffnet. Dort werden der Versionsname sowie – sofern erforderlich – die Erkennungsregel eingetragen.
4. Nach Angabe des gewünschten Freigabestatus wird die App über Speichern angelegt.

Versionsverwaltung und Freigabestatus #

Für native macOS-Apps lässt sich zusätzlich ein Release-Management betreiben: Verschiedene Versionen einer App können parallel für unterschiedliche Personengruppen bereitgestellt werden. So kann etwa eine Version im produktiven Einsatz sein, während eine neue Version durch eine ausgewählte Gruppe getestet wird, ohne dass die übrigen Anwender davon betroffen sind.

Jede Version durchläuft dabei einen der folgenden Status:

• Produktiv: Version, die regulär über den Relution Agent verteilt und installiert wird.
• Entwicklung bzw. Prüfung: Status für Versionen, die vor der Produktivsetzung getestet werden.
• Archiv: Status einer früheren Version, die durch eine neuere Produktiv-Version abgelöst wurde.

Neue Version parallel testen #

Soll eine neue Version parallel zur bestehenden produktiven Version getestet werden, wird diese über die Schaltfläche Neue Version hochgeladen und zunächst in den Status Entwicklung oder Prüfung versetzt. Optional lässt sich ein Freigabedatum hinterlegen, zu dem die Version automatisch in den Status Produktiv wechselt. Beide Versionen sind währenddessen in den App-Eigenschaften einsehbar; Anwender mit entsprechender Berechtigung können die neue Version bereits auf Endgeräten sehen, installieren und testen.

Manuelle Produktivnahme #

Alternativ zu einem automatischen Wechsel über das Freigabedatum kann eine Version auf der App-Detailseite manuell über die Schaltfläche Produktiv in diesen Status versetzt werden. Eine bereits produktive Version wird dabei automatisch in den Status Archiv verschoben.

Erkennungsregel über den Bundle-Identifier #

Die Erkennungsregel teilt Relution mit, woran der installierte Zustand einer App erkannt wird. Für native macOS-Apps erfolgt dies über den Bundle-Identifier (z. B. com.hersteller.appname). Anhand dieses eindeutigen Werts wird auf dem Gerät geprüft, ob die App bereits vorhanden ist, und ob eine Installation als erfolgreich gilt.

Der zuverlässigste Weg, den korrekten Bundle-Identifier zu ermitteln, führt über einen bereits verwalteten Mac:

1. Die App wird auf einem in Relution verwalteten Mac einmalig manuell installiert.
2. Im Relution-Portal wird das Gerät unter Geräte → Übersicht geöffnet.
3. Auf dem Reiter der installierten Apps wird die App gesucht. Der dort ausgewiesene Bundle-Identifier wird ausgelesen.
4. Dieser Wert wird in der App-Detailseite als Erkennungsregel eingetragen.

Alternativ lässt sich der Bundle-Identifier direkt auf dem Mac über das Terminal auslesen:

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

Ist der Pfad der Programmdatei bekannt, kann der Wert auch aus dem Paket-Metadatum gelesen werden:

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

Soll die Erkennungsregel bereits vor einer Installation ermittelt werden, kann der Inhalt eines .pkg mit einem Drittanbieter-Werkzeug wie Suspicious Package inspiziert werden. Ein solches Werkzeug zeigt neben den Installationspfaden und enthaltenen Skripten auch den Bundle-Identifier an, ohne dass das Paket ausgeführt werden muss.

Hinweis: Drittanbieter-Werkzeuge dienen ausschließlich der Analyse. Der maßgebliche Bundle-Identifier bleibt der Wert, der nach einer Installation im Relution-Inventar ausgewiesen wird.

Alternative Wege ohne funktionierende Erkennung #

Bei manchen nativen Apps kann Relution den installierten Zustand nicht zuverlässig prüfen – etwa weil kein eindeutiger Bundle-Identifier vorliegt oder das Paket die App an einen untypischen Ort ablegt. In diesen Fällen bieten sich zwei Wege an, die ohne belastbare Erkennungsregel auskommen:

• Bereitstellung über den Relution App Store: Die App wird den Benutzern im Relution Agent bereitgestellt und dort manuell installiert. Da die Installation aktiv angestoßen wird, ist keine automatische Zustandsprüfung nötig. Optional kann die App über die Zuweisung als automatisch zu installierende App (Auto-Deploy) an einen Benutzer oder Benutzergruppe gebunden werden.
• Verteilung per Aktion: Über eine App installieren-Aktion auf ausgewählten Geräten oder Gruppen wird die Installation gezielt ausgelöst. Der Installationsbefehl wird an das Gerät übertragen und dort ausgeführt, unabhängig von einer Erkennungsregel.

Signierung und Notarisierung #

macOS prüft über Gatekeeper, ob Software aus einer vertrauenswürdigen Quelle stammt. Pakete, die weder signiert noch von Apple notarisiert sind, können blockiert werden oder eine Nutzerinteraktion erfordern – was eine unbeaufsichtigte Verteilung verhindert.

• Signierung: Das Paket ist mit einer gültigen Developer ID signiert. Dadurch ist die Herkunft nachvollziehbar und Manipulation ausgeschlossen.
• Notarisierung: Das Paket wurde zusätzlich von Apple geprüft (notarisiert). Erst dadurch wird es auf aktuellen macOS-Versionen ohne Warnhinweis akzeptiert.

Ob ein Paket korrekt signiert und notarisiert ist, kann auf dem Mac im Terminal überprüft werden:

spctl --assess --type install -vv /Pfad/zur/App.pkg
pkgutil --check-signature /Pfad/zur/App.pkg

Hinweis: Schlägt eine Installation nur bei einzelnen Paketen still fehl, ist eine fehlende Signierung oder Notarisierung eine der häufigsten Ursachen.

Fehleranalyse per Logs und Geräteprotokollierung #

Bleibt eine Installation ohne Erfolg, lassen sich die Ursachen über die Protokollierung eingrenzen.

Geräteprotokollierung in Relution #

Die Geräteprotokollierung wird auf globaler Ebene im Inventar über die Geräte aktiviert und erfasst die Kommunikation zwischen Server und Geräten. Nach Aktivierung werden Befehle wie die App-Installation samt Rückmeldung des Geräts protokolliert und lassen sich im Portal einsehen. Auf diese Weise wird sichtbar, ob ein Installationsbefehl das Gerät erreicht hat und mit welchem Status er quittiert wurde.

Installationslogs am Mac #

Ergänzend geben die Systemprotokolle des Macs Aufschluss über den Installationsvorgang. Der Verlauf einer PKG-Installation wird lokal protokolliert und kann im Terminal ausgewertet werden:

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

Für die laufende Beobachtung während einer Installation eignet sich der Live-Datenstrom des Systemprotokolls:

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

Aus diesen Ausgaben lässt sich ablesen, ob das Paket entpackt, ein Skript ausgeführt oder der Vorgang durch Gatekeeper abgebrochen wurde.

Deinstallation #

Native macOS-Apps, die über Relution installiert wurden, lassen sich über Relution auch wieder deinstallieren – sowohl .pkg- als auch .dmg-Apps. Voraussetzung ist ein Bundle-Identifier (Erkennungsregel), über den die App auf dem Gerät eindeutig adressiert wird. Ohne gültigen Bundle-Identifier wird keine Deinstallation ausgelöst. Wie schon bei der Installation läuft die Entfernung je nach Format über unterschiedliche Kanäle – .pkg über MDM, .dmg über den Companion –, das Vorgehen im Portal ist jedoch identisch.

Für die Deinstallation bestehen zwei Wege:

• Gezielt über eine Aktion: Über die Aktion App entfernen auf ausgewählten Geräten oder Gruppen wird die App deinstalliert. In der Befehlshistorie des Geräts erscheint der Vorgang als <Bundle-Identifier> deinstallieren.
• Automatisch beim Wegfall der Zuweisung: Wird eine zuvor automatisch bereitgestellte (Auto-Deploy) App aus der App Konformität entfernt, kann Relution sie automatisch deinstallieren. Dies greift jedoch nur, wenn in der App-Konformitäts-Konfiguration die Option zum Entfernen automatisch bereitgestellter Apps aktiviert ist – andernfalls bleibt die App auf dem Gerät installiert.

Nicht über Relution entfernen lassen sich Apps ohne Bundle-Identifier sowie manuell – außerhalb von Relution – installierte Apps. Bei .dmg-Apps ist zusätzlich ein verfügbarer Relution Companion erforderlich; ist dieser deaktiviert oder auf dem Gerät nicht einsetzbar, ist keine Deinstallation über Relution möglich. In diesen Fällen wird die Entfernung über ein Skript umgesetzt, das die App beendet und die zugehörigen Verzeichnisse entfernt und gezielt über eine Aktion verteilt wird.