
Flutter looks good, but is painful - xhroot
https://medium.com/@bernaferrari/from-android-dev-flutter-looks-good-but-is-painful-here-are-my-frustrations-with-it-81b4bbe739f8
======
pcr910303
While this has little relationship to the original article... We really should
be trying to use the native GUI toolkit (or cross-platform native UI libraries
like libui), not using Flutter-esque libraries that draws everything from
scratch.

Coherent UI is a very important point to users IMO. Users can assume that some
special feature from App X will also work on App Y.

For example, in macOS Cocoa, textboxes have universal readline-esque
keybindings (and is configurable globally) which, as an Emacs user, very, very
useful.

Most Mac apps use Cocoa as the GUI toolkit, so basically all kinds of apps can
benefit these keybindings.

Another example of this directly benefiting users is the addition of tabs in
macOS Sierra.

macOS Sierra added tabs to Cocoa apps, and applications could get the feature
without additional modification. I can use tabs in any application, with the
same look-and-feel, in all apps.

Stories like these are mostly only macOS; since Windows apps usually just re-
invent all kinds of UI elements, while Linux's GUI toolkits are super-
fragmented. (GTK vs Qt is one thing, and there are lots of other options!)

Adding Flutter or any other UI library that draws everything from scratch is a
_bad_ idea.

~~~
jazoom
>Adding Flutter or any other UI library that draws everything from scratch is
a bad idea.

Some would say re-writing the same app 5 times (Windows, macOS, Linux, iOS,
Android) and maintaining 5 codebases is a _bad_ idea.

~~~
Cthulhu_
IMO it really depends. There's a lot of big companies that have more than
enough resources to be able to pay multiple dev teams to build and maintain
apps across operating systems.

From a few years ago, Twitter and Facebook were famous examples. They pushed
so hard to try and build their apps using web technology but kept running into
performance issues (thanks to infinite scrolling). After spending fuck knows
how much they finally admitted that maybe native components are better.

But this is Facebook, who have so much resources they can afford to build
their own version of PHP three times over. I just don't understand why they
put so much effort into trying to fit a square peg into a round hole instead
of just going with native development.

But, I'm not an insider, I don't know the thought processes behind it. Long
story short, IMO people overestimate how complex it is to build multiple
native apps in parallel.

~~~
iainmerrick
_people overestimate how complex it is to build multiple native apps in
parallel._

I agree, although there are now more platforms to deal with than back in the
days when it was just Mac and Windows: add iOS, Android, desktop web, mobile
web.

I think it also helps when it's easy to share code between platforms, which
again, used to be easier when you were just targeting the desktop (just use C
or C++).

Now it's a bit harder because there are no great languages that span all
platforms easily without a bit of hacking. Most languages are managed and
memory-safe now; that's a good thing, but it makes them more heavyweight and
less portable. They generally want to drag in their own frameworks (e.g.
Flutter, React Native) rather than letting you put your own UI layer on top.

~~~
pjmlp
I remember the days of Apple II, TSR-80, Commodore 64, Commodore 128, ZX
Spectrum, ZX Spectrum 128K, ZX Spectrum 128K +2A, ZX Spectrum 128K +3A, Atari,
Atari ST, Amiga 500, Amiga 600, Amiga 1200, PC CGA, PC EGA, PC VGA, PC
PS2,.....

Platform fragmentation exists since ever.

~~~
iainmerrick
You’re right, of course! It’s amazing to think how many 8-bit and 16-bit games
got ported to a whole bunch of different computers.

I was thinking mainly of the 90s and early 2000s, I guess, and for desktop
apps where the main platform of interest was Windows, followed by a long tail
of Mac, X-Windows, BeOS, etc... All those platforms could “easily” (i.e. with
effort, but no rocket science required) be handled by a single C/C++ codebase
with platform-specific #ifdefs.

I think the equivalent for today’s platforms would have to be Javascript.
Unlike the C/C++ approach, you lose direct access to platform features.

------
_-___________-_
> it took them almost a year to add support for 64 bit in APK

