Hi Stephen
No, it is not a goal to stay close at all. That said, there's a lot to like about those APIs and lots of great ideas to take inspiration from. The project does use inheritance, but a very shallow inheritance tree.
It is, in general. That said, the expectation would be that there would be some conditions in the code that alter the behaviour on different platforms. For example, there might be a component that implements a macOS tool bar, and one that implements a ribbon for Windows. The recommendation would be to use the appropriate component on the current platform, and maybe this would even be enforced by only compiling components appropriate to the current platform. There are common components, too, but the expectation is that styling and configuration would be supplied for each supported platform such that they feel entirely native.
This approach also allows for things like perfectly consistent layouts across platforms, identical behaviours (at least outside core functionalities, like windowing etc.), and of course, maximum code sharing. Today, users expect things like slick animations, and implementing these individually is a huge effort. If a team has the resources to do that on all their supported platforms, then they absolutely should, but in many cases it's not possible. If a cross-platform toolkit can succeed at being indistinguishable from native applications, in looks and performance, then it is objectively better. But it's a very difficult task, of course.
This is what Apple is rumoured to be working on. Of course, their constraints are very different in that their target platforms are all running the same stack. One thing I strongly dislike about other solutions in this area is the mixing and matching of languages. I want to write my code in one language, using APIs that are well designed for the task. This gives access to the full power of the language, and while some declarative UI technologies provide big building blocks, I think these leave rough edges and developer frustration.
Additionally, if the native code for the current platform is a different language, then there still needs to be a solution for interacting with that code at runtime.
All that said, a Swift API that allows one to easily and efficiently compose UIs in a declarative manner is something that could be explored later--something that would use what's already there in Suit.
I like this in theory, but there's an overhead, and a challenge in maintaining consistent behaviour across platforms, as well as a strong temptation to implement a lowest common denominator UI.
You mean that the UI would be written in the native toolkit for the platform, in the native language, and it'd call into some Swift business logic or something like that? If the interop between languages works well, this would be a fine solution, but obviously is more work. I'm not sure Swift would be the best language to use for the common code today, however.
