Well, great question! I’d love to know how it will evolve, but all I can help (hopefully) with is how we currently intend for it to evolve? Ok, before I rattle on and write a miniature novel…
TL;DR: As of Rhino 6, Rhino for Windows and Rhino for Mac share the same codebase. Development is happening at different rates on each product, but they will have much more feature parity than they do now. Rhino 6 for Windows will ship before Rhino 6 for Mac.
A little background is necessary here (I’ll leave out some details and simplify a little bit)…
Rhino for Windows and Rhino for Mac share a TON of code. A lot of this code is in the “core” - the geometry engine that drives Rhino. This is the exact same code. Bugs in one will be bugs in the other.
At one point during Rhino 5 for Windows’ development, the code for all of Rhino was “branched” and separated into a different project. Changes that could be merged from Rhino 5 for Windows were merged into Rhino 5 for Mac (our initial release)…but they were two separate “code-bases” (or projects). If the Rhino for Windows code was not building, that didn’t impact the Rhino for Mac builds (and vice versa). This meant that developers of Rhino 5 for Windows did not have to care if the code that they committed would work on Mac. By the same token, development of Rhino for Mac would not slow down Rhino 5 for Window’s development. So, even though Rhino 5 for Windows and Rhino 5 for Mac share a LOT of code, they were/are still independent (at the code level).
Ok, now let’s talk Rhino 6…
We knew this separation of the project code was unsustainable. So, late in 2014 - simply because the timing was “right” - we merged the Rhino 5 for Mac codebase back into the Rhino 6 (for Windows) codebase…effectively unifying them for Rhino 6 (for both Mac and Windows). OH, and we did one other really important thing: we created a process by which, whenever a McNeel developer checks in a change to Rhino, it has to build on BOTH platforms: Windows and Mac. If that test fails, the developer has to correct their work so that the builds will not break. What does this mean? Lots of things: developers have to pay attention to the impacts of their code cross-platform and find solutions that work on both while they make even the smallest of changes (and there is absolutely no doubt in my mind that this is slowing down the development of Rhino 6 for Windows). This also means that even more of the code will be the same. Notice that I said: “it has to build on BOTH platforms” …that doesn’t actually mean it has to “work as intended” on both platforms…that’s a whole 'nuther story (for later). In sum: we are taking huge steps toward writing cross-platform code and “unifying” the products at the most basic level: source code.
At an organizational level, learning to develop cross-platform does not happen overnight. It’s really tough. Some of this is technical, but a lot of this is not. People are comfortable with the platform and the tools they know. Sometimes going over to macOS - for a seasoned Windows user - and doing the simplest of tasks is a real chore. The same happens for macOS developers.
I doubt it, but this likely depends on which plugins you depend on and which third-party developers decide to develop and release for Rhino for Mac. I think there will be people who will say in the future: “Rhino for Mac is a toy because it lacks [insert really obscure niche plugin here].” But it could also cut the other way: “Rhino for Windows doesn’t have [insert really obscure macOS-specific feature used by 10% of people here].” I kinda think this distinctions are rather silly. We want to create an awesome product and development platform in Rhino. Much still needs to be done to get plugins working on both platforms…but this is something that we necessarily need to do with cooperation of third-party developers.
I’m glad you are. Let me know if any of the above doesn’t make sense.