title: SMLoginItemSetEnabled sometimes silently fails to launch sandboxed UI helper
body: <p>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).</p>
  
  <p>This works... most of the time.  But sometimes it doesn't; it just silently fails to start the helper.</p>
  
  <p>Since the helper has UI, I use <code>SMLoginItemSetEnabled</code> to load it, then <code>NSXPCConnection</code> to communicate with it.  But sometimes <code>SMLoginItemSetEnabled</code> fails to launch it, while still returning YES.</p>
  
  <p>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).</p>
  
  <p>I can detect this situation by comparing the result of <code>-[NSWorkspace URLForApplicationWithBundleIdentifier:]</code> 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.</p>
  
  <p>Is there any way to make <code>SMLoginItemSetEnabled</code> always use the login item from the current app bundle, rather than some random one elsewhere on the disk?</p>
  
  <p>Or has anything changed in recent OS releases to support a more elegant mechanism for helpers with UI?</p>
  
  <p>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.</p>