Unity builds for StandaloneOSX are not runnable.

[dyarosla]

When building for StandaloneOSX, the resultant file uploaded to artifacts isn't runnable.

If you add executable permissions to the artifact the project can then be run.

chmod +x [PATH-TO-ARTIFACT]/StandaloneOSX/StandaloneOSX.app/Contents/MacOS/*

I'm not entirely sure where this would be added in the build pipeline, but I imagine these permissions should be added prior to artifact upload.

[webbertakken]

Hi @dyarosla,

Thanks for reporting this.

I guess this should be run after the creation of the build, at the end of build.sh, only for OSX Standalone and Linux Standalone builds, as the Windows Standalone build seems to be fine.

Feel free to draft a pull request!

[dyarosla]

Yeah that would be a good spot for it as the build target is all set up there already. That said, don't know how you'd prefer to separate compile-target specific code.

[webbertakken]

You will have to use BUILD_TARGET variable which is passed in here and match it for one of the platforms in the platform model class

[mastef]

So not sure if there's a regression happening, but it was not runnable for me with a recent build ( LSOpenURLsWithRole() failed with error -10810 for the file /Downloads/Build/StandaloneOSX/StandaloneOSX.app.

I needed to chmod +x everything manually for now. I documented that regression in the PR #99 (comment)

@nathanleiby @webbertakken so I recently tried the MacOS build, and the resulting StandaloneOSX.app and the StandaloneOSX.app/Contents/MacOS/ProgramName were not executable. So double-clicking on the StandaloneOSX.app would come up with an error :

Trying to run it through terminal, would throw this error :

$ open StandaloneOSX.app/
LSOpenURLsWithRole() failed with error -10810 for the file /Downloads/Build/StandaloneOSX/StandaloneOSX.app.

After running chmod +x on both of them, I was able to open the app.

Maybe a regression is happening? Or the chmod +x is getting lost in the .zip?

[GabLeRoux]

@mastef I reproduced your exact same error.

I did reproduce the issue where StandaloneOSX's executable needs to be chmod +x for the app to start. I wonder what's going on. Tested with recent 2020.1.7f1 version on a very simple project here:
https://github.com/Unity-CI/unity-actions-example

edit: oh, I used unity-ci.com docs and I was using older versions. I just saw related PR which was merged. Pushed game-ci/unity-actions-example@e65839d and I'll see what happens

[GabLeRoux]

I tried again with -nographics and @master (which uses unitybuilder@v1.4 right now) and I also reproduced LSOpenURLsWithRole() failed with error -10810 for the file /Downloads/Build/StandaloneOSX/StandaloneOSX.app. here: https://github.com/Unity-CI/unity-actions-example/tree/9f0672b9e4a79c738bcf2814c6a893cd66e196d5.

@webbertakken there seem to be a regression. I'll spin a matrix with all unity-builder and try to locate the regression

[aidan-waite]

Incase it's useful, I ran into this issue today (The application “StandaloneOSX” can’t be opened) and doing chmod +x StandaloneOSX.app/Contents/MacOS/* in terminal solved the issue. Mac OS 10.15.7

[webbertakken]

There was a commit reverted that should solve this problem.

Please confirm.

[jsm174]

Should this be fixed in webbertakken/unity-builder@v2.0-aplha-5?

I am seeing this issue as well.

[webbertakken]

Yea it should have been, but perhaps there's still something wrong.

We had reverted some user permissions as far as I remember, but yea I also think we should give the executable bit to the file prior to uploading if it doesn't already.

Accepting PRs for this.

[Zetonia]

Is this still an issue, since updating I am seeing our app is damaged. Tried the above solutions but they do not work.

[webbertakken]

If you use the default build path it should work.

If it doesn't we'd appreciate any help to debug the issue.

[mastef]

I'm running this command before creating the dmg :

      - name: Restore executable permissions
        run: |
          find StandaloneOSX -type f -iname "MapFileParser" -exec chmod +x {} \;
          find StandaloneOSX -type f -iname "*.sh" -exec chmod +x {} \;
          find StandaloneOSX -type f -iname "usymtool" -exec chmod +x {} \;
          find StandaloneOSX -type f -iname "lzma" -exec chmod +x {} \;

[Zetonia]

None of the above worked for me however I did notice with the downloaded application that it has extra attributes when running

ls -la
drwxr-xr-x@ 3 <Zetonia>  staff    96 11 Mar 01:26 zetonia.app
	com.apple.quarantine	  57 

If i run the following command on the file then it opens fine.

xattr -d com.apple.quarantine zetonia.app

[webbertakken]

Should we be removing the extended attributes? What's your view on this?

[Zetonia]

OK - I managed to pull the docker images locally and build my project (rather than on gitlab ci) and they have no issue.
Doing some reading it looks like when apps are zipped then the latest release of MacOS has an issue and quarantines them reference1., reference2.

Looks like we can get around this by Notarizing the builds reference.

[davidmfinol]

It sounds like distributing a macOS app pretty much now requires going through the codesign process. I believe the initial issue (builds not runnable without chmod +x path/to/executable) has been fixed, so maybe we should close this issue and open a new issue for documentation about macOS distribution? We may want to create a docs/github/deployment/macos page that goes into codesign, notarization, and maybe even fastlane for mac apps.

[webbertakken]

Feel free to reopen for issues related to not being runnable.

[Zetonia]

For reference found this issue on the unity tracker -> https://issuetracker.unity3d.com/issues/macos-builds-now-contain-a-quarantine-attribute and also a mention of it being fixed in https://unity3d.com/unity/beta/2021.1.0b8

[jamescrowley]

I just encountered this "The application XXXX.app can't be opened" for the first time building our app on MacOS. The command that worked for me, mentioned here https://issuetracker.unity3d.com/issues/macos-builds-now-contain-a-quarantine-attribute was running both these commands:

xattr -rc XXXX.app
chmod +x XXXX.app/Contents/MacOS/*

Anyone have an idea why this would still be an issue?

[jamescrowley]

If anyone finds this on Google like I did, there's a more up to date issue discussing this here: game-ci/documentation#262