A cross-platform UI for Swift

OMG, there isn't one! That's not quite true, but the few that do exist have fallen by the wayside.

So, what can Swift.Org do about this?

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.

1 Like

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 tried a bit out of curiosity, and this results in Initial support for Windows by stevapple · Pull Request #5 · stackotter/SwiftGtk · GitHub. The process is quite easy thanks to pkg-config and I'm glad to share the steps after one of the upstream PR I used is merged.

1 Like

Thanks! I’ve merged the PR. What were the main steps for installing gtk on windows? Id love to add some simple instructions to the readme.

As I mentioned, I made use of some patches that were not merged yet. I’ll add the guide when all the requirements are settled.

Oh right, sorry, i misunderstood. I thought you meant once the patches were merged into mine. All good :+1:

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.

If it's possible at all, I would look at the SPM Plugin (swift-evolution/0303-swiftpm-extensible-build-tools.md at main · apple/swift-evolution · GitHub). I haven't tried invoking specifically cmake, but I believe you can do almost anything, if you disable sandbox.

1 Like

Thank you for the resource. I’ll check it out

What about those installers?

1 Like

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.

1 Like

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.


I definitely agree with you.

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.

1 Like

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.

1 Like

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.

Also, if there is a cross platform ui framework that works on all platforms, someone building a windows/Linux app can easily drop the app onto macos.

Which means macos gets more apps.

I don’t think this would negatively impact apple bottom line in any way.

1 Like

Just out of curiosity, how is "open sourcing SwiftUI" even supposed to work? Like, fine, you get to look at the code, but this alone doesn't achieve anything; SwiftUI is heavily reliant on other platform frameworks, like Core Graphics and what not, so at best you'll end up successfully porting only some syntax and maybe the layout engine.

Furthermore, to a big part SwiftUI is built with many platform-specific idioms in mind, like the common navigation patterns and gestures, typography, even colours etc. One will have to re-engineer a big load of those to make them generic enough to accomodate for more than just Apple platforms and look at least decently over there.

Also, if there is a cross platform ui framework that works on all platforms, someone building a windows/Linux app can easily drop the app onto macos.

This has historically been tried dozens of times and never worked. Being totally honest, even SwiftUI itself doesn't work well macOS currently either. Bringing a yet another platform into the common denominator of a framework that's still unstable even on native platforms from the same ecosystem will most likely just make things even worse for Apple, developers and end users all at once.