Guide des problèmes d'autorisation de développement macOS

Comme le LCC Unity SDK utilise une bibliothèque de décodage webP tierce, vous pouvez rencontrer l'erreur « Failed to open xxx.bundle » lors de l'utilisation du SDK sur macOS. Il s'agit du mécanisme de sécurité de macOS (Gatekeeper) qui bloque l'exécution de plugins tiers non certifiés, et cela n'a rien à voir avec Unity ou le SDK lui-même.

Ce guide comporte deux parties :

• Partie 1 : Résoudre temporairement les problèmes d'autorisation des bibliothèques tierces dans l'environnement de développement.
• Partie 2 : La solution formelle lors du packageage d'une application (pour la distribution publique).

Partie 1 : Résoudre temporairement les problèmes d'autorisation des bibliothèques tierces dans l'environnement de développement

Les méthodes suivantes s'appliquent pour supprimer rapidement la restriction du bundle pendant le développement ; essayez-les par ordre de priorité.

Méthode 1 : Autoriser directement dans les réglages système (la plus rapide)

Méthode 2 : Supprimer l'attribut de quarantaine via le Terminal (la plus complète)

macOS ajoute l'attribut de quarantaine com.apple.quarantine aux fichiers téléchargés depuis le réseau ; vous pouvez le supprimer directement avec une commande du Terminal.

Conseil :

Cette commande nécessite des privilèges administrateur (sudo). L'écran n'affichera rien pendant que vous tapez le mot de passe ; terminez simplement de taper et appuyez sur Entrée.

Méthode 3 : Ajouter des autorisations d'exécution (complémentaire)

Si les méthodes 1 et 2 ne fonctionnent toujours pas, ajoutez des autorisations d'exécution au bundle :

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

Vous pouvez également faire glisser le fichier bundle dans le Terminal pour compléter automatiquement le chemin, appuyer sur Entrée et redémarrer Unity.

Méthode 4 : Vérifier les paramètres de plateforme du plugin Unity

Cocher Any Platform ou macOS dans Platform Settings dans l'Inspecteur

Méthode 5 : Désactiver temporairement Gatekeeper (dernier recours)

Avertissement :

Cette méthode réduit la sécurité du système. Elle n'est recommandée que pour une utilisation temporaire sur une machine de développement ; assurez-vous de le réactiver une fois le développement terminé.

Si aucune des méthodes ci-dessus ne fonctionne, vous pouvez désactiver temporairement la vérification de sécurité du système :

sudo spctl --master-disable

Vérifiez s'il est désactivé :

spctl --status
# assessments disabled s'affiche lorsqu'il est désactivé avec succès

Réactivez la protection de sécurité une fois le développement terminé :

sudo spctl --master-enable

Partie 2 : Résoudre les problèmes d'autorisation des bibliothèques tierces lors du packageage d'une application

Pour permettre aux utilisateurs finaux d'utiliser une application contenant un SDK tiers sans percevoir le problème, vous devez effectuer « signature profonde du code + notarisation Apple + liaison du ticket Staple » côté développeur. C'est la seule solution standard conforme sur macOS avec zéro opération utilisateur.

Prérequis (tous requis)

Flux de travail complet de signature et de notarisation

Étape 1 : Effacer les attributs étendus

xattr -cr "YourApp.app"

Étape 2 : Signature récursive profonde

Le paramètre --deep parcourt automatiquement tous les fichiers internes .bundle, .dylib et .framework et les signe uniformément, résolvant complètement le problème des bundles tiers bloqués pour être non signés.

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

Point clé :

Remplacez YourCompany (TeamID) par votre Developer ID complet. L'utilisation de --deep garantit que tous les bundles tiers internes sont signés — c'est la cause racine de 90 % des problèmes « erreurs toujours après signature ».

Étape 3 : Packager un zip standard pour la notarisation

Vous devez utiliser la commande ditto pour packager ; n'utilisez pas la compression par clic droit du système (sinon la vérification de notarisation échouera).

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

Étape 4 : Téléverser vers Apple pour la notarisation

Utilisez notarytool (le nouvel outil officiel) pour soumettre à la notarisation ; le backend d'Apple analyse automatiquement le code malveillant :

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

Attendez que Accepted soit retourné, ce qui signifie que la notarisation a réussi.

Étape 5 : Agrafer le ticket de notarisation dans l'App

Après l'agrafage, les utilisateurs peuvent passer la vérification même en s'ouvrant hors ligne :

xcrun stapler staple "YourApp.app"
# Vérifier s'il a réussi
xcrun stapler validate "YourApp.app"

Tests internes / distribution intranet d'entreprise (alternative)

Si vous n'avez pas encore de compte développeur Apple, vous pouvez distribuer au sein de l'intranet en utilisant l'approche suivante :

Limitation :

Cette approche ne s'applique qu'au transfert intranet. Les téléchargements par navigateur ajouteront à nouveau l'attribut de quarantaine, provoquant la réapparition de l'erreur de bundle, et n'est pas adaptée à la distribution publique.

Pièges courants

Résumé

La seule solution standard pour la distribution publique = Apple Developer ID + codesign profond + notarisation notarytool + ticket stapler. Une fois terminé, les utilisateurs téléchargent et utilisent immédiatement, sans boîte de dialogue de sécurité et sans perception du problème.