Creating a build of StandaloneOSX it doesn't work on Mac with M1 chip

[danitseitlin]

Bug description
When creating a build of StandaloneOSX it doesn't work on Mac with M1 chip

How to reproduce
build a StandaloneOSX and try to run on Macbook with M1 chip

*Expected behavior:
The game starts

Additional details

[webbertakken]

Could you please be slightly more descriptive? Are you building on a Mac runner with M1 chip or are you trying to execute the resulting artifact after a successful build on a Mac with M1?

Can you speak for whether your other builds work etc.?

[danitseitlin]

@webbertakken I am trying to run the artifact on a Macbook with M1 Chip.
I am getting this:

Other builds for Windows64bit works.

[davidmfinol]

Does it work on an intel mac?
Have you tried chmod +x to confirm it isn't a permissions issue?
Are you able to get it to work with a simple project that only has a small sample scene in it?

[danitseitlin]

@davidmfinol I don't have an intel mac to test on. but I did build this project previously on the Apple silicone Mac via the Unity Hub and it works great.
I attempted the permissions and it doens't seem to fix the issue.

[danitseitlin]

Also, is this a correct way to specific unity version:

- uses: game-ci/unity-builder@v2
      env:
        UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
      with:
        targetPlatform: StandaloneOSX
        unityVersion: 2020.3.26f1
        allowDirtyBuild: true

[webbertakken]

Actually we recommend not specifying unityVersion, so that builder can pick up the version from your project automatically.
Building for a different version than your project is saved in may have undesired results.

Note that we also don't recommend using allowDirtyBuild parameter unless absolutely necessary for your workflow.
Building a project based on files that differ from your version control may also have undesired results.

[danitseitlin]

@webbertakken Then I don't know how to fix the issue, from what I read the version I am using (and is specified in the project) should by default support both Silicion CPU and Intel CPU by default. Therefore, it should work.

[webbertakken]

Not sure if you do, but in case you have an M1 yourself, could you try running your (local working) editor to build your project from CLI to see if CLI generated builds works at all on it?

We don't do much more than packaging the editor in a container image, not much special at all either.

[danitseitlin]

@webbertakken How do I do that?

[webbertakken]

Here's an example command, that we use inside unity-builder itself.

unity-builder/dist/platforms/ubuntu/steps/build.sh

Lines 128 to 144 in 4e38a84

	unity-editor \
	-logfile /dev/stdout \
	-quit \
	-customBuildName "$BUILD_NAME" \
	-projectPath "$UNITY_PROJECT_PATH" \
	-buildTarget "$BUILD_TARGET" \
	-customBuildTarget "$BUILD_TARGET" \
	-customBuildPath "$CUSTOM_BUILD_PATH" \
	-executeMethod "$BUILD_METHOD" \
	-buildVersion "$VERSION" \
	-androidVersionCode "$ANDROID_VERSION_CODE" \
	-androidKeystoreName "$ANDROID_KEYSTORE_NAME" \
	-androidKeystorePass "$ANDROID_KEYSTORE_PASS" \
	-androidKeyaliasName "$ANDROID_KEYALIAS_NAME" \
	-androidKeyaliasPass "$ANDROID_KEYALIAS_PASS" \
	-androidTargetSdkVersion "$ANDROID_TARGET_SDK_VERSION" \
	$CUSTOM_PARAMETERS

Here's also the build script that we use (with $BUILD_METHOD) in case you don't have your own build script.

[ewrogers]

I'm also having this issue with running builds on my M1 MacBook Pro, with essentially a "Hello World" Unity 2D project (URP). Nothing fancy and I'm using the same Github action definitions as the Getting Started guide from Game CI.

On my local machine I am using the 2021.2.16f1 Silicon build, not the Intel one. I suspect this is where the issue may lie. Even though M1 chips should be able to run the x86 builds via Rosetta 2, not sure why this breaks with Mono builds.

I have a feeling this may be related to running the builder under Linux trying to build for Mac versus running the editor natively on macOS + Silicon hardware. Probably some M1 growing pains or cross-compiliation.

[ewrogers]

Here's the workflow for those wondering:

name: Build project

on: [push, pull_request]

jobs:
  buildForDesktop:
    name: Build for ${{ matrix.targetPlatform }}
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        targetPlatform:
          - StandaloneOSX
          - StandaloneWindows64
          - StandaloneLinux64
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
          lfs: true
      
      - uses: actions/cache@v2
        with:
          path: Library
          key: Library-${{ matrix.targetPlatform }}
          restore-keys: Library-

      - uses: game-ci/unity-builder@v2
        env:
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
        with:
          targetPlatform: ${{ matrix.targetPlatform }}

      - uses: actions/upload-artifact@v2
        with:
          name: Build-${{ matrix.targetPlatform }}
          path: build/${{ matrix.targetPlatform }}

[davidmfinol]

My understanding is that Unity has 3 architecture options for macOS builds:

1. Intel
2. Apple Silicon
3. Intel + Apple Silicon

By default, Unity (and therefore also unity-builder) will use 'Intel + Apple Silicon', which should typically work for both, at the cost of a slightly larger build.
However, you could be using a library that only works on one or the other, so maybe you only want to build just for Apple Silicon.
We don't currently have a clean solution for targeting just Apple Silicon, but maybe you can try using a custom buildMethod (see the docs, in particular, you may want to modify the default build script at line 48) with the workaround mentioned in these links:
https://dev.to/clpsplug/how-to-force-unity-to-target-x64-or-arm64-for-macos-builds-2e5a
https://forum.unity.com/threads/cloud-build-defaulting-to-intel-64-bit-apple-silicon-dlls-failing-in-macos-build.1066970/

[ewrogers]

My project is pretty simple and as mentioned I've tried this with a simple project with default package dependencies. I get this:

I thought it might be a corrupted file or something, but the "Show Package Contents" works to display what's inside:

So I did some digging using otool -L StandaloneOSX.app/Contents/Frameworks/UnityPlayer.dylib and it does indeed have both executables inside:

StandaloneOSX.app/Contents/Frameworks/UnityPlayer.dylib (architecture x86_64)
StandaloneOSX.app/Contents/Frameworks/UnityPlayer.dylib (architecture arm64)

I will continue to dig further and figure this out.

Looks like here's the error from the terminal when opening:

$ open ~/Downloads/StandaloneOSX.app

The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x6000003ce070 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}

And digging into the Console logs:

handle LS launch error: {\n    Action = oapp;\n    AppMimimumSystemVersion = "10.13";\n    AppPath = "/Users/erik/Downloads/StandaloneOSX.app";\n    ErrorCode = "-10810";\n}

[ewrogers]

Alright, seems it's a macOS permissions issue that started in Catalina. Not a M1 issue in particular.

To fix it:

chmod +x ~/Downloads/StandaloneOSX.app/Contents/MacOS/<app>
xattr -d com.apple.quarantine ~/Downloads/StandaloneOSX.app/Contents/MacOS/<app>

Seems to be a macOS specific code-signing issues which would explain why building + running locally does not have this issue (it can self-sign using your keychain). For proper builds maybe have to integrate the codesign utility, which I am not sure it can be done outside of a macOS environment.

Some info here: https://gist.github.com/dpid/270bdb6c1011fe07211edf431b2d0fe4

I'm still a bit new to Github actions, mostly my experience is in GitLab CI. But I guess you'd need another post-build stage that takes the Build artifact and signs it using runs-on: mac and have some way to add keychain/certs as secrets. Or some way to auth/pull them from the Apple dev portal.

EDIT: Looks like it may be possible to code-sign on non-Mac platforms: https://crates.io/crates/apple-codesign
However, there is also the need to notarize the app which is another step and an open request: indygreg/PyOxidizer#381

[davidmfinol]

If it helps, this is what I use to codesign my macOS builds: https://github.com/finol-digital/Card-Game-Simulator/blob/develop/fastlane/sign-mac-build.sh

This script does need to run on a macOS runner, and you can see how I do that here too: https://github.com/finol-digital/Card-Game-Simulator/blob/develop/.github/workflows/main.yml#L274

[wedgiebee]

Alright, seems it's a macOS permissions issue that started in Catalina. Not a M1 issue in particular.

To fix it:

chmod +x ~/Downloads/StandaloneOSX.app/Contents/MacOS/<app>
xattr -d com.apple.quarantine ~/Downloads/StandaloneOSX.app/Contents/MacOS/<app>

@ewrogers I'm in the same position where my mac build won't open on my M1 Mac, but my Windows builds work fine on my Windows machine. I'm new to CI and also Mac permissions - where do I put these lines to make the M1 build work? Do they go somewhere in the Github Action workflow?

[davidmfinol]

where do I put these lines to make the M1 build work? Do they go somewhere in the Github Action workflow?

@wedgiebee You run the commands on your M1 Mac terminal. It assumes that you have downloaded the artifact in your mac's Downloads folder.

Since this issue seems to be caused permissions/code-signing, I've created a separate issue to document this process, and am closing this issue: game-ci/documentation#262

[Propagant]

If it helps, this is what I use to codesign my macOS builds: https://github.com/finol-digital/Card-Game-Simulator/blob/develop/fastlane/sign-mac-build.sh

This script does need to run on a macOS runner, and you can see how I do that here too: https://github.com/finol-digital/Card-Game-Simulator/blob/develop/.github/workflows/main.yml#L274

Thanks a bunch for providing your solution. By any chance - would it be possible to run this (with some modifications) on linux runner? Or to codesign and verify the .app is only possible on mac runners? It would be really nice to have everything setup in the build pipeline...

[davidmfinol]

If it helps, this is what I use to codesign my macOS builds: https://github.com/finol-digital/Card-Game-Simulator/blob/develop/fastlane/sign-mac-build.sh
This script does need to run on a macOS runner, and you can see how I do that here too: https://github.com/finol-digital/Card-Game-Simulator/blob/develop/.github/workflows/main.yml#L274

Thanks a bunch for providing your solution. By any chance - would it be possible to run this (with some modifications) on linux runner? Or to codesign and verify the .app is only possible on mac runners? It would be really nice to have everything setup in the build pipeline...

I don't really think it would work on Linux, since it requires Apple credentials and the codesign tool, which I would assume are only available on mac.