Sounds good, can’t wait to test it out
So true! Many people underestimate the work for the Apple Silicon transition.
In cases like Unity it is not just a recompile like a lot of people think.
thank you to the whole team for the hard work on this! As others have said, you should know how much we appreciate your efforts and are looking forward to using the editor on Apple Silicon. Fingers crossed it goes smoothly, and let us know how we can help
Once it’s finally shipped I would love to read a blogpost about how you tackled this. I can imagine there are all kinds of hairy problems to solve.
That’s great news. I can’t wait to run the editor natively. Great job, guys!
Will the editor also be supported in 2020 LTS? Or will the native support only be available in 2021 versions?
Thanks to everyone involved with getting that HDRP crash fixed as of 2021.2 alpha 16.
2021.2 at first. We may reevaluate it later, if we can get it stable enough in time.
As a fairly new (like, 2 weeks ago) mac user, this is great !
I wish good luck and no road blocks to the whole Unity dev team!
Native Apple Silicon Unity will be a huge blast!
I’m also eagerly waiting for JetBrains to port Rider
You can already get the editor part of Rider in ARM native form! Need to copy over the JBR folder from another one of their programs, used PyCharm or GoLand in my case, and the editor is a lot more snappy now Of course, that’s only 1/4th of the stack, broadly speaking - Mono, Unity Editor, Unity IL2CPP, etc aren’t native still, but we’re getting there.
Seems there’s still a long time to publish the native editor?
That sound interesting, can you explain a bit more?
Sure thing, so the JBR folder is the runtime for the editor. Also on mac, xyz.app is just a folder with its own structure, and info on how to execute the folder.
Anyway, currently Rider ships with the old, x86 JBR, since some parts of the editor aren’t ARM native. This is mostly Mono related I believe, so will be fixed towards the end of the year. However, I am impatient.
Also keep in mind all the following paths could change for you. I’m using Jetbrains Toolbox, so I’m going off those defaults.
Before doing anything, close down rider so you don’t run into permissions issues and the likes.
I found the jbr folder at ~/Library/Application Support/JetBrains/Toolbox/apps/Goland/ch-1/211.7442.27/GoLand.app/Contents/jbr
. Goland is just an example, just need an ARM native editor, PyCharm and the likes would work just as well. Copy this folder.
Then you want to navigate to your Rider app’s contents folder, which is ~/Library/Application Support/JetBrains/Toolbox/apps/Rider/ch-0/211.7442.29/Rider.app/Contents
in my case. Make a copy of the jbr folder, and paste the Apple native jbr in.
Once that’s done, restart Rider, and it’s Kind
in the process monitor should show up as Apple
Tautvydas-Zilys, will assembly reload times be improved when the alpha of Apple Silicon support comes out in 2021.2? I’m not asking for benchmarks or anything, just whether that process (MonoJIT mostly I guess) will be native with the first alpha.
From what I understand, it seems the biggest day-to-day performance hit with running UnityEditor under Rosetta2.
Rider M1 support is available in preview releases now!
https://youtrack.jetbrains.com/issue/RIDER-54092#focus=Comments-27-4922392.0-0
This version seems not working with unity project, after launching rider I have all my C# scripts full of errors.
Is Busrt not supported on apple M1 chip?
I’m using Unity2019.3.9 with package
entities: preview.6-0.10.0
busrt: preview.9-1.3.0
On mac with m1 chip, right after I open the unity project, error log display
Anyone can check if there is any difference between 8gb m1 version and 16gb version? because 16 seconds to compile each time i modify my c# is excesive…
i have a 16gb m1 and it is taking 30 seconds each time, though i have a bigger project.
On my intel macbook it takes ~15 seconds.
Unity on M1 is pretty much unusable until this is fixed