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

Any word on the "native apple silicon" version? or when we can expect an alpha etc

 

+

 

Thanks

 

Nice, are you working alone on the porting? It just sounds like it.

also, could you maybe say something about the performance increase we could roughly expect from a native version? The Rosetta emulation on my m1 mac mini runs pretty decent by just using the editor. Changing a line of code is painful tbh. Up to 10 seconds before i can use the editor again. On my windows pc i wait around 4 seconds. What could we expect from a native apple silicon editor version?

thanks!

 

Do you have any suggestions for getting the fastest best IDE experience on M1?
The main thing i have done so far is switch the editor to do manual code refresh, so that helps a lot when switching between the IDE and the editor.

I have been using JetBrains rider 2020.3.1 (which i think is an intel ide) and the typing experience is laggy. Is there a better IDE or IDE settings? Visual Studio, VS Code, or XCode?

 

VSCode is optimized for M1

 

Have you been able to get the C# plugin loading and omnisharp working (with autocomplete etc) in the M1 native insiders edition of VSCode on ur M1 Mac?

 

Hi, i am having my app rejected after delivering it to the apple servers.

[B]ITMS-90238: Invalid Signature[/B] - The executable at path ***.app/Contents/Resources/Data/ARM64/GameAssembly.dylib has following signing error(s): valid on disk /Volumes/data01/app_data/app-processing/mz_4040850737257950882dir/mz_3052890068781178191dir/***.***.***.pkg/Payload/***.app/Contents/Resources/Data/ARM64/GameAssembly.dylib: satisfies its Designated Requirement test-requirement: code failed to satisfy specified code requirement(s) .

[B]ITMS-90238: Invalid Signature[/B] - The executable at path ***.app/Contents/Resources/Data/x64/GameAssembly.dylib has following signing error(s): code object is not signed at all In architecture: x86_64

Signed with the procedure outlined here https://docs.unity3d.com/2020.2/Documentation/Manual/HOWTO-PortToAppleMacStore.html

Using Unity 2020.2.2f1 universal build.

 

I don't use insiders, but it all works fine, yes.

 

I suspect we'll be waiting for C# 6 later this year for the whole stack to be native. Hopefully unity can get some of the major speed humps fixed before then (long wait in editor after script changes / pressing the play button).

 

We've just run into the same issue. I noticed there's actually 3 versions of GameAssembly.dylib in the built .app - one in Contents/Frameworks (this one is x86_64 & arm64), one in Contents/Resources/Data/ARM64 (this one is arm64 only) and one in Contents/Resources/Data/x64 (this one is x86_64 only)

I tried just deleting the ARM64/ and x64/ folders in Resources/Data and the app is still fine on both intel and Apple Silicon devices.

Interestingly, the 'universal' dylib is smaller than either of the single-arch ones..

 

Thanks for the super quick response! I will do that, and we'll go ahead with a submission without those dylibs

 

Just FYI, .NET Core hasn't been yet ported to Apple Silicon, but they're working on it. VS Code Insiders doesn't work correctly with Omnisharp at the moment, if you want to do Unity Development. Given that said, Intel VS Code runs perfectly. The only problem right now is Unity taking double compile time when scripts are changed.

 

Updating the thread for visibility on this issue. Bug reported and active: https://issuetracker.unity3d.com/is...-in-the-standalone-player-when-making-a-build

 

Hi, when i click play button Unity seems to get stuck and appears the spinning wheel during 6-10 seconds before the game starts running, has that been reported?? I've also noticed my macbook makes a weird "prrft" noise when I'm using Unity and open youtube on different browsers

 

Hey there, we're currently having issues with notarized builds hanging at specific points on our DTK. I'm unsure whether this is the best place to post this, so I can create a new thread if necessary.

For context:

• The project uses 2019.4.13f1 when built via UCB (and thus Intel build architecture).
• Our builds are notarized through UCB (however this happened on a build I manually notarized myself, after building on the DTK itself with Unity 2020.2.0b14).
• DTK was on Big Sur Version 11.0 beta, but I've just updated it to Big Sur Version 11.2.1 and the problem persists.
• As the build is notarized, we cannot seem to grab any Player.log from it.
• This is on a Mono build.
• If using IL2CPP, the build seems to crash after the splash screen. Currently ignoring this, we're just trying to get something usable for M1 Macs.
• This does not happen with the same builds on my 2015 MBP running macOS Catalina Version 10.15.7 (might be able to test on a newer M1 device soon).

What specifically seems to be happening is there is some hanging when we are trying to load files from unpacked Asset Bundles. We have seen (quite infrequently) that the build can recover from this hang, but more often than not, it must be manually force quit as it is non responsive.

Has there been any reports of something similar happening? It is particularly tough to debug as we can't seem to get any logs from the builds.

EDIT: Also, since updating to Big Sur 11.2.1, seems like the Unity editor is freezing the screen on project load. A quick unplug and plug of my HDMI cable renders it usable again however.

EDIT 2: Ooft yeah, it seems less stable than ever on this version of Big Sur. Is there a recommended version of Unity to be using on the DTKs?

 

My bad, ironically as I was reading through this thread the one post I forgot to actually go back and read again was the original. I'll update to the latest 2021 version and give that another go. Thanks for the tip.

 

Oooh i see, thanks a lot, thanks for your work, you're awesome <3

 

Download and install the newest Rider EAP, then download the native DataGrip app from JetBrains, right click on the DataGrip.app and go to Show Package Contents, then copy the "jbr" folder, then right click Rider EAP.app and Show Package Contents and replace the jbr folder in there. Now you will have native UI performance, there's a few bugs with preference windows and stuff so I keep the intel jbr folder around, but this trick has been working for me so far!

 

So I have a rather large project that takes around 23 seconds to compile on my 16", but it's taking more than 3 minutes per change on the M1. Looking at the log file it's mostly due to it taking an incredible amount of time on DLLs in the project, around 15 to 20 seconds for each one. I find this odd as running non converted apps doesn't even take 10 seconds. I'm also curious if there is a way to cache the rosetta conversions? I could handle double compile time but obviously 3 minutes is unusable.

 

Yeah domain reloads are disabled. That's a shame, guess I'll be returning the M1 for now!

 

Hmm, so after that, the hanging issue is still happening on the DTK. However, I just got access to a released M1 Mac (Macbook Air running Big Sur Version 11.1), and it appears that the hanging is not occurring on it. This is the case on both a manual 2021.1.0b6 build (notarized manually) and our UCB build (2019.4.13f1, notarized automatically). It's pretty annoying to see this behaviour on the DTK, but as long as it doesn't affect end-user experience, it might be better that we cut our losses now.

I could still provide the spindump if you think it's worth investigating, unfortunately I have no clue how to parse any information from it myself.

Could this be the culprit behind this hanging behaviour?

 

We didn't get ours until around September last year IIRC, so I think that may be the reason why. Now that you mention it though, I might need to go through the proper company channels to make sure it gets returned in time.

Thanks for your assistance anyway, been following the M1 development for a while and gotta say your support has been fantastic. Keep it up

 

I'm using Big Sur on a non-apple silicon macbook. Is it a known problem that you cannot append iOS builds anymore? I click on "Append", then am greeted with the attached screen saying the folder "already exists. Do you want to replace it?" with the options of "Cancel" or "Replace". I have a bunch of stuff done in xcode that I do not want to overwrite. Any workarounds to this? Is this a known issue? This project is using Unity version 2019.4.4f1.

 

Ok, so I can click the second replace without ruining my life? Perfect. I'll make a backup just in case, of course. Thanks!

 

Really glad you guys are working on M1 support. Thank you!
I wonder if you plan to roll it all out at once, or release it piecemeal? Asking because, for example, the texture compression process that gets spawned when importing textures could perhaps be able to be a M1 even if nothing else is.

 

So after testing for about a month here are some of my observations with some advice taken from the people on the forum. Take it with a grain of salt:

Of all of the versions of unity3d I have tested on the mac (as of Feb 26 I haven't tested everything) m1, 2019.4.20f1 + VS Code has been the most stable no crashing no hanging just works. The main setting needed to be set is to uncheck "Auto-refresh" in the general settings because the script compilation is really slow especially on large projects.

Some of the newer unity versions fully crash (orange screen) actually quite often and requires a reboot. 2020/2021 crashes randomly on certain tasks for me (especially the sprite editor and model importing), but it works better for making builds especially for IOS (especially for doing IOS VM tests).

VS Code works but my preference is Rider.

Rider out of the box is still not M1 native. The intel through rosetta had a really big lag on large projects. Also, it would sometimes hang during large refactorings. But the message from FIGBASH to do a swaparoo above totally worked for me! And the results so far are good. Just remember that c# runtime itself is still using rosetta and likely many of the command line tools that ride or VSCode are running on.

Finally, the benefits of using assemblies with Rosetta are even more questionable. Try timing the compilation instead of using assemblies blindly.

 

If I disable it, do I have to do something to manually compiling it?

 

I upgraded my project from 2018 to 2020.2.5f1, seen a massive performance boost in editor. Works great on my mac mini. Tried newer versions (2020 or 2021 beta) and those have strange editor performance issues, so I'm sticking to 2020.2.5.

 

Any news about when a Universal build will be released? 2020.2.5f1 is still Intel only.

 

Sorry for the maybe stupid question, but 2021.2 alpha 6 is already out. Or do you mean a different version?

 

Nice~~ Thanks for the hard work.

 

Reading through this thread it is a little hard to tell if running Unity on an M1 vs previous generation is still a worse experience but it looks like a dangerous step to change to an M1 Mac at the moment (for non-native work - ignoring future silicon support), is this so?

 

My personal experience has been surprisingly good. The Intel Unity builds usually run smoothly and I haven't encountered anything that's clearly broken. I imagine once the native editor is released, we'll start seeing issues with compiled libraries that haven't been updated to ARM however..

 

By the way, I havent had any joy with getting Unity to start without crashing on a M1 Mac if I use one of the 2021.2 alphas with the HDRP 12 versions they come with. Even with a fresh project created by selecting the HDRP template when creating the project.

 

Seems the official version of 2021.2 will come out soon

 

EDIT : I found a workaround. I disabled Vsync in the project settings but enabled it in the aspect ratio menu of the game view. It runs smoothly at 60 FPS now. I still don't understand why the project settings doesn't apply though :/

Hello @Tautvydas-Zilys ,

I'm currently running 2020.3.0f1 LTS on M1 MacBook Pro 16Go.

I have an issue with play mode when the stats panel tells me the project runs at roughly 80 FPS but I can tell you visually it runs at sub-30 FPS

The simple fact that it tells me the project runs at 80 FPS is strange by itself as Vsync was activated in the project settings. Disabling Vsync didn't change anything.

Is it a known issue ? Is there a workaround ?

Thanks