Hacker News new | ask | show | jobs
by pcr910303 2370 days ago
Well, just Emacs bindings are not the point; it’s that non-native widgets don’t respect the user’s intent of customizing the whole OS. Let’s take another example: macOS supports Dark Mode from Mojave... and Electron apps usually don’t implement them, or if they do: with a separate toggle.

Yeah, these aren’t great deals, but people who care enough try to switch to alternatives. And by using native UIs, you can mitigate your concerns about whether you implemented everything the user expects or not.

2 comments

The most popular apps in the world -- Facebook, Instagram, Twitter, Uber, Line, Airbnb, Snapchat, many many more -- all use completely custom UIs focused on consistentcy across platforms, which they accomplish by purposely not following any individual platform's specs or using platform widgets.
Yeah, and they are successful (mostly due to networking effects — all of the apps you’re mentioning have strong network effects) in spite of their app quality.

The Facebook app is criticized everywhere, I can’t think of anyone who likes their app.

AFAIK AirBnB once used RN but moved to native development, and Twitter use native widgets.

Also, don’t forget that they have the resources to develop all of the expected features of native widgets, for example Accessibility. The OP probably doesn’t.

And, this is all talking about RN which is actually half native since they use native widgets; Flutter is much worse than this because they draw their own widgets.

>> don’t forget that they have the resources to develop all of the expected features

You're talking out of both sides. The OP is obviously limited on resources. That's the exact reason flutter is a good option, he gets an app that works on iOS and Android in one codebase using a modern language. Going native requires 2 distinct code bases, which itself requires learning all the specific quirks and features of each platform. Android adapters and fragments, XML layout, distinct libraries for simple Http calls, object serializers, etc, etc. The only downside you can point to is "its not native" and guess what, see above, users don't really care.

> Yeah, and they are successful (mostly due to networking effects — all of the apps you’re mentioning have strong network effects) in spite of their app quality.

That seems to live up with what was said further up the thread:

> People will put up with a lot of garbage if your product fills a need. And non-native UI is not even inherently garbage, just sub-optimal (and even that depends on the product)

They also have dozens of developers working on their apps.
And the OP doesn't, which is why a cross-platform toolset like flutter is a great option in his case.
A mobile example : I know a company that decided to scrape their crossplatform codebase (I can't remember if it was flutter, RN, or whatever else).

They had the opportunity to be promoted as app of the day by Apple, which would have been awesome for them.

Unfortunately the condition was to ship an apple watch integration. The sdk they were using did not support it.