How do you write a proper cross-platform app?

[leothetechguy]

Compiling something for Windows, MacOS or Linux is easy, but supporting android, iOS and the web too seems difficult.
I think the best answer is that you don't, but creating a separate application for mobile, web and desktop is time consuming.

Electron is just a way for WebApps to force everybody to use embedded Chromium, so compiling native code to Webassembly and running it in the browser or a runtime looks like the best option. Or are there any great Cross-platform Toolkits and Frameworks that I'm not aware of?

[noobsoftware]

Mono and .NET are pretty nice options.

[Moonchild]

If you want to write a fully cross-platform "app" then you're going to be limited to very high level languages by definition. Transpiling is a crutch. While it may work relatively well, it's going to inevitably run into issues of some sort.

So you'll have to focus on things like java, html+js+webengine, XUL+UXP+js, or cross-platform things like rapid application builders with native OS support on your targets.

By definition you can't do more than basic GUI design since you can't rely on os-specific native controls. Alternatively you make your own UI and widgets like XUL allows.

[moonbat]

Cross platform apps just end up being shitty to use everywhere, as seen with Electron, the most popular framework for them. In my experience, Qt framework apps are the best at offering native look and feel compatibility on all platforms.

[tcaudilllg]

"Give to Wintel what is Wintel's, give to ARMdroid what is ARMdroid's"

Or use a scripting solution with HTML.

[moonbat]

Or use a scripting solution with HTML.

That's what they're doing currently, resulting in a shitty app that doesn't follow any platform conventions beyond the obvious target of mobile touchscreen. At this point one has to ask why even bother calling it cross platform. I had this issue with web based applications long before smartphones for the same reason - every website has its own design and layout and navigation style unlike a regular desktop application.

[leothetechguy]

Couldn't this just be solved by detecting what the OS is? On Windows and MacOS, imitating the default style can't be that hard.

On linux, only the Desktop Enviroment matters. If it's KDE, imitate QT, else imitate GTK.

[Moonchild]

imitating the default style can't be that hard.

have a look at different versions of Windows and MacOS X and how the "default style" is different in pretty much every iteration...
Same with Linux.. Imitate GTK... 2? 3? 4?

[athenian200]

Couldn't this just be solved by detecting what the OS is? On Windows and MacOS, imitating the default style can't be that hard.

You could, but you would have to write a separate theme for every version of the OS that changed the default styling. So you'd need a Windows 7 theme, a Windows 8 theme, a Windows 10 theme, and a Windows 11 theme for Windows. Plus you'd want to detect any changes the user made to the default theme to try and match them. It's not so much that you can't do that, as that you would be reinventing the wheel by doing that instead of tapping into the default way of using the OS native styling. It would ultimately be more work than keeping up with the changes required to keep using the native styling on various platforms.

On linux, only the Desktop Enviroment matters. If it's KDE, imitate QT, else imitate GTK.

Linux is actually the worst platform on this front. At least with Windows and Mac, there is a native system styling to tap into that you can be sure will look good. On Linux, there is no guarantee the user is using KDE (Qt) or GNOME (GTK). They could using Enlightenment, Motif, or just about anything really. Even if they are using GTK, you don't know if they're using GTK2, GTK3, or even something newer.

What our platform does (I'm not a fan of this approach, we inherited it, and I would not recommend it), is it just assumes that if the user is on Linux or any other platform that uses X11, it should use GTK styling. It actually makes some fairly GNOME 2-centric assumptions that are somewhat applicable to forks like MATE. It uses libcanberra for the "system" sound effects, for instance. The only reason UXP-based apps don't look terrible on KDE is because most distros that use KDE have to install some version of GTK and apply a default theme that doesn't look terrible against whatever the default KDE theme is. This is because there are a ton of GTK apps with no Qt versions, and GNOME was historically treated as a sort of "standard" on Linux, even though there really is no consistent standard and GNOME/GTK changes all the time anyway without regard to backwards compatibility.

Off-topic:
I used early versions of KDE, and I kept finding that all the applications I wanted to use were written against GTK and looked awful on KDE as a result. In general, Linux users often have to deal with having a patchwork of applications that use different frameworks and never having anything look native anyway. It's the price they pay for having as much freedom as they do, and they are pretty much used to it. It's really Windows and Mac users that find an inconsistent user interface jarring. In practice, developers can pick GTK or Qt for Linux, then shrug and tell those users using the other one who aren't happy with the decision to be happy Linux is supported at all.

Interestingly, you could absolutely use Qt or GTK on Windows and Mac if you wanted to, and just have one toolkit for your application that way. I have even used a few GTK/Qt applications on Windows and they don't look too bad. But most Windows and Mac users wouldn't stand for that... because they are used to having applications target the OS native toolkit and would view anything else as broken. Linux users have to be more tolerant of things not matching the moment they go outside of what their distro gives them by default.

[vannilla]

Off-topic:
In theory, the Linux (not UNIX or BSD) approach would be to have an initial toolkit like GTK and then one or more community-backed alternatives that can be chosen before compiling with the configure script.
Nobody does it except a handful of small-to-medium projects because it's not easy to manage especially as new features are introduced, but the "bazaar" model that Linux taught us would work like that.

[mr tribute]

Off-topic:

It actually makes some fairly GNOME 2-centric assumptions that are somewhat applicable to forks like MATE.

This is why Pale Moon looks so good no matter if you use the gtk2 or gtk3 version. There is nothing oversized about Pale Moon unlike the default Adwaita theme for gtk3. Pale Moon only becomes oversized if you apply an oversized gtk3 theme.

Extra padding was added to gtk3 and gtk4 for touch devices - luckily it's CSS so theme makers can make normal themes. I think the Gnome 2 design fits in everywhere, because it's unintrusive and desktop centric. If you really want big padding a gtk3 theme can add that.