I've been working on a couple of pet projects for a while now, which I plan to release as open source in the coming weeks. In preparation for that, I'd thought I'd share a little preview in order to see what, if any, interest the community has in these projects.
The projects are called Suit and Stride.
Suit is a GUI toolkit, written entirely in Swift. It currently supports macOS and Linux (an earlier version supported iOS, too, and I plan to re-add that).
Stride is an IDE written using Suit. Again, it's entirely written in Swift and is designed to be fully cross platform. The videos below show Stride in action on both macOS and Ubuntu. There are some obvious bugs on show here, and this is very much pre-alpha quality at this point. If you're interested, let me know what you think.
I would like to add iOS, Windows, and Android backends at some point in the future. While cross-platform is definitely not the right choice for most apps, there are a certain class of apps that, in my opinion, make sense for such a solution. (This is my attempt to pre-empt the "Nooooooo cross-platform is worse than raisins" responses. Raisins are the worst.).
If you're interested in either of these projects, and of potentially becoming a contributor, please get in contact. And feel free to follow me on Twitter for updates: @ saniceadonut
Very cool @pmacro It's nice to see people exploring cross-platform UIs.
Is it a goal of the project to stay close to the UIKit/AppKit API? Or do you plan on exploring different APIs? I assume we can do better in Swift than just using big inheritance hierarchies
Also, what are your thoughts on the different approaches to cross-platform UI? Here are some that come to mind:
Fully cross-platform UI (seems like this is what you're going for).
Cross-platform native UI by using a declarative language or DSL that translates a declarative UI into native code for the current platform.
Cross platform domain with a native UI per platform using Swift bindings for the native UI frameworks (such as GTK on Linux).
Cross platform domain with native UI code calling into Swift. This avoids the need for bindings, but mixes Swift code with native code in a possibly different language (such as C# on Windows).
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.
Great. I even think these are very valuable projects even if the GUI library is not "complete" on every platform or the IDE is not as feature rich as XCode or CLion. In many projects there is only a need for a simpler GUI and no need to be able to support every feature of a platform. (But maybe this is not a contradiction?) And having an IDE that might be considered as "part" of the Swift distribution on every platform would be great too.
Of course there should be Windows versions, too. Even if this is not something you would do, maybe it would be a good idea to evaluate what the obstacles for a Windows version of the GUI library could be, so a Windows version could be possible later.
A Windows version is definitely possible. Any system that has windowing, text, and graphics APIs callable from Swift should be fairly straightforward to support.
I'll be open sourcing Stride very soon, too. And will post back here with a link for anyone interested. I also asked to have it added as a project under this category, so hopefully that request is accepted.
It is possible that they where flat-out deleted or maybe just made private. Anyway, I was able to find what appear to be forks of the projects that were created before this occurred:
