[moughxyz]

There's no reason it has to hurt UX in theory. The difficulty is just in spending a lot of extra time perfecting the animations and interactions, which is 100% doable. We just released navigation present and dismiss animations a few weeks ago, which feel pretty great imo. They're non-interactive, and again, this will take a lot of extra work you get for free with native, but the tradeoff is worth it for us, and again, amenable.

[KerrAvon]

You seem to be in very heavy denial. This will never be as nice to use as a native app, because you cannot replicate all of the small details of how native UI works on each platform. And say you manage to get close to emulating a native app on one platform — when the OS UI updates, you’ll be behind again.

I get that it’s inconvenient/expensive for you to build three UI layers. But that’s the only way to do this well. This was true for cross-platform apps in 1989 and it remains true decades later.

[locutous]

> This will never be as nice to use as a native app, because you cannot replicate all of the small details of how native UI works on each platform.

Not sure how much of that is necessary. I mean, a button doesn't "look native", so what? It's a button.

Apps written to require network requests to resolve a navigation are much worse than JavaScript handling a user event.

> And say you manage to get close to emulating a native app on one platform — when the OS UI updates, you’ll be behind again.

Not really the goal. You have this backwards. Keeping up with OS churn is one of the reasons to use an abstraction like this. It doesn't break your app nearly as much. The browser is a much more stable target than native mobile APIs.

> I get that it’s inconvenient/expensive for you to build three UI layer. But that’s the only way to do this well.

Inconvenient is dramatically understating the case. 3x spend is flat out impossible for many places.

[dmitriid]

> Not sure how much of that is necessary. I mean, a button doesn't "look native", so what? It's a button.

Is it? Native buttons also come with things like affordances, accessibility, recognizability.

"So what" is what lead Google to spend money on user research involving hundreds of people to figure out that text boxes looking like text boxes is good, actually.

[locutous]

> Is it? Native buttons also come with things like affordances, accessibility, recognizability.

And web views come with things like scaling, accessibility, page/document search. The recognizability and discoverability is up to the designer. Between the two, I miss browser features a lot more than native look and feel.

Then let's not forget the privacy nightmare that mobile apps have been.

I can also often fix poorly built web with some css or other hacks that I cannot do on mobile for poorly built apps. I helped a user do just that the other day, if it had been native he would not have been able to work around the design issue.

The native bias here is crazy. Most users just don't care and can't tell if they are on something that's native vs a web view. What they care about is, does this provide me value? That's real UX. Not blowing out development budgets on duplicating the same features on 3 platforms. You can spend that potential budget on refining and improving the features.

Does it matter sometimes? Yes! The are limits to what you can reasonably do in a web view. But most of the time a web view works fine.

[dmitriid]

> The native bias here is crazy. Most users just don't care and can't tell if they are on something that's native vs a web view.

They can. You just don't know how to listen. "It's slow to open", "it's janky", "it stutters when it scrolls", "I tap/click and nothing happens" etc.

Does this happen with native apps? You betcha. It is significantly more prevalent with web because web has never been and never will be an app platform. It's core is to display text and images, and it can barely manage that.

[locutous]

> They can. You just don't know how to listen.

I've worked on many mobile products. This has been true of none of them. Please provide some evidence of otherwise?

> Does this happen with native apps? You betcha.

Something I agree with. It is the indian and not the arrow. I've seen native, multiple cross platform apps of different flavors, and web views. All of the major problems were due to institutional shortcomings. If our app is bad, it isn't a tooling problem it's because we fail to execute.

> It is significantly more prevalent with web because web has never been and never will be an app platform.

Ummm... I sell web apps. Many major vendors have products that are, at heart, web apps. Progressive web apps, web apps, electron, phone gap, Cordova, capacitor, etc. I find this observation a demonstration of your ignorance of this market.

[riwsky]

3x spend may well be impossible for some places—but maybe that means great UI is impossible for them, too. The fact that I can’t afford a Ferrari does not magically make “the best car I can afford” be as good as a Ferrari.

[locutous]

If my customers don't really need a Ferrari, then making them pay for one is expensive. Most cars work just fine for most people.

Software is expensive. People resent high rate subscriptions as it is. Including on here. They resent it a lot more than lack of native toolkit. Ironically, price resistance on mobile is at legendary levels.

But so many can't seem to escape the gravity pull of dev strategies that blow up budgets like multiple code bases, micro service backends, etc etc.

Very very few of my customers actually want a Ferrari with the accompanying price tag. They want stuff that is convenient and works, the car is less important than the destination I can take them to. They don't really care about the last 5% percentile UI flexibility that is a native toolkit.