Awesome marketing video for an under hyped product!
My startup abandoned .NET in favor of Qt to develop a cross platform screenshot app to digitize math equations because we wanted Linux support (https://mathpix.com) and it's delivered. We still use Swift for our Mac app. The thing about .NET is that it's not nearly as seamless as a development stack as Swift + the whole Mac ecosystem. Whatever clunkiness exists in Qt apps already exists 10x in the Windows ecosystem of clunkiness everywhere, because Windows itself is, in a sense, cross platform. So the difference between a Qt app a .NET app is not super noticeable on Windows.
A good Qt app will be very nearly as good as a good .NET app, and a good Swift app on MacOS beats them all by a landslide.
You've contradicted yourself. WPF is a .Net technology. Are you saying it pays a performance penalty, or not?
> If you develop on windows with WPF/MFC/Win32 calls, it will be obviously faster than Qt, because you're saving on that bridge calls.
Not so. Both frameworks make calls down into one of Windows' graphics subsystems. This is how all GUI toolkits work.
If draw performance is important to you, Qt might well beat WPF, as it has a Direct3D 12 backend [0]. To my knowledge, WPF does not - as far as I can tell it uses Direct3D 9. Of course, none of this gives us any hard assurances that the performance of one beats the other, but in terms of the inefficiencies of using intermediate layers, it's far from clear than WPF wins.
(I couldn't find any decent concrete numbers on this. I presume that's because GUI draw performance isn't a real problem these days.)
I'm not convinced that Swift is any different (though it well might be a good deal less bloated). It seems unlikely that the syscalls end up all that different simply because of using a different language for your GUI work.
> Why don't you use Qt on Mac then?
Obviously I can't speak for nicodjimenez, but I presume it's because Qt doesn't deliver quite the native Mac feel that they're aiming for. My understanding is that Qt is also a little immature on mobile platforms, but I'm not sure that's relevant here.
Not exactly and this view of it is IMO why a lot of people dislike it: MFC is not a layer like Qt, you don't use it to avoid Win32, you use it to enhance Win32. When using MFC you need to know both MFC and Win32 and you use both of them at the same time. On the other hand when you use Qt you can ignore anything related to Win32 because the Qt API layers itself over whatever is below.
Of course this has several implications, starting with that if you don't like Win32 then you wont like MFC either (and the reverse isn't necessarily true - you may dislike MFC while liking Win32).
I ported a popular Google application from Windows to OS X using Qt Designer (and Qt in general) a number of years ago.
Qt is really good for quick bringup of a cross platform app, and Designer and its associated code generator does a good job of generating reasonable UI's. Swift didn't exist at the time, but the combination of InterfaceBuilder and Cocoa was amazing.
Where things start to get tricky is that Qt has to reimplement a lot of widgets themselves, on account of their target platforms being quite different from each other, so you end up with a slightly non-native feel on each platform, and some behaviors are subtly different. Things have gotten better since then, but that non-native behavior is still there. These behavioral differences aren't too bad on Windows and X11, since those platforms have a lot of inconsistency between apps, but mac users expect the mac to "feel" a certain way, and Qt is a little different, so we got a _lot_ of feedback, some of which I still remember - "Google Earth looks like it fell out of the ugly tree and hit every branch on the way down".
The tradeoff you have with a cross platform toolkit like Qt is quick bringup of a cross platform app, versus later chasing down a lot of platform differences causing problems, and that slight non-nativeness. The alternative is to write your UI natively on each platform and abstract away the functional core from the UI, which is a lot more work but works better. If I was building a UI for major public consumption today, I would go with the extra work of native UI. If I was building tooling for my own developers, hands down, I'd use Qt.
Qt is more than a UI library, it abstracts away the platform too, from networking, to disk access, to UI. Think of it as an analogue to Chromium more than just UI.
You can use it as a simple gui library just fine. I've been using it in place of Tk for my python stuff for a while now. (Qt.py is a lifesaver) I haven't even tried their options for what I want to do yet, but it is definitely tempting.
My impression is that tools, over the last few years and no matter the stack they're for, have kind of converged onto where Flash was eons ago. Remember when web was littered with 2advanced clones? Looks like we've abandoned Flash, but never gave up the idea.
> we've abandoned Flash, but never gave up the idea
I'd argue that's a very good thing. Obviously lots of people disliked the Flash player for various reasons, but the Flash authoring tool was terrific. Specifically, the features/metaphors it comprised are IMHO precisely the recipe for a powerful design tool:
* Composable hierarchy of objects that can contain other objects
* Each object has states (keyframes) and state transitions
* Each object is an instance of a class, and editing the class affects all instances
* Code can be attached to each object / state / state transition
Presumably this formula didn't originate with Flash but it's where I first encountered it, and I think it probably ought to be the skeleton of any design tool for interactive content.
It becomes really apparent in web games. Some crude HTML5 game will need a relatively modern PC to run, while graphically superior flash game from 10-15 years ago ran fine on a 500mhz Celeron
Right? I’m surprised there isn’t more of this sentiment here. Flash did 15 years ago on a hardware from 15 years ago exactly what the “web platform” does now with hardware that’s orders of magnitude more powerful in every aspect. It’s embarrassing that Flash was left to die for superficial reasons.
I dunno if they're so superficial. At the time it seemed a very real prospect that every single website would run on Flash, which is a proprietary and closed-source ecosystem entirely run by a single company with an API protected by copyright law.
It wasn't just games. Every damn website had a flash animation that autoplayed and got right in your face.
Flash was also used to bypass privacy controls, create un-deletable tracking cookies, and generally do bad things.
Remember when we needed to update Flash every couple of weeks because it was so full of security holes? And they were serious holes, used by bad people to do bad things to a lot of innocent victims. And, of course, while we were downloading and updating the Flash player, the web was basically useless because every damn site refused to do anything until it could do it with Flash.
No, much as I loved those games, I'm soooo glad we didn't go down that road
This. I always looked at Flash as better Java Applets. They filled the gap that Applets were intended to address but Flash was a much easier to work with.
Flash, while full of issues, was sort of a prototype of functionality that people wanted built into browsers. It took a while for standards to catch up, because standards move slow.
At the same time, people were motivated to make it happen because of all of those terrible things about Flash.
We can all thank Steve Jobs for delivering the death blow to Flash to really force the issue.
> I always looked at Flash as better Java Applets.
This is kind of funny to see for me after spending a lot of time years ago trying to make some performance intensive games and stumbling on the horrible performance (and API limitations) that Flash - at the time i wished i was able to make applets instead :-P.
To also play devil's advocate: Flash was a great authorship environment, certainly far easier to write games with, and with better results, than C could give you twenty years before. Developing JS/HTML5 games is far more painful and unpleasant than developing Flash games -- it's a worse developer experience that somehow requires significantly more advanced hardware for comparable results.
That's true, but web developers did it to themselves. It's not hard, or at least wasn't hard several years back, to find developers complaining that Flash was ruining the web and needed to go away.
That the results aren't as good isn't surprising. Flash was specifically built (and optimized) for interactive graphic content like games. HTML was originally made to display text documents and it's been a long series of revisions and hacks to get where it is now.
Unfortunately this seems to be true of just about all software. I was messing around with KDE Neon on an old 8 core Xeon server with 32GB of ram and had to wait a second or two minimum for applications to launch and show their windows, but Windows 2003 on that box was so responsive part of me was actually a little freaked out by it from being so used to modern UI sluggishness.
A product that I've been keeping an eye on is Subform [1]. Apart from Flash-esque design tools, it includes more or less "novel" ways of defining the layout of the app. I think the layout tools set this product apart form similar offers. One of the main developers has a talk about the philosophy behind the UI of this app [2].
The same team is working on an app to use state machines to define UI interactions, which is also super interesting [3].
> A product that I've been keeping an eye on is Subform
Dude, hate to be the bearer of bad news, but subform shut down, during beta.
I also was keeping track of it and hoping it would launch.
sketch.systems is created by the same people though, and sketch.systems is pretty much their pivot. not quite the same thing but it seems to be receiving a better response in the market.
Is that so! Such a pity, this product looked really promising!
I just saw that they haven't updated the blog since March or so, but I wasn't sure since their forum is invite only. Did they announce this somewhere? Perhaps they are taking a break from subform to work on sketch.systems.
Which idea are you thinking of? (Flash was very similar to tools that had been on the scene for many years before, like Director and it's predecessor VideoWorks.)
What Director enabled on interactive CDs we got in mail and as freebies continued with Flash on the web and culminated with 'skip intro'. Idea of having motion graphics on the web. Sometimes in form of small elements, sometimes full everything. Something's gotta move though.
I was just reviewing Hypercard's history yesterday and realized that it's really one of many tools from that period circa 1985-1995 where everyone was driving commercial dev tools towards the "RAD" paradigm and merging IDE, database, code editing, and forms editing into one Smalltalk-esque environment. Flash and Director date from this era, and other antecedents include Filemaker(still around today!) and MS Access, as well as more "code-centric" ideas like Visual Basic or Delphi.
Flash survived longer than most just by developing into a Web-centric product, but for the most part, these products are old and there's room for a new generation of them. The thing that I think has held them back is that it requires a more holistic approach than is usually taken by open-source projects. It's easier to make a programming language that is dumped on top of the C/Unix environment and just accumulates power-user features over time.
Perhaps the computing experience should be precisely the more holistic one. Hypercard is exceptional for many reasons: new users can do a lot without writing code, but can easily "see" how it works by inspecting things (in a language that is readable even for non-programmers). You can copy and paste everything. It integrated well with the system upon which it was built. It let users do what they needed to, for their own ends, without making too many assumptions -- and it did this in a highly accessible way. That should be what personal computing is all about.
I think the key lesson, really, is that you need intuitive metaphors to make such things work. The idea of cards and stacks are highly intuitive in this case.
It's worth booting up Sheepshaver and giving the final version of Hypercard another look. The default home stack -- complete with interactive examples and documentation that you can straight up copy and paste -- is still a marvel of design in my view.
Qt seems to have a very strong niche market share, but to this day I still can't tell exactly who is using out commercially outside of maybe a few bigger name Linux utilities.
> but to this day I still can't tell exactly who is using out commercially outside of maybe a few bigger name Linux utilities.
Microsoft OneDrive is made with Qt, the Blizzard launcher, the AMD drivers panel, authoring software like Guitar Pro, Maya, CryEngine, Allegorithmic software (one of the slickiest UIs in that field I think : https://www.allegorithmic.com/)... Blackberry also used Qt for their OS's shell and apps, as well as HP/LG WebOS.
Embedded products like medical devices, car infotainment systems, factory robots control panels, research labs monitoring devices, CAD, 3D animation packages,....
The only contender to Qt in these companies is usually WPF.
Most of them have found niche markets in verticals like automotive/medical/embedded, where it's easier to just ship a runtime for the UI.
UI/UX designers working on the dominant platforms (web/mobile) have a lot of nostalgia for Flash--particularly the perceived ability to actually ship functioning product. There's no lack of new tools trying to improve on the status quo: drawing pictures of UI and throwing them over the wall for developers to figure out how to implement.
I suspect that we haven't seen the aforementioned IDEs become industry standard for a couple reasons:
+ They're by nature more difficult to use than drawing tools, often surfacing a lot of advanced parameters, state machines, and code
+ The variability in languages/frameworks/platforms inherent in web and native development make usable output a much harder problem than having everyone all-in on a single framework/runtime
I know QT is this big powerful thing, but where does this fit in compared to QtQuick/QML/QtCreator and so on? My frame of reference is .NET desktop development FWIW, but this looks like some cross between VS Blend and Adobe Flash/Animate.
I'm pretty sure that is incorrect, can someone please enlighten me?
Qt Widgets can be wired up graphically with QtDesigner but AFAIK that program does not work with QML, which is basically modern Qt.
So this looks like a design tool for creating QML interfaces. The animation parts come in because QML allows for embedding javascript so you can probably do all of that graphically now and get QML code out
So QML and QT design tools are awesome! I think nothing matches the capabilities of this platform.
Still, each time I think of using QT I get discouraged (a bit) by the licensing (even though there's almost zero chance I'll ever independently sell a software product! :-p).
In paper, one should be able to use the community version of QT for commercial software, but it looks like actually doing this could be really tricky [1]. And the commercial license is so expensive! QT page says: "Pricing starts at $459/mo." :-O.
Your quoted link points out no actual problems? It just conveys a fearful mystic vibe about the license and then reduces to "if you get acquired, the lawyers might want to look into the LGPL and it might cause a delay, thus hurting the acquisition". Maybe this person has not read the LGPL, it's an easy read.
Can someone tell me in simple terms what the Qt licensing situation is? The webpage for Qt Design Studio says you can only use the designs you come up with in an app if you have a Qt commercial license.
It looks like Qt Design Studio is a commercial product that's free for evaluation only.
> Qt Design Studio is available today as a free tool for everyone to try out and evaluate. You will need a commercial Qt developer license to distribute your UIs created with Qt Design Studio.
> We are also working on an open source version with a limited feature set, to be published in December.
The Qt library itself has both commercial and LGPL licenses. You can safely use LGPL libraries in commercial products with a couple obscure provisions: it's commonly held the library has to be dynamically linked, the user has the right to replace the Qt dynamic libraries, and maybe a few other inconsequential things.
As long as you can deliver the toolchain used to build the libraries, and allow the finished libraries to be installed on your target hardware over the current ones.
I know one major vehicle manufacturer that won't go past 5.6 because of this reason. They put it right in the RFP.
As I've looked, it's in section 4, paragraph d), choice 0) of the LGPL3 :
"Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source."
So not exactly the toolchain, but definitely allows reinstallation of upgraded libraries. I didn't know.
Has nothing to do about the royalty fees. Those didn’t change from 5.6 to 5.7. It has everything to do with being required to allow end customers to install their own libraries on a piece of their machinery. LGPL 3 closed the LGPL 2.1 loophole concerning this.
The legal and warranty issues around letting customers reflash their dashboards are what the company wants to avoid.
Exactly. No problem whatsoever selling something made using Qt[0].
But there is a "problem" using Qt to release proprietary software, of course, because Qt is free, and perhaps parent isn't aware of the distinction between commercial and proprietary?
This is incorrect, using LGPL licensed software does not prevent you from keeping your software closed source, any components you rely on from Qt will need to be provided (or reference given which is a _really_ weak requirement) in open source but any functions referencing Qt functions do not themselves need to be provided in a decompiled form, this is pretty much why LGPL exists. So if you're company is trying to make money making proprietary improvements to Qt _which require you to edit Qt_ then you're a bit hooped, but I strongly suspect instead there was a misunderstanding which how contagious free software is.
(That said, whenever possible please give back to the FSF community)
Does #including (non-trivial) Qt headers make your software a derivative work? IIRC there is a decent amount of actual code in some of the headers. Seems like a very grey area.
It does not, and with significantly complex header files (like the SIGNAL/SLOT macros Qt includes) this can seem like a grey area, but the LGPL specifically splits code into object & specification code, if your code directly references and links against publicly defined specification code you're in the clear... if you are doing this with knowledge of how specific object code works and manipulating that object code using your own code (i.e. intentionally overwriting a stake frame) I think that does become more of a grey area, but the intent of the license is very straightforward about allowing non-contagious use of interface specifications, that is what specifically makes it LGPL instead of GPL (the latter lacks that distinction and does not allow the use you're asking about among some other uses).
This is of course complicated by SaaS and all that is covered in more detail in Affero license and in that field I'm out of my depth.
Oh also, I am not a lawyer, if you're developing something commercially or otherwise reading this for advice please take a moment to consult a professional.
Thanks, what you said makes sense, or licensing Qt under LGPL in addition to GPL would make no sense.
> Oh also, I am not a lawyer, if you're developing something commercially or otherwise reading this for advice please take a moment to consult a professional.
Unless you start to mess with the QT libraries directly, there should be no problems whatsoever. You just attach unmodified object files and/or source code (as you did not make changes to them) into the software distribution.
The answer on Quora is also rather alarmist. Plenty of startups use LGPL'd software without any issues. Yes, you will need to be aware of it, and disclose it as needed. Same with any other bit of open source. So?
I have really read the Quora answer, is this an issue with understanding how LGPL licensing works? It does have some complications but the common approach when compiling a binary involving large precompiled libraries the .so/.dll objects will be excluded direct inclusion in the binary and kept as linked objects. I certainly can understand this being a bit hazy for people not used to working with compiled languages and that goes double for lawyers but this is a well established approach.
A decent developer is ~$15,000/mo after taxes and benefits, give or take. Does the toolkit provide you capability or efficiency gains at 1/30th that which an extra developer would? If so, then it would seem to be well worth it.
Working in (or for a company from) a very expensive/rich technological hub of the world, i.e. couple of places in US, couple in Europe and couple in Asia.
At least in Europe "decent" would mean "top 1%" - because it translates to ~300k€+ before taxes.
I think you read the parent wrong, they meant $15k total expense to employer, so $180k per year. I don't know how large are the US employment costs in addition to the salary, but assuming 40%, the employee would see ~$130k before taxes.
Way above "decent" engineer salary for the rest of the world, but I guess that's plausible in US?
The common rule of thumb is to estimate ~16% over the top of salaray for taxes, benefits, etc. in the U.S.
So I was estimating roughly a $150k engineer. That's high in some places and low in others. But at least in the U.S. in any significant metro area, that's not an unreasonable marker for a senior engineer.
However, it hardly seems meaningful to squabble over where $150k sits in the range of software engineer pay scales when we're comparing it to a $495/mo potentially productivity boosting alternative. $6k is a lot less than $50k, $100k, or $150k.
Doesn't bring ego into their work, can flexibly learn things quickly to identify and then use the right tools for the job, isn't driven by the fad-of-the-day unless there's legitimate (not contribute) merit to said fad applied to their problem, decreases the amount of immutable calcified process/design/implementation debt over time rather than increasing it, and knows on their own how & when to balance being a framer vs. a finisher.
Looks like this is mainly QtQuick? Has anyone had success getting platform native-(ish) looking and behaving Desktop applications working in QtQuick? I have a few applications running on QWidgets which I'd like to port over for performance reasons (QWidgets has known performance problems on high-DPI Apple platforms they probably won't ever fix), but QtQuick apps tend to behave like off-brand tablet apps, out of the box.
Right now this is less and less "important". QtQuick.Controls2 fill that niche a bit, but it isn't the point.
To them, the world has moved on. Web apps have zero consistency and people prefer them. There is also little money left in desktop application development. Qt on Android and iOS targets the "good enough" rather than driving their business. The people who will choose Qt for mobile don't do it for consistency. The money is on IoT and embedded. This is where having a certified platform with support is important. It's also where you can't use the OpenSource license and have to pay for the commercial one. It's also where having native UX is absolutely irrelevant.
In a way, it's hard to argue about any of that. It's sad, but unavoidable.
Right - so why can't we have this for the DOM? Much of the power of QML could work wonders for that, for example setting anchor points based on other elements. I think the problem is that in many cases it needs either weird css hacks or injecting dynamic values via js.
It'd be nice to have a web layout tool that ties it all together and lets the designer use familiar tools like pivot, anchor, align, etc. - even if it exports some proprietary combo like react + styled components.
No doubt that's what FramerX and friends are after... so I guess there's progress, but it feels like the web just needs an overall rewrite to get out of the legacy cruft that came along with making static pages dynamic.
That's actually the limiting factor, otherwise you could just compile Qt to WASM and draw to a canvas.
To render text nicely you need to know the geometry of the screen so you can anti-alias properly. A canvas goes through a series of transforms that work fine for images but garble text.
The look of the text is just the tip of the iceberg. Many text editing operations are tightly integrated with the operating system and impossible to implement without an editable element. For example, on recent iPads you can move the cursor around by swiping the keyboard with two fingers. I don't know how you'd support this gesture without creating an actual editable element on the page.
Does anyone have experience if it is currently possible to use QT open source license for commercial iOS app distributed on App Store? People seems divided about that.
Qt is a set of interoperating libraries for the development of cross-platform graphical applications. It covers a lot of topics from abstracting basis operating system services to various ways to create the actual UI (with traditional widget hierarchies instantiated in C++ code, declaratively using QML...) and advanced features like embedded webkit or interfacing with OpenGL or Vulkan.
The library has two core strengths: it works on virtually every platform that can run a GUI and the application code can be made to be pretty much agnostic of the underlying OS. Unless an application uses OS interfaces directly for fancy things, most of the porting work is just recompiling the code.
I noticed on the Qt website that it's used in everything from car dashboards to coffee machine interfaces. Is there a special reason for this? Is Qt hard to get into?
It is used for even more than that. KDE, the Linux desktop environment with its huge set of applications has used Qt since its early releases in the 90s. There is also a large set of commercial desktop applications for Windows and macOS that use Qt. That Qt is used for embedded software UIs is a comparably recent development in its long history.
I think the reason for this is that Qt has extremely high quality widgets and graphical elements. They allow you to do things out of the box that would be crazy hacks with most of the competitors. And the options for styling the UIs are very good, too, which matters a lot for these embedded use cases.
Is Qt hard to get into? Yes and no. In C++, you are required to use some mechanisms like signals/slots, which are used for routing events. These features look like non-standard language extensions and rely on a special source code preprocessor to generate the glue code that is implied. The other concepts are easier to pick up. And the toolkit is very consistent in the structure of its interfaces, so once you pick up the patterns, you can get very productive.
As I understand it, QT is good for embedded applications because it uses a very direct, weakly/efficiently abstracted API. You can do a lot with minimal computing resources. Putting something like chrome or firefox's rendering engine in embedded devices means carrying across lots of costly bloat or doing absurd work to slim them down.
The only thing that might make QT hard to get into is the lack of enthusiasm for it, the sparseness of expertise, stagnant job market, etc. Things that are "not hip" in development usually have similar obstacles.
Qt is much more than that. The sibling comment by gmueckl explains it properly. I also don't understand the immediate mode recommendation. QWidgets are immediate mode with QPainter. QML is retained mode with a scene graph and OpenGL.
Well, Ok, I mean any good tutorial on making a desktop app with Qt Design Studio. I expected it to be something like a better Qt Designer which is reasonably intuitive to use but in the video it looks completely extraterrestrial although beautiful. I'd like to build a desktop app with it but don't feel like I have any idea about how. The only tutorial video easy to find shows "Building an Instrument Cluster for Your Car HMI" and doesn't seem to make it clear how is the app supposed to interact with the computer it is ran on. Is it for cars only? Is it not supposed to be used for desktop apps development?
The old QtDesigner was simple enough. If you want to create classic desktop applications, use it.
QML is closer to a game engine than a widget toolkit. It is intended to provide an easy way to animate everything and create custom looks. It feel alien for a few months before you "get it". It is very powerful and easy to use, but the learning curve is steep and when you hit the limitations of the framework, have fun making any progress beyond it. It's also a bit hostile to native and modern code. Shared pointers are ignored and crashy. The binding between C++ and QML is also not the fastest thing in the universe.
I am writing complex apps using both as my bread and butter. I would not recommend QML for quick prototyping of complex apps. QtDesigner/QtWidgets still beat it. However if you need touch or fluid and modern looking GUI, QtWidget is a dead end and QML/QtStudio shine. It's really a project per project choice. They fill different niches.
Isn't it convenient to develop the whole app GUI in QML/QtStudio and use HTTPS to communicate to a backend without using any kind of pointers (ever since I've been coding C and C++ many ears ago when I was a schoolboy, the word "pointer" scares the shit out of me %-)) or something like that? In fact my whole experience is about C#/WinForms and I'm thinking about what modern cross-platform GUI toolkit that is probably going to be relevant in future and more pleasure than pain to use should I possibly switch to. I am also interested in developing KDE5 desktop widgets ("plasmoids") which are to be written in QML AFAIK.
> Isn't it convenient to develop the whole app GUI in QML/QtStudio and use HTTPS to communicate to a backend without using any kind of pointers
It /can/ be done, but almost nobody uses Qt that way. The web stack is a better fit for this. Pointers are not scary. Alsmost all languages these days use pointer (object reference) by default and it scares no one. Qt doesn't mix pointers with scoped/std::move in the default API, so you wont shoot yourself in the foot by accident. QObject, the base C++ class of every Qt component is reflected into the QML vm automatically, so you can use your objects on both side without any overhead or synchonization. You just need to add the `Q_PROPERTY` and `Q_INVOKABLE` macro in your header and QML will see it.
> Isn't it convenient to develop the whole app GUI in QtStudio
I honestly still think that's impossible. QtStudio isn't (yet?) close be being a good IDE. It aims at closing the gap between designers and coders. For pure coders, writing QML by hand is more predictable.
That's correct, there may be some platform specific things you can dig down deep enough to find but generally speaking you have to misuse the library to actually build something that isn't cross-platform.
My startup abandoned .NET in favor of Qt to develop a cross platform screenshot app to digitize math equations because we wanted Linux support (https://mathpix.com) and it's delivered. We still use Swift for our Mac app. The thing about .NET is that it's not nearly as seamless as a development stack as Swift + the whole Mac ecosystem. Whatever clunkiness exists in Qt apps already exists 10x in the Windows ecosystem of clunkiness everywhere, because Windows itself is, in a sense, cross platform. So the difference between a Qt app a .NET app is not super noticeable on Windows.
A good Qt app will be very nearly as good as a good .NET app, and a good Swift app on MacOS beats them all by a landslide.