As I see it Nim has mostly maintained a neutral position concerning GUIs; that is not favoring or rejecting options. I dont know if it is wise but at least its neutral which is kinda wise ;-)
Quite some GUI-options have been developed, but when uptake stagnates, developers sometimes throttle back on development understandably ..
Some (older) links:
https://github.com/nim-lang/Nim/wiki/Curated-Packages
https://matthiashager.com/gui-options-for-nim/
Elcritch has been active with Figuro lately:
I'm using godot to develop a mobile/desktop app for my business, and I'm using nim to do the heavy lifting. godot has a "low processor mode" config that reduces cpu and gpu usage, making it possible to develop apps using the game engine.
I'm not saying it's the best way, but it's worth a try. There are many good reasons to use it though:
This project is amazing btw gdext-nim.
I'm using godot to develop a mobile/desktop app for my business
That's awesome btw. Good outside-of-the-box thinking, congrats! :-)
I'm really not the "design guy," so don't expect anything amazing. Here is an album with some screenshots and gifs of the desktop version.
But if you are looking for real-world examples, there are some I can mention:
There are good options if one thinks of web technologies as cross-platform UI and potentially native-like. I have used Ionic UI components (Reactive) with CLJS for my front end, made into a PWA (SPA), and use Capacitor to make it native to Android/iOS. UIx, and refx for state management using CLJS. This is my preferred method for any complex UI that must feel fluid and work everywhere but expose different functionalities, and I have clear separation with my core logic.
If my Nim application is purely desktop/workstation, then I stay fully in Nim with Owlkettle.
I've done a fair bit of work with Lazarus and Free Pascal over the years for targeting Mac and Windows. Even the Lazarus project now is deep into work on Fresnel (CSS based, do-all-you-want) to be the next gen moving on from LCL, as CSS is readily composable, works fast, can go beyond typical OS widget lock-ins or limitations.
If someday, someone suitably committed were to begin a project like Fresnel for Nim, I would be glad to join-in. But even otherwise, I'm happy with what Nim offers through its JS interop.
Yes, CLJS can work with JS libraries directly. It is just a PWA with Ionic UI then, and it can be installed from the browser on desktop, and all platforms support it. This stack is web-first and mobile/iPad ready. Can be made native very easily on iOS, Android using Capacitor.
It's quite straight forward with Ionic components to target different screen sizes with SCSS, responsive grids, media queries, etc. You can see a number of examples or tutorials online. The backend (the app core, and data) is written in Nim and deployed natively on the OS core. This allows for strict decoupling, and I have different deployment options for the backend on the client or server, and GraphQL is my only source of truth and the single contract between frontend and backend.
But as I said, if I my application is meant as workstation/laptop only, Owlkettle is my go to, as the app will be Linux native first, and GTK4 has first class support for Mac and Windows. GTK4 also allows to use the native mac title bar and set a global menu bar on macOS. You get a fully native application then on all platforms.
I agree that cross platform GUI is already here and it's seaqt.
Rationale: Native looking cross platform successful open source apps e.g. Transmission seem to use QT a lot. seaqt is special because it doesn't limit you to a particular workflow on the nim side, you just import it and use it.
Regarding seaqt, there's also a companion DSL being worked on here: https://github.com/arnetheduck/nora-poc/blob/master/src/nimside.nim, with usage seen here: https://github.com/arnetheduck/nora-poc/blob/master/src/nora.nim#L154 which allows working more smoothly with QML, slots and signals - nimside is about to become its own library and a balance will be struck between seaqt ("mostly code generated from the C++ headers") and nimside ("mostly convenience stuff to make it feel like native nim").
That said, using seaqt in its raw form is already a solid option, and sometimes the better option vs DSLs.