While the author's confusion is understandable, because most of the people
posting in the linked Github issue have the same confusion, it's always been
possible to build a 64-bit APK (and a 32-bit APK). The linked issue is
actually about building a single "fat" APK with both 32-bit and 64-bit native
libraries in it, which Google Play Store then repackages to have just the
needed library for the device it's being downloaded to.

Shipping two separate APKs has always been possible and gives the same end
result for just a little more build process work, which is (/should be)
automated anyway.

I've been shipping an app like this for some time now, and it's really not a
hardship in any way, certainly not one that justifies the amount of hand-
wringing in that Github issue.

~~~
iainmerrick
What was the holdup, though? This _should_ have been almost a trivial feature
to implement (just make an APK with multiple .so files in separate
directories).

It must have been either low priority (except the Play Store has been strongly
encouraging fat binaries for some time now) or there were additional
complications (which makes me more suspicious about the stability of the
framework).

~~~
_-___________-_
Maybe low priority / insufficient resources, or the issue didn't get triaged
and brought to the attention of the right person to fix it quickly enough. The
fix wasn't complicated at all once it was eventually in, so I don't think it
was any deep issue with the framework.

------
tobiaswk
I simply love Flutter for Android and iOS development and have been using it
since alpha. I haven't tried the web application part; I'm pretty sure I never
will. Here's my opinion. I've created several apps with Flutter and every time
I enjoy it. The UI is easy to make beautiful and the resulting code easy to
read. It feels like all what the current Android SDK is missing. The current
Android SDK is old and quite frankly painfull to work with. You just can't
create beautiful apps with ease; it's always a hassle. It's also messy and not
easy to read the resulting code. The way the whole way the framework is
structured entails ugly code in my opinion. This all becomes evident when you
use different apps on Google Play. You get the sense that every app reinvented
their UI; there is no real UI continuity. Google became a freeloader after
JetBrains created Kotlin and marketed it will. The thing is Kotlin made just a
little better; in terms of boilerplate stuff; the framework I still hate
compared to Flutter. What I really like about flutter is the framework and
“it’s all a widget” idea. You can basically do crazy things in UI with ease
and on the other hand just use the standard UI components with a great result.

As an example I've created an alternative to Nissan's Connect EV app. It's
basically a way to control and monitor your electric vehicle from Nissan. The
official app is I’m very disappointed by; it’s slow and full of wrong
decisions.

