New Framework for GUI apps on Linux and MacOS

Over the last months I worked on a cross-platform GUI framework for Swift. Here is a screenshot of the demo app:

You can find the code and some explanations for SwiftGUI (a better name is necessary, probably) on GitHub

Windows support will be added as well.

I'm very interested in feedback. Do you need such a library? What features do you want to see?

7 Likes

This looks interesting.

Why did you decide to use reference types for the widgets?

1 Like

Thanks for your response. I used reference types for Widgets and RenderObjects (primitives output by the Widgets, e.g. Text, Rectangle, etc.) because:

Each Widget represents one UI element that has a unique identity in the application as it is displayed at only one location on the screen. Being able to easily create many detached objects representing the same interactive element didn't seem useful to me.

Both types are organized as tree structures. And implementing them as reference types allows for all updates to Widgets and their outputted RenderObjects to to be resolved inside each Widget. On the next render cycle, the whole tree state will be up to date without any special update logic.

There are edge cases where things need to be hacked together somehow to get a specific look or functionality. One function facilitating this is the ability to hold references to Widgets outside of their direct parents and do anything with them. Normally you define custom Widgets that are composed of multiple pre defined Widgets to create your views. If you want to you can assign a Reference (actual class in the framework) to each Widget which will always point to that Widget after it has been mounted. That way, not only the direct parent, say a layout Widget such as Row or Column can access their children, but also the custom Widget you defined for your view. This gives you the ability to hack something together.

1 Like

I'd strongly suggest a name that's not a single character away from SwiftUI. Otherwise a lot of people will either get the two confused or will expect it to be a cross-platform clone of SwiftUI.

1 Like

Yes, I'll find a different name for it.

I think you should lean into it by pronouncing it "swift-goo-eye".

Having "Swift" in the name is helpful to avoid competition with other languages in search results. And if the rest of the name describes the function of the framework, it's easily identified as the desired result without needing to read a description first.
Considering that the name is probably going to be written quite often in import statements, playing with the pronounciation to produce a relatively short name might be better than: SwiftCrossPlatformGuiFramework.
But the long name is clearer. Maybe an abbreviation like SwiftCPGUI/SwiftCPUI would be good?

Terms of Service

Privacy Policy

Cookie Policy