Unity on Apple silicon and Big Sur: Known issues and workarounds

Automatic rejection due to some signature problems. It could well be my mistake while signing it tho, but I'm following this guide, and when the binary is built using Mono, it's accepted by the App Store with no extra step (just Unity's delivery manual):

Code (Boo):

1.  
2. ITMS-90238: Invalid Signature - The executable at path Starman.app/Contents/Resources/Data/ARM64/GameAssembly.dylib has following signing error(s): valid on disk /Volumes/data01/app_data/awf/mz_12928241822325705445dir/mz_3404187745139814872dir/games.nadastudio.mac.starman.pkg/Payload/Starman.app/Contents/Resources/Data/ARM64/GameAssembly.dylib: satisfies its Designated Requirement test-requirement: code failed to satisfy specified code requirement(s) . Refer to the Code Signing and Application Sandboxing Guide at http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html and Technical Note 2206 at https://developer.apple.com/library/mac/technotes/tn2206/_index.html for more information.
3.  
4. ITMS-90238: Invalid Signature - The executable at path Starman.app/Contents/Resources/Data/x64/GameAssembly.dylib has following signing error(s): code object is not signed at all In architecture: x86_64 . Refer to the Code Signing and Application Sandboxing Guide at http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html and Technical Note 2206 at https://developer.apple.com/library/mac/technotes/tn2206/_index.html for more information.

 

It definitely helped me, thank you so much.
I used a similar process. However, instead of changing the Game Assembly Script, I just changed the Build Legacy System to the new one (On Xcode, File / Project Settings).

It also worked for release builds, but I had to add the entitlements manually, and also manually codesign every Plugin Bundle I had (which apparently didn't get signed in the process of building from Unity)

 

Hello everyone, need some help here, I need to buy a new MacBook for Mobile development (iOS and Android) should I buy the silicon one or will I have problem with compatibility issues?
Thank you, I really appreciate the experience from the ones who got the Arm Kit

 

Good question, RC2 on DTK and Unity just hangs on any window now. It may be a DTK only issue or a Unity one, Makes me wonder how Apple demo'd the Boat demo on Silicon in the promo video as I could not get it running 100% on older versions of Big Sur.

I would like to think the shipping M1 kit work out of the box.

 

Rosetta 2 is a translation layer, not an emulation layer. On Unity first run, macos will create a translated cache. I don't know the details of course but this has been pointed out by other devs. Not ideal, but still better than real-time emulation.

 

In the current state Unity 2020.2.0b11 is unusable on DTK.
- Editor constantly has screen freezes (monitor on/off gets the issue resolved)
- Built project has absolute screen freezes - monitor on/off only advances it to the latest frame.

Which version are the workarounds expected to land to?

 

This issue is being discussed here: https://forum.unity.com/threads/mac...20-2-0b6-freezing-screen.988352/#post-6424331

Working with animation window will also cause unity to freeze. Issue tracker has already been filed : https://issuetracker.unity3d.com/product/unity/issues/guid/1278810

 

Thanks for the info.
From what I understand, we have to wait for a week (based on Unity's beta roll out schedule) for a workaround to be published.

 

So, all existing Unity games built using Mono simply don't work on M1?

 

I'm getting this error every time I quit Unity.

 

So it means that Rosetta 2 can't translate old Unity games, am I right? As someone who has been using Unity 2018 on a rather big project, I hope I can get my game work on new Macs without upgrading to Unity 2020.

 

Seems games built with IL2CPP do work, but it would be nice to have confirmation. I suppose Mono and other JIT-based solutions, which generate machine code at runtime, are too much for Rosetta 2, and Apple has a tradition of not caring much about making exisiting apps work in their new OSes, placing the burden on developers to go back and update their apps.

 

Hi everyone, I've run into an issue after I updated my Macbook Pro OS from Catalina to Big Sur:

I'm currently using Unity.2019 4.10.14LTS and VFX Graph 7.5.1. I have a Procedular skybox shader in my scene that isn't running properly anymore since the new OS update. I have a [ExecuteAlways] tag so my skybox system will update in real-time so whenever I make changes to inspector it changes in edit mode. However, my Scene and Game Windows(hopefully that's the correct term)aren't updating, they appear frozen, unresponsive, and causes the text in Unity to be unreadable and jumble up. There are no error messages in my console. Whenever I open up Unity with VFX graph installed I see these warning messages in my console:

Code (CSharp):

1.  
2. Metal: Compute shader (Sort.BitonicSort4096) has 1024 threads in a threadgroup which is more than the supported max of 512 in this device
3.  
4. Metal: Compute shader (Sort.BitonicPrePass) has 1024 threads in a threadgroup which is more than the supported max of 512 in this device
5.  
6.  

When I double click on the any of the warning messages, Visual Studio will load up but it doesn't take me to any shader I have. So, I don't know where that issue came from? So, that's my issue. I'm not sure how this issue happened in the first place because this never happened in my previous OS of 10.13 Catalina. I probably shouldn't have update my OS.

 

quick question: so if cant switch between my desktop pc (windows, intel) and potential laptop macbook air m1 even if the project is on 2020.2beta?

or if someone on the team got a intel mac and the other one a m1 mac

 

Do we have any means of detecting that this is an ARM build?
The first thing that comes into my head is using __aarch64__ define in a native plugin.
Is there any other way?

 

That's a relief. The way it's written in the OP didn't make it clear the problem was only with ARM players.

 

Thank you for letting us know! I'm glad to hear it.

 

Hello,

Specs:
- Apple Development Platform, Apple A12Z Bionic
- macOS Big Sur 11.0.1 (20B29)
- Unity 2018.4.29f1

First I need to use the -noUpm command line arg in order to be able to start Unity, otherwise the Editor warns about firewall policies.
Then I create a new blank project and create a new blank script.
Unity fails compiling the script, both in standard/batchmode, with error:
Failed to initialize CoreCLR, HRESULT: 0x80004005

Is there something I need to install/configure?
Thanks.

Here's the log:
[...]
"Assets/NewBehaviourScript.cs"
-----CompilerOutput:-stdout--exitcode: 137--compilationhadfailure: True--outfile: Temp/Assembly-CSharp.dll
-----CompilerOutput:-stderr----------
Failed to initialize CoreCLR, HRESULT: 0x80004005
-----EndCompilerOutput---------------
- Finished compile Library/ScriptAssemblies/Assembly-CSharp.dll
[...]
Aborting batchmode due to failure:
Scripts have compiler errors.

 

I have a new macbookpro M1 with mac OS 11.0.1 machine,how can i support 2019.4 LTS Unity develop? Only can use 2020.2 beta?

 

Hi @Tautvydas-Zilys (or any Unity team member that knows ),

Just looking for a little clarification please. Does the above mean Unity 2019.4 editor is running problem free through Rosetta 2 on the new M1's? Assuming the same for the Unity player through Rosetta as well if so?

I'm thinking of upgrading my 6 year old MacBook Pro and don't mind waiting for a native M1 build but I just wanted to know what the situation is if you install Unity and use it through Rosetta 2 right now for editor and player.

Cheers!

 

Thanks, wasn't sure if Unity might have had some access to M1's. So the issues and fixes I see at the start of the thread are all based on the Apple Developer Transition Kit and might not be issues on the retail kit (thinking positive )

 

Understand, I did imagine I was being a bit optimistic Hopefully you guys will sort any issues as quick as possible, keep up the good work.

 

1.
Thanks for your prompt support!
I confirm your suggested workaround works.
I reported a bug for this issue.

2.
However loading a full project won't work as launching the Editor with -noUpm prevent Unity from retrieving the required packages, then compiling fails on missing dependencies.
Without the noUpm arg, Unity won't launch displaying the Unity Package Manager Error window: Failed to start the Unity Package Manager local server process. Make sure the process [...] is not blocked by your anti-virus configuration.
I reported a bug for this issue.

 

M1 Mac mini here, Big Sur 11.0.1, Unity 2020.2b11, I've not had any editor hangs

Regarding builds, a lot of my crashes involve EXC_BAD_ACCESS (Code Signature Invalid) when I target Apple Silicon, and I am years out of date with macOS code signing requirements so I don't yet know if its just down to me doing something wrong. I can build for Apple silicon using IL2CPP and with the Development Build flag ticked and then I get builds that run ok!

 

Only editor issue I've run into on that machine so far is that arrow keys are blocked when using things like text fields for filename in save as dialog boxes. But since I wasn't using Unity on Mac very much until I got the new Mac mini, I don't know if that was an existing issue not relating to M1 specifically.

 

I can also confirm that I can build mono stuff targeting Apple Silicon using 2021.1 alpha 5 just like the release notes for that alpha indicate.

However I still get code signing crashes like the following one when building for apple silicon with either mono or IL2CPP unless I tick the development build option. And I haven't gotten my head around whether this is expected behaviour or not, it doesn't do it if I build for Intel x64. Maybe I will see if I can disable System Integrity Protection on my Mac.

System Integrity Protection: enabled

Crashed Thread: Unknown

Exception Type: EXC_BAD_ACCESS (Code Signature Invalid)
Exception Codes: 0x0000000000000032, 0x000000010481c000
Exception Note: EXC_CORPSE_NOTIFY

Termination Reason: Namespace CODESIGNING, Code 0x2

 

That isn't what I'm saying though.

I'm saying that mono builds do work using 2021.1 alpha 5 targeting apple silicon, using a M1 Mac mini, but only if I tick development build. And apple silicon builds targeting IL2CPP also crash if I dont tick development build. So I suspect that I am reporting an issue has been fixed in 2021.1, but there are other code signing issues that make non-dev mono and IL2CPP builds fail when targeting apple silicon (but they work if compiled for intel 64 on the same M1 Mac mini)

The release notes for 2021.1 alpha 5 say the following, and you haven't mentioned whether the fix was also pulled from that version (in which case the release notes are wrong):

Scripting: Fixed macOS Standalone player built for Apple silicon architecture crashing on startup with Mono scripting backend when running on macOS Big Sur Beta 6 or later. (1278359)

• This has already been backported to older releases and will not be mentioned in final notes.

 

And just to be completely clear:

2020.2 beta 11:

Mono Intel = OK
Mono Intel Development Build = OK
IL2CPP Intel = OK
IL2CPP Intel Development Build = OK
Mono Apple Silicon = Crash
Mono Apple Silicon Development Build = Crash
IL2CPP Apple Silicon = Crash
IL2CPP Apple Silicon Development Build = OK

2021.1 alpha 5:

Mono Intel = OK
Mono Intel Development Build = OK
IL2CPP Intel = OK
IL2CPP Intel Development Build = OK
Mono Apple Silicon = Crash
Mono Apple Silicon Development Build = OK
IL2CPP Apple Silicon = Crash
IL2CPP Apple Silicon Development Build = OK

Where the ones written above in bold demonstrate a difference between 2020.2 and latest 2021.1 alpha, making me think that the mono fix did make it into 2021.1 alpha 5 as per its release notes.

The underlined ones in red above represent probably a different/new issue (or me not understanding code signing requirements on macOS but only for apple silicon apps, since intel builds of same project still run).

Tests conducted with fresh 3D template projects and default scene.

 

Thanks very much for finding the problem, for the explanation and very much for the workaround, I can confirm that worked for me thanks very much. And sorry to hear that this side of things has been giving you grief!

 

We're having a super weird issue on final Apple Silicon (Mac mini M1), that we were not experiencing on the DTK.

On a game that we're working on, our frame rate hovers a little over 29fps, but never hit stable 30fps. The weird thing is that we were able to run at stable 30fps on the DTK by dropping the Render Scale, while on the M1 the frame rate is not affected in any way by it.

The exact same game, with the same exact settings, runs at locked 30fps on iPhones and iPads.
We're using V-Sync, we're not limiting the frame rate in any other way on Apple Silicon.
We're on Unity 2020.2.0b10 + URP 10.1.0.

We still have to profile properly on Apple Silicon, but it's very weird since we're not experiencing it on all other Apple platforms and we were definitely not experiencing it on the DTK.

Any idea?

 

Not so wild, but I’ve just checked and we’re running at 60hz. :/

 

Ok this is interesting: if we remove VSync, we're getting over 50fps constantly, with the same visual settings, on the Mac mini M1.
But the maximum frame rate we can hit is around 57fps: we can't go up to 60 in any way.
So we should definitely be able to hit constant 30fps while VSyncing.

We're rendering at full native 4K resolution, dropping the render scale only to test performances (rendering at full 4K we get around 50 / 52FPS, dropping the render scale to 0.8 or lower we hit the maximum of 57fps and we're unable to go higher than that).

It's very weird, we definitely had not this kind of behaviour while working on the DTK while connected to the same output, we just swapped the DTK with the new mini.

 

I’ll be able to profile it tomorrow. At the same time I’ll try to understand if there’s something strange going on with the display, since it seems tied to not being able to refresh at 30hz or 60hz correctly.

 

I've been running into an issue with the 2019.4.15 editor (and 2019.4.14) and the latest Big Sur 11.0.1 on an M1 MacBook Air.

The issue is that sometimes, the screen completely freezes. That is, the image on the screen freezes. You can't move the mouse, you can't close the lid (screen stays on). The game however is still running since audio works as expected.

It looks like it gets triggered mostly when the game is in play mode and I try to adjust the game view resolution. It also seems to happen randomly. On game view resolution change, it seems to happen around 5-10% of the time.

The system is not frozen as I can still hear the game running and still play the game by ear. However, the screen is frozen. Any ideas? Is this just an Apple Silicon gpu driver issue? Happy to help debug this.