The RhinoWIP for Mac is now a Universal app, which means that it runs natively on both Apple Silicon and Intel Macs…
You may notice faster launch times, but otherwise Rhino and Grasshopper should run normally.
With massive changes like this, bugs creep in, so please report them as you see them.
PS: This is a separate issue from display performance improvements due to Metal.
Nice work, I bet this was … fun 
You funny man!
We kill you last!
Thank you! This is amazing news!
Does this mean Rhino 8 will run on M1 iPads too?
Wow, fantastic news; thank you so much for your efforts
No. macOS and iOS are still separate operating systems.
Sure, but a porting from macOS to iOS or iPadOS should be easier now.
iPadOS supports mouse and keyboard too
There are no current development plans to work on this.
You are correct, it does make it more possible (I would hesitate to use the word “easy” - but ok - “easier” is technically correct 
). That said, it’s still a long path.
I would also point out that the only way of delivering software to an iPad is via the iOS App Store, with all the myriad issues that raises.
But back to your point: yes, the fact that Rhino for Mac is running natively on Apple Silicon does indeed make something like this more technically feasible. It certainly makes us take another look at our woefully neglected viewer project (iRhino 3D) and explore some new possibilities.
Just please do not hold your breath for a Rhino for Mac you purchase on the iOS App Store.
Thank you for your clear reply.
I understand it’s a long and not planned path (for now).
If one of App Store issues is “the Apple cut”, consider that external App Store subscriptions are not subject to it.
That said, thank you for keep improving Rhino as a great multi platform software!
Congratulations @dan, that is a mean feat.
Is there any change in plugin architecture required to support this (aside from compiling native plugins for Apple Silicon/ARM64) ?
I suppose nothing would change if you are using Mono/RhinoCommon?
Not if we’ve done our jobs properly. Correct, if you’re calling into a native library, you’ll want to include a FAT binary with both the x86_64 and arm64 slices.
As you likely know, we have already made the transition to .NET 6 in the RhinoWIP for Mac. @curtisw is currently working on the same transition on Windows. Fun times.
We are a bit behind updating our documentation, extensions, etc. to support all this, but we hope to get to it soon. We hope to have better support for Visual Studio for Mac and Visual Studio Code going forward.
Out of curiosity, does Fologram use Display Conduits to make OpenGL calls?
Good point Dan, that is going to be a problem for existing plug-ins. Rhino 8 for Mac will be using Metal and we are not going to probably only allow OpenGL as a legacy fallback if we support it at all. If you are using the Rhino display pipeline functions to draw things, we can support this by performing the appropriate action depending on the underlying GPU technology. If you are directly calling OpenGL, there is nothing we can do.
Not as of yet. We currently are investigating the best way for us to render to the viewport at the moment for a future release; based on Steve’s comments it sounds like using the wrapped calls i.e. DisplayConduit.DrawMesh will be a reasonably safe platform agnostic way to do this?
That is correct. If you need some sort of new display routine, please let us know and we’ll see what we can do.
What about GHGL? Would these components work on Macs one you’ve switched to Metal?
In my Rhino plug-in, I have a few GLSL shaders called through a custom flavor of GHGL code.
GhGL will not work on metal as GLSL is OpenGL specific. Sorry, that’s the downside of platform specific technologies.
