Ask HN: What's the best library for making cross-platform UIs? - rer
======
dahart
It would help a lot to have the question elaborate on what you really need.
What do you mean by "best", and do you actually need the best? Do you need
easy to learn, or code that is easy to deliver, or most powerful features, or
most number of platforms covered? Do you include mobile in cross platform, and
do you have a performance or language requirement?

A web app is one of the most cross platform ways to go, is the easiest to
deliver, and can be easy-ish to learn, but isn't the easiest. But, you are
stuck with JavaScript. If a web app won't work for you, why not? Knowing that
will allow people to help you more.

Qt is great, especially if you're using C++ or some other language. It's
pleasant and very powerful, but a lot to learn, and deployment to users is
harder than a web app.

What are your constraints & requirements?

~~~
mhuffman
I agree across the board with your assessment.

It is a shame that OP does not want to go HTML/CSS engine, because over the
years, I have found that to be the easiest to update, the most reliable across
platforms, and (most importantly) the easiest to support for multiple users.

I have tried (and used in production) most of the UI tookits mentioned here.

WxWindows (later WxWidgets), Tk, and FLTK are getting long in the tooth and
show it.

Java (SWT, etc), looks wonky across platforms and really do not stand up to
the "write once, run anywhere" promise. Also, if you have to do anything even
a little out of the lines, count on keeping multiple codebases for different
platforms.

Although I had a brief love affair with other VM-type platforms (Adobe Air,
Silverlight), mobile mostly pushed support for them out (Air just pivoted to
mobile altogether, I believe). They offered single codebase, easy updates, and
easy-ish support at a cost of have the user install additional software, but
worth the tradeoff in my opinion.

All of the python UI libs are a pain in the ass to distribute, update, and
support.

Ultimate++ and Borland Delphi are pretty polished, but you either have to buy
into their ecosystems or accept their limitations.

At the end of the day, even though Javascript is a bullshit language for
desktop development, HTML/CSS engines (phonegap, Electron, sciter, etc) are
just pleasant for maintaining codebase, pushing out updates, doing anything
you want with the UI, and support has been a breeze.

