3 ms·
There’s definitely some ambiguity as I have reasonable doubt that a Qt app wouldn’t clear the bar for “native” and yet, on Windows and macOS, it doesn’t really
by jchw 5y ago
There’s definitely some ambiguity as I have reasonable doubt that a Qt app wouldn’t clear the bar for “native” and yet, on Windows and macOS, it doesn’t really use the native UI toolkit. (To be fair, it can be the native UI toolkit on some platforms, but that’s a bit irrelevant to this point.)
I don’t really know what makes an app “native.” React Native apps are considered “native” because they are using the native UI toolkit. (C++) Qt apps are native because they are “native code,” and compile down to machine code with native binaries for their platform.
Web is distinctly not native because it’s a different runtime abstracted from the underlying OS. Electron introduces wrinkles in the distinction since they put the abstraction layers into the application package. React Native does that and then also introduces the idea of “native” meaning native widgets.
But what is the native UI toolkit? Win32 has a controls system, but even many Microsoft apps built into the OS don’t use it… so if your app does the same thing the built-in OS does, and uses say, WinUI or what have you, it’s hard to argue it’s “non-native.” Likewise for Linux. There’s no actually standard UI toolkit in any given Linux desktop setup.
MacOS and iOS largely stand alone as the platform where the “native UI” distinction stands strong, but I do think Flutter challenges it a bit on iOS, if at a high cost.
This all to say, I think the word “native” is surprisingly unclear.
- ampdepolymerase 5y agoThat is not a fair take. Windows has multiple first party UI toolkits, Win32 simply being one of the oldest and most well known. The Windows ecosystem places a greater emphasis on binary and dependency level backwards compatibility compared to Unix style systems.
- jchw 5y agoThe point I was making was that the distinction between native and non-native UI on Windows is very blurry, both by criteria one might define “native” UI (as windows UI libraries differ in how they are linked, distributed, and integrated with applications and the OS) and also by subjective criteria like look’n’feel. Even Windows itself can’t keep the story straight, and it isn’t improving dramatically in current Windows 11 previews, which feature a lot of different UI libraries and design languages across native apps. “First party UI toolkit” is a phrase that imparts some bias because it implies, in the frame of this discussion, that this is what makes a UI “native.” But even though that would be a workable criteria, it does have one serious problem: it’s utterly meaningless to the end user. It doesn’t imply almost anything about the user experience or the integration with the OS. It doesn’t really imply a whole lot to the developer anymore either. Compare this to the Linux desktop ecosystem, and it’s hard to tell much of a difference (other than the obvious fact that the Linux desktop is terrible :) — the UI toolkits feel similarly disjointed. Nothing feels “specifically” native. The only frame of reference is what your DE happens to use. Obviously, this all comes down to philosophy and I don’t mean to imply that this makes Windows worse except for in the more obvious ways (conflicting design language, look’n’feel, developer experience.) After all, even though I still believe macOS is ahead in this regard, I loathe to use macOS.
- ampdepolymerase 5y agoFirst party UI toolkit implies no bias. You are the one being biased by suggesting that open source/Linux-originated UI kits are somehow superior. The inability of the open source operating system ecosystem to deliver a coherent GUI is no fault of Microsoft or Apple. Ubuntu is going with Flutter, Google's answer to the GUI problem. The Linux foundation is to blame for the kernel not prioritising standardized systemland support for a consistent GUI. In commercial operating systems, the UI server/shell is not an after thought.
- BoorishBears 5y agoQt would not be considered native on mobile outside of the embedded space. (That is, despite running native code, your app would not be a native app.) Native on mobile is very easy to define because both major mobile platforms have extremely opinionated development kits that include a "blessed" method of making apps.