Could it come up with something better than one that re-paints the entire UI, instead of just painting the parts that need to be updated? Could it come up with something better than running the entire UI on a single loop? Better still, could it come up with one that doesn't need an event loop? What do you think?
NB. I'm not a low level developer. I'm an old-timer who thinks the World is out of control, so I'm probably ranting from my backend.
If you mean a UI framework for creating applications, I did start a project to create a SwiftUI-like framework for cross platform native desktop applications, but it currently uses gtk as the backend and I just don’t have the time to work on the project. Here’s a link to SwiftCrossUI (my framework).
iirc, the TokamakUI project has an experimental GTK backend hidden away somewhere (its regular backend is for wasm and the web)
I think it is definitely an important area for improving adoption of Swift on non-Apple platforms, because I agree that currently there aren’t any good solutions available.
In case anyone is interested in contributing to SwoftCrossUI (PRs very welcome), here’s the current state of the project and what the next steps are.
Currently, it is possible to make a stateful app consisting of buttons and text. And the framework works on linux and mac (it should work on windows but I haven’t managed to install gtk)
The next steps are:
Implementing more core view types (e.g. text inputs, drop downs, etc) by wrapping the widgets that gtk ships with.
Creating a view modifier system for styling
Creating a better view layout system
Figuring out how to build gtk on Windows (theoretically SwiftCrossUI should work on windows, but I’m not well-versed with windows and couldn’t get gtk compiling and detected by the swift compiler)
Future directions
Possibly implementing a WebGPU based backend to have full control of rendering performance as well as styling and layout (replacing gtk completely). This backend would also be able to support a wider range of platforms (including the web)
Optimising view updates (I haven’t looked at the code for a while, but iirc view updates might not be too efficient if there are lots of views)
I’m thinking of creating a Swift wrapper for FLTK. It will require building cfltk (the C wrapper) and FLTK as part of the build process. I’m not sure if it’s possible to invoke CMake as part of spm.
How come I never found those while trying to find ways of installing Gtk on Windows… that looks like a much nicer way of doing it!
However, last time I tried getting swiftgtk to build on windows I did manage to install gtk through the pygtk installer or something, but I ran into issues getting Swift to detect the gtk installation. It sounds like the way @stevapple got it to work was using a patched version of pkg-config.
To be clear, I didn’t use any installer — I managed to build it completely from source and the build tool (Vcpkg) collects pkgconfig files automatically. The current blockers are:
If the SwiftPM pull get merged soon, hopefully we can have it with 5.7 release, or we’ll need extra workaround. And I have no idea when the Vcpkg pull can be merged, but if someone needs it he/she could check out the PR directly.
I also came across the installer mentioned by @sspringer, but it seems to only contain runtime libraries. Clang needs the header and linker needs import libraries, so that’s not enough for development.
Ideally, SwiftUI would take this role. Apple would need to open source it, but the community could pick up the work for supporting other platforms. Similar to how swift on windows came to fruition.
And aside from potential cross platform support, open sourcing it would also mean people could download later versions of it independently of OS releases.
At one of my previous companies I implemented a few pages entirely in SwiftUI. At the time, iOS 15 was in beta. Our minimum supported version was iOS 13.
Having completed the development of these features on an iOS 14 device, it was fairly painless. We didn’t use any APIs that weren’t available on iOS 13. But the second we started testing on iOS 13 devices we noticed that there were a ton of bugs. Many of them just visual. But there were some crashes, navigation issues, etc…
If SwiftUI was open source, many of these issues would have been fixed by simply updating the package version.
I know this is probably preaching to the choir. But I really think apple needs to do something about this if they want to see more adoption of SwiftUI.
Because at this point, adoption is more than just “can my minimum version use swiftUI?” It’s also: “does the version of SwiftUI on my minimum supported version actually work?”
Apple should understand that taking the cross-platform thing even more serious would help them. See what Microsoft is doing with .NET Core. Currently for many cross platform applications .NET Core seems to be a much better solution. Especially the Windows version of Swift has to get much more support from Apple, leaving all to the community is not enough. And I do not think that costs is a matter here, Apple should be rich enough to invest here.
But apple historically has not really cared about developing for other platforms.
At the bare minimum, open sourcing swiftUI would give the community a library to focus their attention on, rather than the dozen or so open source swiftUI alternatives that are abandoned/not progressing in any meaningful way.
Consider that Apple is a hardware maker, and ask, how would opening SwiftUI help them? Opening Swift appealed, why? I suspect it was that it simply wouldn’t hurt them, and might get Swift to mature more quickly.
The strategy around SwiftUI is less clear, it might not be in their immediate interests for full apps to be easily portable away from the hardware they sell.
If Swift is the language of choice for many people, they are more likely do make good macOS apps with it instead of using .NET Core. It will also not hurt because the strengths of the Apple devices are their hardware and the APIs outside the „standard“ APIs. But yes, you do have an argument.
related Vcpkg port is approved and expected to be merged into mainline soon;
related SwiftPM patch is merged into release/5.7 but didn’t get into 5.7.0 release. We’re expected to see it in Swift 5.7.1.
This means we can build SwiftCrossUI on Windows in a relatively easy way with Swift 5.7.1 and newer toolchains. I’ve started to write the guide in order to release it along with the next Swift release, and it should also provide a practical path for other Swift packages to get rid of CMake and embrace SwiftPM on Windows.
