What is the background of this info in the system requirements ?
https://www.rhino3d.com/6/system_requirements
Not supported :
- ARM processors
Simply put: we havenât compiled Rhino for the ARM architecture. Havenât even tried yet as far as I know.
We have an Apple Developer Transition Kit and are working on this. No idea how much effort needs to be put in to transition yet.
3 Likes
No news; this project will take quite a bit of time to complete.
3 Likes
Maybe helpful?
2 Likes
thanks @rudolf.neumerkel, sounds interesting. also please post further news in the second part of this to keep a better overview, but whatever 
@stevebaer @dan i assume you could delegate someone? but i assume you already know all that.
Maybe you guys could get some valuable information / give feedback by requesting an appointment ?
@encephalon sure thing! 
1 Like
Thanks for the input guys. We have a contact at Apple that can help us with issues as we run into them.
4 Likes
RUNNING x86 ON ARM
Maybe this is helpfull for anybody choosing to work with an early-arm-mac.
It will probably take some time for some developers to create mac-arm-apps.
Or some devolopers may decide not to switch to arm-apps at all.
Somehow itâs a bothering issue like Nvidia Cuda on Mac, or Power PC Mac to Intel Mac.
We just want a easy creative workflowâŚ
On this, thanks to Rhino devolpers, Rhino is so awesome.
Dave
Why do you need to compile differently on Arm, while you donât need to do that for Intel and Amd targets? And why is there no proper cross-compiler if this is an issue? I do understand that you cannot properly optimize for a certain chip, but at least it should run nowadays? No?
I mean if you have a different build for arm targets youâll need to deploy more executables, you need solve it for all your dependencies, and basically all plugins need to update as well. Even .net code needs to run on the lastest framework. So anybody needs to convert to latest Core. I went through this process once, and its not that straightforward as it should be. Of course at some point this transition has to be made, but if a vendor is forcing you to do that for not to loosing customers, its really stupid.
Wouldnât it be better to wait for Rhino 8, since you probaly updating all your build tools anyway and skip Arm targets until then? I guess that wouldnât work, since people want to use Rhino with the latest Apple products. That sucksâŚ
We donât really have a target version of Rhino yet for ARM support.
We are still in the investigation stage of finding where we will have problems due to libraries that we use and our own code.
.NET code should not need to be updated.
It is extra work, but itâs not as big of a project as supporting metal. It is simply what we are forced to do if we want to continue to support an Apple version.
date is set, apple silicon / arm macs will be presented on nov 10
Okay if itâs like this. Whenever I read about Arm64 support of .net, I always read about .net core or the new .net 5.0 (which is not .net framework 5.0).
If itâs work with the older .net framework than itâs fine, but just in case you need to migrate to a newer release that could be tricky. On a 50 classes project I remember having around 60 build errors plus changes in WPF and different behaviour on some Reflection methods, while changing from .Net 4.8 to Core 3.1
We currently use mono for our .NET runtime on Mac. This is one of the libraries we will need an ARM compile of
1 Like
Maybe I just have a wrong understanding on how mono works. But now that you mentioning Mono, I remember that I have written C# code on a raspberry pi 7 years ago 
. So yes, you are probally right. Its probally based on my false assumption that mono targets a specific framework version and replaces win api calls with those of Mac or Linux. But actually its a complete rewrite. Iâm quite confused that in Rhino you create .Net Framework dlls which automatically also run on Mac. How this actually works is a big blackbox to me. Probally its because the IL is the same, it just requires a mapping to the bare metal. Anyway, I guess that partially explains why there is probally no need for updating the target. ARM was always supported by Mono and Mono can interpret libraries targeting the .Net framework.
This is just how .NET has always worked. You can write assemblies that target "Any CPUâ and have those assemblies execute in both 32 and 64 bit processes (x86 or x64 for Intel) on Windows under the .NET framework. The same concept works for other CPU architectures. .NET assemblies are composed of a set of instructions that are just in time compiled to native instructions depending on where they are executing. At a low level there is a large native library that does all of this and for our case on Mac this library is mono. This is the library that needs to be updated to compile for ARM using Apples latest tools.
I think you know all of this already, but Iâm writing this down in case others are interested.
Of course I know this, but independent from the cpu you have to select a framework version. Now I always thought that mono is not equal to the .net framework or.net core. But now, if you target framework 4.7 it means the mono counterpart needs to support ARM. So wouldnât that mean Mono devs need to support ARM 64 on Mac builds for all .Net framework versions? I still donât get fully, but I was expecting that any change of the Mono library just affects the latest versions? Or is Mono just a big library supporting many framework versions in one big chunk of code? Or do they recompile for any major framework version then?
Again, if Iâm developing a Rhino or GH addin, I never select Mono as I would do in a normal app but instead the .Net framework as target. And for some reason it can run this dll on Mac as well. That whatâs confuses me, how this works
Mono is just the implementation of the .NET framework runtime, whichever you choose to target (4.6, 4.7, newer).
The .NET core implementation is in a different SDK and runtime.
For Mono to work on the new chip architecture it needs to be compiled for that. There is platform specific code in the implementation that most likely needs to be adapted for the compilation to succeed.
Any .NET code you write has not to bother about such low-level considerations. Once Mono works there your .NET code will work (assuming full support and proper specification implementation in Mono, of course).
Ok this means âMonoâ is a pure â.Net Frameworkâ port and can not interpret projects targeting âCoreâ. (And it doesnât really need that, since Core is designed to be platform independent to some extend and so its rather an alternative. I guess thats clear now.
So it probally also means that a migriation to Core is not planned in near future? Or are you considering this for Rhino 8? Especially regarding overall performance the Core implementation performs extremly well compared to the Framework and especially to Mono (in case thats still true for late 2020)
Iâm completly understanding this. Your code becomes Intermediate Language, and on Mac, Mono knows how to make it run on that OS with that specifice chipset.
But now, to close the loop to my initial comment, if Iâm not wrong it still would require Mono to recompile for any major releases of the framework. Certainly there is a difference between 4.7 and 4.8.
But as you implied, it may also work differently. If Mono just doesnât know a specific framework api call, it will refuse that to execute, so it doesnât really care about framework versions and so my initial comment on a forced framework update is nonesense in that regards. I would have expected to at least update to higher framework versions. And from my experience this is not always just as simple as it should be.
Anyway. I guess Iâm more clear on this one. Sorry asking these âdumbâ questions but since Iâm usually not in need to support multiple operating systems, this is a rather blackbox for me.