Подтвердить что ты не робот

SMLoginItemSetEnabled иногда бесшумно не запускает изолированный помощник интерфейса

У меня есть приложение с песочницей и включает помощника, который представляет некоторый пользовательский интерфейс (в виде полноэкранного окна, но может быть элементом статуса или аналогичным).

Это работает... большую часть времени. Но иногда это не так; он просто молча запускает помощника.

Поскольку хелпер имеет UI, я использую SMLoginItemSetEnabled для его загрузки, а затем NSXPCConnection для связи с ним. Но иногда SMLoginItemSetEnabled не запускает его, но все равно возвращает YES.

Это похоже на старую сборку приложения где-то на машине; что, похоже, путает механизм входа. Удаление старого приложения исправляет его, но я не могу разумно ожидать, что пользователи это сделают (некоторым нравится сохранять старые версии).

Я могу обнаружить эту ситуацию, сравнив результат -[NSWorkspace URLForApplicationWithBundleIdentifier:] с URL-адресом помощника в комплекте приложения, но попросить пользователя удалить другое приложение не очень изящное решение.

Есть ли способ сделать SMLoginItemSetEnabled всегда использовать элемент входа из текущего пакета приложений, а не какой-нибудь случайный в другом месте на диске?

Или что-то изменилось в последних выпусках ОС для поддержки более элегантного механизма для помощников с пользовательским интерфейсом?

Я прочитал много других вопросов здесь и в другом месте по этой теме, и кажется, что этот неуклюжий механизм по-прежнему является лучшим решением, но, возможно, я что-то пропустил.

4b9b3361

Ответ 1

Есть ли способ сделать SMLoginItemSetEnabled всегда использовать элемент входа из текущего пакета приложений, а не какой-нибудь случайный в другом месте на диске?

Кажется, что есть ошибка в SMLoginItemSetEnabled. Когда я тестирую свое приложение, исполняемый файл находится в папке DerivedData Xcode.

Когда я создаю выпуск, я помещаю приложение и его помощник в папку /Applications. Но по некоторым очевидным причинам, помощник, который запускается, является помощником, который находится в папке DeriveData. Поэтому я использовал для удаления всего, что находится в этой папке, перед запуском основного приложения в/Приложения.

Ответ 2

Выделение источника/объяснения, размещенного в комментариях:

Если несколько приложений (например, несколько приложений от одной компании) содержат вспомогательное приложение с одним и тем же идентификатором пакета, запускается только приложение с наибольшим номером версии пакета. Любое из приложений, содержащих копию вспомогательного приложения, может включать и отключать ее.

https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLoginItems.html#//apple_ref/doc/uid/10000172i-SW5-SW1

Таким образом, потенциальным решением этой проблемы является увеличение номера версии пакета вспомогательного приложения. Затем будет запущена новая версия с наибольшим номером версии.

Ответ 3

Если вы принудительно закроете элемент входа в систему из Activity Monitor, он будет перезапущен и внесет некоторую информацию.

Проверьте журнал консоли ниже, чтобы определить местоположение запускаемого нового экземпляра:

LSApplicationCheckIn(), регистрируемое приложение: "/Applications/YourApp.app/Contents/Library/LoginItems/YourLoginItem.app/Contents/MacOS/YourLoginItem"