Swift is developed by Apple for Apple ecosystem. Thus, the native calls are of course efficient.
Qt is a framework that works as bridge between the native calls and your application, the same applies for .NET.
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.
Why don't you use Qt on Mac then? The main advantage of using such a framework is that you have only one codebase/language that runs everywhere.
> 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.
[0] https://doc.qt.io/qt-5.11/qtquick-visualcanvas-adaptations-d...
.NET Core 3.0 will apparently finally bring .NET Native to Windows desktop apps as well.
Qt (Quick) is on the same level than WPF actually. Both create a scene graph and render it. WPF does not use native windows primitives.
WPF is somewhere else; as the sibling commenter told you, it is a .Net framework, so it has entire .Net VM underneath.
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).
In what sense(s) does the final application end up better?
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 = UI library.
What did you write your back-end code with? C++ ?
(You mentioned that the Mac version is written in Swift, but what about the Windows and Linux versions)?
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.
Here's a good list of things Qt has stuff for.
Oh no! Why then Qt is all over my server code?!
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.