Individual controls aren't the problem. Unique controls and idioms that cover multiple controls are.
For example settings dialogs on Mac are usually not modal and usually apply immediately. Meanwhile Windows dialogs are usually modal and transactional, with Cancel button to roll back and Apply to commit without closing.
Full fidelity inevitability ends up bifurcating the codebase or compromising the nativeness of the UI.
Simple things like button, text box, drop down, check box, radio button that have been in use for 30 years or more are just fine. But look at the list view in Windows; that has grown dozens of options to support Explorer, the file system browser. The deeper you go, the less you can keep common.
I see that the deeper you go, the less you can keep common. I learned a lot from your answers.
I didn't understand why the nativeness of the UI must bifurcate (fork) the codebase. In your example, can't non-modal on Mac vs modal on Windows be a config value in the cross-platform UI?
I also didn't get an answer to one of my questions. Why can't applications have low level access to create controls on their own?
For example settings dialogs on Mac are usually not modal and usually apply immediately. Meanwhile Windows dialogs are usually modal and transactional, with Cancel button to roll back and Apply to commit without closing.
Full fidelity inevitability ends up bifurcating the codebase or compromising the nativeness of the UI.
Simple things like button, text box, drop down, check box, radio button that have been in use for 30 years or more are just fine. But look at the list view in Windows; that has grown dozens of options to support Explorer, the file system browser. The deeper you go, the less you can keep common.