There's a severe lack of good libraries of this type; all the UI libraries want to invent their own controls and rendering instead. I think this is a shame, demonstrating more than a small amount of NIH.
There are a ton of reasons for a UI library to do their own controls and rendering instead of using the native, a big one being consistency across platforms and once you implement something on the UI, it is there on all platforms.
In addition, some platforms - specifically Linux and to a lesser extent macOS - have a very awful track record of backwards compatibility, at least as far as "out of the box" setups are concerned (sure you can install, e.g., Gtk 1.2 on a modern Linux, but aside from Slackware no distro has that available out of the box - not to mention that even where it is available it still lacks a ton of features introduced in later yet backwards incompatible versions). So while it might be more work now to implement something, it saves you a ton of work later when inevitably someone will break something you rely on and you'll have to fix it on your side.
Here is an example from my own experience working with and a bit of working on a library that does expose the "native" controls (LCL, the framework of Lazarus[0]): a couple of years ago or so i implemented MDI support for Win32 (the API was there for years, just never implemented). Spent some time reworking things and refactoring them on both the system agnostic and system specific parts and after a review it was merged. Yesterday i wanted to make a small tool where i thought MDI would fit, however nowadays i'm on Linux as my main OS. Gtk (specifically Gtk2 but in that case it doesn't matter) doesn't have any MDI support at all so of course that wouldn't work there, but fortunately LCL also has Qt backends and Qt does have MDI support - so i changed the LCL backend to Qt5 just for that tool, tried the MDI tool and... MDI for Qt5 support was very buggy. Things that i know worked on the Win32 backend (because i implemented) wouldn't work on the Qt backend.
So now what? Well, i don't feel like fixing the Qt5 backend's MDI support (at least not anytime soon) but Qt itself does support MDI just fine. And thus i made the tool using C++ and Qt6 instead (i had Qt6 Creator installed and decided to go with that since i already had it available).
And of course the tool would work fine under Win32 and probably macOS too because Qt does implement and render its own controls.
Note that this is just one example from my very recent experience. Also it isn't specific to LCL, i had similar experiences with wxWidgets -which also does similar wrapping- at the past.
That is not to say that there are no positives to having native controls, but in my experience the only platform where that works reliably and with little fuss in the long term is Win32, everything else is a PITA, even if you decide to be as conservative as you can (e.g. LCL has its own DPI scaling support but HiDPI scaling in LCL with the Gtk2 backend under KDE/Wayland doesn't work because it seems to lie to the X clients about DPI - it does work fine under KDE/X11 however).
Comments
There are a ton of reasons for a UI library to do their own controls and rendering instead of using the native, a big one being consistency across platforms and once you implement something on the UI, it is there on all platforms.
In addition, some platforms - specifically Linux and to a lesser extent macOS - have a very awful track record of backwards compatibility, at least as far as "out of the box" setups are concerned (sure you can install, e.g., Gtk 1.2 on a modern Linux, but aside from Slackware no distro has that available out of the box - not to mention that even where it is available it still lacks a ton of features introduced in later yet backwards incompatible versions). So while it might be more work now to implement something, it saves you a ton of work later when inevitably someone will break something you rely on and you'll have to fix it on your side.
Here is an example from my own experience working with and a bit of working on a library that does expose the "native" controls (LCL, the framework of Lazarus[0]): a couple of years ago or so i implemented MDI support for Win32 (the API was there for years, just never implemented). Spent some time reworking things and refactoring them on both the system agnostic and system specific parts and after a review it was merged. Yesterday i wanted to make a small tool where i thought MDI would fit, however nowadays i'm on Linux as my main OS. Gtk (specifically Gtk2 but in that case it doesn't matter) doesn't have any MDI support at all so of course that wouldn't work there, but fortunately LCL also has Qt backends and Qt does have MDI support - so i changed the LCL backend to Qt5 just for that tool, tried the MDI tool and... MDI for Qt5 support was very buggy. Things that i know worked on the Win32 backend (because i implemented) wouldn't work on the Qt backend.
So now what? Well, i don't feel like fixing the Qt5 backend's MDI support (at least not anytime soon) but Qt itself does support MDI just fine. And thus i made the tool using C++ and Qt6 instead (i had Qt6 Creator installed and decided to go with that since i already had it available).
And of course the tool would work fine under Win32 and probably macOS too because Qt does implement and render its own controls.
Note that this is just one example from my very recent experience. Also it isn't specific to LCL, i had similar experiences with wxWidgets -which also does similar wrapping- at the past.
That is not to say that there are no positives to having native controls, but in my experience the only platform where that works reliably and with little fuss in the long term is Win32, everything else is a PITA, even if you decide to be as conservative as you can (e.g. LCL has its own DPI scaling support but HiDPI scaling in LCL with the Gtk2 backend under KDE/Wayland doesn't work because it seems to lie to the X clients about DPI - it does work fine under KDE/X11 however).
[0] https://www.lazarus-ide.org/
Lazarus is great, especially on the desktop, but wish they made mobile development a priority and went in on it fully.