I hear you on the native UI is better all things considered. I'm trying to figure out how that works in practice. I.e., to accompany a "cross-platform UIs are inferior to native ones", you would be effective to also include the workflows you use. In a realm where you choose options, eliminating one should come with illuminating another, as one must choose a path, and others could be eliminated for their drawbacks as well, leaving none available. What is your path here?
- proprietary,
- command line tooling,
- single-platform.
A good example of what I consider to be a great approach (not mine) is Ghostty, which has fully native UI per platform and a shared core between platforms. JetBrains tools also go out of their way to integrate with platform conventions everywhere.
An example that cross-platform toolkits usually get wrong: cursor navigation in text fields. Home and End do different things on different platforms, and on macOS, basic emacs/readline bindings are supposed to work in all text entry fields.
It’s worth noting that this extends beyond GUIs - command line tools written in Go tend to use “package flag” which is native nowhere. The standards between Windows (which has two, in cmd and powershell), GNU-style and “legacy” Unix style are just not reconcilable without implementing platform-specific behaviour.