Search Issue Tracker

Fixed in 2020.1.9f1

Fixed in 2019.4.X, 2020.1.X, 2020.2.X, 2021.1.X



Found in


Issue ID




[macOS] Code Signing using '--deep' flag Fails on Built Package due to incorrect case in built Contents/PlugIns folder



When building a macOS package for the game, which now needs to be signed and notarized, Unity adds a 'Plugins' folder to the Contents folder. This folder should be called 'PlugIns' (see - `Table 3 Standard locations for code inside a bundle`). As such when signing using the `--deep` flag the libraries in the 'Plugins' folder are not signed.

1. Open attached project ""
2. Build macOS standalone
3. In finder navigate to built player > right-click > Show Package Contents
4. Go to Contents/ folder
Expected: there is a PlugIns folder (capital I)
Actual: the folder name is Plugins (lowercase i)

Reproduced with: 2017.4.37f1, 2018.54, 2020.1.0a25

  1. Response avatar

    Resolution Note (fix version 2021.1):

    fixed in 2021.1.1f1

  2. Response avatar

    Resolution Note (fix version 2020.2):

    fixed in 2020.2.5f1

Comments (2)

  1. D0845e73bbd64eb9b1ad7d5bb2461396?d=mm


    Sep 25, 2020 10:20

    On 2019.4.9f1 and lower, we were doing this:

    1. Manually codesign everything inside "Contents/Plugins" and inside any subdirectory/framework within "Contents/Frameworks" (for example, "Chromium Embedded Framework")
    2. codesign --deep at the top level (i.e. codesign --deep
    3. Bundle that app into another app generated by an Xcode project (Unity app sits inside "Data" within the parent app). XCode handles signing the parent app using normal xcodebuild behaviour.
    4. pkgbuild and productbuild to make a .pkg, and then that is sent for Notarization.

    This all worked fine.

    Since we upgraded to 2020.1.6f1 however, "Contents/Plugins" has changed to "Contents/PlugIns" as-per this ticket.

    Now, whether you manually codesign Contents/PlugIns or not (we assume that we must still manually sign all libs inside it because Unity doesn't do our signing as part of the build process), Notarization now fails due to "The signature of the binary is invalid.".

    The only way to make Notarization pass is to rename the directory back to Plugins with a lower-case "i".

    codesign -vvvv at any of the XCode-generated parent app, or the Unity-generated app passes and shows a valid certificate (and the same Developer ID certificate is used across the entire signing process and hasn't changed between 2019.4 and 2020.1), as does spctl --assess when run locally.

    I expect the problem may be that Apple's documentation says this directory must be PlugIns, but in reality they've changed it.

  2. 5425fa6185bf2dc77376d87d94925979?d=mm


    Sep 25, 2020 09:53

    This fix seems to break Notarization for us (2020.1.6), we've had to rename the folder back to Plugins (lowercase i).

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.