Den App-Start bei der macOS-Anmeldung auf einem entfernten Mac prüfen

Eine macOS-Menüleisten-App Ihres Teams soll nach der Anmeldung eines Benutzers starten. Auf einem Mac in der Cloud aktivieren Sie „Bei der Anmeldung öffnen“; die Oberfläche zeigt die Funktion als aktiviert an. Sie trennen die Remotedesktop-Verbindung, verbinden sich erneut – und stellen fest, dass die App die ganze Zeit lief. Das belegt nicht, dass das Anmeldeobjekt funktioniert. Für die Abnahme müssen Registrierung, Benutzerfreigabe und Start nach einer tatsächlichen Neuanmeldung getrennt dokumentiert werden. Vor allem darf eine unterbrochene Remoteverbindung nicht mit einer macOS-Abmeldung verwechselt werden.

Zuerst Testgegenstand und Grenzen festlegen

Getestet wird hier das mit SMAppService.mainApp registrierte Anmeldeobjekt der Haupt-App, kein Hintergrund-Hilfsprogramm und kein Systemstartdienst. Die App muss für macOS 13 oder neuer vorgesehen sein und die Registrierungsschnittstelle im eigenen Prozess aufrufen. Ein separat ausgeführtes Swift-Kommandozeilenskript kann diese Registrierung nicht an ihrer Stelle vornehmen.

Richten Sie ein separates Standardbenutzerkonto für den Test ein und prüfen Sie vorab, ob Sie sich erneut an dessen grafischem Schreibtisch anmelden können. Verwenden Sie dafür nicht das Arbeitskonto, auf dem gerade Builds laufen: Eine Abmeldung beendet die interaktive Sitzung und kann davon abhängige Prozesse unterbrechen. Speichern Sie Ihre Arbeit und halten Sie fest, wie Sie sich wieder verbinden, bevor Sie beginnen.

„Registriert“, „vom Benutzer freigegeben“ und „nach der Anmeldung gestartet“ sind drei verschiedene Ergebnisse. Für jedes ist ein eigener Nachweis nötig; aus einem Zustand lässt sich der nächste nicht ableiten.

Die installierte App prüfen

Testen Sie das App-Paket, das Sie ausliefern wollen, statt die App nur aus Xcode heraus zu starten. Ersetzen Sie den folgenden Pfad durch den tatsächlichen Installationsort:

APP="/Applications/ExampleApp.app"
test -d "$APP" || { echo "App bundle not found"; exit 1; }
/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' \
  "$APP/Contents/Info.plist"
codesign --verify --deep --strict --verbose=2 "$APP"

Notieren Sie die ausgegebene Bundle-ID und gleichen Sie sie mit dem vorgesehenen Build ab. Schlägt die Prüfung mit codesign fehl, beheben Sie zuerst das Problem mit dem App-Paket. Verwechseln Sie eine App, die nicht ordnungsgemäß startet, nicht mit einem defekten Anmeldeobjekt. Auch eine erfolgreiche Signaturprüfung belegt weder die Benutzerfreigabe noch den Start nach der Anmeldung.

Den Registrierungsstatus in der App behandeln

Verknüpfen Sie die Registrierung mit einem eindeutigen Schalter in den App-Einstellungen, statt sie bei jedem Start bedingungslos aufzurufen. Der folgende Code gehört in das macOS-App-Target; die aufrufende Stelle sollte den zurückgegebenen Status in einen Hinweis für die Benutzeroberfläche übersetzen:

import ServiceManagement

@MainActor
func enableLaunchAtLogin() throws -> SMAppService.Status {
    let service = SMAppService.mainApp
    if service.status == .notRegistered {
        try service.register()
    }
    return service.status
}

Nur bei .enabled darf die Oberfläche die Funktion als aktiviert bezeichnen. Bei .requiresApproval sollte sie dazu auffordern, die Systemeinstellungen zu prüfen – nicht einen Fehler anzeigen oder die Registrierung unbemerkt immer wieder versuchen. Auch Ausnahmen müssen zur Behandlung an die Benutzeroberfläche weitergegeben werden. Wird der Schalter deaktiviert, rufen Sie in der App try SMAppService.mainApp.unregister() auf und lesen anschließend den Status erneut aus. Nur das Aussehen des Schalters zu ändern, reicht nicht.

