SMLoginItemSetEnabled有时有时会默默地无法启动沙盒UI帮助器 [英] SMLoginItemSetEnabled sometimes silently fails to launch sandboxed UI helper

问题描述

我有一个带有沙箱的应用程序，其中包括一个提供一些UI(作为全屏窗口，但也可以是状态项或类似项目)的助手.

I have an app that is sandboxed, and includes a helper that presents some UI (as a full-screen window, but could be a status item or similar too).

这在大多数情况下都有效.但有时并非如此；只是默默地没有启动助手.

This works... most of the time. But sometimes it doesn't; it just silently fails to start the helper.

由于帮助程序具有UI，因此我使用SMLoginItemSetEnabled进行加载，然后使用NSXPCConnection进行通信.但是有时候SMLoginItemSetEnabled无法启动它，而仍然返回YES.

Since the helper has UI, I use SMLoginItemSetEnabled to load it, then NSXPCConnection to communicate with it. But sometimes SMLoginItemSetEnabled fails to launch it, while still returning YES.

这似乎是由于该应用程序在计算机上某个地方的旧版本所致；这似乎混淆了登录机制.删除旧应用程序可以解决该问题，但是我不能合理地期望用户这样做(有些人喜欢保留旧版本).

This seems to be due to an old build of the app somewhere on the machine; that seems to confuse the login mechanism. Deleting the old app fixes it, but I can't reasonably expect users to do this (some people like to keep old versions around).

我可以通过将-[NSWorkspace URLForApplicationWithBundleIdentifier:]的结果与应用程序捆绑包中的帮助程序的URL进行比较来检测这种情况，但是不得不要求用户删除另一个应用程序并不是一个很好的解决方案.

I can detect this situation by comparing the result of -[NSWorkspace URLForApplicationWithBundleIdentifier:] with the URL of the helper in the app bundle, but having to ask the user to remove the other app isn't a very elegant solution.

有什么方法可以使SMLoginItemSetEnabled始终使用当前应用程序捆绑包中的登录项，而不是磁盘上其他位置的随机项?

Is there any way to make SMLoginItemSetEnabled always use the login item from the current app bundle, rather than some random one elsewhere on the disk?

或者在最近的OS版本中有什么更改，以支持UI助手的更优雅的机制?

Or has anything changed in recent OS releases to support a more elegant mechanism for helpers with UI?

在这里和其他地方，我已经阅读过许多其他有关此主题的问题，看来这种笨拙的机制仍然是最好的解决方案，但也许我错过了一些东西.

I've read many other questions here and elsewhere on this topic, and it appears that this clunky mechanism is still the best solution, but maybe I missed something.

推荐答案

是否有任何方法可以使SMLoginItemSetEnabled始终使用当前应用程序捆绑包中的登录项，而不是磁盘上其他位置的随机项?

Is there any way to make SMLoginItemSetEnabled always use the login item from the current app bundle, rather than some random one elsewhere on the disk?

似乎在SMLoginItemSetEnabled中存在错误.当我测试我的应用程序时，可执行文件位于Xcode的DerivedData文件夹中.

It seems that there is is a bug in SMLoginItemSetEnabled. When I test my application, the executable is in the DerivedData folder of Xcode.

构建发行版时，我将应用程序及其帮助程序放在/Applications文件夹中.但是出于某些显而易见的原因，启动的帮助程序是DeriveData文件夹中的帮助程序.这就是为什么我习惯在/Applications中启动主应用程序之前删除此文件夹中的所有内容的原因.

When I build the release, I put the application and it's helper in the /Applications folder. But for some obvious reasons, the helper that is launched is the helper which is in the DeriveData folder. That's why I'm used to remove everything that is in this folder before launching the main application in /Applications.

这篇关于SMLoginItemSetEnabled有时有时会默默地无法启动沙盒UI帮助器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！