My alternative is called "My Leaf" and its available on Google Play and the
App Store;
[https://play.google.com/store/apps/details?id=dk.kjeldsen.ca...](https://play.google.com/store/apps/details?id=dk.kjeldsen.carwingsflutter)
[https://apps.apple.com/us/app/my-leaf-for-nissan-
ev/id143670...](https://apps.apple.com/us/app/my-leaf-for-nissan-
ev/id1436701776) It's completely open source.

~~~
555513
Those 1-star reviews on the Play Store are infuriating !

~~~
tobiaswk
I agree. It tears on the developer for sure.

------
desaiguddu
I am working on 3 Flutter Applications & 2 of them are currently in
production. On average we receive 1 major bottleneck a month, which gets
resolved with 3rd Party fixes.

Happy to help if you are stuck on any issue with Flutter. Our background is
native application development, so far this is the best Cross-Platform
Development toolkit available.

Phonegap, Ionic & others are web wrappers. PLEASE let Flutter grow!

~~~
GeneralTspoon
React Native isn't a web wrapper. It uses a Javascript engine to render native
iOS/Android components (unlike Flutter, which doesn't use native components,
and instead renders everything from scratch).

~~~
gitgud
Because Flutter has it's own rendering engine, it's inherently more consistent
in refresh rates and UI components.

Although React Native shows Native elements, they vary slightly across
different; devices, platforms, OS's etc.. this can create many weird edge
cases, which makes it unreliable in some cases.

~~~
bsaul
I'm actually investigating getting some skills on react native, but i've got
the suspicion it isn't all sunshine and rainbows. From what i've seen so far,
a real-world stack has many more dependencies other that react native itself,
and becomes a convoluted mess.

However, i'm surprised that i haven't found a similar post to OP detailing
real-world React Native pain points.

Do you have more info ?

~~~
rhodysurf
RN pain points are upgrading more than anything else. Also as a native dev I
don’t understand why the JS dev ecosystem is full of disjointed tooling
instead of just making the process more streamlined.

I have also developed a production flutter app for a client and am now working
on a RN app for another. I like RN so much more just because I can create
custom native views that use the platform toolkits. You can also share a lot
of code with an SPA web app and set up a monorepo for everything pretty
easily.

Flutter dev tools are incredible though and much easier to use than react
native.

~~~
bsaul
how is the view animation / vc transition story on RN ?

Say you’d like to implement a snapchat-like UX with RN, would that be possible
without relying heavily on native custom components ?

~~~
rhodysurf
Animation with RN is very good.

Snapchat like UI is definitely possible, but for the performance to be really
good youd probably want to do something native. I consider that a good thing
though. RN is better if you just treat it as the coordinator on top of native
view components IMO.

------
ibejoeb
Flutter is young, and there are bugs, but velocity is high and it is advancing
the state of the art. It is a huge leap in accessibility and productivity.

I really don't understand the complaint about setup. If expanding an archive
and setting an environment variable are that daunting, wait til you try mobile
development...

Snark aside, remember phonegap/cordova? Pine for those glory days of low
friction?

~~~
andrekandre
> it is advancing the state of the art

in what ways?

------
piokoch
The question is: if Flutter will not get traction that Google expects, what
will happen with the project?

The space of multi-platform mobile apps toolkit is already occupied by several
well established players (React Native, Qt, Xamarin and a dozen of other more
or less popular tools, sometimes well entrenched in their niches, like Unity
for games).

Flutter comes with rather obscure language and is late in the game, so it will
have to provide something truly game-changing to succeed and I am not sure if
that what it offers now is sufficiently appealing.

~~~
krzat
The strength of Flutter is it's architecture. Nothing comes close. Web is too
slow. Xamarin/React Native is too restricted by native layer. Qt is C++.

Popularity of Flutter increases steadily:
[https://trends.google.pl/trends/explore?cat=31&date=today%20...](https://trends.google.pl/trends/explore?cat=31&date=today%205-y&q=flutter,react%20native,xamarin)

~~~
jinglebells
Nativescript is more powerful than React Native because it gives you direct
access to the JAVA/Objective C libraries if you need it.

I reviewed Flutter but got put off by the levels of abstraction.

~~~
krzat
How can you be interested in RN if Flutter is too abstract?

------
krzat
I like Flutter very much. In some aspects it is much better than native iOS
development. But it's far from perfect, so perhaps this post will prompt
Google to hire more people to handle issues.

But, it's not like other companies are much better at this. At React Native
they just autoclose them after some time. While Apple most likely has more
open issues than Flutter but the data is not public.

------
mekkkkkk
Tip: For anyone trying out Flutter, please remember to evaluate it based on
release builds of your app. Scrolling and animations can feel a bit "off" when
running the default debug builds. The 60 FPS butter is only really applied
when that `--release` flag gets tacked on.

Not using Android Studio, so not sure how easy it is to miss the massive
performance difference of optimized vs. debug builds in that workflow.

~~~
jinglebells
If running in Debug mode means it's running < 60fps I wouldn't touch it with a
bargepole. Native stuff doesn't do that and React Native/Nativescript don't do
that either!

~~~
johnday
The debug mode induces a _seriously huge_ overhead. In return you get stateful
hot reloading and high quality error management and tracing, both of which are
incredibly valuable while developing.

------
lovelearning
I have a couple of android app PoCs in mind but didn't want to go down the
Android SDK way which IMO is becoming more and more complicated and verbose
with every release.

Just tried Flutter and React-Native yesterday for the first time, and I'm
sorry to say both were sorely disappointing.

Flutter was easier to install and get working, but Dart seems to be as verbose
as Java with some JavaScript style syntax mixed in. The main dart file was as
verbose as a boilerplate native SDK Activity.

RN was worse, though I expected it to be simpler. Something called metro
server nearly froze the entire machine on every attempt. Had to power off and
restart about 5 times. Then, based on GitHub discussions, built something else
called watchman from sources. The official docs don't mention that watchman is
critical. That improved it for a while but then the system wide near-freeze
came back again. I wasn't even able to display a simple hello world app
because of installation and deployment problems.

So far, Kivy seems to be the only alternative that is both simple to code and
to deploy. Its file sizes are massive, but given that I already find Android
SDK so frustrating to design and implement quickly, I don't want alternatives
that are equally frustrating.

~~~
nnq
Yep, React Native has horrible dev experience... this is what drove me to
Flutter. Dart may be ugly but after you get used to it it's mostly _"
Typescript done right"_ imo ;)

~~~
thiht
I'm pretty sure Typescript is already "Typescript done right"

~~~
nnq
...ok, tbh TS has a much more powerful and expressive typesystem then Dart,
otoh it also works with the constraint of being a superset of JS hence some
things are forced to be the way they are since they sit on the foundation they
sit.

I don't really like Javascript as a foundation so I'd almost be inclined to
throw away a superior type system in order to have the bedrock be something
else, opinions might vary though, I know.

And probably we'd all have loved to have Kotlin instead...

~~~
eropple
_> And probably we'd all have loved to have Kotlin instead... _

For what it is, I quite like Kotlin (particularly when placed against Java, of
course), but I would not want to give up structural typing for much of
anything in 2019. It makes writing obviously-correct code significantly
easier.

------
gamma3
> Why should someone ever need to offer a bug-fix bounty!?

Author expects bugs in open source projects to get fixed for free, by someone
else.

We need to support open source maintainers instead of shaming them. I'm
excited about Open Collective and made a monthly donation to a project I use.

------
wastedhours
I tried Flutter a few times to have a play - really like it. Obviously a lot
of the packages available hook you into the Google ecosystem (Firebase is
ridiculously easy to get working).

There are quite a few things missing, and I personally found it quite hard to
get going (but that might just be a general lack of skill at getting tooling
set up), but there's an awful lot to like if you want to dive into getting
something set up on-device quickly.

------
gitgud
This seems like a fairly biased post (as he admits himself). Flutter has a lot
of problems, but if you've used any other _cross-platform_ system, you know
it's a hard problem to solve.

A friend described it to me as _" Unity for apps"_, which I think is pretty
positive and accurate.

~~~
bernaferrari
Author here. Yeah, it was supposed to be "here are my frustrations", not like
"Flutter is bad, let's burn it".. but of course, the thing grew up beyond
control. 38k view so far.

------
hardwaresofton
For those who are looking for an alternative to Flutter/React Native, please
check out Nativescript @
[https://docs.nativescript.org](https://docs.nativescript.org)!

It's different in a few key ways:

\- Draws native components (Flutter draws every pixel)

\- Pure JS native (i.e. JNI powered) shim layer (you can write stuff like
`const intent = new Intent()`)

\- Typescript as first-class (not quite so with React Native, and IMO
Typescript > Dart as far as type systems and ergonomics are concerned)

\- Ability to use both Angular and Vue to structure your app (there's also
projects out there like Svelte-Native, which is extremely promising from the
performance perspective)

\- More community driven project (with Progress standing behind, following the
open-source & extra features business model)

~~~
ex3ndr
They are running JS code on Main thread. Thank's but no.

~~~
hardwaresofton
Nativescript has supported the web worker paradigm for multi-threading for a
while now[0]. Also, I'd like to point that for a _lot_ of applications
(especially the ones that are basically informational without much interaction
or client-side work, this actually isn't an issue early in the development
process.

I've used Nativescript on client projects, and it is _fantastic_ for
prototyping, with well demarcated paths to performance optimization. Since you
can easily use native screens/controllers/etc with it, at the _very_ least you
can use it for fast prototyping then drop all your custom code in.

Do you know of any hybrid frameworks that are _not_ running JS code on the
main thread _by default_? And by JS code I assume you mean display-related
code, because Flutter suffers from this same issue, do too much hard work on
the main thread and it stalls (as anything would). Even on android itself[1]
you need to do some extra work to make sure your UI-related heavy lifting
happens off the main thread:

> However, when the main thread’s messaging queue contains tasks that are
> either too numerous or too long for the main thread to complete the update
> fast enough, the app should move this work to a worker thread

[0]: [https://docs.nativescript.org/core-
concepts/multithreading-m...](https://docs.nativescript.org/core-
concepts/multithreading-model)

[1]:
[https://developer.android.com/topic/performance/threads](https://developer.android.com/topic/performance/threads)

------
latchkey
I've recently done a bit of Flutter development and have enjoyed it quite a
bit. The third party Provider API solves all the state management issues, it
should become the default.

OP has some valid points for sure, but fact is that any framework is going to
have issues. Just part of the game.

~~~
sgt
That sounds interesting. What would be the go to documentation for a good
Provider API implementation (i.e. like a best practice guide with an example)?

~~~
hansjorg
See the official Flutter guide on state management:
[https://flutter.dev/docs/development/data-and-
backend/state-...](https://flutter.dev/docs/development/data-and-
backend/state-mgmt)

It refers to other solutions as well, but the hands-on example is with
provider (starting in the "Simple app state management" chapter)

------
karma_fountain
I've written one app in flutter and the experience was good. It was very easy
to get started, and the dev experience was on par with web development with
very fast hot reload.

However I would say where it excels at is in creating a fully custom-branded
experience rather than sticking to the native elements. I reckon
[https://reflectly.app/](https://reflectly.app/) is the poster child for this.

------
codedokode
I am not sure if users care about controls being "native". Examples from
desktop: Photoshop used non-native controls, and nobody cared. MS Office
always had non-native looking menus. DAW (digital audio workstation) apps all
look non-native.

~~~
saagarjha
> Photoshop used non-native controls, and nobody cared.

There's a number of Photoshop alternatives that use native controls that are
reasonably popular (they're also generally cheaper, too).

------
winter_blue
A solid alternative is Intel's Multi-OS Engine: [https://multi-os-
engine.org/](https://multi-os-engine.org/)

All it does is let you write iOS UI code in Java or Kotlin, and target _both_
iOS and Android from a single project.

It uses the actual underlying iOS API, and simply provides Java wrappers for
them, that map one-to-one.

I keep wondering, and don't know why it hasn't gained much traction. It is _so
much_ better than Flutter, is obviously reliable since it's a simple 1-1
mapping/translation layer. (There _is_ more work involved with it, as you have
to write the UI lawyer twice, but that's about it.)

------
TylerE
Is “one week of electric scooter rental in Bucharest” the new world currency?

~~~
jimmcslim
‘Mobile phone minutes’ were a common medium of exchange in parts of Africa
(Kenya?) for a while (and maybe still is?)... mobility is also another
commonly desirable service, so sure, why not?

~~~
tomca32
Yup, it still is. Lots of that in eastern parts of Africa like Kenya, Rwanda,
Uganda. I'm sure cell service providers are pretty happy with it since it
turned them into banks.

------
navd
Flutter is not that bad. It is a step in the right direction but there are
some paradigms that makes simple things hard. Animations are harder than
necessary and building non default layouts requires a bit of thinking to get
right.

My biggest issue is that there is still this "uncanny valley" feeling when
using a flutter app. It feels much better than a react native or Cordova app,
but something still feels off.

Right now it seems great for prototyping. For iOS however, I've been playing
around a bit with SwiftUI which currently (even in its beta state) provides an
astronomically better dev experience and user experience.

------
royal_ts
I don't get the part about Scrolling. It doesn't feel not native it feels
incredible fluid, smooth as butter.

------
dejaime
Even though my experience is basically the same as the author's (8y using
java/kotlin toolchain), the article still seems to be written by someone with
a hammer frustrated with screws for not working properly. His points can be
summed up as "Flutter isn't as stable as the java toolchain that has existed
for over a decade" and "I want Flutter to work the way I am used to work".

------
bsaul
Does anyone has a link for the market shares of cross-platform mobile
development tech ( react native, phonegap, flutter, etc) vs native ? in terms
of apps on the stores, for example.

i know they were considered experimental a few years ago but wonder what’s the
status today.

------
meerita
My experience working with Flutter:

\- Overclomplicated syntax. \- Material Design doesn't look as good as the
native. Feels like imitation in many cases. \- no vector drawable, PDF or
Lottie support \- I had to create special code for iOS to match certain
patterns and components. \- Typopraphy done wrong.

Flutter maybe something good to start with, but once you want to reach good
app design/code maintain that would be painfull and you will feel faster and
more organized if you do things in their native realms.

~~~
verttii
Are you a native iOS dev? I feel Flutter is a major upgrade over React Native,
but perhaps native devs just feel it still falls short on a lot of accounts.

------
bfrog
This just reminded me of how horrible doing things with react native was. A
reminder I didn't really need.

------
curyous
I moved from Flutter to native Android development and found it to be much
more pleasant..

------
pjmlp
I still don't see any big advantages over Xamarin Native, Qt or plain C++ with
native views, when going through this route.

All of the with the bonus that C#, JavaScript and C++ actually have lots of
market demand, Dart remains a possible CoffeScript.

~~~
rileyteige
Speaking strictly to the Xamarin here... as someone who has worked
professionally w/ Xamarin, Xamarin.Forms, and Flutter: Flutter knocks it out
of the park. My experience with Xamarin was so buggy as to be nearly unusable
(on Stable no less!). The documentation, _especially in Xamarin.Forms_, was
sooo lacking! I wanted so hard for it to be "the next great thing", but there
were just too many gotchas and pain points. In contrast, Flutter "just works",
has great documentation, great community, great tooling. My development in
Flutter, especially with the hot reload they support, has sped up immensely. I
can pause the debugger, change code on the fly, continue the debugger, no
hiccups. It has been nothing short of wonderful. My anecdotal two cents.

~~~
pjmlp
Hence why explicitly left Forms out.

For me having to deal with Dart, a programming language without any other
purpose than Flutter, it rules out any advantage over Xamarin.

With Xamarin I have C# and the whole .NET ecosystem available.

------
IshKebab
So mostly this is just complaining about bugs. Does he think that native
Android doesn't have bugs? One could easily write the same article for _any_
UI framework.

Also it seems like he is complaining that the Flutter team actually uses a
public bug tracker. Does he really prefer Android's bug tracker? The place
where bug reports go to die. A year or so ago they gave up on it and basically
closed every bug as obsolete.

------
dep_b
I liked the way the UI was built in Flutter and of course Dart > vanilla JS.
But with SwiftUI and Jet Pack around the corner there's a bit less appeal,
especially since Kotlin & Swift > Dart and a lot of UX niceties come for free
in iOS, like rotation / resizing or hiding the keyboard while scrolling.

------
mirceal
yeah no. i would not bet the farm on this one especially when it comes to
developing for Apple devices. Google just doesn’t have the track record to
inspire confidence that anything they do is going to stick around

------
hitekker
Last major discussion and conclusions about Flutter:

[https://news.ycombinator.com/item?id=19853247](https://news.ycombinator.com/item?id=19853247)

------
ensiferum
So.. in summary Flutter is a buggy unfinished and badly designed framework.
Nothing new here folks.

~~~
hoskdoug
Not as simple as that. Some people clearly manage to create things effectively
with it. Newcomers can see this but understand that there will be
difficulties.

The difficulty for newcomers is anticipating where the pain points might be.
Detailed articles like this are rare and a huge help with assisting with
decisions on whether to invest time into it.

