Guida ai problemi di autorizzazione nello sviluppo su macOS

Poiché l'LCC Unity SDK usa una libreria di decodifica webP di terze parti, potresti incontrare l'errore "Impossibile aprire xxx.bundle" quando usi l'SDK su macOS. Si tratta del meccanismo di sicurezza di macOS (Gatekeeper) che blocca l'esecuzione dei plugin di terze parti non certificati, e non ha nulla a che fare con Unity o con l'SDK stesso.

Questa guida è divisa in due parti:

• Parte 1: risolvere temporaneamente i problemi di autorizzazione delle librerie di terze parti nell'ambiente di sviluppo.
• Parte 2: la soluzione formale durante il packaging di un'applicazione (per la distribuzione pubblica).

Parte 1: risolvere temporaneamente i problemi di autorizzazione delle librerie di terze parti nell'ambiente di sviluppo

I seguenti metodi servono a rimuovere rapidamente la restrizione del bundle durante lo sviluppo; provali in ordine di priorità.

Metodo 1: consenti direttamente nelle Impostazioni di Sistema (il più rapido)

Metodo 2: rimuovi l'attributo di quarantena tramite Terminale (il più completo)

macOS aggiunge l'attributo di quarantena com.apple.quarantine ai file scaricati dalla rete; puoi rimuoverlo direttamente con un comando del Terminale.

Suggerimento:

Questo comando richiede i privilegi di amministratore (sudo). Lo schermo non mostrerà nulla mentre digiti la password; completa la digitazione e premi Invio.

Metodo 3: aggiungi i permessi di esecuzione (supplementare)

Se i Metodi 1 e 2 non funzionano ancora, aggiungi i permessi di esecuzione al bundle:

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

Puoi anche trascinare il file del bundle nel Terminale per completare automaticamente il percorso, premere Invio e riavviare Unity.

Metodo 4: verifica le impostazioni di piattaforma del plugin in Unity

Spunta Any Platform o macOS in Platform Settings nell'Inspector

Metodo 5: disattiva temporaneamente Gatekeeper (ultima risorsa)

Avviso:

Questo metodo riduce la sicurezza del sistema. È consigliato solo per un uso temporaneo su una macchina di sviluppo; assicurati di riattivarlo al termine dello sviluppo.

Se nessuno dei metodi precedenti funziona, puoi disattivare temporaneamente la verifica di sicurezza del sistema:

sudo spctl --master-disable

Verifica se è disattivata:

spctl --status
# viene mostrato assessments disabled quando la disattivazione riesce

Riattiva la protezione di sicurezza al termine dello sviluppo:

sudo spctl --master-enable

Parte 2: risolvere i problemi di autorizzazione delle librerie di terze parti durante il packaging di un'applicazione

Per consentire agli utenti finali di usare un'applicazione contenente un SDK di terze parti senza percepire il problema, devi completare "firma approfondita del codice + notarizzazione Apple + associazione del ticket Staple" lato sviluppatore. È l'unica soluzione standard conforme su macOS con zero operazioni per l'utente.

Prerequisiti (tutti obbligatori)

Flusso di lavoro completo di firma e notarizzazione

Passaggio 1: elimina gli attributi estesi

xattr -cr "YourApp.app"

Passaggio 2: firma ricorsiva approfondita

Il parametro --deep attraversa automaticamente tutti i file .bundle, .dylib e .framework interni e li firma uniformemente, risolvendo a fondo il problema dei bundle di terze parti bloccati perché non firmati.

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

Punto chiave:

Sostituisci YourCompany (TeamID) con il tuo Developer ID completo. Usando --deep garantisci che tutti i bundle di terze parti interni vengano firmati: è la causa principale del 90% dei problemi di "errore ancora presente dopo la firma".

Passaggio 3: crea uno zip standard per la notarizzazione

Devi usare il comando ditto per il packaging; non usare la compressione con il clic destro del sistema (altrimenti la verifica di notarizzazione fallirà).

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

Passaggio 4: carica su Apple per la notarizzazione

Usa notarytool (il nuovo strumento ufficiale) per inviare la richiesta di notarizzazione; il backend di Apple esegue automaticamente la scansione del codice dannoso:

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

Attendi la restituzione di Accepted, che significa che la notarizzazione è riuscita.

Passaggio 5: applica il ticket di notarizzazione all'app

Dopo l'applicazione del ticket (stapling), gli utenti possono superare la verifica anche aprendo offline:

xcrun stapler staple "YourApp.app"
# Verifica se l'operazione è riuscita
xcrun stapler validate "YourApp.app"

Test interni / distribuzione intranet aziendale (alternativa)

Se non disponi ancora di un account sviluppatore Apple, puoi distribuire all'interno dell'intranet usando il seguente approccio:

Limitazione:

Questo approccio si applica solo al trasferimento intranet. I download tramite browser aggiungeranno nuovamente l'attributo di quarantena, facendo ricomparire l'errore del bundle, e non è adatto alla distribuzione pubblica.

Errori comuni

Riepilogo

L'unica soluzione standard per la distribuzione pubblica = Apple Developer ID + codesign approfondito + notarizzazione notarytool + ticket stapler. Una volta completata, gli utenti scaricano e usano l'app immediatamente, senza alcuna finestra di dialogo di sicurezza e senza percepire il problema.