Die Benutzerfreigabe prüfen

Öffnen Sie die Systemeinstellungen unter demselben Testkonto und sehen Sie auf der Seite für Anmeldeobjekte nach, ob die App aufgeführt ist und manuell freigegeben werden muss. Die Bezeichnung des Einstellungsbereichs kann je nach macOS-Version variieren; maßgeblich ist die Oberfläche des verwendeten Systems. Kehren Sie nach der Freigabe zur App zurück und lesen Sie SMAppService.mainApp.status erneut aus. Allein aus dem Eintrag in den Systemeinstellungen folgt noch nicht, dass der automatische Start erfolgreich getestet wurde.

Eine tatsächliche Neuanmeldung durchführen

Beenden Sie zunächst die App regulär und halten Sie fest, dass sie nicht mehr läuft. Melden Sie sich dann über das macOS-Menü ausdrücklich vom Testkonto ab und anschließend wieder an dessen grafischem Schreibtisch an. Prüfen Sie, ob das App-Fenster oder das Menüleistensymbol erscheint beziehungsweise ob sich ein app-eigener Betriebszustand verifizieren lässt. Legen Sie vor dem Test fest, welches dieser Merkmale als erfolgreicher Start gilt, damit eine unmittelbar nach dem Start abstürzende App nicht als bestanden gewertet wird.

Testen Sie die letzte Zeile, nachdem Sie das Anmeldeobjekt in der App deaktiviert haben. Falls die App auch über andere Mechanismen gestartet wird, identifizieren Sie diese zuerst: Ein laufender Prozess allein widerlegt das Ergebnis der Deaktivierung nicht. Aktivieren Sie die Funktion nach dem Test bei Bedarf wieder und prüfen Sie den Schalterstatus.

Fehlschlüsse durch Remote-Sitzungen vermeiden

Das Schließen des Remotedesktop-Clients, eine kurze Netzwerkunterbrechung oder das bloße Sperren des Bildschirms beendet die macOS-Benutzersitzung nicht zwangsläufig. Wenn nach dem erneuten Verbinden die alten Fenster zu sehen sind, zeigt das meist nur, dass die Sitzung fortbesteht – nicht, dass das Anmeldeobjekt ausgelöst wurde. Auch ein App-Start über SSH ist kein Test der grafischen Anmeldung: Die Umgebung einer SSH-Shell unterscheidet sich von der einer Schreibtischsitzung.

Ist der Registrierungsstatus korrekt, die App nach der Anmeldung aber nicht zu sehen, prüfen Sie der Reihe nach: Sind Sie mit demselben Benutzer angemeldet, unter dem die Registrierung erfolgte? Testen Sie das installierte App-Paket statt einer anderen Build-Kopie? Verlangen die Systemeinstellungen weiterhin eine Freigabe? Beendet sich die App unmittelbar nach dem Start? Falls die App Startvorgänge protokolliert, vergleichen Sie den Zeitpunkt des Ereignisses mit dem dieser Anmeldung. So unterscheiden Sie „nicht gestartet“ von „gestartet und anschließend fehlgeschlagen“. Schreiben Sie keine Zugangsdaten in die Protokolle.

Das Abnahmeergebnis für den nächsten Build festhalten

Halten Sie kurz fest: App-Version, Bundle-ID, macOS-Version, Testkonto, Status vor und nach der Registrierung, Freigabeschritt, Ergebnis der Neuanmeldung und Ergebnis des erneuten Tests nach dem Deaktivieren. Prüfen Sie nach jedem Update des App-Pakets mindestens dessen Identität und das Ergebnis einer Neuanmeldung erneut. Ändert sich die Implementierung des Anmeldeobjekts, testen Sie sowohl die Registrierung als auch die Deaktivierung noch einmal.

Dieses Vorgehen soll nicht beweisen, dass eine bestimmte Maschine die App „immer automatisch startet“. Es macht vielmehr das Verhalten eines konkreten Builds reproduzierbar und Fehler eingrenzbar. Wer die grafische Anmeldung klar von einer Remoteverbindung trennt, kann Probleme mit Anmeldeobjekten meist auf das App-Paket, die Benutzerfreigabe oder den App-Start selbst zurückführen.

Häufig gestellte Fragen