Руководство по проблемам с разрешениями при разработке на macOS

Поскольку LCC Unity SDK использует стороннюю библиотеку декодирования webP, при использовании SDK на macOS вы можете столкнуться с ошибкой «Failed to open xxx.bundle». Это механизм безопасности macOS (Gatekeeper), блокирующий запуск несертифицированных сторонних плагинов, и не имеет отношения ни к Unity, ни к самому SDK.

Это руководство состоит из двух частей:

• Часть 1: Временное решение проблем с разрешениями сторонних библиотек в среде разработки.
• Часть 2: Официальное решение при упаковке приложения (для публичного распространения).

Часть 1: Временное решение проблем с разрешениями сторонних библиотек в среде разработки

Следующие методы применяются для быстрого снятия ограничения bundle во время разработки; пробуйте их в порядке приоритета.

Метод 1: Разрешите напрямую в Системных настройках (самый быстрый)

Метод 2: Удалите атрибут карантина через Терминал (самый тщательный)

macOS добавляет атрибут карантина com.apple.quarantine к файлам, загруженным из сети; вы можете удалить его напрямую командой Терминала.

Совет:

Эта команда требует прав администратора (sudo). На экране ничего не будет отображаться при вводе пароля; просто допечатайте его и нажмите Enter.

Метод 3: Добавьте права на выполнение (дополнительный)

Если методы 1 и 2 всё ещё не работают, добавьте права на выполнение для bundle:

chmod -R 755 /path/to/xxx.bundle

Вы также можете перетащить файл bundle в Терминал для автодополнения пути, нажать Enter и перезапустить Unity.

Метод 4: Проверьте настройки платформы плагина Unity

Отметьте Any Platform или macOS в Platform Settings в Inspector

Метод 5: Временно отключите Gatekeeper (крайний случай)

Предупреждение:

Этот метод снижает безопасность системы. Он рекомендуется только для временного использования на машине разработки; обязательно включите его снова после завершения разработки.

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

sudo spctl --master-disable

Проверьте, отключена ли она:

spctl --status
# при успешном отключении отображается assessments disabled

Снова включите защиту безопасности после завершения разработки:

sudo spctl --master-enable

Часть 2: Решение проблем с разрешениями сторонних библиотек при упаковке приложения

Чтобы конечные пользователи использовали приложение со сторонним SDK без осознания проблемы, вы должны выполнить «глубокую подпись кода + нотаризацию Apple + привязку Staple-билета» на стороне разработчика. Это единственное соответствующее стандартам решение на macOS с нулевыми операциями пользователя.

Предварительные условия (все обязательны)

Полный рабочий процесс подписи и нотаризации

Шаг 1: Очистите расширенные атрибуты

xattr -cr "YourApp.app"

Шаг 2: Глубокая рекурсивная подпись

Параметр --deep автоматически обходит все внутренние файлы .bundle, .dylib и .framework и подписывает их единообразно, полностью решая проблему блокировки сторонних bundle за отсутствие подписи.

codesign --force --deep --options runtime --sign "Developer ID Application: YourCompany (TeamID)" "YourApp.app"

Ключевой момент:

Замените YourCompany (TeamID) на ваш полный Developer ID. Использование --deep гарантирует подпись всех внутренних сторонних bundle — это корень 90% проблем «всё ещё ошибка после подписи».

Шаг 3: Упакуйте стандартный zip для нотаризации

Вы должны использовать команду ditto для упаковки; не используйте системное сжатие правой кнопкой (иначе проверка нотаризации не пройдёт).

ditto -c -k --sequesterRsrc --keepParent "YourApp.app" build.zip

Шаг 4: Загрузите в Apple для нотаризации

Используйте notarytool (официальный новый инструмент) для отправки на нотаризацию; бэкенд Apple автоматически сканирует на вредоносный код:

xcrun notarytool submit build.zip --apple-id your@apple.com --password app-specific-password --team-id TeamID --wait

Подождите, пока не вернётся Accepted, что означает прохождение нотаризации.

Шаг 5: Прикрепите Staple-билет нотаризации к приложению

После прикрепления пользователи смогут пройти проверку даже при открытии офлайн:

xcrun stapler staple "YourApp.app"
# Проверяем, успешно ли
xcrun stapler validate "YourApp.app"

Внутреннее тестирование / распространение в корпоративной интрасети (альтернатива)

Если у вас ещё нет учётной записи разработчика Apple, вы можете распространять в интрасети, используя следующий подход:

Ограничение:

Этот подход применим только к передаче в интрасети. Загрузки через браузер снова добавят атрибут карантина, вызывая повторное появление ошибки bundle, и не подходят для публичного распространения.

Распространённые подводные камни

Сводка

Единственное стандартное решение для публичного распространения = Apple Developer ID + глубокая codesign + нотаризация notarytool + билет stapler. После завершения пользователи сразу загружают и используют его, без диалога безопасности и без осознания проблемы.