Hacker News new | ask | show | jobs
by Illniyar 3175 days ago
"Since every pixel on the UI is rendered by the framework"

This is a deal breaker for me. It's not about the ui feeling a bit off - the drawer going over instead of pushing things or some such, it's about losing the integration with the native OS.

For example the android version of the gallery app shown elsewhere doesn't adjust to font size changes (which can be done at the system level), won't make a sound when clicking things if sound on tap is set, has no accessibility support.

Rather then marking the entire word double tapping on a word in an input-text does nothing, long pressing on the input opens a non-native menu with cut/paste/copy while a regular input has share and translate (at least for me).

And this is just a minute of tests, it probably fails to integrate into the larger ecosystem in a gazillion ways - many of them you'll find out when users complain about it once you go into production.

This was tried before (for instance Java's swing vs SWT) it almost always results in eventually outdated slow interfaces that are a pain to migrate to newer technologies.

5 comments

(disclaimer: I'm on the Flutter team)

Thanks for the feedback! We are working on improving our accessibility now, which is required for our business-critical Google users and others. For example, you can follow this issue if you're interested: https://github.com/flutter/flutter/issues/12311

The clicking sound on button presses has been fixed in the latest build, and the Flutter team is working on accessibility. But I agree that a Flutter app will always have some deficiencies compared to a native app.

However, the question is whether a Flutter app will be Good Enough when the alternative is writing two separate apps. I would argue that even in the current alpha stage it's getting pretty close to Good Enough - the Hamilton app was written in Flutter and gets 4.7 stars on Google Play [1] so users aren't too bothered that double-tap doesn't select text.

Java Swing was slow, bloated and looked far less like a native app than Flutter. And in 2003 Windows had a 95% market share, so there was no major benefit to writing a cross-platform desktop application. Things may be different this time.

[1] https://play.google.com/store/apps/details?id=com.hamilton.a...

As some one who has written cordova apps they often times are also good enough. There are cordova apps in the 4.5 range with 100's of reviews.

Life rpg was one that I remember (now its down to 3.9).

The alternative isn't writing two native apps, the alternatives are cordova, react-native and xamarin.

Frankly I haven't other people's compatibility issues with react native.

> However, the question is whether a .. [Flutter, Cordova, React-native etc app] .. will be Good Enough when the alternative is writing two separate apps

This is a more important consideration than is often given credit for, perhaps because the perspective we most often read about is the high end of the industry. But vast amounts of software is written to extremely tight budgets, often for small businesses, where there is flat-out zero chance of two native apps being written. It's choose-your-platform, or something cross-platform.

For very many of these kinds of apps, which are pretty much invisible from the blogs/HN/medium world, RN/Flutter/Cordova etc are perfectly appropriate. The fact that these may not be the best platforms from which to use the very latest, most hardware-entwined OS features, or to do highly custom 'delightful' bits of UX, is often in this world quite irrelevant.

I don't like the approach either, and the point about accessibility is an important one that's very much non-trivial (but developers often ignore it completely at first).

It's like making a web page that renders everything inside Canvas elements. If that doesn't seem like a good idea to you -- why would you build your mobile apps that way?

The interesting part of Flutter for me is that it powers Fuchsia.

IF Fuchsia becomes a major thing, like the future of Android (and I can't emphasise enough how much it is uncertain right now) then it might become very interesting as a way to publish your new app on Fuchsia while being able to publish it on Android as well in order to support `legacy` devices (again, supposing that Android is abandoned in favor of Fuchsia)

Otherwise, it is 'just' another hybrid solution with the usual caveats.

I also use a cross-platform framework that "renders every pixel". The two major problems I had are the lack of native input and the integration with native ad SDKs. I solved the input with overlaying a native input view on top of everything but it's very clunky and have to be careful to keep it the topmost in the view hierarchy. I haven't found a solution for native ads.

Most of the other things are relatively easy to solve if they come up as actual problem.