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.
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.
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.
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. :)
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:
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.
So far wxWidgets is the only library that anybody has mentioned that actually can be counted on to make somewhat accessible UIs. To see it dismissed because it's a little crufty for the developer to work with makes me incredibly sad, as it's just part of the slow decline that leaves me as a blind person with less and less accessible stuff to use.
One day I'll be stuck on an old emulated version of Windows running only apps which I have created for myself. What a bleak, shitty future.
"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.
> 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.
"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.
At least on Windows, there's a new UI API every 7 years. MFC, Winforms, WPF...
Maybe "wxwidgets has a very antiquated feeling to the API" really means that platform-neutral concepts do not encapsulate well when keeping the UI truly native?
Cross-platform with a single code base has always been a bit of a myth, if only because different platforms have different conventions for things like how to lay out dialog boxes or the writing style used for buttons. If you want something that feels like a native application on different platforms, it's always going to require some level of customisation.
It's still useful to have a single UI library in your code that you can tell to make a text box or open a menu or draw some graphics and have it translate into the correct API calls on each platform under the hood. For all the much-touted rearrangements of UIs, particularly in recent versions of Windows, the reality is that most of the familiar GUI controls haven't really changed that much in decades.
I think the biggest difficulty for any attempt at a cross-platform GUI framework today is probably making sure it does properly handle the widgets or behaviours that really are different or unique on each platform. More generally, if you're building for multiple platforms you also have to deal with all the installation and updating and sandboxing and so on that tends to be completely different from one OS to another, and often the GUI libraries and UI integration is a big part of that too.
Instead of giving me the tools to make a modal pop-up, but then leaving me to match that modal pop-up to the stylistic conventions of each OS GUI, why can't a UI framework give me a "YesNoModalPopup" that looks and acts however a "YesNoModalPopup" is supposed to act on the respective OS—even going so far as to actually be a modal sheet or a command-line prompt instead?
This, I think, is one of the bigger but oft-unstated reasons that people actually prefer to target the web rather than targeting native. Javascript's window.alert() is a function with a semantic behaviour-contract; it will alert the user. It doesn't specify how it'll alert the user, that's up to the browser to define. (And, therefore, up to the user to pick the browser whose definition they enjoy.)
Perhaps what I'm really craving, here, is a XAML-like or XUL-like constraint-based declarative view format, which has a very high-level and abstract set of controls available to be specified. Then, different GUIs could have renderer-clients for this system, that rendered those controls in all sorts of different ways. Maybe you could even mix-and-match your favourite concrete controls, like with browser extensions.
I want to agree with the spirit of what you're saying, but given the potential complexity and uniqueness of a GUI, I think it's an extremely hard problem in practice, if not impossible. You're asking for a toolkit that is both generic enough to provide the common functionality you're describing, yet also comprehensive and flexible enough to cope with the diverse needs of different applications and the diverse conventions and capabilities of different platforms.
How hard can it be to build a toolkit that supports a textbox on Mac OS X, Windows, and Linux? For a moment I thought you proposed a solution a thread up:
> have it translate into the correct API calls on each platform under the hood.
What if instead of writing controls for applications, the applications had low level access to create controls on their own?
Individual controls aren't the problem. Unique controls and idioms that cover multiple controls are.
For example settings dialogs on Mac are usually not modal and usually apply immediately. Meanwhile Windows dialogs are usually modal and transactional, with Cancel button to roll back and Apply to commit without closing.
Full fidelity inevitability ends up bifurcating the codebase or compromising the nativeness of the UI.
Simple things like button, text box, drop down, check box, radio button that have been in use for 30 years or more are just fine. But look at the list view in Windows; that has grown dozens of options to support Explorer, the file system browser. The deeper you go, the less you can keep common.
I see that the deeper you go, the less you can keep common. I learned a lot from your answers.
I didn't understand why the nativeness of the UI must bifurcate (fork) the codebase. In your example, can't non-modal on Mac vs modal on Windows be a config value in the cross-platform UI?
I also didn't get an answer to one of my questions. Why can't applications have low level access to create controls on their own?
> why can't a UI framework give me a "YesNoModalPopup" that looks and acts however a "YesNoModalPopup" is supposed to act on the respective OS
As a simple counter-example, macOS rarely uses Yes/No/OK/Cancel buttons. Instead, dialog buttons have meaningful names based on the task at hand, e.g. "Overwrite File" and "Keep Old File".
That's exactly what I meant, though. "YesNoModalPopup" is the name of a semantic behavioural contract, not a concrete implementation class whose name describes what you'll see. In instantiating a YesNoModalPopup, there would be required fields for button labels—even though those field-values will only be used on OSX.
With an abstract+declarative toolkit, you would still have to do just as much customization toward your use-case as you would if you were writing one view class for each GUI. You just get to skip the marginal cost of everything that's not that customization. You can have a single code path to create, and show, and receive input from, the instance of the pop-up abstraction.
I just started using it a few months ago, and perhaps the antiquated API you refer is the "old methods" described in wxWidgets books and such. There is a new modern-ish API with jQuery like function chaining, and an Advanced UI (AUI) subsystem enabling one complete control to the presentation layer. It is not perfect, but I'm liking it.
> Qt only emulates Windows controls, but wxWidgets uses the actual Windows controls via Microsoft Win32 API.
I don't think this is actually what you want on Windows. The standard common controls are pretty outdated. Anyone who has built a complex program with a lot of widgets using common controls (or a framework that wraps them) can probably tell you that they're really slow and they have problems with flicker. They also use outdated font rendering (GDI rather than DirectWrite) and they don't natively support alpha-blending. Even Microsoft avoid using common controls. Task dialogs, Aero wizards and most control panels are built with an internal toolkit called DirectUI. Office is built with similar technology, and obviously WPF and Windows Store apps don't use common controls.
This makes Qt pretty much what you want on Windows. It uses the native theming APIs so its controls look native, but they are rendered with a high performance raster engine that supports alpha-transparency and eliminates flicker. Also, I think the latest version of Qt uses DirectWrite for font rendering.
Because one platform supports more options and when using that control on a different platform there are exactly two choices: break cross compatibility or reimplement the control.
Add evolution of controls and idioms over time, and it's literally impossible to always unify: not all platforms evolve their non-trivial components in the same direction.
I'm glad I asked this because your answer suggests this is the main problem with cross-platform UIs.
What do you think is the right thing to do? To have a common denominator kind of approach where a control works on all platforms but with fewer features, or to reimplement the control?
Do you have an example handy of a control/idiom that caused this problem?
It sounds like reimplementing (emulation) is a good thing.
Not against wx by any means, but I actually tried it recently on osx and it drew most controls manually on a canvas of its own. So "xplatform nativeness" is not a selling point for wx.
You've probably used wxUniversal. Try wxOSX/Cocoa, it wraps native controls such as NSButton. You can even get this object and use Cocoa API directly (inside appropriate #ifdef block obviously).
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].
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.
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.
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.
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?
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?
> 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?
Tk is 25-year-old tech, not 10. ;-) It has also maintained backwards compatibility since 1997 or so, which is a nice feature to have in many cases but comes at a price. For example, you have to know to use a "ttk::button", not a plain "button", to get the native (Windows, macOS) or a least the somewhat better-looking (*nix) widget. The result is that old Tk software still runs unchanged instead of forcing its maintainers to upgrade, but it looks bad and outdated, contributing negatively to Tk's general image.
The poor look on Linux is definitely a big downside. You can ameliorate it somewhat with a custom theme [1] but your GUI will still look out of place in any major desktop environment. TileGTK and TileQt [2] aren't maintained.
I haven't used it myself, but Tk has at least some CJK support [3]. One thing to keep in mind from the start, though, is that Tcl/Tk suffers from a UTF-16 code unit limitation similar to Java's; it only handles the Basic Multilingual Plane [4] natively.
As for antialiasing, what do you mean when you say it is disabled by default? Is that in a particular Linux distribution? A recent Tk release (post-Tcl 8.5) should render antialiased text unless you compile it with "--disable-xft" or your font is raster.
> As for antialiasing, what do you mean when you say it is disabled by default? Is that in a particular Linux distribution? A recent Tk release (post-Tcl 8.5) should render antialiased text unless you compile it with "--disable-xft" or your font is raster.
Sorry, I was thinking about antialiased drawings (canvas). Text was antialiased if I remember correctly.
IIRC Tk only has linear gradients, no fancy gradients that is needed to make your GUI look good.
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.
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.
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.
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.
This is common in older C++ projects that predate good quality STL and good compilers everywhere. They should factor it out, but that would break a ton of code.
We have chosen Qt for our new cross-platform app (Android, Windows, MacOS) which we've developed for the past 1.5 years and have overall not regretted it. Doing UIs with QML and Qt Quick is so much faster than Android's XML based system and gives you a lot of flexibility.
However there's a bit of a UI rendering overhead, although I understand they made it faster with Qt 5.7. And OpenGL integration is more complicated than doing it natively since you have to understand Qt's UI scene graph system and the way Qt is threading things.
Same here. I ran into a few problems with Android. Controls 2 is not quite ready yet, I had to write some Java, but it worked. Hopefully more AndroidExtras will be added in time.
My impression with Qt is that it has less language bindings than the alternatives. For Qt5 you find lots of bindings for QtQuick stuff but if you want to use traditional QtWidgets then its basically C++ or Python.
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.
+1 on this, I'm having a very pleasant time working on a couple Electron+React apps right now. I've been starting my apps based off https://github.com/chentsulin/electron-react-boilerplate but diverging greatly after getting it running.
Instead of react native you can also just reuse the UI-code directly for the mobile deployment. Just add meta tags like apple-mobile-web-app-capable=true and style with @media-rules.
To be fair "just" might be over simplifying things a bit. I've been doing this for an application and thinking that it actually would be a benefit to have a different code bases for the desktop and mobile editions. It can be a bit challenging to design for both targets at once.
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.
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.
Electron is ok for certain applications, but I'm really wary of this whole trend. It's leading to extremely buggy, resource intensive desktop applications.
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).
"The best" is subjective. I have played around with 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.
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?
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.
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.
- 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.
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 or the Debian or SUSE equivalents).
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.
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:
Yes, I'm compiling for Windows using mingw64. I gave up with VC because, it worked, but since Windows 10, the MS dynamic runtime contains parts of the OS. This doesn't always install properly on windows 7 & 8. Mingw worked.
> - The UI to look as good or better than the UI on Mac OS X. I'm not willing to compromise on looks.
Just remember that the UI kit is only part of having a good UI. Apple's historical success with good UI is based on their long standing guidelines for designing good UIs.
I doubt I need to tell you this (although Google seems to recently have forgotten it), you app needs to use the patterns of the platform it is on. Users respond well when the app looks like it is "native" and not a port.
> I doubt I need to tell you this (although Google seems to recently have forgotten it), you app needs to use the patterns of the platform it is on
Not that I agree with it, but I am fairly certain Google has not forgotten - they have just remapped the definition of "platform" from "the operating system" to "Google's app constellation & sites". The pattern commonality is no longer with other apps on the OS you are currently on, but with other Google property.
- do you need to support high DPI monitors? If "yes" then you need a) something capable to render on GPU and b) to use scalable vector image formats like SVG and others.
- Do you need adjustable styling? Like today it is a flat UI and tomorrow they will return back to skeumorphism. Material design for example is step in that direction. What about UI branding, when the same UI is used for different brands with their own color schemes, etc? What is expectation for the lifetime of your application? Just for the note: http://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-on...
- What about UI accessibility? "Section 508" and the like.
- So called "richtext" WYSIWYG editing - yes/no?
- Printing and print preview?
- Dynamic UI composition? When UI is composed from actual data structure. In some cases simple flat property lists may work but not always.
- UI animations and transitions ?
- What about UI internationalization?
As of "No HTML, no CSS"...
HTML is just a serialization form of tree of UI elements. Not more not less. Any library has this (serialization) in one form or another.
CSS is simply the way to define things like: "this element in that state has to be rendered te following way". Any good library has that in one form or another.
You do not need full scale browser for HTML/CSS, and actually should not use solutions based on browsers for the UI. Primary goal of a browser is to provide safe browsing experience, UI rendering is only next function after the first...
Before you start to roll your own consider that there have been many attempts to do this already and they have all failed to varying degrees. The reason for this is that it's much harder to get right than it seems.
QT is what I've used when a client is determined to go down this path, but if a web app doesn't make sense the best option is almost always to spend extra time making sure that most of your code is portable and then write a native UI that uses it for each platform that you care about.
It's not necessarily hard but it is a ton of work and requires a lot of low level knowledge of the underlying window system. You need to have a very good understanding of the layer beneath you (xlib, Wayland, win32) and how fonts are rendered on the various systems you want to support. There's also various tradeoffs you need to make. Do you go with custom drawn widgets or use native ones? Native offers a shortcut if you have a greater understanding of the lower system API. Custom drawn requires possibly less knowledge of the various widget API but more knowledge of the underlying window drawing API. Getting basic buttons and labels drawn is not hard. The harder parts are menus, text entry, scroll bars and scrolling. None of the current toolkits were cross platform from initial release. Almost all started with Xlib and then years later were ported to Windows. Some still haven't made the port to OSX (except to rely on x11). It's a lot of work and maybe that's what makes it hard.
Setting aside that most windows client development should probably be done in WPF/C# these days...
low level differences:
There are differences between GDI and xlib. For instance GDI has a concept of a "combo box" at the API level and in X11 you need to either roll your own or use a higher level GUI toolkit. IIRC, Handling of the non-client area and window scrolling are different between platforms and handling of audio/video is completely different between platforms.
There are a LOT of features:
Power modes (e.g. suspend, hibernate, low battery), tooltips, the clipboard, drag and drop, maximize, and a bunch of subtly different "must have" features need to work between platforms and you need to know what all those features are. Accessibility should work and touch/gesture support is likely to become important over the next few years. At the point where you start cutting features to make it more manageable you have started down the road of making another crappy "lowest common denominator" GUI toolkit and you are better off just using QT.
User expectations are different between platforms:
This is mostly a lot of little details, like where the "close" button goes, what a "right click" does, menu layouts, standard icons, and which direction the window scrolls when you move the mouse wheel "up" but it adds up to an application not feeling right. You can see this taken to an extreme with any number of bad ports from console to PC.
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.
"...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.
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.
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).
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.
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.
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.
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.
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).
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.
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.
JavaFX also has support to bundle a JRE with its native installer support, it can build a exe, msi, dmg etc. The bigger issue is Oracle not really giving it the proper attention.
Even if it were true, you can easily bundle a JRE with your app, which is what Oracle recommends actually. In the end, it still ends up being smaller in size than a Electron/NW.js app.
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.
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.
> 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.
> 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.
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.
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.
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.
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).
GTK+'s Windows support is mixed. It mostly works, but bugs reports don't seem to get much attention and you're on your own if you want Windows binaries. macOS support is effectively an afterthought. The only teir 1, actively supported platform appears to be Linux which makes me wonder why the project advertises itself as "cross-platform."
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.
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.
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.
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.
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 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/ 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.
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.
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)
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 !
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:
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?
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.
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.
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.
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]
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.
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. :-)
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.
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.
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.
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.
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.
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.
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.
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!
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.
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:
Licensing and cost is similar to Qt (free for open source, $$$ for commercial applications, though I think JUCE is cheaper). So, at least relatively to Qt, it doesn't particularly limit popularity.
And even in an absolute sense, you can't confidently say that dual-licensing limits popularity in the long term. If JUCE and Qt were free for everyone, perhaps they wouldn't be able to have the full-time developers they both currently have. So maybe they wouldn't be as good, thereby decreasing popularity against competing dual-licensed libraries. This is all wild speculation, of course, but it's an example to show how their model works.
I still haven't found a clear answer to that, but using the LGPL license could pose a problem, because you need to allow the user to recompile the application with his own version of Qt.
On iOS shared libraries are not allowed on the store, so you should distribute the files for static linking... it becomes quite messy and sort of unclear from the legal point of view.
Even if it's wasn't clear before now it's pretty clear - you must buy commercial license if you want to be on App Store. There was Qt license change[1] in January 2016 and there is no longer LGPLv2.1 licensed version since Qt 5.7.
Only option for commercial software currently is LGPLv3 and it's doesn't allow tivoization.
Hey thanks. I wasn't aware of the dylib appstore restriction. Is this still the case with iOS8 and if not, could a dynamic LGPL Qt app be put on the store. I hope they allow this going forward.
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?