Hacker News new | ask | show | jobs
by whiplashoo 1625 days ago
Even if you can spot a non-native app in seconds, does it really matter? The vast majority of users simply won't notice and not care at all if it's native or built with Flutter, Xamarin, RN, etc.

The same has been said for Electron on desktop for years, but look at how VS Code is probably the top editor in use on desktop platforms, and even more demanding audience, like developers, don't really care that it's non-native.

5 comments

It does matter, I skip using a lot of airline apps and some bank apps, because of the horrible experience they provide.

It’s easier to do it via their website.

You're equating horrible experience with cross platform architectures, whereas there are any number of reasons apps can be bad.

It is perfectly possible to build a poor app in any language.

Well that’s the point. While it’s perfectly possible to build a poor app in any language, it’s almost impossible to build excellent app in cross-platform framework. The reason why you recognize them almost immediately is that there are some people obvious annoying details - scroll lag, non-standard UI elements, non-standard navigation patterns, you can just immediately feel something is wrong, even if you are a normie. It can be partially compensated by the app having some other great benefits.
I disagree about scroll lag. There are plenty of WebView apps (and websites obviously) that have zero scrolling issues.

Non-standard UI elements is something I don't personally care about. Some people do, but I think this is an issue that is often overstated (or perhaps rather overestimated as a factor) by platform enthusiasts.

What does matter a great deal to me though is launch speed and battery usage. Mobile apps are often used for short periods of time. They must launch instantly. And battery is the scarcest resource in mobile computing.

Nobody will voluntarily use an app that is slow to launch and shows up at the top of the battery usage table in spite of only having been in use for a few minutes.

As a developer, these are the issues I would like to learn more about in respect of any new cross-platform technologies.

> While it’s perfectly possible to build a poor app in any language, it’s almost impossible to build excellent app in cross-platform framework.

100% this. Cross platform frameworks will always fall into a weird uncanny valley where there are just things that are subtly off about apps made with them. Most of the user base may not be able to pinpoint exactly what's wrong with such apps, but I believe they still notice on some level.

I rarely notice unless the developer hasn't put any effort into the UI. Most people don't care.
Of course they don't care. But you can feel the experience is not spotless.
I usually don't notice or care, unless they haven't put any effort into it. Now that I'm thinking about it, there are a few that I suspect aren't native, and I don't get bad feelings from the apps unless they are badly programmed and the functionality doesn't work.
But if they don't care, why does it matter what they feel?
Even the best Flutter apps feel awful compared to a decent native iOS app. Which honestly sucks, because I much prefer writing Flutter apps to anything else.
Unfortunately the horrible experience is much more normalized with the amount of bloatware and horrible ux software out there to the point that users will use it either way in many cases.
And truth is, as long as you have exclusive content on a service, the quality of your app (and thus the satisfaction of your end users) doesn't matter all that much.
This comment applies equally to native as it does cross-platform frameworks
And yet those businesses continue with the app they have. That tells that the vast vast majority of their clients don't care or are happy with them.
I'm not sure why you're getting downvoted. I often don't notice, and I've never heard anyone comment about those things. Most end users don't even know what those platforms are. Some apps look different than others just like some websites look different than others.
Or just suffer through.
That’s not how cause and effect work.
I hate when people bring up VS Code in defense of electron. It is basically the one application built in electron that isn't obviously significantly worse because of it. And it's because it is backed by a trillion dollar company that can afford to invest the time to fix the electron limitations for their project. No other app built in electron is even remotely close to VS Code, which is still noticeably bad in performance when compared to native editors.
Slack, Spotify, and Obsidian.md are other apps where I couldn’t really care that it’s using electron.
Slack and Spotify are not great. You can tell they're electron. I don't know Obsidian.
It's still used by millions, so I would say it's a success
I use Electron based apps, because they are part of the job, refusing them means looking for another job, which in the current world status is kind of not really what I want to do.

The path to sucess is a very tortuous one full of victims.

1password 8 is also very good, being built in Electron with a Rust backend.
Is it better than the native 1password7?
Personally, yes, I think so.
Additionally they offload tons of stuff to native code out of process.
> The vast majority of users simply won't notice and not care at all if

Users will of course notice and care. It's just they are not versed in shitty tech to properly articulate what they notice.

So every time a user says "the app is broken/slow/hard to use/loses data/can't update data etc." quite often it's because it's some shitty wrapper on top of a shitty "web app".

It’s not that people like to play the game “spot the non-native app” for fun, but rather that the fact that non-native apps are so easy to spot means they have some obvious deficiencies that become apparent within seconds of use. No one ever said “I can tell this app is non-native because it’s too fast and fluid”.
I care that VS Code is non-native. Don't you dare move an open file around the file system outside of VS Code, less it thinks it's been deleted. And it still doesn't have the standard macOS file operations available in the window titlebar.