For UI you always want to use the a platform or OS’ native controls and APIs rather than some stack on top of it for best performance and a polished look and feel. Anything else is most often second class.
Except on Windows, where Qt looks more "standard" than whatever MSFT's current "standard" framework is this week, and on Linux, where GTK and Qt are the native frameworks. If you handle these with Qt and your budget is limited, you might want to handle more platforms with Qt.
This is how I’m developing my application with Rust.
The UI is completely separated from the core of the app, and the core can be compiled natively or target Web Assembly.
I’m building the UI with HTML and JS (by the way, Web Components feel way better than React) and running the whole app in the browser (via WASM).
Eventually, I’d like to create native applications for all platforms, but I don’t have the time to spend on that right now. When the time comes, I’ll be able to easily remove the HTML frontend and bolt on a new one written specifically for the target platform.
This lets me prioritize dev speed in the short term and native UX in the long term.
QWidgets is the one to use if you want to blend in. Qt Quick is highly productive, but native styling is, AFAIK, not completely there yet. It's getting better, not sure how good it will get.
Right, QWidgets are not very suitable for mobile. QML is... very suitable for custom (especially touch) GUIs, native styling is WIP. Seems to be done with higher priority than desktop native styling.
From my work experience: it's not cheaper. Paying people to reimplement stuff that is already implemented and functioning, and then pay them to fix the bugs, and then pay them to make it accessible.
I once took part in a project where we created a QML based implementation of a previously Node.js based embedded app. Node.js took ten people two years, QML three people six months - and no callback hell. Lots of caveats though: I'm not sure how experienced the Node.js guys were - team QML was fairly experienced (and competent in general). JS GUI frameworks have improved a lot respectively become available in the first place. Recreating something is always easier than creating it the first time. We used the same backend parts that were probably co-developed with the Node.js frontend (but AFAIK not counted in the two years, ten people).
We heard that the Node.js version had quite high velocity initially, but slowed down greatly when it came to polishing. Like more than half of the time spent on the last 5%. The QML version also ran more smoothly.
Qt should just copy Cocoa already, on both desktop and mobile, and both in API surface area and appearance (on desktop, at least, i.e. the Mac look). Now is a better time to do so than ever, given the flattening of Aqua, which makes it easy to mimic, and the Oracle v. Google precedent moving API copyrightability out of the grey area.
What I did some time ago was create two native projects, drop in a WebView, write most code in C++, then use a single shared C++ header for things like bluetooth. This functionality is implemented in a C++ file for Android and an ObjC++ file for iOS. On Android you use JNI to access the Java Bluetooth API's and on iOS you can directly invoke the iOS Bluetooth libraries using Objective-C.
The WebView on Android and iOS supports configuring an interop function. It allows you to map a JavaScript function to Java/ObjC functions. In my case, I had a single function with a single string argument, which I used to pass JSON messages.
I then implemented a callback mechanism where each message would get a unique ID. From JavaScript code, I could call a function in the shared C++ core and get a callback when data is returned.
The shared C++ code can directly access the internet and filesystem (I read in another comment that they changed this recently?).
The performance of the WebView is amazing, especially if you just rawdog it and write plain JavaScript. Modern JavaScript is nothing like it was back in the IE6 days.
With flat UIs, at the end of the day, who cares that it "doesn't feel native". What price are you willing to pay just so that it "feels native"?
Performance? Not so much on Android I would say. The bloated gigantic UI toolkit is so large and complex. A native c application would run much much faster. Harder to create for sure. But if you want performance you should go low level.
That's what wxwidgets does and... yeah, it's not always great. Native widgets have specific behaviour/attributes which don't necessarily translate to generic frameworks. My wx experience is constantly running into "why didn't this call do anything" situations because of that. There's no perfect solution that I've seen.
I believe QML ListView actually does support kinetic scrolling - Qt calls it "flicking". To get behavior closer to React Native, it might work to decrease the value of the Flickable flickDeceleration property [1].
That said, my troubles with Qt's performance and behavior on mobile led me to create my own cross-platform GUI library: https://github.com/styluslabs/ugui/
You're right, I will update my post. However, it's quite difficult to get this right on all devices as compared to i.e native where it just works. Plus, there are performance issues like those you mentioned that further impact scrolling and rendering responsiveness.
Your framework looks cool! I like that you have some flex support.
Flexbox support in QML[1].
Plus, there are some wrappers that make seamless transition between desktop and mobile view like MauiKit[2] and Kirigami[3]. I don't think they're perfect or that they are doing it correctly even, but they're onto something with their main approach.
your library seems really interesting (I'd be interested in collaborating if it had a license compatible with my projects) but I've not found it mentioned in the repo. Would you be interested in clarifying the licensing terms?
Agree with other comments about needing a license - your library looks like it would integrate into audio plugins quite nicely (it's self contained). If it's licensed to allow it, I do try to upstream changes I make!
Honestly, I don't know what you were expecting. QT sucks pretty much everywhere. For universal UI I think the three choices are native (and if you have to pick one start with iOS because of reach and the fact that iPhone users pay for apps), React Native, or Flutter.
The problem with 3rd party frameworks is that you're always playing catch up. So if you're soloing it / developing a proof of concept you're good but if you're a real business you'd have a hard time selling me on anything but native.
Businesses don't necessarily want to maintain 10 versions of the same thing just so that it can run on different platforms. It is costly and they don't like costs.
You're thinking from the perspective of a solo developer making an ios app and nothing else.
Seems like you are thinking from the perspective of "internal enterprise app, possibly sideloaded to use inside warehouse", or something along those lines. Those can really look like anything, but there is a high chance it will be designed and tested on a single platform anyway (since the company can purchase specific devices), so why bother with multi platform. I have seen plenty of cases like these in my work, and those apps always suck and are eventually replaced by native ones.
If you are building an app which is supposed to be used by regular end consumers, native is the only real way to go. And as prizzom mentioned, choosing native iOS toolkit is a good idea if you want to sell, because Android users are not very keen on paying for apps.
Steam also recently remade their apps. Authenticator and chat for steam uses native ui toolkit (styled to look like Steam desktop app). Store browsing still uses html frame, but that is less relevant for Steam on mobile.
Thanks for sharing! What performance issue are you talking about? Did you separate your logic to C++? I'm building an advanced block editor[1] where the model is in C++ and the view in QML and the performance is really great.
The scrolling like you mentioned is subpar compared to native macOS one, so I hope Qt will address that. I saw someone mentioning `flickDeceleration` but at least on desktop it doesn't seem to change anything? Maybe it's because my delegates are so different from each other?
I also plan to support mobile version for my app in the future, so it's sad to read about the rest of the issues.
I haven't seen any performance issues on desktop, but on mobile they really stand out. I have separated logic into QML, and even experimented with implementing custom QQuickItems in some places.
Here are some issues I've seen related to performance on mobile:
1) Opening a larger app is really slow (maybe 3-5 seconds), but works okay for smaller apps. I'm not sure what's going on behind the scenes and haven't had time to dive deep there yet, so this could be specific to me.
2) Rendering full pages is quite slower than native, as is QML rendering in general, even when using the QML compiler (which compiles your QML to C++)
3) Qt text rendering is a bit slow too, but you may not need i.e QTextDocument if you're implementing a text editor of some sort.
Regarding your first point, instantiating a lot of QML items is usually what makes startup slow. You can use Loaders to load things on demand (and timer triggered Loaders to load stuff you will probably need but shouldn't delay startup). Make the Loaders asynchronous and timer triggered (async but immediately triggered still slows down startup) and switch them to synchronous when their contents are needed immediately.
I have a component for it, it's 10-15 lines or so.
These performance issues are vastly different from what I experience on Desktop, so I'm curious to test my app on mobile. In my experience, C++ and QML outperforms comparable native apps by 4x.
Regarding no.3, what do you mean by QTextDocument? My block editor is implemented by each delegate being a TextArea (inh: TextEdit), and it's very fast.
One trick I've learned, is to use `reuseItems`[1][2] in ListView. It gives incredible performance boost. You'll need to adjust some things according to the onPooled and onReused signals, but it's a no-brainer for many use cases.
QTextDocument is a class in Qt::Gui that many of the other text classes/components use. I was thinking you may have implemented your own text handling widget/item, but using delegates of text areas makes sense too.
I will try reuseItems again. It's something I tried before briefly but thought it may have been causing some rendering glitches and removed it. Maybe because I didn't implement onResused or onPooled properly. Thanks!
> I was thinking you may have implemented your own text handling
Yes, but without QTextDocument as I had some problems with it. I had to implement my own undo/redo/copy/paste/etc.
> It's something I tried before briefly but thought it may have been causing some rendering glitches
Yes, I've experienced some (minor) glitches that I've yet to figure out how to fix. For example, the cursor seems to (sometimes) jump when creating new blocks. Sometimes delegates reappear with animation (while I turned them off when onPooled ran). I'm trying to figure out if I'm doing something incorrectly (highly probable) yet I don't get these issues without reuseItems.
Hmm, for 1 and 2 have you actually tried to profile your code? You can use the QML profiler to check which parts of QML compilation are slowing you down. Also consider using GammaRay [1] to see what's causing the rendering to be slow.
This really depends on the target platform , Qt version you are using.
To put things into perspective, With Gstreamer/QML, we've had smooth 1080p30 fps on measly imx6ul hardware, thanks to zero copy pipelines.
I've had good experiences with Flutter on both mobile platforms and Mac desktop. After doing several React Native apps over the years Flutter feels better engineered across the board. It would certainly be my first choice for a cross platform mobile app at this point.
I havent had good experience with either Flutter or React Native and at this point I am willing to bite the bullet and try native next. And they say webdev is bad.
It is quite usable. Why not Uno or Avalonia? Because of better tooling, different concept, and more importantly, because MS has better resources to pull it of.
Nancy FX was nice but most people used the Framework and it became the standard.
It seems like a lot of the newer UI frameworks are weirdly lacking when it comes to a few highly functional widgets like that… UI-as-branding custom styled buttons are prioritized over rich textviews and tableviews/datagrids.
My impression is that MAUI was released with a lot of fanfare but wasn't really ready (but that's just from articles I read, I haven't tried it myself). That's before even getting into lack of official Linux support. It then seems to have very little attention.
It fits the classic Microsoft pattern of releasing a developer technology that doesn't quite work, then abandoning it before they ever finish it. For example, WinForms was meant to get hardware acceleration but, before then, was soft-deprecated in favour of WPF.
It seems like that isn't your experience, is that right? I'm genuinely curious because I want to like MAUI – I'd love a cross platform (Windows, Mac, Linux), hardware accelerated, C# GUI toolkit (that works and is supported).
> My impression is that MAUI was released with a lot of fanfare but wasn't really ready
[...]
>It fits the classic Microsoft pattern of releasing a developer technology that doesn't quite work, then abandoning it before they ever finish it.
My sense is that MS is all-in on "web ui" (html/css/[js|ts]). Native apps don't fit with the commercial imperative to get as much compute happening in Azure as possible. The Windows desktop increasingly has just one purpose: to maximise the likelihood that the end consumer will use Microsoft's cloud, and not someone else's. The Desktop UI is now a bedraggled mix of several UI toolkit generations, with many built-in apps going all the way back to the original Win API.
Microsoft's own headline apps - Office and Teams - have a web tech future. Teams started there, Office is going through a long, slow and somewhat painful migration.
Windows is slowly becoming just a remote desktop. You don't need native apps on those.
Every year since 2007 I tried Qt for mobile development (starting with Nokia N8) only to be disappointed again and again. Making a game with 3d graphics? Drawing charts? no problem. Using ui elements and sensors? You inevitably run into a bug, a missing feature or learn some new framework that works well until you do something that is not in one of the demos.
The team is obviously incredibly talented and their coding style know-how matured over time, and I really want it to work, but unfortunately it still isn't there yet.
To be fair Qt development on late Symbian versions felt great, as it was the native development environment on late Symbian versions (Symbian Belle if I remember correctly).
Symbian anna and belle came back to back after Microsoft's acquire. Shortly after belle (which regularly crashed), there were no more updates and store stopped working. They essentially killed my phone.
Qt on mobile aka QWidgets?
Otherwise QML/QtQuick is no different from Flutter. I have worked on a couple of different QtQuick Mobile apps, and they work just as well as any other native apps there were. It really depends on what your app does.
I was thinking about QML. In theory it's the same as Flutter, but in practice it's not at all because it was designed for desktop. They basically shrank a desktop app down to phone size. It's the Windows CE of phone GUI toolkits.
Huh? QML is specifically designed for Mobile/Embedded use cases though. That too when Nokia was targeting their Meego and Symbian touch interfaces. The best example usecases of QML you'd see is on Nokia N9/Ubuntu touch/even Sailfish OS.
It was meant to be a declarative scripting language around their QGraphicsView back then iirc. That's how there was no QML Components for Desktop until quite a bit later. Then they made QtQuick a lot more fast/powerful in Qt5 by rewriting it on top of their new OpenGL scenegraph.
So what desktop design paradigms do you see in QML that make it unfit for mobile?
>Being able to share UI and code on Android and iOS is still a desire for many developers. As hinted throughout the post, I think React Native may be the only other possible contender.
I have been a codenameone developer for 8 years now. On Android you run java and on ios you run static c which comes from the java code itself
Shai Almog and Steve Hannah have done a great job at making cn1 a comprehensible platform to develop on mobile. All the issues listed on this post are covered (scrolling with inertia, Android file system updates, etc)
I don't know how successful cn1 is in terms of users but I wish it were more popular on places like HN where React Native/Flutter is the bread and butter
Is there any solid proof of this? It seems that Flutter is not used in any notable apps and React Native is used even by the big players in the field. I have yet to see a single high quality app made with Flutter and literally the only app I’m using that is made with it is the one I’m working on. React Native seems massively popular in comparison. It really feels that the stats that show Flutter being popular are not really measuring real life use. The Flutter ecosystem seems especially tiny and it has close to no support from 3rd parties, even Google treats Flutter as a second class platform when it comes to libraries like Google Ads.
The main issue I felt with Qt on mobile, was that the effort writing JNI bindings or Objective-C++ wrappers for stuff Qt didn't account for, like the file dialogue example, would be better spent just having the business logic in C++ and writing the UI in the platform native languages.
The effort was already there anyway, so Qt wasn't bringing anything to the table, when a desktop app isn't part of the offering.
Everyone is looking for the magical WORA, however the reason Java failed at that, and Electron sucks, is that they are all leaky abstractions.
In reality, for delivering a good experience, knowing the underlying platform is still a requirement, and it only adds up in layers to debug, OS APIs to wrap, build tooling to integrate, IDE plugins for the platform SDK interoperability, and so on.
68 comments
[ 3.8 ms ] story [ 138 ms ] threadThe UI is completely separated from the core of the app, and the core can be compiled natively or target Web Assembly.
I’m building the UI with HTML and JS (by the way, Web Components feel way better than React) and running the whole app in the browser (via WASM).
Eventually, I’d like to create native applications for all platforms, but I don’t have the time to spend on that right now. When the time comes, I’ll be able to easily remove the HTML frontend and bolt on a new one written specifically for the target platform.
This lets me prioritize dev speed in the short term and native UX in the long term.
I don't know the state of QWidgets on iOS/Android but my guess is it's even worse than QML if at all possible.
We heard that the Node.js version had quite high velocity initially, but slowed down greatly when it came to polishing. Like more than half of the time spent on the last 5%. The QML version also ran more smoothly.
The WebView on Android and iOS supports configuring an interop function. It allows you to map a JavaScript function to Java/ObjC functions. In my case, I had a single function with a single string argument, which I used to pass JSON messages.
I then implemented a callback mechanism where each message would get a unique ID. From JavaScript code, I could call a function in the shared C++ core and get a callback when data is returned.
The shared C++ code can directly access the internet and filesystem (I read in another comment that they changed this recently?).
The performance of the WebView is amazing, especially if you just rawdog it and write plain JavaScript. Modern JavaScript is nothing like it was back in the IE6 days.
With flat UIs, at the end of the day, who cares that it "doesn't feel native". What price are you willing to pay just so that it "feels native"?
That said, my troubles with Qt's performance and behavior on mobile led me to create my own cross-platform GUI library: https://github.com/styluslabs/ugui/
[1] https://doc.qt.io/qt-6/qml-qtquick-flickable.html
Your framework looks cool! I like that you have some flex support.
[1] https://github.com/tripolskypetr/qml-flexbox
[2] https://mauikit.org/
[3] https://develop.kde.org/frameworks/kirigami//
https://bugreports.qt.io/browse/QTBUG-116388
https://github.com/styluslabs/ugui/issues/1
The only slight nitpick I have is the unity gui system is also called ugui so search conflicts might be annoying.
The problem with 3rd party frameworks is that you're always playing catch up. So if you're soloing it / developing a proof of concept you're good but if you're a real business you'd have a hard time selling me on anything but native.
You're thinking from the perspective of a solo developer making an ios app and nothing else.
If you are building an app which is supposed to be used by regular end consumers, native is the only real way to go. And as prizzom mentioned, choosing native iOS toolkit is a good idea if you want to sell, because Android users are not very keen on paying for apps.
slack uses html, steam uses extremely slow html… big companies do not care.
Steam also recently remade their apps. Authenticator and chat for steam uses native ui toolkit (styled to look like Steam desktop app). Store browsing still uses html frame, but that is less relevant for Steam on mobile.
The scrolling like you mentioned is subpar compared to native macOS one, so I hope Qt will address that. I saw someone mentioning `flickDeceleration` but at least on desktop it doesn't seem to change anything? Maybe it's because my delegates are so different from each other?
I also plan to support mobile version for my app in the future, so it's sad to read about the rest of the issues.
[1] https://www.get-plume.com/
Here are some issues I've seen related to performance on mobile:
1) Opening a larger app is really slow (maybe 3-5 seconds), but works okay for smaller apps. I'm not sure what's going on behind the scenes and haven't had time to dive deep there yet, so this could be specific to me.
2) Rendering full pages is quite slower than native, as is QML rendering in general, even when using the QML compiler (which compiles your QML to C++)
3) Qt text rendering is a bit slow too, but you may not need i.e QTextDocument if you're implementing a text editor of some sort.
I have a component for it, it's 10-15 lines or so.
Regarding no.3, what do you mean by QTextDocument? My block editor is implemented by each delegate being a TextArea (inh: TextEdit), and it's very fast.
One trick I've learned, is to use `reuseItems`[1][2] in ListView. It gives incredible performance boost. You'll need to adjust some things according to the onPooled and onReused signals, but it's a no-brainer for many use cases.
[1] https://doc.qt.io/qt-6/qml-qtquick-listview.html#reuseItems-...
[2] https://doc.qt.io/qt-6/qml-qtquick-tableview.html#reusing-it...
I will try reuseItems again. It's something I tried before briefly but thought it may have been causing some rendering glitches and removed it. Maybe because I didn't implement onResused or onPooled properly. Thanks!
Yes, but without QTextDocument as I had some problems with it. I had to implement my own undo/redo/copy/paste/etc.
> It's something I tried before briefly but thought it may have been causing some rendering glitches
Yes, I've experienced some (minor) glitches that I've yet to figure out how to fix. For example, the cursor seems to (sometimes) jump when creating new blocks. Sometimes delegates reappear with animation (while I turned them off when onPooled ran). I'm trying to figure out if I'm doing something incorrectly (highly probable) yet I don't get these issues without reuseItems.
Sure, I hope it works out well for you (:
[1] https://www.kdab.com/development-resources/qt-tools/gammaray...
[1] https://doc.qt.io/qt-6/qtmultimedia-video-mediaplayer-exampl...
https://doc.qt.io/qt-6/qquickitem.html
As frustrating as the web can be I’ll take that over being locked into a single platform proprietary toolkit.
Nancy FX was nice but most people used the Framework and it became the standard.
They have a WPF compatibility thing but it's "enterprise" overpriced.
It fits the classic Microsoft pattern of releasing a developer technology that doesn't quite work, then abandoning it before they ever finish it. For example, WinForms was meant to get hardware acceleration but, before then, was soft-deprecated in favour of WPF.
It seems like that isn't your experience, is that right? I'm genuinely curious because I want to like MAUI – I'd love a cross platform (Windows, Mac, Linux), hardware accelerated, C# GUI toolkit (that works and is supported).
My sense is that MS is all-in on "web ui" (html/css/[js|ts]). Native apps don't fit with the commercial imperative to get as much compute happening in Azure as possible. The Windows desktop increasingly has just one purpose: to maximise the likelihood that the end consumer will use Microsoft's cloud, and not someone else's. The Desktop UI is now a bedraggled mix of several UI toolkit generations, with many built-in apps going all the way back to the original Win API.
Microsoft's own headline apps - Office and Teams - have a web tech future. Teams started there, Office is going through a long, slow and somewhat painful migration.
Windows is slowly becoming just a remote desktop. You don't need native apps on those.
It seems to be the most accurate choice to answer the described needs while solving the lack of native dependency that QT is apparently facing.
It looks like the iOS support is in alpha though, and I'm curious if it uses native components on iOS?
The team is obviously incredibly talented and their coding style know-how matured over time, and I really want it to work, but unfortunately it still isn't there yet.
It was meant to be a declarative scripting language around their QGraphicsView back then iirc. That's how there was no QML Components for Desktop until quite a bit later. Then they made QtQuick a lot more fast/powerful in Qt5 by rewriting it on top of their new OpenGL scenegraph.
So what desktop design paradigms do you see in QML that make it unfit for mobile?
I have been a codenameone developer for 8 years now. On Android you run java and on ios you run static c which comes from the java code itself
Shai Almog and Steve Hannah have done a great job at making cn1 a comprehensible platform to develop on mobile. All the issues listed on this post are covered (scrolling with inertia, Android file system updates, etc)
I don't know how successful cn1 is in terms of users but I wish it were more popular on places like HN where React Native/Flutter is the bread and butter
The effort was already there anyway, so Qt wasn't bringing anything to the table, when a desktop app isn't part of the offering.
Everyone is looking for the magical WORA, however the reason Java failed at that, and Electron sucks, is that they are all leaky abstractions.
In reality, for delivering a good experience, knowing the underlying platform is still a requirement, and it only adds up in layers to debug, OS APIs to wrap, build tooling to integrate, IDE plugins for the platform SDK interoperability, and so on.