~~~
rer
Why is Tk getting long in the tooth? This comment believes Tk is as good as
wkWindows and QT
[https://news.ycombinator.com/item?id=12380456](https://news.ycombinator.com/item?id=12380456)

~~~
mhuffman
Tk and WxWidgets are not in the same league as QT.

Tk is limited, specifically, to being a gui toolkit, and even though the most
recent versions look like native widgets, they are limited and the online
support (from groups, etc) is limited. All the connecting libraries feel like
you are back in the 90's programming again.

WxWidgets is to QT, as Linux is to Mac OS X -- one is cobbled together from
amateurs with varying quality of components, and the other is built by
professionals and held to professional rigor. The API (and output, in my
opinion) is amateurish and dated in comparison. It lacks the polish and
ecosystem that the professionally-supported QT has.

If you are making a full-fledged application (as opposed to a user tool or
back-end interface) and are hell-bent on using a windowing toolkit (over say
an HTML/CSS engine), then QT is currently the only correct answer. There are
others around, but they all fall short of QT.

On a side note, Tcl (by the same original author as Tk) is a wildly under-
appreciated scripting language.

~~~
rer
Thanks for sharing this knowledge.

What can Tk not do, specifically? This thread believes Tk is as good as QT
[https://news.ycombinator.com/item?id=12380456](https://news.ycombinator.com/item?id=12380456)

~~~
justinclift
This might help illustrate:

[http://forum.sqlitestudio.pl/viewtopic.php?f=16&t=334](http://forum.sqlitestudio.pl/viewtopic.php?f=16&t=334)

That post is by the lead developer of a SQLite project competing with the one
I'm involved in. The original version was developed in Tcl/Tk, and outgrew it.

Note - I'm not personally familiar with Tck/Tk, I just remembered reading this
when you mentioned it. :)

------
babuskov
Strange nobody mentioned wxWidgets so far which gives you true native apps, so
I'll do it:

[http://wxwidgets.org](http://wxwidgets.org)

It provides API layer which compiles to Win32 API on Windows, Gtk2 on Linux
and Carbon/Cocoa on Mac OSX.

Qt only emulates Windows controls, but wxWidgets uses the actual Windows
controls via Microsoft Win32 API.

BTW, there's wxQt, a wxWidgets implementation that uses Qt instead of Gtk, but
it's still experimental:

[https://wiki.wxwidgets.org/WxQt](https://wiki.wxwidgets.org/WxQt)

wxWidgets has been used by some popular projects like Audacity, TortoiseCVS,
RapidSVN, FileZilla, BitTorrent, etc.

Another wxWidgets advantage over Qt is the license, which gives you more
freedom.

If you're looking for a faster start, take a look at wxFormBuilder which is a
graphical WYSIWYG UI editor where you can drop controls in windows/dialogs and
hook up event handlers.

You can find links to more related tools/IDEs on the Wikipedia page:

[https://en.wikipedia.org/wiki/WxWidgets](https://en.wikipedia.org/wiki/WxWidgets)

~~~
Svenstaro
In my experience with it, wxwidgets has a very antiquated feeling to the API
(I know, subjective) and it didn't ship high DPI support when I used it. Its
Python bindings at the time felt rather unpythonic. Generally I wouldn't want
to use this again.

~~~
fsloth
"wxwidgets has a very antiquated feeling to the API"

This should not be relevant in any professional technical discussion. Last
time I looked there was not an overflowing oversupply of cross platform UI
frameworks.

"it didn't ship high DPI support "

This, on the otherhand, might be a critical deficit.

~~~
orbitur
> This should not be relevant in any professional technical discussion. Last
> time I looked there was not an overflowing oversupply of cross platform UI
> frameworks.

That latter sentence kinda defeats the argument in your first sentence.

If there's a dearth of options, then there's room for a better API.

~~~
fsloth
"If there's a dearth of options, then there's room for a better API."

A new UI framework is not something you can wish for Christmas. One can
implement one (like Blender has done) but other than that, one is limited to
the options which are available.

I don't think anyone claims there is no space for new UI libraries. It's not
obvious one can simply implement a new one. This is not something someone does
for fun over a weekend (at industrial scale) or just to try an epiphany of
design over a few months. They are huge, laborious beasts. If one has
resources to implement a huge UI framework, then generally, they probably have
the resources to implement the UI natively on every platform they wish to
deploy on.

"A better API" is kinda moot feature for a UI library since they are
technically so demanding, all other factors are more critical.

------
networked
What is the best depends on your exact requirements but three good options to
get a GUI off the ground quickly are Tk [1], wxWidgets (and wxPython [2] and
wxLua [3] in particular) and Lazarus (LCL) [4].

Tk widgets look native on Windows and macOS (if you use the right ones — see
[5]), though their behavior is implemented by Tk itself. On Linux it draws its
own widgets in several styles; GTK and Qt theme support is immature. Lazarus
and wxWidgets use native widgets on Windows and macOS. Both can use GTK2 on
Linux but Lazarus also supports GTK1 and Qt.

If I had to deliver a cross-platform desktop GUI application by midnight
today, I would go with Tk, write the code in Tcl (which necessarily has the
best Tk integration) and package it in a static binary Starpack [6].

[1] [http://www.tkdocs.com/](http://www.tkdocs.com/)

[2] [https://wxpython.org/](https://wxpython.org/)

[3] [http://wxlua.sourceforge.net/](http://wxlua.sourceforge.net/)

[4] [http://www.lazarus-ide.org/](http://www.lazarus-ide.org/),
[http://wiki.lazarus.freepascal.org/LCL](http://wiki.lazarus.freepascal.org/LCL)

[5]
[http://www.tkdocs.com/tutorial/idle.html](http://www.tkdocs.com/tutorial/idle.html)

[6] [https://tcl.wiki/Starpack](https://tcl.wiki/Starpack)

~~~
witty_username
Tk is antiquated (no antialiasing [1]) and has a poor look on Linux. It lacks
functionality in widgets such as embedding a progressbar in a tree/list (don't
remember) widget, which Qt supports. Also, poor font rendering support.
(doesn't render Devanagari and probably CJK scripts). It feels like a 10 year
old tech which it is.

(1) Maybe there is some option for it somewhere, but if so, having
antialiasing disabled by default is weird.

~~~
jrapdx3
Suitability of Tcl/Tk depends on what the goal is. For some applications, like
utilities, GUI access to CLI tools, form-based data entry, etc., Tk is fine.
It isn't a good option for a sophisticated drawing program, and I would try to
use it for a full-bore word processor.

Within its domain, Tk is a very capable tool that easy to use, well-
documented, versatile and relatively bug-free.

Future versions are planned to acquire antialiasing and other improvements, no
doubt it will be a while before it's available.

~~~
rer
From what I'm reading in this thread, Tk is out of the question. Poor
antialiasing sounds like bad looks.

~~~
auriocus
I don't understand how anyone can assume that antialiasing is missing in Tk,
it's simply wrong and has been there for many years for font drawing. On
Linux, it must be compiled against fontconfig/xft (default, if the headers can
be found). On OSX and Windows, it uses the native font renderer. The only
point on OSX high dpi displays: you need to set a property that the
application supports high dpi (in a .plist file), but this holds for any App-
bundle on OSX. Antialiasing on a canvas (as opposed to text in labels, buttons
etc.) is only enabled in OSX by default. tkpath replaces the default canvas
with a more complete implementation (alpha blending, gradients,
antialiasing...) on all 3 platforms.

~~~
rer
Thanks so much for this! I know very little about Tk.

Besides antialiasing on a canvas, does antialiasing also work in text in
labels, buttons, etc? Can I get in Tk all the fonts I can get in a Mac? Is
Helvetica there?

Why can't I find on the web screenshots of Tk apps running on Mac OS X? Is the
only way to get Tk to look good on a Mac using Tile
[http://tktable.sourceforge.net/tile/screenshots/macosx.html](http://tktable.sourceforge.net/tile/screenshots/macosx.html)
?

From what I'm reading now there might be 4 options: Tk, wxWindows, QT, and a
custom "thin layer".

~~~
networked
The link [5] in my top-level comment plus
[http://www.tkdocs.com/tutorial/fonts.html](http://www.tkdocs.com/tutorial/fonts.html)
should answer your questions. The former has screenshots of Tk on macOS and
discusses how to make it look good there. There is a screenshot of a
commercial Mac application built with Tk at
[http://www.codebykevin.com/portauthority.html](http://www.codebykevin.com/portauthority.html).

Tile was integrated into Tk with version 8.5 (2007). The Tile button, label,
etc. are now built in.

~~~
rer
This comment says Tk is limited
[https://news.ycombinator.com/item?id=12381978](https://news.ycombinator.com/item?id=12381978)
You and the GP say it's not.

Is there anything Tk can't do?

Also a question on fonts. Does Tk make it possible to use webfonts I see on
websites?

~~~
networked
>You and the GP say it's not.

But I did not say that. In the reply to the comment you've linked you write
that "this thread believes Tk is as good as QT". I am puzzled by this
conclusion because I do not see any comparison to Qt at all. Certainly, I
didn't want to suggest any with my comments.

If you want to know my option on how Tk compares to Qt, I currently believe
that, for the most part, they serve different use cases, with some overlap in
the middle. Tk is better than Qt in one area (roughly: small-to-medium
applications developed by a lone hacker ASAP) and Qt is better than Tk in
another (roughly: medium-to-large applications developed by a team on some
sort of a schedule).

Qt does a lot more than Tk. It comes with more features, e.g., networking
abstractions. Compared to it, Tk _is_ limited. Qt looks better, too — much
better on *nix. I would not recommend Tk over Qt in the general, catch-all,
could-become-a-kitchen-sink-application case. (In fact, working well in the
general case seems to be a major selling point for Qt.) If you develop one,
chances are you will find yourself wanting to do something that Tk can't. In
other words, I would expect a large application to outgrow Tk before it
outgrows Qt.

I recommended Tk specifically for making a GUI quickly. It is good for
prototyping and rapid iteration and has neat widgets like canvas and the text
editor that help a lot with that. Tcl with Tk is expressive, so you can do a
lot in under 1000 lines of code (toy example: [1]). The Tcl REPL helps more
still, as does a great binary deployment story. After the prototype or MVP,
once you understand what you want to do better, you may stay with Tk if you
decide it suits your needs or switch to something else.

>Is there anything Tk can't do?

That is a very open-ended question. One thing that comes to mind is
integrating with the host platform's accessibility features. Most cross-
platform GUI toolkits suck at it. There is a wishlist wiki page [2] that might
offer some hints at what other things Tk users find missing.

>Does Tk make it possible to use webfonts I see on websites?

Not easily. See [3].

[1] [https://tcl.wiki/41294](https://tcl.wiki/41294)

[2] [https://tcl.wiki/4055](https://tcl.wiki/4055)

[3]
[https://www.reddit.com/r/Tcl/comments/456ydh/is_there_a_way_...](https://www.reddit.com/r/Tcl/comments/456ydh/is_there_a_way_to_load_a_ttf_font_file_and_use_it/)

~~~
witty_username
> I recommended Tk specifically for making a GUI quickly. It is good for
> prototyping and rapid iteration and has neat widgets like canvas and the
> text editor that help a lot with that. Tcl with Tk is expressive, so you can
> do a lot in under 1000 lines of code (toy example: [1]). The Tcl REPL helps
> more still, as does a great binary deployment story. After the prototype or
> MVP, once you understand what you want to do better, you may stay with Tk if
> you decide it suits your needs or switch to something else.

Actually, I would argue the opposite. I found it easy to create GUIs using Qt
Designer and to use connect() to bind functionality together. (Albeit, this
was with Python, it might be harder in C++).

> widgets like canvas and the text editor

Is there something particularly unique in Tk's canvas and text editor?

------
edtechdev
React Native supports

* iOS

* Android

* OS X [https://github.com/ptmt/react-native-macos](https://github.com/ptmt/react-native-macos)

* Windows [https://github.com/ReactWindows/react-native-windows](https://github.com/ReactWindows/react-native-windows)

* Ubuntu [https://developer.ubuntu.com/en/blog/2016/08/05/introducing-...](https://developer.ubuntu.com/en/blog/2016/08/05/introducing-react-native-ubuntu/)

* the web [https://github.com/necolas/react-native-web](https://github.com/necolas/react-native-web)

~~~
babuskov
AFAICT, it isn't "Windows", but "Windows 10 only".

Is this correct?

~~~
jc4p
Yes the windows link above is for Universal Windows Platform apps which isn't
what most people think of when they think "windows app". For React Native on
desktop I've been bundling my React app into a Electron shell, works pretty
well.

------
scrollaway
Qt has a truly pleasant API and bindings in many languages. If you haven't
used it before - and I know you haven't, otherwise you wouldn't be asking :) -
give it a try. There's very little that's more cross-platform.

~~~
ryandrake
Qt's nice, but the thing I've always disliked about it is that it re-
implements all these basic types, like QString, QVector, QList, QMap, etc. and
you need to use them to interact with all their APIs. So, you either have to
decide you're all-in on Qt and have these QThis and QThat types littered all
over your code (making it more difficult to interact with other third party
libraries like boost that know nothing about Qt, or you need to agree on a
boundary between your non-Qt-specific code and your UI, and maintain a layer
that converts to and from standard types.

~~~
gusmd
I'm working on a Qt project, and our convention is to have a pure C++ back-end
(i.e., STL), but use QObjects everywhere on the Models, Views and Controllers
(as per Qt's MVC pattern). That way we can one day re-implement the UI if
needed and keep the same "pure" C++ back-end. This has worked fine for us so
far.

~~~
steaminghacker
+1. that's exactly what I do.

------
fitzwatermellow
Just getting started on Electron myself. Used by Atom, Slack, Visual Studio...
It's worth a look ;)

Electron - Build Cross-Platform Desktop Apps With HTML, JS, CSS

[http://electron.atom.io/](http://electron.atom.io/)

~~~
jbergens
Electron only works for desktop applications and probably needs a js-framework
to work good. I think that React + Electron looks like a nice combo and then
you can use React Native to create Android and iPhone apps also, probably
sharing a lot of code between all versions.

~~~
WorldMaker
At the moment the pairing seems to be Electron + Cordova for non-React JS
frameworks; with those two you can share 100% HTML at least if you have a
responsive CSS design.

Also, now that React Native is extending into the Desktop space more directly
(with Linux, Mac, and Windows UWP variants), for React you may not need
Electron at all.

~~~
WorldMaker
Further aside, I'm also amused and unsurprised that engineering has been going
into React Native for Web [1] so that with React Native you might not even
target base DOM React again.

[1] [https://github.com/necolas/react-native-
web](https://github.com/necolas/react-native-web)

------
knabacks
There are plenty of options (all biased by personal opinion) for this task.
Maybe one of these projects is a good fit for you (creating consistent uis
should be easy with all of these).

\- [https://crosswalk-project.org/](https://crosswalk-project.org/)

\- [https://cordova.apache.org/](https://cordova.apache.org/)

\- [https://kivy.org/](https://kivy.org/)

\- [https://www.nativescript.org/](https://www.nativescript.org/)

\- [https://www.xamarin.com/](https://www.xamarin.com/)

\- [https://facebook.github.io/react-
native/](https://facebook.github.io/react-native/)

#

\- [https://www.wxwidgets.org/](https://www.wxwidgets.org/)

\- [http://nwjs.io/](http://nwjs.io/)

\- [http://electron.atom.io/](http://electron.atom.io/)

------
edko
"The best" is subjective. I have played around with libui
([https://github.com/andlabs/libui](https://github.com/andlabs/libui)), which
runs on Windows, Linux, and macOS. A nice thing about it is that it is written
in C, and therefore has bindings with several programming languages. I have
experimented using it from Java (via JNA) and it works quite nicely.

~~~
rer
libui is kind of neat. It wraps around GTK+. Why did libui have to do that? In
other words, is GTK+ bad enough that the easiest way to use it is to wrap
around it?

~~~
barrkel
GTK+ is dreadful on Windows. I'd stay away.

Personally I implement the UI in as thin a layer as can be architected and
reimplement for every platform. It's the best way, and probably cheaper for
most apps than trying to force some lowest common denominator library to
express what you want in high fidelity.

~~~
rer
Ok, no GTK+! (Could this be fixed with GLib?)

I didn't understand this. When you say you implement the UI as a thin layer do
you mean you wrap only the few controls you need?

~~~
andlabs
libui only wraps around GTK+ on Unix systems. On Windows, it uses the native
Windows API directly.

GLib is a utility library; it provides things like container types, filesystem
access, networking utilities, threads, object-oriented programming with events
and properties, and other similar functions in a platform-independent manner.
GTK+ uses GLib. You can use GLib on its own as well. It won't solve the
problem of GTK+ being clunky on Windows, though.

~~~
rer
What I don't get is: which library lets you draw stuff on the screen. GLib or
GTK+?

I thought that was GLib, and GTK+ was using GLib to implement controls.

Which library does one need to build their own controls?

------
rer
Here's what I want.

\- The UI to look as good or better than the UI on Mac OS X. I'm not willing
to compromise on looks.

\- The library to be cross-platform. I want to deploy the software on Mac OS
X, Windows, and Linux. I don't care about mobile right now.

\- I want it to be possible and easy to (a) develop new features on my own and
(b) change existing features. I'd rather reimplement a textbox from scratch if
it's the only way to change a control. If this means I need something more
like GLib instead of GTK+, so be it.

\- I won't use the web. No HTML, no CSS, no Javascript. Sorry.

The end goal is to build the best, easiest UI environment to write software
with. If it's not possible to build this with existing UIs and I have to write
one from scratch, so be it.

~~~
rwmj
Pretty sure that C++ and Qt is what you want. Maybe not perfect in every
sense, but widely used and battle-tested.

If you don't want to deal with Windows, you can cross-compile for Windows from
Linux using the mingw-* packages (eg
[https://fedoraproject.org/wiki/MinGW](https://fedoraproject.org/wiki/MinGW)
or the Debian or SUSE equivalents).

~~~
SXX
Or you can use preconfigured cross-compilation toolchain like MXE[1]. If you
have clean codebase and use CMake it's usually enough to just pass one extra
argument to get working binary out. And it's also work on OS X.

[1] [http://mxe.cc/](http://mxe.cc/)

~~~
justinclift
MXE has an ok reputation. Not everything seems to play well with it though. :(

For example, we (sqlitebrowser.org) compile our window nightly releases from
Linux, using MXE. But, SQLCipher (an encryption library) doesn't build with
MXE. So the nightlies don't support encryption.

Meanwhile, we've figured out how to do full Windows dev setup and builds. eg:

    
    
      https://github.com/sqlitebrowser/sqlitebrowser/wiki/Setting-up-a-Win64-development-environment-for-DB4S
    

We're building our releases natively now, and the nightlies will be built
natively too in (hopefully near) future.

Guess we just outgrew MXE?

------
doozy
None, abstract the functionality of your app into a cross-platform library and
build a native GUI for each platform you support using that platform's native
SDK.

~~~
rer
Shouldn't this be a solved problem?

~~~
paulddraper
There's a reason there are multiple OS's, right?

One of the reasons is different UI paradigms and choices.

------
open-source-ux
Take a look at Free Pascal and the Lazarus IDE.

What is a Lazarus? From their website:

" _...a cross-platform IDE for Rapid Application Development. It has variety
of components ready for use and a graphical form designer to easily create
complex graphical user interfaces._ "

Why use Lazarus and Free Pascal? You can create native, cross-platform UI's
all combined into a single, fast, low-memory executable that can easily be
deployed and distributed on different platforms.

[http://www.lazarus-ide.org/](http://www.lazarus-ide.org/)

------
gwbas1c
I work on a cross-platform application that runs on both Windows and Mac.

We have a cross-platform library for business logic, and native Windows and
Mac UIs.

The problem is that cross-platform UI libraries don't really let you fine-tune
the UI. They're great for very rapid development with a basic, functional, UI.

If you get an "artiste" in product management, or you need to plug into
Windows-specific and Mac-specific functionalities, you will need to use
platform-specific UI libraries and keep your business logic platform-neutral.

~~~
rer
> cross-platform UI libraries don't really let you fine-tune the UI

I want to be able to fine-tune the UI.

~~~
infinite8s
You can't have both - cross-platform with native looks yet fine tunability,
since those desires are at odds with each other (unless you want to implement
that tunability for each platform you support).

------
anmorgan
I've recently been using Crank Storyboard and I've been off to a good start.
You can run it on embedded devices like ARM Cortex-M series processors, or
Linux, iOS, Android, Windows, with openGL support. It does require a license
though.

[http://cranksoftware.com/storyboard-
suite](http://cranksoftware.com/storyboard-suite)

Also someone else mentioned Phonegap and using HTML/JS. I think is a good
option but it depends on what your app does and if you're doing mobile app
design.

I have not used QT yet, but after doing some research, it's kind of a pick
your poison type of choice, IMO.

------
tyfon
I have tried many but always turn back to qt. It has bindings for whatever
language, compiles for any platform and the documentation is superb.

------
mushiake
IUP[0] has not been menthioned.

IUP is wrapper for gtk+, motif and win32.

Pros:

* really simple api

* native toolkit

* c api, so other languages can easily write binding for it

Cons:

* controlls(widgets) are limited

* cocoa(mac) is not supported {they suggest to use gtk instead}

* documentation is spotty

* nobody is using? (I believe no linux distros have it in repository)

somebody here menthioned libui[1], it is exactlly the same philosophy

[0][http://webserver2.tecgraf.puc-rio.br/iup/](http://webserver2.tecgraf.puc-
rio.br/iup/)
[1][https://github.com/andlabs/libui](https://github.com/andlabs/libui)

~~~
corysama
There is a project to add cocoa support that would appreciate some help.

[https://github.com/ewmailing/IupCocoa/tree/Cocoa](https://github.com/ewmailing/IupCocoa/tree/Cocoa)

------
antonios
If you don't want a _native_ GUI, you can go the Electron way. This way you'll
have a fully cross-platform application with minimum hassle.

If you want a native one, probably Qt is the winner here.

------
zackify
React (Native). You can build an iOS and android app with the same codebase.
Even windows phone and ubuntu are starting to support it. Then when you want
to use the web, your whole data layer can carry over to reactjs. It's a really
nice way of doing things. There's even react native for Mac OS that someone
has started.

~~~
alexmuro
You can also wrap the reactjs web application in in Electron
([http://electron.atom.io/](http://electron.atom.io/)), which supports Mac,
Windows and Linux.

------
mherrmann
For a file manager I'm developing [1], this question recently boiled down to
Electron vs (Py)Qt. I chose (Py)Qt because Electron's startup speed is too
slow.

[1]: [https://fman.io](https://fman.io)

~~~
infinite8s
How are you handling licensing? Are you using the commercial version of PyQt?
I've been thinking of distributing some apps I've built but I don't want to
make them GPL (I don't mind using MIT or BSD though).

~~~
ptman
There's PySize [https://wiki.qt.io/PySide](https://wiki.qt.io/PySide) but it
probably needs work

~~~
infinite8s
PySide doesn't work with Qt5 yet.

------
jlarocco
It depends on what language you're using and your requirements, but my
preference is Qt. It has bindings to several languages; it supports most
common platforms; the API is consistent, stable, and well documented; and it's
easy to get up and running on all of the platforms it supports.

One complaint people have about Qt is that it doesn't "look native" enough.
That's not something I personally care about, and it's not a problem at all
for the applications I write, but it's an issue for some people. IME, that's
just a trade off of using a cross-platform GUI library. If the layout is good
and it's easy to use, most people won't care if it doesn't look native.
Photoshop doesn't "look native" either, yet it has a huge following and brings
in a ton of money.

------
levbrie
My vote is for electron, although I'm following how React Native develops
really closely. From what I've seen, the best new "Desktop" apps tend to be
built with electron. We've been using it in production and, despite having to
make pull requests for framework-level bugs fairly regularly, we've haad a
pretty good experience overall, and far better than anything else we've tried
- although, as I said, we have yet to seriously look into React Native. Also,
by cross-platform I'm assuming you mean OS X, Windows, and Linux. If you also
want to include mobile, then there are so few options there's no longer any
real reason to debate.

------
SeaDude
I'm barely a geek, let alone a hacker, but have been trying to learn
NativeScript for the past month or so. You might want to check it out.

Not sure how it compares as a "library" or "framework" etc. I'm still figuring
out where the lines are drawn.

[http://docs.nativescript.org](http://docs.nativescript.org) Emulator Here:
[https://docs.genymotion.com](https://docs.genymotion.com)

~~~
rer
No Javascript, sorry.

------
melle
Depending on the type of UI, you could also give Kivy a try.
[https://kivy.org/](https://kivy.org/)

It's python based, and really easy to get going. It does have it's quirks, but
overall I found it a joy to use.

~~~
BucketSort
I've had some hard times porting Kivy to the Raspberry PI 3 on Raspbian. It is
a decent toolkit, but I'm not so sure on the ease of cross-platform.

------
tariqrauf
Depends on what you're after :)

Electron or QT for cross-desktop apps, Angular & Ion framework for cross-
mobile apps, React & React-native for cross-mobile apps

~~~
api
There are efforts to bring React Native to desktop but I don't think they are
production ready yet.

~~~
tariqrauf
you can get react on desktop with electron

------
tumdum_
There is also swing and javafx if you want to use jvm.

~~~
Cyph0n
JavaFX is amazing, but I'm not sure how it holds up when an app gets complex.

~~~
WoodenChair
I think a bigger problem is that less and less end users have the JVM
installed.

~~~
mushiake
You can use javapackager.

~~~
invalidname
Did you try to using it in production? It's flaky at best...

------
agentultra
It depends on what you mean by, "cross-platform." In my world there is no such
thing. You pick your target platforms and program to them. However it is
common to imply "major platforms" (ie: _iOS_ , _Android_ , _Windows 10_ ,
_OSX_ ). Different platforms have different requirements and will shape your
solution.

Next... what is the application? Do you need to target native APIs? Do you
have memory limitations?

If you don't mind taking up a lot of memory try one of the "cross platform"
systems like Xamarin or some Java-based solution. If you need to be more
constrained try writing to the native APIs and porting your project to each
target platform you need to target. Lastly if you're highly constrained maybe
you need to try an immediate-mode style library like Nuklear[0].

It really depends on your needs. There's no one-size-fits-all.

[0] [https://github.com/vurtun/nuklear](https://github.com/vurtun/nuklear)

~~~
rer
> there is no such thing

Why?

~~~
agentultra
Different platform, different requirements.

If a language run-time or virtual machine promises, "you can write code once
and run it anywhere," then they're not telling you the whole story. There's no
such thing as, "cross platform." It's just a vague term that is commonly
interpreted as, "major OS platforms," or, "most popular mobile platforms,"
etc.

Requirements are both technical and non-technical. If we just focus on the
technical requirements you have to look at the data you're working with, your
user, and how the program interacts in this system between the human and the
rest of the world. If you're writing safety-critical mobile applications for
remote workers that spend a week or more in the field you're probably not
going to waste your resources on a memory-hungry VM just so that life is more
convenient for you. That's starkly different to prototyping an application in
a lab where convenience is paramount compared to cheap resources. I have yet
to see any kind of language or run-time that lets you have it both ways.

One may say, "Yes agentultra, but what about generating the code for the
highly-constrained environment from the higher-level language?" I love this
approach. It's possible to generate _efficient_ code this way. This approach
still requires you to understand your target platform well enough to spot bugs
in the generated code. So while it may be an approach to gain some leverage as
a single developer or small team; you're still quite constrained but this
DSL... the same code written for the DSL is not likely going to run well or
even be considered for use by your other target platforms.

I haven't yet found a way to "escape" the reality that different combinations
of hardware and OSs require different solutions for different applications. It
may seem like "all you need is Java" or X, Y, or Z -- but the reality is more
nuanced than that.

~~~
rer
> I have yet to see any kind of language or run-time that lets you have it
> both ways.

If there were such a language I wouldn't be asking this question on HN. I have
yet to see a clear answer _why_ there is no such kind of language or run-time.

> the same code written for the DSL is not likely going to run well or even be
> considered for use by your other target platforms.

Why? Can be you more specific with an example?

~~~
agentultra
> I have yet to see a clear answer why there is no such kind of language or
> run-time.

... I'm having trouble not being glib in my response. I want to say, _because
computers_. But let's be a little hand-wavey for a moment.

As programmers we sometimes put too much faith in our poorly-thought-out
abstractions. We think, "why is there not a library/runtime/VM that abstracts
away all of these painful, tedious details? Surely someone must've invented a
GUI library that runs on all platforms, perfectly." We look for ways to avoid
the difficulty of thinking too hard about it. We just want to write an
application and not think about operating systems, hardware architectures,
memory allocation, etc, etc.

Well there are systems that do remove some of the effort in writing such
applications. They will manage memory for you, abstract away the differences
in various operating systems, and they might even provide a common library for
writing a GUI that works across all of the platforms that the VM/runtime
supports... this is a great tool to have.

However it has a cost. It has it's own memory model. It makes assumptions
about what GUI interfaces are. It targets the common denominator between
operating systems. It is, by necessity, quite complex on the inside... so as
long as you can sit comfortably in the box and write programs that the system
expects you to write you can safely ignore the hairy details of allocating
memory, making system calls, managing resources, etc.

But if your application requirements pull you out of that comfort zone be
prepared to have to deal with garbage collection algorithms and mapping your
application's data to the runtime's model. That has a cost.

For some applications that cost isn't worth it or even feasible. How much
battery power are you willing to consume? How many updates to the simulation
can you make per second? How fast do you have to stream that data of the disk
to this other component?

These languages and runtimes that claim to be "cross platform" are really just
selling you a subset of functionality on a subset of platforms that you may or
may not care about. It's never what you intuitively assume it to mean, "write
once, run everywhere."

> Why? Can be you more specific with an example?

I wrote a 6502 assembler in Common Lisp many moons ago. With it I was able to
write applications for that processor in a high-level language with all of the
Common Lisp tools I was used to. However that DSL was restricted to that
platform backend.

Had I a requirement to target another platform, say x86_64, I would have to
write another backend for my high-level DSL and introduce plumbing to my build
tools to produce the executable code for either platform. Great! Cross
platform code!

Well... not _really_. I still had to write two different backends. And I can't
really exploit the unique features of either. I can only really make use of
the common denominator between both or else emulate features of one in the
other at the expense of making one platform less performant/useful than
another.

There's no such thing as "cross platform." It's just a marketing buzz-word.
There are hardware platforms. There are operating systems. These are the
things we program.

Abstractions are great but they're not free and they don't free you from
thinking. It's an easy mistake to make because it comes so naturally to us
humans -- we hate doing things that are difficult. But there's nothing natural
about programming. It's hard.

------
tylerlarson
A few other people have mentioned JavaScript and HTML but in my experience
HTML and CSS support varies wildly between platforms and as applications
become larger it is difficult to tune the performance of your running
application. Also the implementation of the base code for HTML tags and what
CSS properties can do are inaccessible to JavaScript making many task much
harder than they would be in other environments where you can simply extend or
introspect the internals.

But if you want something to run everywhere including web browsers, JavaScript
is the only realistic option. So we make do. My current approach is to rely on
HTML/CSS and React/React Native for the easy stuff and everything else is
rendered in the Canvas tag with lots of JavaScript to bend the platforms into
doing what you want.

In the past I have taken similar approaches by using things like Ejecta but
the android support for this is lacking and now that WKWebView has addressed
many of its issues, using standard WebViews within native containers is fast
enough on mobile.

On desktop, Electron, NW or the other things like this can fulfill the same
setup.

People will complain about performance which was a really big issues a few
years ago but today the difference isn't large enough that it can't be worked
around and most of the fear is in people heads. Most environments have web
workers, and webgl, and JavaScript that has a JIT, and many new things like
Web Assembly and SIMD should be available in the coming years making these
platforms even more viable.

------
shireboy
Not a library per se, but HTML+CSS+JS. Bootstrap or some other mobile
responsive framework. Works on just about every device&OS. Phone gap or
similar if you really need native.

~~~
DougWebb
+1, because I had the urge to say the same thing.

I think the question needs to be a lot more specific about the type of app and
the platforms it needs to run on. Web-based applications give you the broadest
reach for the lowest cost if you can assume internet connectivity and if the
GUI that's possible from within the browser sandbox is sufficient for your
needs. (Capabilities are growing all the time, but it's still not the same as
native.) If your app needs to be offline, it's still possible with web tech
but it's harder to justify, unless you're doing a hybrid of online and offline
and the online part isn't just service calls.

------
antoineMoPa
GTK may have a difficult API, but it is portable and it gives a better feel
than Qt for Linux+Gnome users like me (I will always choose a GTK app over a
Qt app).

~~~
justinclift
GTK's documentation is atrocious for anything in depth, and has been for
years.

Saying that from wrongly choosing it over Qt for a cross platform
screenrecording/annotation project a few years ago.

There's literally no way in hell to recommend GTK for any new desktop project
that likely has a Windows audience. GTK is a mess. :(

~~~
rer
@geraldcombs and @justinclift I didn't know any of this, thanks so much!

It sounds like GTK is eliminated too.

What's left now, QT and wxWidgets?

~~~
justinclift
If you're looking to do a desktop GUI type of application, then those two are
decent choices.

If you have skill in C++ already, then Qt is a natural fit there. Also, Qt's
docs are _very good_. None of the "oh, I was advised to use this class. Where
are the docs? What do you mean... go read the source code?".

Gah... sorry... still haven't gotten my __extremely bad __experiences with Gtk
out of my system (years later). ;)

If I were doing a desktop GUI type app again, I'd choose Qt for sure. Good
docs, very large user base, actively helpful Community on IRC. (I'm not really
a forums guy). Plus, bunches of Qt code (of various quality) on GitHub for
getting ideas from.

Hope that's useful. :)

~~~
rer
There seems to be a third choice though. Writing a "thin layer", which sounds
like writing one's own wxWindows or QT.

I want to know the difference between the thin layer and the existing
libraries. Not in vague terms but specifically with a code example.

~~~
justinclift
Hmmm, on first thought, writing "thin layer" sounds like a potential
boondoggle.

But then again, it's not something I've personally tried (nor needed), so that
might be an inaccurate assessment.

If you don't need a full/complete GUI stack (and other related bits)
implementation for your application, then yeah, it might be the way to go.

------
SyneRyder
I'll throw in a mention for Xojo:

[http://www.xojo.com](http://www.xojo.com)

Xojo used to be called REALbasic, and it's a cross-platform 'Visual Basic'
with support for Windows, Mac, Linux, iOS and Raspberry Pi. I tend to use it
for internal tools that need to run on both Windows & Mac, and find it's great
for getting to a prototype stage very quickly.

~~~
rer
Is it open-source?

What I want is closer to writing my own Xojo.

~~~
SyneRyder
Xojo isn't open source, but I think Lazarus is. It's an open source cross-
platform version of Delphi, which could be described as "Visual Pascal". I've
not used Lazarus myself but I used to use Delphi.

[http://www.lazarus-ide.org](http://www.lazarus-ide.org)

------
Sir_Cmpwn
I like Xwt: [https://github.com/mono/xwt](https://github.com/mono/xwt)

Used it for the TrueCraft launcher:
[https://github.com/SirCmpwn/TrueCraft/tree/master/TrueCraft....](https://github.com/SirCmpwn/TrueCraft/tree/master/TrueCraft.Launcher)

------
pipio21
It depends on what you need.

In the past we used GTK and wxwidgets with OpenGL but we did not like it.

We started using Qt, much better(proper object oriented by design, and cleaner
design than wxwidgets) and web apps. Now we use native libs with our own
multiplattform lib with bindings for each plattform:

-javascript for the web.

-native cocoa and windows libs, with openGL, metal and directX.

-Qt for linux with OpenGL.

\- Native mac(iOS and cocoa) and windows.

------
heavenlyhash
There's a lot of great web-tech based solutions. Other commentors are covering
those, so I'll suggest something different: For a take outside of the web,
Golang with OpenGL bindings has a lot of promise for shipping $everywhere.

The [https://github.com/go-gl](https://github.com/go-gl) github org has repos
with comprehensive pre-generated OpenGL linking. When building off these, you
need almost zero interaction with any host libraries. Cross compiling is a
_breeze_. I made a demo application on Linux one afternoon to try it out: I
was able to hand the code to a friend with a Mac, and he compiled and ran it
_first try_. It's hard to understate the level of "wow" there.

Golang+GL also ships to mobile devices. There's a little squeeze dealing with
the app stores, but fundamentally, build on GLES2 and you can go anywhere.

[https://github.com/google/gxui/](https://github.com/google/gxui/) is one
library on top of these foundations that went all the way to providing (
_beautiful!_ ) cross-platform widgets that can be used to quickly build a
desktop application.

Unfortunately, gxui, though a very attractive proof of concept, is now
unmaintained. (At the same time, it's worth mentioning that _it still works_ ;
there's no insane deprecation schedule or fast-moving/fast-breaking libraries
to wreck your day here.) If anyone Out There is interested in renewing this
project or starting more frameworks like this, I'd love to collaborate.

Overall, there's work to do here, but if you have some appetite for cutting
edge, the foundation is in place to nail portability properly.

Finally, this is unrelated, but I feel compelled to give an anti-pitch to
pretty much everything in C/C++ ecosystem of GUI tools: it's a landscape of
last decade's promises, and today's despair. I've had comrades complain
bitterly over time they've spent in codebases where the wxwidget string
objects got out of hand. I have a half dozen applications suffering from
various C++ linker hells on my various computers and can't recommend QT with a
straight face. I _still_ haven't gotten all my gtk3 and gtk2 configs to line
up on my last debian reinstall and all the font sizes are fragged on the
computer for no known reason (I literally the gtk configs in my dotfiles in
git; I can't imagine how different machines drift)... And I haven't even said
a word about build and shipping infrastructure required to really tackle
cross-platform. I'll say it again: _the entire C /C++ ecosystem of GUI tools
is a landscape of despair_.

------
c-smile
[http://sciter.com](http://sciter.com)

Embeddable HTML/CSS UI engine designed specifically for desktop UIs.

The "Embeddable" here means that: \- it is a compact (3...4mb) monolithic
DLL/dylib/so without external dependencies. \- can be linked statically if
needed. \- has simple plain C API of 20-30 functions -
C++,C#,Rust,Go,Delphi,Python wrappers.

Same UI resources are used on all platforms: [http://sciter.com/images/sciter-
clock.png](http://sciter.com/images/sciter-clock.png)

Check technology introduction article:

[http://www.codeproject.com/Articles/859098/Sciter-
multiplatf...](http://www.codeproject.com/Articles/859098/Sciter-
multiplatform-embeddable-HTML-CSS-scripting)

------
TheGrassyKnoll
Which one has the best tutorial so a wanna-be can get started ? Usually, to
me, the 'best' tutorials have the most examples. (Yes, an example is worth a
thousand words) (I'd want to be starting on Ubuntu, with Python 3)

------
justsaysmthng
The choice of the UI library depends a lot on the type of app you're
developing. For many types of apps, a single page HTML/JS/CSS app bundled as
an executable is the best choice.

If your app will do a lot with the hardware (sound, video, networking,...),
then you should look at native libraries for cross-platform hardware access
and UI (though HTML/JS/CSS based UIs with native core are also possible).

In my experience, making a good "cross-platform" UI can be tricky, especially
if your platforms include both desktop and mobile.

The reason is that each platform has it's own set of features, limitations and
design requirements, which you either have to emulate, ignore or implement as
platform-specific modules.

Most UI libraries implement their own windowing systems which makes it
possible to have an app that behaves similarly on all platforms.

The drawback is that the app looks and feels 'cooked' \- things aren't quite
standard, animations are a bit off, fonts are rendered differently, etc.

One such example is Qt, which has been mentioned many times here. It is
probably the best choice if pixel perfection and native look/feel isn't your
primary requirement. With a bit of work you could probably achieve native
'perfection' with it too.

If you work with sound, then you should take a good look at JUCE - it has a
very pleasant API, has a low overhead and a very friendly community.

That being said, the best choice IMHO is to develop native UIs for each
platform or at least for the mobile versions of your app.

The trick is to separate your design into "core" and "ui" parts. The core is a
cross platform C++ library, which implements all the business logic and low
level hardware access, exposing an API to the UI layer.

The UI is then implemented in Qt/JUCE for the desktop apps, Objective-C++ and
Swift for iOS (and OSX if you want) and Java+JNI on Android.

The advantage of this method is that it forces you to have clear separation of
concerns between the core business and UI layers and you can have different
people working on the core and the specific platform UIs.

The ultimate advantage is of course your user's experience - native apps are
more gratifying.

It might sound like a lot more work, but it's usually not as bad as it sounds
- if you have a well designed core API, the UI is just a visual representation
of your application state, which is not that difficult to implement on each
platform.

In the end, personal preference and tastes also matter - use whatever makes
you (and your team) feel more comfortable. Good luck !

------
EGreg
I'm just going to come out and say The Web. Stick WebViews in your app and if
you need some native API use a bridge (like PhoneGap).

By itself you can already have tons and tons of great UI components that work
cross platform.

But if you want a web based library specifically designed to present a common
interface tailored to each device (desktop, tablet and mobile) and taking
advantage of its unique characteristics, use our open source one:

[http://qbix.com/platform](http://qbix.com/platform)

~~~
EGreg
Just out of curiosity, why did you downvote this? You don't think the Web is a
good platform for UI or you don't like that I linked to our library built on
top of it that we open sourced for UI?

~~~
exDM69
Didn't downvote but... At the very least, a suggestion for a cross platform
library for "sticking webviews to your app" would be needed to answer OP's
question.

------
maramono
Here's what I use to develop Mutator's [0] and TestLess' [1] GUIs: \-
implement in Ruby \- compile to Java using Warbler/JRuby \- Run as Java on any
platform that supports Java.

You can use javafx or swing, although javafx needs certain combination of
warbler and jruby to work.

[0] [http://ortask.com/mutator/](http://ortask.com/mutator/)

[1] [http://ortask.com/testless/](http://ortask.com/testless/)

------
SimianLogic2
I've been going the other direction recently. We have a photoshop plugin that
exports layers with metadata (where an image is located, fonts, font sizes,
text, etc). For any platform that has a basic scene graph and some sort of
label functionality (Unity, iOS, android, theoretically even web) we write a
runtime that converts the metadata into runtime UIs.

So it ends up being custom logic for interaction on each platform, but the
design/assets can be shared cross-platform.

------
jbergens
You might have to define which platforms you want or need to target. There is
a difference between just writing a desktop application that should work on
Windows and Mac, an app that should work on iPhone and Android and a solution
that needs to work on all of the above plus Linux desktops and Windows Phones
and web browsers. [edit: spelling]

------
jasonjei
You can have your cake and eat it too. If you have to build a native desktop
app, you can use Chromium Embedded Framework. Spotify is one of its biggest
users. You can still build your UI in HTML but drive it with native code (C++,
Objective-C, C#, etc). We used CEF when we realized how painful Win32 C++ WTL
desktop UI was.

------
codesmythe
SWT rarely gets any love in desktop UI threads around here, but I recently
wrote a small desktop program using SWT and Java and found it to be a
reasonably pleasant experience. The main purpose of the program was to allow
the user to view a couple of database tables, and using a tree view widget
with columns was a key requirement. SWT is the widget toolkit used by Eclipse
and is mostly native, using GTK on Linux, Cocoa on macOS and the Win32 API on
Windows. It is still in active development, and support for HiDpi was recently
added.

I started off with an Angular 1 app using Dropwizard for the backend. But I
was frustrated with (1) the incidental complexity needed to use a decent tree
view widget with sorting, filtering, pagination, etc. and (2) the slow
response time of having to go from the web page, to the backend server, to the
database and then back again.

Around that time, I ran across a Java Swing app written by another group and
was surprised about how fast it was to start up and to access and display info
from a database. Since it used Swing though, the fonts under Red Hat 6 were
terrible. Since I already had most of the "business logic" in Java, it was
straightforward to quickly prototype a viewer using the SWT/JFace tree viewer.
It was fast to start up, and the fonts looked decent since it was using native
GTK2. I dropped the Angular stuff and coded the program in SWT and it has been
well received by my coworkers.

I'm a big believer in using native widgets to the extent possible, which SWT
does. For the tree view widget, for example, it uses GTKTreeView for Linux and
NSOutlineView for macOS. For Win32, there is not a native tree view widget
with columns; SWT uses the native Tree widget and draws the columns itself. Qt
on the other hand emulates a treeview widget on macOS for example and does not
use NSOutlineView.

There is occasionally a least-common-denominator issue when using SWT. For
example, I wanted to use tab widgets that have close buttons on the tab like
web browsers do. The native Win32 and Cocoa tab controls do not provide for
close buttons, so I had to use an SWT provided tab widget that is not native
at all. Doesn't look great, especially on the Mac, but it's fine.

The SWT API is dated, as it comes from the early 2000's, but it seems
straightforward and I rarely find myself surprised. Getting the GridLayout to
do what I wanted was probably the trickiest part. There are examples to follow
on the web. It does not have the kitchen sink aspect that Qt and WxWidgets
have, since Java is there to provide the networking and database access, etc.
Java 8 cleans up a lot of the issues with having to use anonymous inner
classes everywhere in favor of lambdas, and if Java is not your cup of coffee
then SWT is usable from other JVM languages.

Deploying the program works ok. For macOS and Windows, I package it up with
its own JRE. I do face the issue of the best way for end users to update the
program easily. I haven't found an easy to use update package like Sparkle on
macOS that works for cross desktop platform Java apps. I'm contemplating
turning my program in to a full Eclipse RCP program to take advantage of that
framework's built in update facility, but the learning curve seems daunting.
And I'm a big fan of Intellij IDEA for Java development, and don't want to use
Eclipse. :-)

~~~
dguaraglia
To be fair, I feel like most people either would rather not use Java (I know,
I know, it's unreasonable considering the language has become much more
idiomatic and the tooling is great) or they just associate Java with huge
backend, WebSphere kind of projects.

In a way, Java is a victim of its own success.

------
BatFastard
Adobe AIR - much as people like to hate on flash, Adobe AIR kicks ass as a
cross platform UI. It has years of use and abuse.

Its one downside is if you need really low level hardware interaction with OS
you have to use an ANE library which are sometimes great, and sometimes
sketchy.

------
matthewhall
Electron shell without a doubt. HTMl is so fluid and extensionable that it is
hard to beat. It doesn't work on mobile however. Also it isn't as fast as c
native but you use node js which is greater than pure js for obvious reasons.

------
cel1ne
I'd probably use Electron and/or SWT along with javascript and kotlin.

------
evolighting
QT！

~~~
muminoff
Not QT, it is Qt.

~~~
emilsedgh
No idea why you're being downvoted.

QT refers to Apple's Quick Time.

Qt refers to the Qt project, pronounced 'cute'.

------
fezz
I like JUCE. [http://www.juce.com/](http://www.juce.com/) It's used for a lot
of audio apps and plugins but lots beyond that too.

~~~
tomcam
JUCE is all that and a bag of chips. It is a perfectly capable competitor to
QT, yet also has fantastic multimedia APIs. Docs are excellent. Source is
ultra clear.

------
sergiotapia
Electron I would say. You make your UI's using HTML and CSS, it looks the same
everywhere. Not bad, I guess although it does have it performance issues.

Atom for example is built with Electron.

------
max_
I have used Electron previously, but now Ionic is my favorite
[http://ionicframework.com/](http://ionicframework.com/)

~~~
saurik
Electron is desktop only and Ionic is mobile only; you can't really compare
them as there is never a choice between them.

~~~
dangoor
Ionic 2 supports (or intends to support) Electron, desktop web and progressive
web apps: [http://blog.ionic.io/announcing-
ionic-2-beta-7/](http://blog.ionic.io/announcing-ionic-2-beta-7/)

------
kev6168
There is Livecode (livecode.org). Does anyone have experience using it in
production? It's cross-platform and has both commercial and open source
(community) versions.

~~~
tluyben2
I like it for prototyping. I have done some real client projects with it and
it does work well and fast. Especially for apps that either require a custom
UI or not too polished at all.

------
Toover
Qt with no hesitation. It works everywhere.

------
skoocda
I'm surprised nobody has mentioned Angular 2 yet. It's new, so don't expect
tons of support. Nonetheless, it's there as an option!

~~~
jack9
Probably because you didn't read the OP's explanation of minimum standards
that included.

> \- I won't use the web. No HTML, no CSS, no Javascript. Sorry.

If you're using HTML, you're already limited in known ways. Conflaguration of
logic with presentation and callback hells and limitations of CSS extensions
by platform. Then the there's the need to split HTML views due to technical
limitations and practicality of maintenance adding a whole new layer of
complexity in view and view fragment management!

------
Toover
Qt with no hésitation. Works everywhere.

------
undoware
Motif. >:]

------
robot
The best one I know is html 5

------
elcct
I see nobody mentioned Juce. It is pretty neat if you like C++

~~~
pierrec
JUCE is a great framework, has a very commendable coding style and is easy to
get into. One thing to note is that the "JUCE way" of doing things is to have
a UI that looks exactly the same on every platform - this is good for
predictability, but if you want a UI that looks _native_ , you're better off
using Qt or wxWidgets (as C++ UI toolkits go).

In many cases I'd say that's not an issue, and JUCE is underrated/underused as
a general-purpose UI toolkit.

~~~
solipsism
_commendable coding style_

Please explain!

~~~
pierrec
Well, commendable means "deserving praise", and when working with it, I
generally appreciated the simplicity, consistency, and clarity I found
throughout the JUCE codebase.

It also encourages you to adopt a coding style that's consistent with the rest
of JUCE, particularly in terms of memory management. This is one of the things
that makes it a lot more "framework" than "library", and again might not be
for everyone. Take a look at the "Object lifetime and ownership" section in
this page:

[https://www.juce.com/learn/coding-
standards](https://www.juce.com/learn/coding-standards)

------
EddieSpeaks
Why isn't anyone here mentioning Xamarin + GTK#?

~~~
fsloth
You just mentioned them. You could elaborate what makes them worthwhile your
endorsement...

------
totocino
Qt obviously, but beware of licencing

~~~
_ZeD_
Obsolete. Nowadays qt libs are distributed on choice between commercial and
lgpl

~~~
totocino
Don't you have to release the source code of your application if you don't
want to pay?

~~~
majewsky
No. That's GPL, not LGPL.

------
indubitably
The internet.

