Native implies that you are building for each OS and their native toolkit. On macOS, you write Cocoa. On Linux you write GNOME or KDE or CDE. On Windows you write...I dunno. Win32 probably.
Current tech is C++/WinRT, for this year, but last year it was WPF and five years ago it was XAML, then previously it was MFC/ATL, and original Win32 somewhere back in the old days.
And Linux isn't better. I think OSX is the only desktop OS that has an idea of what an app should look like.
MacOS used to have a choice between Carbon and Cocoa, didn't it? Maybe still does.
C++/WinRT uses XAML. But XAML isn't a control library/toolkit. You can tell because it isn't called the Extensible Application Control Library. I'd say it shouldn't be included in your list, but MFC/ATL is just a way of accessing Win32 via C++ -- it makes the same function calls -- so it's not clear that your purpose was to make a fair statement about native development, but perhaps to complain about Windows turnover of apis.
On Linux, it's quite simple to live entirely in Gtk-compatible land. I think Firefox and JetBrains are the only foreigners I use on my box, but I'd be using them on any opertaing system so it's not exactly a fair cop.
Let's go with a file picker dialog, a simple OS-provided component. Windows provides three versions of this dialog (the "app" view, the tree-view, and the explorer-in-your-app view) depending on which API you use. You see this pattern repeated. It being the same calls "underneath" is true, but it's also irrelevant, as the user experience noticeably changes depending on which API is invoked.
And Linux isn't better. I think OSX is the only desktop OS that has an idea of what an app should look like.