macOS Development Permission Issue Guide

Because the LCC Unity SDK uses a third-party webP decoding library, you may encounter the "Failed to open xxx.bundle" error when using the SDK on macOS. This is macOS's security mechanism (Gatekeeper) blocking uncertified third-party plugins from running, and has nothing to do with Unity or the SDK itself.

This guide has two parts:

• Part 1: Temporarily resolve third-party library permission issues in the development environment.
• Part 2: The formal solution when packaging an application (for public distribution).

Part 1: Temporarily Resolve Third-party Library Permission Issues in the Development Environment

The following methods apply to quickly removing the bundle restriction during development; try them in order of priority.

Method 1: Allow directly in System Settings (fastest)

Method 2: Remove the quarantine attribute via Terminal (most thorough)

macOS adds the com.apple.quarantine quarantine attribute to files downloaded from the network; you can remove it directly with a Terminal command.

Tip:

This command requires administrator privileges (sudo). The screen will not show anything while you type the password; just finish typing and press Enter.

Method 3: Add executable permissions (supplementary)

If Methods 1 and 2 still do not work, add executable permissions to the bundle:

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

You can also drag the bundle file into the Terminal to auto-complete the path, press Enter, and restart Unity.

Method 4: Check Unity plugin platform settings

Check Any Platform or macOS in Platform Settings in the Inspector

Method 5: Temporarily disable Gatekeeper (last resort)

Warning:

This method reduces system security. It is only recommended for temporary use on a development machine; be sure to re-enable it after development is complete.

If none of the above methods work, you can temporarily disable system security verification:

sudo spctl --master-disable

Verify whether it is disabled:

spctl --status
# assessments disabled is shown when disabled successfully

Re-enable security protection after development is complete:

sudo spctl --master-enable

Part 2: Resolve Third-party Library Permission Issues When Packaging an Application

To let end users use an application containing a third-party SDK with no perception of the issue, you must complete "deep code signing + Apple notarization + Staple ticket binding" on the developer side. This is the only compliant standard solution on macOS with zero user operations.

Prerequisites (all required)

Complete Signing and Notarization Workflow

Step 1: Clear extended attributes

xattr -cr "YourApp.app"

Step 2: Deep recursive signing

The --deep parameter automatically traverses all internal .bundle, .dylib, and .framework files and signs them uniformly, thoroughly solving the problem of third-party bundles being blocked for being unsigned.

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

Key point:

Replace YourCompany (TeamID) with your full Developer ID. Using --deep ensures all internal third-party bundles are signed — this is the root cause of 90% of the "still errors after signing" issues.

Step 3: Package a standard zip for notarization

You must use the ditto command to package; do not use the system right-click compression (otherwise the notarization verification will fail).

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

Step 4: Upload to Apple for notarization

Use notarytool (the official new tool) to submit for notarization; Apple's backend automatically scans for malicious code:

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

Wait for Accepted to be returned, which means notarization passed.

Step 5: Staple the notarization ticket into the App

After stapling, users can pass verification even when opening offline:

xcrun stapler staple "YourApp.app"
# Verify whether it succeeded
xcrun stapler validate "YourApp.app"

Internal Testing / Enterprise Intranet Distribution (alternative)

If you do not yet have an Apple developer account, you can distribute within the intranet using the following approach:

Limitation:

This approach only applies to intranet transfer. Browser downloads will re-add the quarantine attribute, causing the bundle error to reappear, and is not suitable for public distribution.

Common Pitfalls

Summary

The only standard solution for public distribution = Apple Developer ID + deep codesign + notarytool notarization + stapler ticket. After completion, users download and use it immediately, with no security dialog and no perception of the issue.