No, it's a GUI application. There are ways of making the GUI parts cross platform, like webview and such. But the GUI parts in this application are native to the OS. "Only" the core functionality is shared between platforms.

This is also something I have been battling with in the past. All the cross GUI platforms have their quirks and problems and varying OS dependencies you are then married to. Since this is my own personal project, I decided cut the knot differently and just do the GUI parts native.

So far, I have found it be incredibly liberating. Instead of trying to instinctively shoe-horn functionality into something that will fit on all platforms, the code itself becomes much clearer when all the really "abstract" or "logic" code is completely separate from the platform code.

This is of course best practice anyway, but the decision to split this way made separation incredibly obvious. When the "logic" parts code cannot communicate with OS resources, you aren't tempted to put stuff where it doesn't belong.

Very interesting. May I ask was what your approach is wrt the Mac GUI: are you going to use XCode's GUI builder or rather build a fully programmatic GUI (that is creating View Controllers, etc. by hand in Objective-C++ )? Have no direct experience myself but I intuitively find the latter approach more appealing. I have seen examples of it here and there.

I don't know yet, whatever feels easier. In Windows, the GUI is made so far with code and RC files.

then i will have to know how to do GUI natively on mac, windows and gtk/linux, not easy to do them all.

for GUI(not gaming GUI like imgui, I just do normal GUI with widgets) cross platform I "shamelessly" do electron, for non-GUI I'm all the way with c++.

Qt is LGPL, no need to pay for a license.

Unless you use the non LGPL modules.

Not that simple, I think it's more than LGPL, IANAL however, its license always confuses me.

Technically, LGPL is also problematic whenever used in appstore applications.