The tricky thing about cross-platform UI dev, when considering macOS, isn't just about the widgets and so on. It's things like placement, hierarchies, etc. Like you said, easier said than done. To demonstrate for those who aren't sure:
Say Joe Bloggs wants to make an alert window to confirm if the user wants to save the document, but needs to add custom text and graphics so can't rely on a default implementation on each platform. So he makes an alert window, looks great.
Except his design is utterly confusing for macOS users. See, on Windows (and plenty of Linux environments), the Save and Cancel buttons would be centred on the window, and Save would be at the left. On macOS, Save and Cancel would be aligned to the right, and Save would be the right-most button.
Okay, so that's a pretty easy thing to solve with a cross-platform toolkit. Instead of defining the placement of buttons, you just define the text and action for the default button, the text and action for the cancel button, and they'll be put in the right place for every platform. Easy.
But that's such a small example. Try scaling that to the way macOS and Windows/Linux differ in the use of view hierarchies. Windows-style tab controls vs NSTabView; Windows/Linux-style tabbed, left-aligned settings windows vs standard macOS-style centre-aligned preference windows with NSToolbar at the top; each window/section of an app having its own menu bar as opposed to macOS having a static menu bar whose items enable/disable depending on context; MDI vs document-based apps; the fact that macOS apps can still be running even with no windows open, meaning that certain parts of the UI can still be opened, and your UI must account for this despite another window that you would expect to be open (on Windows or Linux) not being in memory at all.
To an engineer, these might seem trivial or not that big a deal. To a user, that's potential data loss.