Przewodnik problemów z uprawnieniami w deweloperstwie na macOS

Ponieważ LCC Unity SDK używa biblioteki dekodującej webP innej firmy, podczas korzystania z SDK na macOS możesz napotkać błąd „Failed to open xxx.bundle". To mechanizm bezpieczeństwa macOS (Gatekeeper) blokujący uruchamianie niecertyfikowanych wtyczek firm trzecich i nie ma to nic wspólnego z Unity ani samym SDK.

Ten przewodnik ma dwie części:

• Część 1: Tymczasowe rozwiązywanie problemów z uprawnieniami bibliotek firm trzecich w środowisku deweloperskim.
• Część 2: Formalne rozwiązanie przy pakowaniu aplikacji (do dystrybucji publicznej).

Część 1: Tymczasowe rozwiązywanie problemów z uprawnieniami bibliotek firm trzecich w środowisku deweloperskim

Poniższe metody dotyczą szybkiego usuwania ograniczenia bundle podczas tworzenia; wypróbuj je w kolejności priorytetu.

Metoda 1: Zezwól bezpośrednio w Ustawieniach systemowych (najszybsza)

Metoda 2: Usuń atrybut kwarantanny przez Terminal (najdokładniejsza)

macOS dodaje atrybut kwarantanny com.apple.quarantine do plików pobranych z sieci; możesz go usunąć bezpośrednio poleceniem Terminala.

Wskazówka:

To polecenie wymaga uprawnień administratora (sudo). Ekran nie pokaże nic podczas wpisywania hasła; po prostu dokończ pisanie i naciśnij Enter.

Metoda 3: Dodaj uprawnienia wykonywania (uzupełniająca)

Jeśli metody 1 i 2 nadal nie działają, dodaj uprawnienia wykonywania do bundle:

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

Możesz też przeciągnąć plik bundle do Terminala, aby automatycznie uzupełnić ścieżkę, nacisnąć Enter i uruchomić ponownie Unity.

Metoda 4: Sprawdź ustawienia platformy wtyczki Unity

Zaznacz Dowolna platforma lub macOS w Ustawieniach platformy w Inspektorze

Metoda 5: Tymczasowo wyłącz Gatekeeper (ostateczność)

Ostrzeżenie:

Ta metoda zmniejsza bezpieczeństwo systemu. Zaleca się ją tylko do tymczasowego użycia na maszynie deweloperskiej; pamiętaj, aby ponownie włączyć ją po zakończeniu tworzenia.

Jeśli żadna z powyższych metod nie działa, możesz tymczasowo wyłączyć weryfikację bezpieczeństwa systemu:

sudo spctl --master-disable

Sprawdź, czy jest wyłączona:

spctl --status
# po pomyślnym wyłączeniu wyświetlane jest „assessments disabled"

Ponownie włącz ochronę bezpieczeństwa po zakończeniu tworzenia:

sudo spctl --master-enable

Część 2: Rozwiązywanie problemów z uprawnieniami bibliotek firm trzecich przy pakowaniu aplikacji

Aby użytkownicy końcowi mogli używać aplikacji zawierającej SDK firmy trzeciej bez odczuwania problemu, musisz po stronie dewelopera ukończyć „głębokie podpisywanie kodu + notaryzację Apple + zszycie biletu Staple". To jedyne zgodne standardowe rozwiązanie na macOS z zerową liczbą operacji po stronie użytkownika.

Wymagania wstępne (wszystkie wymagane)

Kompletny przepływ podpisywania i notaryzacji

Krok 1: Wyczyść rozszerzone atrybuty

xattr -cr "YourApp.app"

Krok 2: Głębokie rekurencyjne podpisywanie

Parametr --deep automatycznie przechodzi przez wszystkie wewnętrzne pliki .bundle, .dylib i .framework i podpisuje je jednolicie, dokładnie rozwiązując problem blokowania bundle'ów firm trzecich za brak podpisu.

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

Kluczowy punkt:

Zastąp YourCompany (TeamID) swoim pełnym Developer ID. Użycie --deep zapewnia podpisanie wszystkich wewnętrznych bundle'ów firm trzecich — to główna przyczyna 90% problemów „nadal błąd po podpisaniu".

Krok 3: Spakuj standardowy zip do notaryzacji

Musisz użyć polecenia ditto do pakowania; nie używaj systemowej kompresji prawym przyciskiem (w przeciwnym razie weryfikacja notaryzacji się nie powiedzie).

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

Krok 4: Prześlij do Apple do notaryzacji

Użyj notarytool (oficjalnego nowego narzędzia), aby przesłać do notaryzacji; backend Apple automatycznie skanuje w poszukiwaniu złośliwego kodu:

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

Poczekaj na zwrócenie Accepted, co oznacza, że notaryzacja przeszła.

Krok 5: Zszyj bilet notaryzacji do aplikacji

Po zszyciu użytkownicy mogą przejść weryfikację nawet przy otwieraniu offline:

xcrun stapler staple "YourApp.app"
# Sprawdź, czy się powiodło
xcrun stapler validate "YourApp.app"

Testowanie wewnętrzne / dystrybucja w intranecie przedsiębiorstwa (alternatywa)

Jeśli nie masz jeszcze konta dewelopera Apple, możesz dystrybuować w intranecie przy użyciu następującego podejścia:

Ograniczenie:

To podejście dotyczy tylko transferu w intranecie. Pobieranie przez przeglądarkę ponownie doda atrybut kwarantanny, powodując ponowne pojawienie się błędu bundle i nie nadaje się do dystrybucji publicznej.

Typowe pułapki

Podsumowanie

Jedyne standardowe rozwiązanie dla dystrybucji publicznej = Apple Developer ID + głębokie codesign + notaryzacja notarytool + bilet stapler. Po ukończeniu użytkownicy pobierają i używają natychmiast, bez okna bezpieczeństwa i bez odczuwania problemu.