HN Explorer

21 comments

[ 3.3 ms ] story [ 70.1 ms ] thread
kevinherron
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).

the_optimist
I think you’re saying that a “native app” just uses the APIs for the “native” OS.
cmiles74
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
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
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
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
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.
BoorishBears
Qt 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.

chrisseaton
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
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
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
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
I wouldn't call HN an "end user forum". So I think this content fits very well with the crowd here.
Zababa
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
Generally when they talk about native people want a small app with good performance and low resource usage.
kcorey
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
The video has a conversation (around 54:00) about the Apple approval implications around something like a REPL. There are other apps with REPLs or coding features. Pythonista is mentioned. Figured I'd drop a link to the actual policy:

https://developer.apple.com/app-store/review/guidelines/#sof...

""" 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.

"""

saagarjha
Unfortunately, this is not an accurate description of how Apple enforces that particular rule against apps.
indiantinker
I think PWAs should be empowered and made easy to install. Major OS players make installing PWAs un-intuitive so they can possibly have more control and charge dev fees. I love the ease and flexibility of PWA and sad that I have to learn new frameworks to make the same thing just distributed via the playstore monolpoly.
phoenixdblack
Depending on what Device API you want to use, wrapping your webapp using Capacitor is a solid option.