Убедитесь, что вспомогательный инструмент установлен

Поскольку вы создаете вспомогательный инструмент, просто добавьте обработчик сообщений XPC, чтобы сообщать о состоянии вашего инструмента. При запуске подключитесь и отправьте это сообщение. Если что-то из этого не работает, ваш инструмент установлен неправильно (или не отвечает).

В моем коде все мои службы XPC (включая моего привилегированного помощника) принимают базовый протокол, используемый для тестирования и управления установками:

@protocol DDComponentInstalling /*<NSObject>*/

@required
- (void)queryBuildNumberWithReply:(void(^_Nonnull)(UInt32))reply;

@optional
- (void)didInstallComponent;
- (void)willUninstallComponent;

queryBuildNumberWithReply: возвращает целое число, описывающее номер версии компонента:

- (void)queryBuildNumberWithReply:(void(^)(UInt32))reply
{
    reply(FULL_BUILD_VERSION);
}

Если сообщение успешно, я сравниваю возвращаемое значение с константой номера сборки в моем приложении. Если они не совпадают, сервис является более старой/новой версией и нуждается в замене. Эта константа увеличивается для каждого публичного выпуска моего продукта.

Код, который я использую, выглядит примерно так:

- (BOOL)verifyServiceVersion
{
    DDConnection* connection = self.serviceConnection;
    id<DDComponentInstalling> proxy = connection.serviceProxy;  // get the proxy (will connect, as needed)
    if (proxy==nil)
        // an XPC connection could not be established or the proxy object could not be obtained
        return NO;  // assume service is not installed

    // Ask for the version number and wait for a response
    NSConditionLock* barrierLock = [[NSConditionLock alloc] initWithCondition:NO];
    __block UInt32 serviceVersion = UNKNOWN_BUILD_VERSION;
    [proxy queryBuildNumberWithReply:^(UInt32 version) {
        // Executes when service returns the build version
        [barrierLock lock];
        serviceVersion = version;
        [barrierLock unlockWithCondition:YES];  // signal to foreground thead that query is finished
        }];
    // wait for the message to reply
    [barrierLock lockWhenCondition:YES beforeDate:[NSDate dateWithTimeIntervalSinceNow:30.0];
    BOOL answer = (serviceVersion==FULL_BUILD_VERSION); // YES means helper is installed, alive, and correct version
    [barrierLock unlock];

    return answer;
}

Обратите внимание, что DDConnection — это утилита-обертка для XPC-соединений, а трюк barrierLock на самом деле инкапсулирован в общий метод — так что я не буду писать это снова и снова — но здесь он развернут в целях демонстрации.

У меня также есть проблемы до/после установки/обновления, поэтому все мои компоненты реализуют необязательные методы didInstallComponent и willUninstallComponent, которые я отправляю сразу после установки нового помощника или непосредственно перед тем, как планирую удалить или заменить установленный помощник.

Я бы проверил файловую систему, существует ли двоичный файл (в /Library/PrivilegedHelperTools и существует ли plist в /Library/LaunchDaemons). Затем вы можете связаться со службой XPC и вызвать функцию проверки связи, которая отвечает, если служба запущена и работает.

только мои 2 балла,

Роберт

На самом деле можно избежать тайм-аута ожидания ответа инструмента. Фактически, приведенный вами пример erikberglund/SwiftPrivilegedHelper печатает слово «Нет» рядом с текстовым полем «Установлен помощник», если инструмент не включен (см. /AppDelegate.swift#L91" rel="nofollow noreferrer">здесь), хотя и асинхронно, но практически мгновенно.

Тем не менее, я был в уникальном положении, имея именно ту проблему, которую вы описали в моей собственной реализации привилегированного помощника, но с примером SwiftPrivilegedHelper, полностью работающим для меня. Если инструмент не установлен, в первом случае обработчик ошибок remoteObjectProxyWithErrorHandler никогда не вызывается, а во втором — вызывается.

Поскольку у меня был пример вашей проблемы, а также рабочий пример, я считаю, что мне удалось определить основную причину:

По крайней мере, в моем случае я не полностью удалил вспомогательный инструмент. В какой-то момент я удалил его plist из /Library/LaunchDaemons, а сам инструмент из /Library/PrivilegedHelperTools, но, похоже, я не запускал sudo launchctl unload x. Он все еще был в списке, когда я запустил sudo launchctl list. В этих обстоятельствах вызов инструмента, очевидно, не увенчается успехом (поскольку инструмент не установлен), но и не завершится сбоем (поскольку launchctl считает, что он установлен).

Как только я все прояснил (запустив sudo launchctl remove x), о чудо, мой remoteObjectProxyWithErrorHandler начал вызывать свой обработчик ошибок, когда инструмент не установлен.