Gids voor macOS-ontwikkelingsmachtigingsproblemen

Omdat de LCC Unity SDK een webP-decoderingsbibliotheek van derden gebruikt, kun je bij het gebruik van de SDK op macOS de fout "Failed to open xxx.bundle" tegenkomen. Dit is het beveiligingsmechanisme van macOS (Gatekeeper) dat niet-gecertificeerde plug-ins van derden blokkeert om uit te voeren, en heeft niets te maken met Unity of de SDK zelf.

Deze gids bestaat uit twee delen:

• Deel 1: Machtigingsproblemen met bibliotheken van derden tijdelijk oplossen in de ontwikkelomgeving.
• Deel 2: De formele oplossing bij het verpakken van een applicatie (voor openbare distributie).

Deel 1: Machtigingsproblemen met bibliotheken van derden tijdelijk oplossen in de ontwikkelomgeving

De volgende methoden zijn bedoeld om de bundle-beperking tijdens de ontwikkeling snel te verwijderen; probeer ze in volgorde van prioriteit.

Methode 1: Rechtstreeks toestaan in Systeeminstellingen (snelste)

Methode 2: Het quarantainekenmerk verwijderen via Terminal (meest grondige)

macOS voegt het quarantainekenmerk com.apple.quarantine toe aan bestanden die van het netwerk zijn gedownload; je kunt dit rechtstreeks met een Terminal-opdracht verwijderen.

Tip:

Deze opdracht vereist beheerdersrechten (sudo). Het scherm toont niets terwijl je het wachtwoord typt; typ het gewoon volledig en druk op Enter.

Methode 3: Uitvoerrechten toevoegen (aanvullend)

Als methode 1 en 2 nog steeds niet werken, voeg dan uitvoerrechten toe aan de bundle:

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

Je kunt het bundle-bestand ook naar de Terminal slepen om het pad automatisch aan te vullen, op Enter drukken en Unity opnieuw starten.

Methode 4: De platforminstellingen van de Unity-plug-in controleren

Vink Any Platform of macOS aan bij Platforminstellingen in de Inspector

Methode 5: Gatekeeper tijdelijk uitschakelen (laatste redmiddel)

Waarschuwing:

Deze methode verlaagt de systeembeveiliging. Het wordt alleen aanbevolen voor tijdelijk gebruik op een ontwikkelmachine; zorg ervoor dat je deze na afloop van de ontwikkeling weer inschakelt.

Als geen van de bovenstaande methoden werkt, kun je de systeembeveiligingsverificatie tijdelijk uitschakelen:

sudo spctl --master-disable

Controleer of deze is uitgeschakeld:

spctl --status
# assessments disabled wordt weergegeven wanneer het uitschakelen is geslaagd

Schakel de beveiliging na afloop van de ontwikkeling weer in:

sudo spctl --master-enable

Deel 2: Machtigingsproblemen met bibliotheken van derden oplossen bij het verpakken van een applicatie

Om eindgebruikers een applicatie met een SDK van derden te laten gebruiken zonder dat zij het probleem opmerken, moet je aan de ontwikkelaarszijde "diepe code-ondertekening + Apple-notarisatie + Staple-ticketbinding" voltooien. Dit is de enige conforme standaardoplossing op macOS zonder gebruikersbewerkingen.

Vereisten (allemaal vereist)

Volledige workflow voor ondertekening en notarisatie

Stap 1: Uitgebreide kenmerken wissen

xattr -cr "YourApp.app"

Stap 2: Diepe recursieve ondertekening

De parameter --deep doorloopt automatisch alle interne .bundle-, .dylib- en .framework-bestanden en ondertekent deze uniform, waardoor het probleem dat bundels van derden worden geblokkeerd omdat ze niet zijn ondertekend, grondig wordt opgelost.

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

Kernpunt:

Vervang YourCompany (TeamID) door je volledige Developer ID. Het gebruik van --deep zorgt ervoor dat alle interne bundels van derden worden ondertekend — dit is de hoofdoorzaak van 90% van de problemen waarbij "het na ondertekening nog steeds fouten geeft".

Stap 3: Een standaard zip verpakken voor notarisatie

Je moet de ditto-opdracht gebruiken om te verpakken; gebruik niet de systeemcompressie via rechtsklikken (anders mislukt de notarisatieverificatie).

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

Stap 4: Uploaden naar Apple voor notarisatie

Gebruik notarytool (de officiële nieuwe tool) om in te dienen voor notarisatie; de backend van Apple scant automatisch op schadelijke code:

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

Wacht tot Accepted wordt geretourneerd, wat betekent dat de notarisatie is geslaagd.

Stap 5: Het notarisatieticket in de app vastnieten

Na het vastnieten kunnen gebruikers de verificatie ook offline doorstaan:

xcrun stapler staple "YourApp.app"
# Controleer of het is gelukt
xcrun stapler validate "YourApp.app"

Interne tests / distributie binnen het bedrijfsintranet (alternatief)

Als je nog geen Apple-ontwikkelaarsaccount hebt, kun je binnen het intranet distribueren met de volgende benadering:

Beperking:

Deze benadering geldt alleen voor overdracht binnen het intranet. Browserdownloads voegen het quarantainekenmerk opnieuw toe, waardoor de bundle-fout opnieuw optreedt, en is niet geschikt voor openbare distributie.

Veelvoorkomende valkuilen

Samenvatting

De enige standaardoplossing voor openbare distributie = Apple Developer ID + diepe codesign + notarytool-notarisatie + stapler-ticket. Na voltooiing downloaden gebruikers de app en gebruiken deze direct, zonder beveiligingsdialoog en zonder dat zij het probleem opmerken.