AdwaitaUI is a high-level library around GNOME's libadwaita to provide a swifty development experience for building GNOME apps.

Furthermore, it exposes Libadwaita, AdwaitaUI's low-level counterpart, wrapping the C-API.

Currently, this library is a POC and I would greatly appreciate input and contributions from the GNOME and Swift ecosystem.

Currently, there are five to six main languages in the GNOME ecosystem, C, JavaScript, Python, Rust, Vala and C++.

While most of them are easy and [memory-]safe languages, I can't find a language which fits my needs. I want to use a modern, relatively popular, ergonomic and memory-safe language, which is statically typed and ahead of time compiled. This eliminates C, JavaScript, C++ and Python. While Rust and Vala might fit this criteria, Vala is not widely adopted outside of the GNOME ecosystem. In my opinion, Rust is a great high level systems programming language, but it is hard to learn and makes writing desktop-apps overly complicated.

• Handwritten POC
• Exposing all libadwaita widgets
• A declarative API similar to Swift UI
• Reactive programming
  • No React-esque "hook-rules"
  • Build on Apple's observation framework
  • Swift actor-model / async await integration
    • GLib event loop integration (in libdispatch?)
    • Thread safety
    • Reactivity should work in multithreaded programs
  • Do not reinvent the wheel and reference
    • Tokamak
    • SwiftCrossUI
    • Owlkettle
    • Adwaita
    • Relm4
    • Blueprint
    • Vue.js Reactivity
    • Leptos
    • OpenSwiftUI

• Handwritten POC
• Autogenerated via GObject-introspection
  • Prior art done by SwiftGTK
  • gtk-rs
  • gir Rust code generation
  • libadwaita-rs
  • gtk-kn
• Only expose "Swift-native" types
• Automatic memory management without leaks
• Handling of GTK-XML UI files
• Still feel mostly swifty

• Documentation
  • Document the source, so other can follow.
  • Write docs on "Getting Started" and usage
• Build or port an App
• Upgrade to Swift 5.9 as soon as it becomes available on Fedora Arm64
  • Try to still support Swift 5.8
• Common commit message practices
  • Try to follow Semantic Commit Messages
  • Not every commit needs this, but try to explain what you're doing, so other can follow your thoughts.
• Follow best practices
• Decide on license. LGPL-2.1 (upstream) or MPL v2
• Easy contribution road
• Automatic linting and formatting
• Works easily with Meson
• Template with Meson and Blueprint
• GNOME Builder integration