> Instead of trying to decide whether a GUI toolkit is native or not, I recommend asking a set of more precise questions: > > * Does text look like the platform

> Instead of trying to decide whether a GUI toolkit is native or not, I recommend asking a set of more precise questions: > > * Does text look like the platform native text? > > * To what extent does the app support preferences set at the system level? > > * What subset of expected text control functionality is provided? > > * Complex text rendering including BiDi > > * Support for keyboard layouts including “dead key” for alphabetic scripts > > * Keyboard shortcuts according to platform human interface guidelines > > * Input Method Editor > > * Color emoji rendering and use of platform emoji picker > > * Copy-paste (clipboard) > > * Drag and drop > > * Spelling and grammar correction > > * Accessibility (including reading the text aloud) > > If a toolkit does well on all these axes, then I don’t think it much matters it’s built with “native” technology; that’s basically internal details. That said, it’s also very hard to hit all these points if there is a huge stack of non-native abstractions in the way. This is it! Browsers handle all of this. It's a ton of work. Many many gui kits start with just ASCII and really don't realize how deep the rabbit hole is for making all of this work. And as always, if you haven't read them https://gankra.github.io/blah/text-hates-you/ https://gankra.github.io/blah/text-hates-you/ https://lord.io/text-editing-hates-you-too/ https://lord.io/text-editing-hates-you-too/