Anleitung zu macOS-Berechtigungsproblemen in der Entwicklung

Da das LCC Unity SDK eine WebP-Decodierungsbibliothek eines Drittanbieters verwendet, kann bei der Verwendung des SDK unter macOS der Fehler „Failed to open xxx.bundle“ auftreten. Dabei handelt es sich um den Sicherheitsmechanismus von macOS (Gatekeeper), der nicht zertifizierte Drittanbieter-Plugins am Ausführen hindert; dies hat nichts mit Unity oder dem SDK selbst zu tun.

Diese Anleitung besteht aus zwei Teilen:

• Teil 1: Berechtigungsprobleme von Drittanbieter-Bibliotheken in der Entwicklungsumgebung vorübergehend beheben.
• Teil 2: Die formale Lösung beim Paketieren einer Anwendung (für die öffentliche Verteilung).

Teil 1: Berechtigungsprobleme von Drittanbieter-Bibliotheken in der Entwicklungsumgebung vorübergehend beheben

Die folgenden Methoden dienen zum schnellen Entfernen der Bundle-Beschränkung während der Entwicklung; probieren Sie sie in der Reihenfolge ihrer Priorität aus.

Methode 1: Direkt in den Systemeinstellungen zulassen (am schnellsten)

Methode 2: Das Quarantäne-Attribut über das Terminal entfernen (am gründlichsten)

macOS fügt aus dem Netzwerk heruntergeladenen Dateien das Quarantäne-Attribut com.apple.quarantine hinzu; Sie können es direkt mit einem Terminal-Befehl entfernen.

Tipp:

Dieser Befehl erfordert Administratorrechte (sudo). Während Sie das Passwort eingeben, zeigt der Bildschirm nichts an; geben Sie es einfach zu Ende ein und drücken Sie die Eingabetaste.

Methode 3: Ausführungsberechtigungen hinzufügen (ergänzend)

Wenn die Methoden 1 und 2 immer noch nicht funktionieren, fügen Sie dem Bundle Ausführungsberechtigungen hinzu:

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

Sie können die Bundle-Datei auch in das Terminal ziehen, um den Pfad automatisch zu vervollständigen, die Eingabetaste drücken und Unity neu starten.

Methode 4: Die Unity-Plugin-Plattformeinstellungen prüfen

Any Platform oder macOS unter Plattformeinstellungen im Inspektor aktivieren

Methode 5: Gatekeeper vorübergehend deaktivieren (letzter Ausweg)

Warnung:

Diese Methode verringert die Systemsicherheit. Sie wird nur für die vorübergehende Verwendung auf einem Entwicklungsrechner empfohlen; aktivieren Sie sie nach Abschluss der Entwicklung unbedingt wieder.

Wenn keine der oben genannten Methoden funktioniert, können Sie die Systemsicherheitsprüfung vorübergehend deaktivieren:

sudo spctl --master-disable

Überprüfen Sie, ob sie deaktiviert ist:

spctl --status
# Bei erfolgreicher Deaktivierung wird „assessments disabled“ angezeigt

Aktivieren Sie den Sicherheitsschutz nach Abschluss der Entwicklung wieder:

sudo spctl --master-enable

Teil 2: Berechtigungsprobleme von Drittanbieter-Bibliotheken beim Paketieren einer Anwendung beheben

Damit Endbenutzer eine Anwendung mit einem Drittanbieter-SDK ohne Wahrnehmung des Problems verwenden können, müssen Sie auf Entwicklerseite „Tiefensignierung + Apple-Notarisierung + Staple-Ticket-Bindung“ abschließen. Dies ist die einzige konforme Standardlösung unter macOS mit null Benutzeroperationen.

Voraussetzungen (alle erforderlich)

Vollständiger Signierungs- und Notarisierungsablauf

Schritt 1: Erweiterte Attribute löschen

xattr -cr "YourApp.app"

Schritt 2: Tiefe rekursive Signierung

Der Parameter --deep durchläuft automatisch alle internen .bundle-, .dylib- und .framework-Dateien und signiert sie einheitlich, wodurch das Problem, dass Drittanbieter-Bundles wegen fehlender Signierung blockiert werden, gründlich gelöst wird.

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

Wichtiger Punkt:

Ersetzen Sie YourCompany (TeamID) durch Ihre vollständige Developer ID. Die Verwendung von --deep stellt sicher, dass alle internen Drittanbieter-Bundles signiert sind — dies ist die Ursache für 90 % der Probleme „nach der Signierung treten weiterhin Fehler auf“.

Schritt 3: Ein Standard-Zip für die Notarisierung paketieren

Sie müssen zum Paketieren den Befehl ditto verwenden; verwenden Sie nicht die System-Rechtsklick-Komprimierung (andernfalls schlägt die Notarisierungsprüfung fehl).

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

Schritt 4: Zur Notarisierung an Apple hochladen

Verwenden Sie notarytool (das offizielle neue Tool), um die Notarisierung einzureichen; das Backend von Apple scannt automatisch auf Schadcode:

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

Warten Sie auf die Rückgabe von Accepted, was bedeutet, dass die Notarisierung bestanden wurde.

Schritt 5: Das Notarisierungs-Ticket in die App stapeln

Nach dem Stapling können Benutzer die Prüfung auch beim Offline-Öffnen bestehen:

xcrun stapler staple "YourApp.app"
# Überprüfen, ob es erfolgreich war
xcrun stapler validate "YourApp.app"

Interne Tests / Verteilung im Unternehmens-Intranet (Alternative)

Wenn Sie noch kein Apple-Entwicklerkonto haben, können Sie wie folgt im Intranet verteilen:

Einschränkung:

Dieser Ansatz gilt nur für die Intranet-Übertragung. Browser-Downloads fügen das Quarantäne-Attribut erneut hinzu, wodurch der Bundle-Fehler erneut auftritt, und ist nicht für die öffentliche Verteilung geeignet.

Häufige Fallstricke

Zusammenfassung

Die einzige Standardlösung für die öffentliche Verteilung = Apple Developer ID + tiefes codesign + notarytool-Notarisierung + stapler-Ticket. Nach Abschluss laden Benutzer die App herunter und verwenden sie sofort, ohne Sicherheitsdialog und ohne Wahrnehmung des Problems.