SMLoginItemSetEnabled schlägt manchmal unbemerkt fehl, den Sandbox-UI-Helfer zu starten

Ich besitze eine Sandbox-App mit einem Hilfsprogramm, das eine Benutzeroberfläche anzeigt (als Vollbild-Fenster, kann aber auch ein Statuselement oder ähnliches sein).

Das funktioniert ... die meiste Zeit. Aber manchmal tut es nicht; es kann den Helfer nur im stillen nicht starten.

Da der Helfer UI hat, benutze ichSMLoginItemSetEnabled um es zu laden, dannNSXPCConnection, um damit zu kommunizieren. Aber manchmalSMLoginItemSetEnabled kann nicht gestartet werden, gibt aber immer noch YES zurück.

Dies scheint auf einen alten Build der App irgendwo auf dem Computer zurückzuführen zu sein. das scheint den Login-Mechanismus zu verwirren. Das Löschen der alten App behebt das Problem, aber ich kann nicht davon ausgehen, dass Benutzer dies tun (manche Leute behalten alte Versionen gerne bei).

Ich kann diese Situation erkennen, indem ich das Ergebnis von @ vergleich-[NSWorkspace URLForApplicationWithBundleIdentifier:] mit der URL des Helfers im App-Bundle, aber den Benutzer bitten zu müssen, die andere App zu entfernen, ist keine sehr elegante Lösung.

Gibt es eine Möglichkeit, @ zu machSMLoginItemSetEnabled Verwenden Sie immer das Anmeldeelement aus dem aktuellen App-Bundle und nicht ein zufälliges Element an einer anderen Stelle auf der Festplatte?

Oder hat sich in den letzten Betriebssystemversionen etwas geändert, um einen eleganteren Mechanismus für Helfer mit der Benutzeroberfläche zu unterstützen?

Ich habe hier und anderswo viele andere Fragen zu diesem Thema gelesen und es scheint, dass dieser klobige Mechanismus immer noch die beste Lösung ist, aber vielleicht habe ich etwas verpasst.

Antworten auf die Frage(6)

Ihre Antwort auf die Frage