我有一个沙盒应用程序，其中包含一个显示一些 UI 的帮助程序(作为全屏窗口，但也可以是状态项或类似项)。
这在大多数情况下都有效。但有时却并非如此；它只是默默地无法启动助手。
由于助手有 UI，我使用 SMLoginItemSetEnabled 加载它，然后使用 NSXPCConnection 与其通信。但有时 SMLoginItemSetEnabled 无法启动它，但仍返回 YES。
这似乎是由于机器上某处应用程序的旧版本造成的；这似乎混淆了登录机制。删除旧应用程序可以解决此问题，但我不能合理地期望用户这样做(有些人喜欢保留旧版本)。
我可以通过将 -[NSWorkspace URLForApplicationWithBundleIdentifier:] 的结果与应用程序包中帮助程序的 URL 进行比较来检测这种情况，但必须要求用户删除其他应用程序是不行的这是一个非常优雅的解决方案。
有没有办法让 SMLoginItemSetEnabled 始终使用当前应用程序包中的登录项，而不是磁盘上其他位置的随机项？
或者最近的操作系统版本中是否有任何变化来支持更优雅的 UI 助手机制？
我在这里和其他地方阅读了有关该主题的许多其他问题，看来这种笨重的机制仍然是最好的解决方案，但也许我错过了一些东西。
最佳答案
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 文件夹中。
当我构建版本时，我将应用程序及其助手放在/Applications 文件夹中。但由于一些明显的原因，启动的帮助程序是 DeriveData 文件夹中的帮助程序。这就是为什么我习惯在启动/Applications 中的主应用程序之前删除此文件夹中的所有内容。
关于macos - SMLoginItemSetEnabled 有时会默默地无法启动沙盒 UI 帮助程序，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27995970/