Those are not native (on desktop) in any sense of the word. They don't use native controls. For that, you want WX or SWT, but those come with their own sets of problems.
On Windows, it's not even obvious what native is any more, even Microsoft just uses Web views. Mac is a bit better, but there are still 4 UI libraries to choose from (AppKit, UIKit through Catalyst, native SwiftUI and Catalyst SwiftUI).
I'm personally a fan of AppKit and Win32, but those are "dated" apparently.
I am working on the UI library and bindings for Go. Still not finished, but currently, the same app can be compiled for Win32, Cocoa, GTK2, GTK3, GTK4, Qt5, Qt6, and Motif. There is a web browser control, a GL canvas, and a regular canvas. I still work on the native table control, though.
IUP has custom-drawn controls for tables and cells (additional controls), and it uses another CD (canvas draw) library for that, not internal IUP Draw functions. I also started rewriting that to use the core IUP drawing functions instead. I also added a few more drawing functions, for rounded rectangles, bezier curves, and gradients. But ALL drivers, including Motif, have native table controls, so I really want to add one.
Edit: Also, the GLcanvas control now has an EGL driver, with native Wayland support for GTK3, GTK4, and Qt6 (needs private headers). I modernized a bit of everything, added support for APPID, DARKMODE, etc. Linux uses xdg-open rather than hardcoding browsers. Win32 driver is not using the Internet Explorer web control but the WebView2 with custom loader, on GTK, you do not have to worry about the WebKitGTK, it will find the correct library with dlopen, etc, etc. But, there is still a lot to do.
gp was using a more restrictive definition of "native controls". I.e. "o/s builtin UI controls" vs "framework canvas painted elements".
For Windows, "native" would be the classic Win32 UI "common control" elements from "Comctl32.dll"[0] that is directly used by older GUI frameworks such as Windows Forms. Those map to classic Win32 API CreateWindow(L"BUTTON", ...). In contrast, the newer frameworks of WPF and Xamarin Forms and Qt Quick "paints controls on a canvas" which are not "native" and makes every app UI look different instead of standardized "look & feel" of common controls.
But others include custom-canvas painting UI objects as "native" -- as long as it's not Electron.
It's worth noting that some cross-platform toolkits are non-native in the strict sense, but mimic each platform's native controls.
This is harder to get right than one might think; small differences in text rendering look very much alien to me, and user input handling that isn't exactly the same as the platform's native conventions will make me stumble every time I perform common operations.
In my experience, Qt does an excellent job with this. It's not technically native (except on KDE and other Qt-based desktops), but it looks and feels right, or so close that I find it comfortable and well integrated with the rest of each platform I've tried. I haven't found any other cross-platform toolkit to match Qt in this area, so that's what I use for now.
Some day, I hope we'll see an alternative that accomplishes this at least as well as Qt, while being more flexible to license, easier to bind to other languages, and better at memory safety. (It's written in C++.) There seems to be renewed interest in GUI toolkit development lately, perhaps fueled by the excitement for newer languages like Zig and Rust, so perhaps I'll get my wish.
As far as I can tell, Qt Quick doesn't have anything like the same set of
polished widgets that integrate nicely into the target platform. It's been
this way for years, they just don't seem interested in implementing them.
On Windows, it's not even obvious what native is any more, even Microsoft just uses Web views. Mac is a bit better, but there are still 4 UI libraries to choose from (AppKit, UIKit through Catalyst, native SwiftUI and Catalyst SwiftUI).
I'm personally a fan of AppKit and Win32, but those are "dated" apparently.