Writing Gnome Apps with Swift

Original Article ↗ Hacker News Discussion ↗

Swift gaining GTK4/libadwaita bindings is seen as a promising way to bring SwiftUI-style, declarative desktop development to GNOME, potentially offering a fast, type-safe alternative to Electron and traditional C-based GTK apps. Commenters weigh this enthusiasm against concerns about immature or short‑lived language bindings, Apple’s uneven Linux support, and the long, difficult history of “write once, run anywhere” UI toolkits. Many compare Swift’s approach and ecosystem to Kotlin/Compose, Qt/QML, Flutter, Rust GTK bindings, and GJS, debating trade‑offs in tooling, platform integration, and long‑term maintainability.

Overall reaction to Swift + GTK/libadwaita

  • Many find a SwiftUI-like, declarative API over GTK4/libadwaita close to an “ideal” Linux desktop framework, especially for those who already like SwiftUI.
  • Others are wary of new UI stacks that may remain immature, under‑maintained, and niche, making them risky for production apps.
  • Some see this mainly as a proof that “SwiftUI-style cross‑platform UI is possible,” not yet something to bet a product on.

Swift as a language & ecosystem

  • Several commenters praise Swift as modern, expressive, and pleasant, especially combined with SwiftUI and structured concurrency.
  • Criticisms include: ARC and class/struct split, historical threading/concurrency pain (partly addressed by async/await and upcoming Swift 6 data‑race safety), and Apple‑steered evolution with lots of new features.
  • Linux support is debated: official packages target only a few distros, but users report community packages and tools (swiftenv) making Swift usable on many distributions, with Foundation still incomplete in places.
  • Language tooling: sourcekit‑lsp + VS Code and Emacs LSP are reported as solid; some wish for an “Xcode‑lite” cross‑platform IDE.

Cross‑platform UI vs platform‑native

  • Strong skepticism about “write once, run everywhere”: past attempts (Java, Smalltalk, early Flutter, various cross‑platform stacks) often felt non‑native or died off.
  • Others point to Qt/QML as a counterexample that is mature, used in real products, and capable of very native‑feeling apps when carefully styled.
  • GTK on Windows/macOS is widely seen as weak; people doubt GTK4 as a serious cross‑platform base despite its strengths on GNOME.

Comparisons & alternatives

  • Qt/QML and pure Qt are repeatedly suggested as the most practical cross‑platform native toolkit today; libadwaita is preferred by GNOME‑centric users.
  • Flutter is cited as working on Linux/desktop (e.g., Ubuntu’s installer), but concerns about Google’s long‑term commitment surface.
  • Rust+GTK bindings, Vala, GJS/TypeScript, and other DSLs (Relm, QML, various Swift wrappers) are mentioned as existing non‑C options.

Licensing & runtime concerns

  • There is debate about the Swift Flatpak runtime’s GPLv3 license: some argue it’s like a container and doesn’t infect apps; others note that, in general, linking against a GPL runtime can create obligations unless an explicit exception exists.
  • How this applies specifically to Flatpak’s Swift runtime remains somewhat unclear in the thread.