Because the layout that's presented is not native. Actual mac apps don't have tabs and toolbars pushed together like that, and the margins are different.

wxWidgets can use the platform native controls, but the apps rarely look native because the layouts and behaviors are non-native. Mac/GNOME/Windows all have different ideal metrics for spacings, control placement and labeling (OK/Cancel vs Cancel/"Do Thing") -- being native means getting all of those details correct.

Fair point. The spacing and margins are totally wrong, for sure. But that's just spacing & margins, and I assume that's easily adjusted (and they should do that, so their demo doesn't look ugly). But nonetheless, the widgets are native Cocoa widgets, so they not only look native, they feel and behave native, something you can't say about Qt (at least not to the same degree — although I develop with Qt, love Qt, and have zero issues with the way Qt applications look and feel on Mac).

The spacing and margins are all manually specified (or, in the case of the example, aren't specified at all, so they default to 0). If you cared to do so, this spacing could be manually adjusted.

Under the hood, it's 100% native widgets (i.e., on OSX, the code is actually instantiating an NSButton, adding it to an NSView, set as content on an NSWindow; on Ubuntu, it uses Gtk.Button etc), so the look and feel of the widgets themselves are exactly as the platform dictates.

"100% native widgets" is the easy part and wxWidgets/wxPython is doing just that (and always have been). Providing higher-level API is harder and again, wx does that too.

But the devil is in the detail. The reason why many wx apps don't look very well on OS X is because getting all the tiny details like spacing, behavior, layout etc. right for all supported platforms, with (mostly) same code base is hard - and it has nothing to do with the look of individual widgets.

But well, you'll learn that during the journey ;)