> you can both look as native as the other, doesn't the actual UX matter more than how the implementation was made?
An Electron app that draws all its components mostly like the native controls will still not be native and have the same integrations etc. that native apps usually get.
You could get close but some things like for example "ctrl+f" search have native widgets that work different/look different that an electron app realistically won't have. Or for example you will never get the same liquid glass materials that macOS uses in an electron app.
So yea, native in my books means using the platform native (UI) apis. On Ubuntu for examples thats GTK, on Windows its.... idk at this point, WinUI? and on KDE it would be Qt.
You can get all those things in a Rust application drawing with Cairo on macOS, but that isn't "native" according to you regardless, because it's using Cairo instead of AppKit/SwiftUI?
Again I don't understand the obsession with caring so deeply about the implementation, as long as the end results are the same, why it matters so much?
My point is practically you don't get the same results unless you use the native APIs the the platform provides.
Take my Liquid Glass for example, you simply won't be able to match the look in an electron app in practice.
Ofc if the result is the same it doesn't matter how, but in reality it's almost impossible to imitate the look and capabilities since it would require a Herculean effort to keep feature parity.
Right, but you could call native APIs from JavaScript or Java say, then in your world that's a "native" application because it uses the APIs the platform provides, regardless of how it actually was implemented? Meanwhile, an application could be implemented with Objective-C and/or Swift but not use Cacoa/AppKit/SwiftUI APIs, then that's not an native application because it doesn't look like one? Like games written with Vulkan/OpenGL aren't "as native" as one using Metal I'd presume?
you could call native APIs from JavaScript or Java say, then in your world that's a "native" application because it uses the APIs the platform provides
Yes, this is what we want.
an application could be implemented with Objective-C and/or Swift but not use Cacoa/AppKit/SwiftUI APIs, then that's not an native application
Correct. The toolkit matters, not the language. Native toolkits have very rich and subtle behavior that cannot be properly emulated. They also have a lot of features (someone mentioned input methods and accessibility) that wrappers or wannabe toolkits often lack. To get somewhat back on topic I notice and appreciate that Xilem mentions accessibility.
games written with Vulkan/OpenGL aren't "as native"...
Games are usually fullscreen and look nothing like desktop apps anyway so it doesn't matter what API they use.
You can technically get those platform native things by integrating with the native APIs. There's basically a full spectrum from "native" to "custom" rather than it being either-or.
An Electron app that draws all its components mostly like the native controls will still not be native and have the same integrations etc. that native apps usually get.
You could get close but some things like for example "ctrl+f" search have native widgets that work different/look different that an electron app realistically won't have. Or for example you will never get the same liquid glass materials that macOS uses in an electron app.
So yea, native in my books means using the platform native (UI) apis. On Ubuntu for examples thats GTK, on Windows its.... idk at this point, WinUI? and on KDE it would be Qt.