Vérifier le lancement d’une app macOS à l’ouverture de session

L’app macOS de barre des menus développée par votre équipe doit se lancer lorsqu’un utilisateur ouvre sa session. Sur un Mac dans le cloud, vous activez l’option « Ouvrir à l’ouverture de session » ; l’interface indique qu’elle est activée. Vous coupez la connexion au bureau à distance, puis vous vous reconnectez, mais l’app n’avait jamais cessé de fonctionner. Cela ne prouve pas que l’élément d’ouverture de session fonctionne. Pour valider le comportement, consignez séparément l’enregistrement, l’autorisation de l’utilisateur et le lancement après une véritable réouverture de session. Une déconnexion du client distant ne doit surtout pas être confondue avec une fermeture de session macOS.

Définir d’abord ce qui est testé et ses limites

Le test porte sur l’élément d’ouverture de session de l’app principale, enregistré avec SMAppService.mainApp, et non sur un utilitaire d’arrière-plan ni sur un service lancé au démarrage du système. L’app doit cibler macOS 13 ou une version ultérieure et appeler l’API d’enregistrement depuis son propre processus. Exécuter séparément un script Swift en ligne de commande ne permet pas d’effectuer ce même enregistrement à sa place.

Préparez un compte utilisateur standard distinct pour le test et vérifiez à l’avance que vous pourrez rouvrir une session sur son bureau graphique. N’utilisez pas directement le compte de travail sur lequel des tâches de compilation sont en cours : fermer la session met fin à la session interactive et peut interrompre les processus qui en dépendent. Enregistrez votre travail et notez comment vous reconnecter avant de commencer.

« Enregistré », « autorisé par l’utilisateur » et « lancé après l’ouverture de session » sont trois conclusions distinctes. Chacune exige sa propre preuve ; un état ne permet pas de déduire le suivant.

Vérifier l’app installée

Testez le paquet de l’app destiné à être livré, plutôt que de vous contenter de la lancer depuis Xcode. Remplacez le chemin ci-dessous par son emplacement d’installation réel :

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"

Notez l’identifiant de bundle affiché et vérifiez qu’il correspond à la version compilée pour ce test. Si la vérification avec codesign échoue, corrigez d’abord le paquet de l’app : ne prenez pas une app incapable de démarrer correctement pour une défaillance de l’élément d’ouverture de session. La vérification de la signature ne prouve pas non plus que l’utilisateur a donné son autorisation ni que l’app démarre après l’ouverture de session.

Gérer l’état d’enregistrement dans l’app

Associez l’enregistrement à une option explicite dans les réglages de l’app, au lieu de l’effectuer systématiquement à chaque démarrage. Placez le code suivant dans la cible de l’app macOS ; le code appelant doit traduire l’état renvoyé en message pour l’interface :

import ServiceManagement

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

L’interface ne peut indiquer que l’option est activée que si l’état renvoyé est .enabled. Avec .requiresApproval, elle doit inviter l’utilisateur à vérifier les réglages système, et non présenter l’opération comme un échec ou retenter discrètement l’enregistrement en boucle. Les exceptions doivent également remonter jusqu’à l’interface pour être traitées. Lors de la désactivation de l’option, appelez try SMAppService.mainApp.unregister() dans l’app, puis relisez l’état : changer seulement l’apparence de l’option ne suffit pas.

Vérifier l’autorisation de l’utilisateur

Sous le même compte de test, ouvrez les réglages système et consultez la page consacrée aux éléments d’ouverture de session. Vérifiez si l’app y figure et si une autorisation manuelle est nécessaire. Le nom de cette rubrique peut varier selon la version de macOS ; fiez-vous à l’interface du système utilisé. Après l’autorisation, revenez dans l’app et relisez SMAppService.mainApp.status. La simple présence du nom de l’app dans les réglages système ne permet pas de conclure que le démarrage automatique a été validé.

Effectuer une véritable réouverture de session

Quittez d’abord l’app normalement et consignez qu’elle n’est plus en cours d’exécution. Ensuite, utilisez le menu macOS pour fermer explicitement la session du compte de test, puis rouvrez une session sur le bureau graphique de ce même compte. Vérifiez la fenêtre de l’app, son icône dans la barre des menus ou un état de fonctionnement vérifiable dans l’app. Définissez avant le test lequel de ces signes constituera un « lancement réussi », afin de ne pas valider une app qui plante immédiatement après son démarrage.

Testez la dernière ligne après avoir désactivé l’élément d’ouverture de session dans l’app. Si l’app peut aussi être lancée par d’autres mécanismes, identifiez-les d’abord : la seule présence de son processus ne suffit pas à invalider le résultat de la désactivation. Une fois le test terminé, réactivez l’option si nécessaire et vérifiez son état.

Écarter les faux positifs liés à la session distante

Fermer le client de bureau à distance, subir une brève coupure réseau ou simplement verrouiller l’écran ne met pas nécessairement fin à la session utilisateur macOS. Retrouver les anciennes fenêtres après reconnexion montre généralement seulement que la session est toujours ouverte, pas que l’élément d’ouverture de session s’est déclenché. Lancer l’app par SSH ne constitue pas non plus un test d’ouverture de session graphique : l’environnement d’un shell SSH diffère de celui d’une session de bureau.

Si l’état d’enregistrement est correct mais que l’app n’apparaît pas après l’ouverture de session, vérifiez dans cet ordre : s’agit-il du compte utilisé lors de l’enregistrement ? Testez-vous le paquet installé plutôt qu’une autre copie issue de la compilation ? Les réglages système demandent-ils toujours une autorisation ? L’app quitte-t-elle immédiatement après son lancement ? Si l’app produit des journaux de démarrage, rapprochez l’heure des événements de celle de cette ouverture de session pour distinguer « ne s’est pas lancée » de « s’est lancée puis a échoué ». N’inscrivez pas d’identifiants d’accès dans les journaux.

Conserver le résultat de validation pour la prochaine compilation

Gardez une note succincte indiquant la version de l’app, son identifiant de bundle, la version de macOS, le compte de test, l’état avant et après l’enregistrement, l’autorisation accordée, le résultat de la réouverture de session et celui du nouveau test après désactivation. Après chaque mise à jour du paquet de l’app, revérifiez au minimum son identité et le résultat d’une réouverture de session. Si l’implémentation de l’élément d’ouverture de session change, reprenez les tests d’enregistrement et de désactivation.

Cette procédure ne vise pas à prouver qu’une machine donnée lancera « toujours » l’app automatiquement. Elle permet de reproduire le comportement d’une compilation précise et d’en diagnostiquer les problèmes. En distinguant clairement l’ouverture d’une session graphique d’une connexion distante, on peut généralement ramener un problème d’élément d’ouverture de session au paquet de l’app, à l’autorisation de l’utilisateur ou au démarrage de l’app elle-même.

Questions fréquentes