SMLoginItemSetEnabled czasami po cichu nie uruchamia się pomocnika piaskownicy UI

Question

Mam aplikację piaskownicy i zawiera pomocnika, który prezentuje niektóre UI (jako pełnoekranowe okno, ale może być również pozycja statusu lub podobne).

Działa to przez większość czasu. Ale czasami tak się nie dzieje; po prostu cicho nie uruchamia pomocnika.

Ponieważ helper ma interfejs użytkownika, używam SMLoginItemSetEnabled do jego załadowania, a następnie NSXPCConnection do komunikowania się z nim. Ale czasami SMLoginItemSetEnabled nie uruchamia go, a wciąż zwraca TAK.

Wydaje się, że jest to spowodowane starą wersją aplikacji w urządzeniu; to wydaje się mylić mechanizm logowania. Usunięcie starej aplikacji naprawia ją, ale nie mogę rozsądnie oczekiwać, że to zrobią (niektórzy ludzie lubią starsze wersje).

Mogę wykryć tę sytuację, porównując wynik -[NSWorkspace URLForApplicationWithBundleIdentifier:] z adresem URL helpera w pakiecie aplikacji, ale zmuszenie użytkownika do usunięcia drugiej aplikacji nie jest bardzo eleganckim rozwiązaniem.

Czy jest jakiś sposób, aby SMLoginItemSetEnabled zawsze używać elementu logowania z bieżącego pakietu aplikacji, a nie losowego innego miejsca na dysku?

A może coś się zmieniło w ostatnich wydaniach systemu operacyjnego, aby obsługiwać bardziej elegancki mechanizm dla pomocników z interfejsem użytkownika?

Przeczytałem wiele innych pytań tutaj i gdzie indziej na ten temat, i wydaje się, że ten niezgrabny mechanizm jest nadal najlepszym rozwiązaniem, ale może coś przeoczyłem.

Answer 1

Czy istnieje sposób na to, aby SMLoginItemSetEnabled zawsze używał elementu logowania z bieżącego pakietu aplikacji, a nie jakiegoś losowego elementu w innym miejscu na dysku?

Wygląda na to, że istnieje błąd w SMLoginItemSetEnabled. Kiedy testuję swoją aplikację, plik wykonywalny znajduje się w folderze DerivedData w Xcode.

Po zbudowaniu wydania umieściłem aplikację i jej pomocnika w folderze/Applications. Ale z oczywistych powodów uruchamiany helper jest pomocnikiem znajdującym się w folderze DeriveData. Właśnie dlatego jestem przyzwyczajony do usuwania wszystkiego, co jest w tym folderze przed uruchomieniem głównej aplikacji w/Applications.