5 ms·

When people talk about an app being “native” they generally mean one that uses the UI toolkit(s) provided by that target. This is not native, this is just not-

When people talk about an app being “native” they generally mean one that uses the UI toolkit(s) provided by that target. This is not native, this is just not-Electron (or Xamarin or whatever else).

valbaca 5y ago
It's pretty close with Clojure & Obj-C interop: https://github.com/phronmophobic/mobiletest/blob/main/examples/objc/objc.clj https://github.com/phronmophobic/mobiletest/blob/main/exampl...
the_optimist 5y ago
I think you’re saying that a “native app” just uses the APIs for the “native” OS.
cmiles74 5y ago
I don't think people are all that interested in native UI widgets anymore. I think Electron has shown that a web-like UI is more than good enough.
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 ago
  That 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 ago
    The 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 ago
      First 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.
chrisseaton 5y ago
I think they mean it runs as native code. What libraries that native code uses is a different issue - but it's still native code.
- user-the-name 5y ago
  The exact technical details of how an app executes code is a lot less interesting to an end user than whether or not it uses the native UI. The former has almost no noticeable impact on user experience, while the latter can cause tons of annoyance.
  - chrisseaton 5y ago
    I think the number of people who care about a native UI has dropped to effectively zero over the last decade. The ship's sailed.
    - BoorishBears 5y ago
      People don't actively care, but I've watched conversion rates on certain paths in an app skyrocket when the UI changed to respect platform norms. People build up an intuition about how apps on their devices work, going non-native is an easy way to subtly break their expectations.
  - karottenreibe 5y ago
    I wouldn't call HN an "end user forum". So I think this content fits very well with the crowd here.
  - Zababa 5y ago
    I don't think that's true. Outside of a very vocal minority of mac users on HN, most people don't really care about native UI.
  - nicoburns 5y ago
    Generally when they talk about native people want a small app with good performance and low resource usage.
kcorey 5y ago
I feel you're missing the point of Apple's "guidelines", such as they are. Apple's rules are what Apple says they are on a given Tuesday. They can (and do) allow apps that flagrantly violate the guidelines, as well as refuse apps seemingly based on the direction of the prevailing wind, and unless you have an internal contact at Apple to protest, you're stuffed. Developers can do whatever they like with Xcode installed, but good luck distributing anything like this reliably. Nice toy, but I wouldn't bet a business on it.

valbaca 5y ago

It's pretty close with Clojure & Obj-C interop: https://github.com/phronmophobic/mobiletest/blob/main/examples/objc/objc.clj https://github.com/phronmophobic/mobiletest/blob/main/exampl...

the_optimist 5y ago

I think you’re saying that a “native app” just uses the APIs for the “native” OS.

cmiles74 5y ago

I don't think people are all that interested in native UI widgets anymore. I think Electron has shown that a web-like UI is more than good enough.

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 ago
That 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 ago
  The 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 ago
    First 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.

chrisseaton 5y ago

I think they mean it runs as native code. What libraries that native code uses is a different issue - but it's still native code.

user-the-name 5y ago
The exact technical details of how an app executes code is a lot less interesting to an end user than whether or not it uses the native UI. The former has almost no noticeable impact on user experience, while the latter can cause tons of annoyance.
- chrisseaton 5y ago
  I think the number of people who care about a native UI has dropped to effectively zero over the last decade. The ship's sailed.
  - BoorishBears 5y ago
    People don't actively care, but I've watched conversion rates on certain paths in an app skyrocket when the UI changed to respect platform norms. People build up an intuition about how apps on their devices work, going non-native is an easy way to subtly break their expectations.
- karottenreibe 5y ago
  I wouldn't call HN an "end user forum". So I think this content fits very well with the crowd here.
- Zababa 5y ago
  I don't think that's true. Outside of a very vocal minority of mac users on HN, most people don't really care about native UI.
- nicoburns 5y ago
  Generally when they talk about native people want a small app with good performance and low resource usage.

kcorey 5y ago

I feel you're missing the point of Apple's "guidelines", such as they are. Apple's rules are what Apple says they are on a given Tuesday. They can (and do) allow apps that flagrantly violate the guidelines, as well as refuse apps seemingly based on the direction of the prevailing wind, and unless you have an internal contact at Apple to protest, you're stuffed. Developers can do whatever they like with Xcode installed, but good luck distributing anything like this reliably. Nice toy, but I wouldn't bet a business on it.