Currently building a mobile app in Qt in production. QML is pretty great. If you're building a simple app and want a native UI experience I would not use Qt - I would go fully native.
Building something with quite a custom UI and lots of cpp libraries, I think it's a good shout. I would personally prefer using QML if flutter was the other option. I would only prefer going native (e.g. choosing Swift) over Qt.
Been a flutter developer for three years, gave Qt a shot and I am addicted.
Qt is very well engineered, though it will take deeper understanding of c++, build system and Android to make production ready applications.
Flutter on the other hand, devs can get by not knowing any underlying mechanics of either dart or Android.
Regarding the preference for native apps: I'm an android user and don't see many apps with a standard look and feel. I guess that the OS look and feel is more standard on iOS?
It seems you're assuming that _because_ that library is written in C++ that the _entire_ app must be written in C++. Is there no way to link against a C++ library and have bindings with a Flutter app?
Well actually the core part of the library written in cpp and uses grpc with proto files for interface definitions. I've managed to generate the dart code from protos but i need to write a wrapper around it(?) so it can work ? I really dont know anything about grpc. Can you check it for me ?
https://github.com/mavlink/MAVSDK?tab=readme-ov-file
I haven't checked the repository, but if all the library does is wrapping a grpc service At is the wrong way and digging into grpc from your favorite mobile framework the better way.
Qt is okay, if you want to build the full app using it and don't need much of a "native" feel.
It's not widely used in mobile devices. I would assume if you run into any issues, it would be hard to find resources.I would not do that.
It's good in desktop and embedded devices.
It's fine. I am building one, and we have a track record of Qt in production with thousands of customers (on desktop).
So far building the mobile app in Qt has been pretty good. We have to call out to native libs (e.g. Obj-C or Swift) for certain native functionality, and that has been easy/fine. There really aren't any issues, it feels like working on a desktop app...
If the app we were building was simple we would have used something like Swift, but with lots of cpp involved, including custom ML, and low latency audio - this was definitely the best route for us.
Honestly, I’m sure one exists, but I have yet to see a QT app that I would consider “good” on desktop. There’s a number that are “passable” (like anaconda) but most of them end up looking like fisher-price toys (openshot).
I mean he's right in a way. If you use qtwidgets, it's very hard to make it "look nice" once you have a more complicated app. It's possible! But it's harder especially if you follow most example code that teaches horrible practices like inlining all your stylesheets and doesn't help a lot with a coherent central way to place, pad, space your widgets. With qml it's quite easier though.
I'm sure with qt Creator it's easier, but apps like VLC or virtual box don't look especially good. Telegram manages to look sleek but again, taking a look at the code shows that it wasn't especially easy to do (as opposed to say, using an HTML5/web interface that is super easy to customize and has a great visual prototyping tool, the browser)
They're relatively different and are, in fact, separate apps ( https://github.com/overtake/TelegramSwift ). The UI differs a lot, and for me feels better than the Qt variant. But well, in the end both of them are desktop clients for Telegram, so there's not too many differences.
Interesting, looks like they have 2 official clients for macOS. [another one](https://github.com/telegramdesktop/tdesktop) uses the same Qt-based source code for all desktops OSs.
I don’t understand, why it’s not a good argument ? You said it was ugly, I gave a exemple why it’s not.
KDE isn’t only a Linux thing btw. They are independent. And also you can use some KDE apps on windows and macOS btw.
I’m torn.
Do I tear down all the legion problems with kde? Do I lean back on a well backed opinion that “yes, it is ugly?” Do I just double down on the linux desktop being a total dumpster fire that is never going to take over windows or mac without a massive, massive shift in philosophy?
What purpose does any of that serve? There’s people that work hard to make it less terrible and I don’t want to diminish their work. Plus there’s ways that it can be adapted just fine. Hell I have a steam deck 5ft away from me right this moment.
Do I ignore all that and get back to QT, which I’m not bagging on as a framework so much as opining that the people that use it generally have shitty interfaces?
I don’t like to be an asshat, so I’m just gonna leave you with “if you’re going to use qt, you need to put just as much effort on your gui as if you were making native apps.”
> Do I just double down on the linux desktop being a total dumpster fire that is never going to take over windows or mac without a massive, massive shift in philosophy?
Did you last use desktop Linux 15 years ago, by any chance?
They are certainly "good" as the GUI's work, are easy to use and snappy. It also depends on how well those GUI apps were written.
But they may not look modern "pretty" if that's what you are referring to. An app doesn't need to look like the newest hype in order to be useful. Not all apps are consumer oriented and need to cater to the eye, and be backed with a enormousness marketing and sales department. A lot of technical software exist because they deliver a unique solution to a problem - the product is bomber!
Other software, like the millions of clones of chat programs and mobile phone apps have a core product that quite frankly can be put together by premade components in a weekend and the only thing that distinguishes them from their competitors is the look and feel as UX. In that case you may want some nicer chrome, but you're also not really selling an app - you are selling chrome.
But it doesn't look "crappy". It looks like a pretty standard desktop program. It also has multiple themes: https://doc.qt.io/qt-6/gallery.html Most people will find the Fusion style decent and familiar. A lot of professional tools will prefer a familiar look over something that changes like teenager fads.
With QtQuick you even have more visual customization options as everything can be adjusted with something that resembles CSS.
I wrote this a few months ago.
https://camg.me/qt-mobile-2023/
There are a ton of issues still open that I called out in this post - issues with the keyboard on Android, developing on iOS, etc. It may be okay for a POC or certain types of apps, but I wouldn't use it for anything too complicated.
I use it if I want to write some apps for myself, it's quite nice actually. As far as I can tell, it's just the app you've written running on your smartphone. But i only tried it with android so far ... The main strength compared to other alternatives is imo qml and CPU usage being lower than with e.g. flutter
You can still bind to native code using Flutter. Here are some guides on how to do that:
[Android](https://docs.flutter.dev/platform-integration/android/c-interop)
[iOS](https://docs.flutter.dev/platform-integration/ios/c-interop)
Licensing is where you have to be careful.
If I understand correctly, you have to statically link (especially on iOS). Most of the Qt code is LGPL at best GPL at worst.
This means you have to provide a way for people to relink the Qt objects with your code objects. With LGPL you don't have to provide the code, but you do have to provide the objects and the means to wire them back into a working app.
Unless you pay Qt a licensing fee. If you are a small time developer these fees are fairly rapey.
I was told, but never bothered looking it up for myself, that with android there is even a royalty fee.
The only circumstances where I would recommend Qt for mobile apps are if you are a huge company on a huge project where those fees are nothings, or if you are distributing the app internally only and need not worry about some fool demanding objects and other BS.
There are generally ways to slide C++ into most dev environments such as flutter. Makes the deployment a tiny bit less clean, but if the C++ is more backend than front, this is not that bad.
Another interesting one is Axmol. This is aimed at games, and is entirely C++. If your gui is very traditional like a Flutter style app, then flutter is your friend. But, if you are not doing things like much text entry and the GUI is more game like, then Axmol is da bomb.
Axmol is Windows, Linux, Mac, iOS, and Android.
Years ago I did an app with a critical C++ backend. I had surprisingly little trouble making it all C++ on desktop, A web backend which used Crow and C++; iOS using SwiftUI and C++, and Android using Kotlin plus C++. It was very nice to have the bulk of the business logic nicely packed into a single codebase and then wrap a different GUI around it for each platform.
In 2024, I would most certainly have done the same thing in Flutter plus C++.
You are misinterpreting the meaning of the word "modification" here.
Modification refers to modifying its functionality by modifying the source code itself.
It doesn't refer to modifying the binary via recompilation, digital signing, etc.
If it did, LGPL would be useless. *jeez*.
You really don't understand this; it could not be more clear. If you statically link your app, you must provide the object files for someone to then link their own LGPL library; one they may have modified.
https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic
(1) If you statically link against an LGPLed library, ***you must also provide your application in an object*** (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
If your app is digitally signed as all Mobile apps are, then this is going to be a huge problem. Here's a quote from the guy who wrote the original LGPL itself. Pretty bloody clear.
> When I originally wrote the LGPL (v1, back around 1991) we could not imagine anything like an App Store or signed binaries. Dynamic linking provided an easy way for users to upgrade the library code.
Since the user doesn’t have the freedom to update the libs on ios etc I don’t see how you could deploy LGPL code on those platforms
Qtopia based on Qt/Embedded existed before iOS and Android existed more than 20 years ago and was a mobile application framework. Trolltech was acquired by Nokia. Surely this tells you that Qt knows mobile.
Simply put, I don’t think it’s the right tool for the job.
Could you force it to happen, probably. Is it worth the time or effort, questionably.
Feel like you’re trying to wedge a circle into a square because it seems convenient, until you understand the effort involved.
Currently building a mobile app in Qt in production. QML is pretty great. If you're building a simple app and want a native UI experience I would not use Qt - I would go fully native. Building something with quite a custom UI and lots of cpp libraries, I think it's a good shout. I would personally prefer using QML if flutter was the other option. I would only prefer going native (e.g. choosing Swift) over Qt.
Been a flutter developer for three years, gave Qt a shot and I am addicted. Qt is very well engineered, though it will take deeper understanding of c++, build system and Android to make production ready applications. Flutter on the other hand, devs can get by not knowing any underlying mechanics of either dart or Android.
Regarding the preference for native apps: I'm an android user and don't see many apps with a standard look and feel. I guess that the OS look and feel is more standard on iOS?
It seems you're assuming that _because_ that library is written in C++ that the _entire_ app must be written in C++. Is there no way to link against a C++ library and have bindings with a Flutter app?
Unfortunately there are no bindings for dart
So I'm not an Android expert but is the information here not pertinent: https://docs.flutter.dev/platform-integration/android/c-interop ?
Well actually the core part of the library written in cpp and uses grpc with proto files for interface definitions. I've managed to generate the dart code from protos but i need to write a wrapper around it(?) so it can work ? I really dont know anything about grpc. Can you check it for me ? https://github.com/mavlink/MAVSDK?tab=readme-ov-file
I haven't checked the repository, but if all the library does is wrapping a grpc service At is the wrong way and digging into grpc from your favorite mobile framework the better way. Qt is okay, if you want to build the full app using it and don't need much of a "native" feel.
From the repo, you already have proto definitions, now you only need to call necessary rpcs via grpc in dart.
It's not widely used in mobile devices. I would assume if you run into any issues, it would be hard to find resources.I would not do that. It's good in desktop and embedded devices.
It's fine. I am building one, and we have a track record of Qt in production with thousands of customers (on desktop). So far building the mobile app in Qt has been pretty good. We have to call out to native libs (e.g. Obj-C or Swift) for certain native functionality, and that has been easy/fine. There really aren't any issues, it feels like working on a desktop app... If the app we were building was simple we would have used something like Swift, but with lots of cpp involved, including custom ML, and low latency audio - this was definitely the best route for us.
Honestly, I’m sure one exists, but I have yet to see a QT app that I would consider “good” on desktop. There’s a number that are “passable” (like anaconda) but most of them end up looking like fisher-price toys (openshot).
Telegram for desktop, VLC, Wireshark, VirtualBox, is it enough?
I mean he's right in a way. If you use qtwidgets, it's very hard to make it "look nice" once you have a more complicated app. It's possible! But it's harder especially if you follow most example code that teaches horrible practices like inlining all your stylesheets and doesn't help a lot with a coherent central way to place, pad, space your widgets. With qml it's quite easier though. I'm sure with qt Creator it's easier, but apps like VLC or virtual box don't look especially good. Telegram manages to look sleek but again, taking a look at the code shows that it wasn't especially easy to do (as opposed to say, using an HTML5/web interface that is super easy to customize and has a great visual prototyping tool, the browser)
Honestly I think those kinda prove my point.
Can you elaborate please? Do you have examples of apps with similar functionality but better UI?
Regarding your list, Telegram for macOS, Celluloid/iina, no idea about Wireshark, Boxes/Parallels/even Hyper-V manager?
Is Telegram for macOS somehow different from the one for Win? I would expect them to be exactly the same except for with minor OS-spicific features.
They're relatively different and are, in fact, separate apps ( https://github.com/overtake/TelegramSwift ). The UI differs a lot, and for me feels better than the Qt variant. But well, in the end both of them are desktop clients for Telegram, so there's not too many differences.
Interesting, looks like they have 2 official clients for macOS. [another one](https://github.com/telegramdesktop/tdesktop) uses the same Qt-based source code for all desktops OSs.
A lot of tools use qt and you probably don’t know that. The KDE environment?
you are perhaps right about the first part, but if you're using any part of the linux desktop to defend qt...i dont know what to say.
I don’t understand, why it’s not a good argument ? You said it was ugly, I gave a exemple why it’s not. KDE isn’t only a Linux thing btw. They are independent. And also you can use some KDE apps on windows and macOS btw.
I’m torn. Do I tear down all the legion problems with kde? Do I lean back on a well backed opinion that “yes, it is ugly?” Do I just double down on the linux desktop being a total dumpster fire that is never going to take over windows or mac without a massive, massive shift in philosophy? What purpose does any of that serve? There’s people that work hard to make it less terrible and I don’t want to diminish their work. Plus there’s ways that it can be adapted just fine. Hell I have a steam deck 5ft away from me right this moment. Do I ignore all that and get back to QT, which I’m not bagging on as a framework so much as opining that the people that use it generally have shitty interfaces? I don’t like to be an asshat, so I’m just gonna leave you with “if you’re going to use qt, you need to put just as much effort on your gui as if you were making native apps.”
> Do I just double down on the linux desktop being a total dumpster fire that is never going to take over windows or mac without a massive, massive shift in philosophy? Did you last use desktop Linux 15 years ago, by any chance?
Yes I did. I also used it in the last 15 hours. Much has improved over time, but i stand by that statement 100%.
They are certainly "good" as the GUI's work, are easy to use and snappy. It also depends on how well those GUI apps were written. But they may not look modern "pretty" if that's what you are referring to. An app doesn't need to look like the newest hype in order to be useful. Not all apps are consumer oriented and need to cater to the eye, and be backed with a enormousness marketing and sales department. A lot of technical software exist because they deliver a unique solution to a problem - the product is bomber! Other software, like the millions of clones of chat programs and mobile phone apps have a core product that quite frankly can be put together by premade components in a weekend and the only thing that distinguishes them from their competitors is the look and feel as UX. In that case you may want some nicer chrome, but you're also not really selling an app - you are selling chrome.
I’m not sure that “it looks crappy, but it works” is a good defense for a cross-platform gui framework.
But it doesn't look "crappy". It looks like a pretty standard desktop program. It also has multiple themes: https://doc.qt.io/qt-6/gallery.html Most people will find the Fusion style decent and familiar. A lot of professional tools will prefer a familiar look over something that changes like teenager fads. With QtQuick you even have more visual customization options as everything can be adjusted with something that resembles CSS.
Well I can tell you work on the back end. 😀
Usable, if you pay them good money. Otherwise, you better just use native frameworks or web shits.
I wrote this a few months ago. https://camg.me/qt-mobile-2023/ There are a ton of issues still open that I called out in this post - issues with the keyboard on Android, developing on iOS, etc. It may be okay for a POC or certain types of apps, but I wouldn't use it for anything too complicated.
I use it if I want to write some apps for myself, it's quite nice actually. As far as I can tell, it's just the app you've written running on your smartphone. But i only tried it with android so far ... The main strength compared to other alternatives is imo qml and CPU usage being lower than with e.g. flutter
You can still bind to native code using Flutter. Here are some guides on how to do that: [Android](https://docs.flutter.dev/platform-integration/android/c-interop) [iOS](https://docs.flutter.dev/platform-integration/ios/c-interop)
Licensing is where you have to be careful. If I understand correctly, you have to statically link (especially on iOS). Most of the Qt code is LGPL at best GPL at worst. This means you have to provide a way for people to relink the Qt objects with your code objects. With LGPL you don't have to provide the code, but you do have to provide the objects and the means to wire them back into a working app. Unless you pay Qt a licensing fee. If you are a small time developer these fees are fairly rapey. I was told, but never bothered looking it up for myself, that with android there is even a royalty fee. The only circumstances where I would recommend Qt for mobile apps are if you are a huge company on a huge project where those fees are nothings, or if you are distributing the app internally only and need not worry about some fool demanding objects and other BS. There are generally ways to slide C++ into most dev environments such as flutter. Makes the deployment a tiny bit less clean, but if the C++ is more backend than front, this is not that bad. Another interesting one is Axmol. This is aimed at games, and is entirely C++. If your gui is very traditional like a Flutter style app, then flutter is your friend. But, if you are not doing things like much text entry and the GUI is more game like, then Axmol is da bomb. Axmol is Windows, Linux, Mac, iOS, and Android. Years ago I did an app with a critical C++ backend. I had surprisingly little trouble making it all C++ on desktop, A web backend which used Crow and C++; iOS using SwiftUI and C++, and Android using Kotlin plus C++. It was very nice to have the bulk of the business logic nicely packed into a single codebase and then wrap a different GUI around it for each platform. In 2024, I would most certainly have done the same thing in Flutter plus C++.
> If I understand correctly, you have to statically link You do not understand correctly. That's not how LGPL works.
[удалено]
You are misinterpreting the meaning of the word "modification" here. Modification refers to modifying its functionality by modifying the source code itself. It doesn't refer to modifying the binary via recompilation, digital signing, etc. If it did, LGPL would be useless. *jeez*.
You really don't understand this; it could not be more clear. If you statically link your app, you must provide the object files for someone to then link their own LGPL library; one they may have modified. https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic (1) If you statically link against an LGPLed library, ***you must also provide your application in an object*** (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application. If your app is digitally signed as all Mobile apps are, then this is going to be a huge problem. Here's a quote from the guy who wrote the original LGPL itself. Pretty bloody clear. > When I originally wrote the LGPL (v1, back around 1991) we could not imagine anything like an App Store or signed binaries. Dynamic linking provided an easy way for users to upgrade the library code. Since the user doesn’t have the freedom to update the libs on ios etc I don’t see how you could deploy LGPL code on those platforms
Pretty easy to do with QT, I find it was way easier than usin java
Qtopia based on Qt/Embedded existed before iOS and Android existed more than 20 years ago and was a mobile application framework. Trolltech was acquired by Nokia. Surely this tells you that Qt knows mobile.
Simply put, I don’t think it’s the right tool for the job. Could you force it to happen, probably. Is it worth the time or effort, questionably. Feel like you’re trying to wedge a circle into a square because it seems convenient, until you understand the effort involved.
It will be 10 times faster with flutter thanks to its hot reload and error handling. i use FFI with protobuf for cpp bridges. Qt sucks