But this is the result that it should be which matches the xcode projects generated in iOS and allows bundles to be correctly signed:
Note that the correct copy phase is set to PlugIns and has ‘Code Sign on Copy’ enabled per bundle. The copy phase set to Wrapper that was added in 2019.4.8 does not allow this setting to be set on the static plugins folder and makes it impossible to compile at the moment using the mac Xcode project option. The change that addds a static plugins copy phase needs to be removed again is not correct. The solution for this should match what iOS project creation does. We have taken a copy of the PBXProject api and modified this to properly add the bundles, please reach out if it would help to get a copy of how we did this if it speeds up implementation, but as it stand this is the single biggest blocker for Unity developers that want to use the Xcode project option for Mac and because it’s a extremely technical process to modify the PBXProject properly many developers we know have given up on trying to use the xcode project for mac option because of this.
Not sure if it helps or if your issue is deeper, but I had something similar the other day and fixed it by renaming the PlugIns folder in the xcode project to Plugins (lower case i).
Thanks but no it’s more of a matter that the xcode project generated is not sufficiently code signing bundled plugins. The output folder name Unity were incorrectly using in precompiled .app builds ‘Plugins’ was recently renamed to PlugIns to match the correct mac app structure. My post processing script is adding a pass that happens to be adding a reference group in the xcode project Plugins with lowecase i, but it’s not important, it’s more to do with the output of the app and those plugins are added in the copy phase to the correctly named PlugIns folder. Without this setup xcode never signs the bundle files. If you open up an xcode project generated for iOS that uses a .bundle file it has the correct setup, the mac xcode project at the moment doesn’t, it just needs to replicate the exact same process that iOS xcode project creation uses.
While this fix correctly adds the missing copy file phase and adds bundles marked to be signed, windows based DLL files are being swept up and incorrectly added to copy phase as well which should not be there and obviously cause the xcode compiler to fail. It’s easily replicated in a new empty project by compiling with 2020.3.0, Rewired plugin added, build target set to Mac and create xcode project ticked in build settings. Trying to compile in the generated xcode project and it will fail to compile.
I’ve submitted a repro project bug report: 1321049
For now I’ve had to do this post processing workaround to remove incorrectly added DLL’s using PBXProject api:
project.RemoveFile( project.FindFileGuidByProjectPath( $“{PlayerSettings.productName}/PlugIns/SomeWindowsPlugin.dll” ) );
Note: that my workaround is not perfect though. It leaves some strange remnants in the build phase which I can’t remove without editing the project as a raw string because the PBXProject api does not have any exposed methods that allow me to remove a build file reference from build phases properly. But it removes the files enough that I can compile the project and should not cause any runtime issues…?!
Thanks =) it’s super close to being how we need it, just this one glitch. I’ve tried compiling a few different projects which have different sets of DLL files and yup it can get pretty nuts on the results where various references to unrelated editor DLL’s can be compiled into the xcode build phase. The workaround I’ve mentioned seems to be working pretty well in the meantime. Thanks for prioritzing it, cheers!
Hey, I implemented a fix for this yesterday, and hoping to get it reviewed and merged as soon as possible. Hang tight!
By the way, yesterday somebody clicked the wrong button on the bug and instead of commenting on it, they sent an email to you. Feel free to disregard it…