SMLoginItemSetEnabled a volte non riesce a lanciare l'helper UI sandboxed

Question

Ho un'app che è in modalità sandbox e include un helper che presenta un'interfaccia utente (come una finestra a schermo intero, ma potrebbe anche essere un elemento di stato o simile).

questo funziona ... la maggior parte del tempo. Ma a volte no; semplicemente non riesce a far partire l'aiutante.

Poiché l'helper ha l'interfaccia utente, io uso SMLoginItemSetEnabled per caricarlo, quindi NSXPCConnection per comunicare con esso. Ma a volte SMLoginItemSetEnabled non riesce a lanciarlo, mentre sta ancora restituendo SÌ.

Questo sembra essere dovuto ad un antico edificio, delle app da qualche parte sulla macchina; sembra confondere il meccanismo di accesso. L'eliminazione della vecchia app la risolve, ma non posso ragionevolmente aspettarmi che gli utenti facciano questo (alcune persone preferiscono mantenere le vecchie versioni in giro).

posso rilevare questa situazione mettendo a confronto il risultato della -[NSWorkspace URLForApplicationWithBundleIdentifier:] con l'URL del aiutante nel pacchetto app, ma dover chiedere all'utente di rimuovere l'altra applicazione non è una soluzione molto elegante.

C'è un modo per fare in modo che SMLoginItemSetEnabled utilizzi sempre l'elemento di accesso dal pacchetto di app corrente, piuttosto che un altro casuale sul disco?

o è cambiato qualcosa negli ultimi release del sistema operativo per supportare un meccanismo più elegante per aiutanti con UI?

Ho letto molte altre domande qui e altrove su questo argomento, e sembra che questo meccanismo goffo è ancora la soluzione migliore, ma forse ho perso qualcosa.

Answer 1

C'è un modo per rendere SMLoginItemSetEnabled utilizzare sempre l'elemento di login dagli attuali fascio applicazione, piuttosto che qualche casuale altrove sul disco?

Sembra che sia presente un errore in SMLoginItemSetEnabled. Quando provo la mia applicazione, l'eseguibile si trova nella cartella DerivedData di Xcode.

Quando costruisco il rilascio, ho messo l'applicazione ed è aiutante nella cartella/Applications. Ma per alcune ovvie ragioni, l'helper che viene lanciato è l'helper che si trova nella cartella DeriveData. Ecco perché sono abituato a rimuovere tutto ciò che è in questa cartella prima di avviare l'applicazione principale in/Applicazioni.