
Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment - Rubytron
https://blog.codemagic.io/flutter-vs-ios-android-reactnative-xamarin/
======
Townley
Another factor when evaluating platforms to build an app with includes ease of
initial submission/submission of updates.

I've never used Xamarind or flutter, but easily one of the best parts of using
Expo (React-Native) was their built-in certificate management, guidance
through the submission process, and eventually immediate publication of
updates through running `expo publish`

My client was pleasantly speechless when I was able to change code and have it
appear on her device a few seconds later, as it had been her experience that
updates have to go through another review process.

~~~
deltron3030
Isn't there the danger that Apple just forbids/bans this remote code
reloading/replacement to protect their users? I mean it's a loophole that can
get abused (and likely is) for stuff that wouldn't make it through the review
process in first place..

~~~
Townley
Definitely crossed my mind. It'd be easy enough to submit a legitimate app and
then modify the content it serves to be something malicious. No idea if/when a
follow up review might catch that outside of user reporting.

But in the scenario where apple decides to no longer allow OTA updates, you're
just back to the extended review process that native apps have to go through,
so I think the productivity gains make it worthwhile.

~~~
kangaroozach
I always wondered why Someone doesn’t make a YouTube like app that connects to
content repositories via end to end encryption so Apple can’t see what content
you are accessing. You could connect to something like Khan Academy for
educational videos. This would also allow you to connect to Pornhub or
something similar in a native experience without Apple being able to stop it.

~~~
fauigerzigerk
You mean something like a Web browser?

I think letting users find and select content is the only way to avoid getting
banned. As soon as the app does anything to nudge users toward a particular
kind of content it risks getting banned.

------
latchkey
OP mentions the Provider package [1] wasn't around when they did the Flutter
version. That is really too bad, because it is absolutely the best way to
manage state in Flutter. It makes things so much easier and cleaner than the
other methods.

[1]
[https://github.com/rrousselGit/provider](https://github.com/rrousselGit/provider)

Edit: I probably would have even gone back and refactored the app to use
Provider before publishing the article. =) That would have been a nice
additional bit of information for the reader.

~~~
rhlsthrm
Looks like lots of things didn't exist then for each framework which made a
lot of the issues he encountered easier: SwiftUI, React Hooks/useContext,
Jetpack. I'd like to see a revisit of this whole project.

------
Benjammer
This is super interesting, but the problem I have is that this guy's eye for
design leaves a lot to be desired. When was the last time someone built a
clunky table directly into the UI and added fully styled table rows
dynamically? Why not modernize the design, and use a styled list view with a
data adapter and try this again on each platform? It didn't surprise me at all
that he struggled with the table in basically every scenario. There's a reason
(or two) they've fallen out of fashion, imo, and it sort of clouded the
assessment of everything for me, since he kept mentioning struggling with the
table.

~~~
crowbahr
As an Android developer I looked at the code he wrote and felt bad for him. Of
course it was painful trying to set all your styling up programmatically for
the table! Use a viewholder pattern and a recyclerview/adapter then throw your
data into the adapter. Make a simple xml file for your rows and inflate those
into the viewholder then you're good to go! None of these clumsy declarative
attempts to do what xml does well.

It's still a great write-up, but that part hurt me.

~~~
ink404
Hi, slightly unrelated to the thread, but do you have any resources you can
recommend for modern Android UI development? (besides the basic google
resources/ codelabs...etc)

~~~
crowbahr
Unfortunately I cannot. I've mostly taught myself by reading exactly those
same specs you're talking about and watching a lot of YouTube.

I know I'm a thoroughly inadequate Android developer because I've only ever
worked on a small team at a small company and have had 0 tutelage, but what
I've taught myself in the past 3 years boils down to:

Libraries to use: Retrofit, RxJava, Dagger2, Room

Use AndroidX over support/compat whenever you can.

Kotlin is amazing, though I'm still learning. If you know Java then Kotlin
makes a lot of sense.

Use constraint layouts so that when you try to dabble with AndroidX motion
layouts you'll have an easier time.

MVVM is commonly accepted architecture, and I like it personally.

Use single activity architecture: 1 activity with many fragments is the
industry standard (or it should be). Some exceptions exist but mostly that's
how it works.

XML files are your friends and editing them directly is faster and often
easier than the Visual Builder in Android Studio.

Be sure that when you install the emulator you have it integrating with HAXM
or HyperV or whatever they have it integrate with these days: it'll make
debugging on the emu a lot less painful.

------
arciini
I think building a toy app for yourself is among the best ways to decide for
yourself which framework to go with!

The conclusions from the article were:

> Creating the Flutter application only took approximately ⅓ of the time it
> took to create both native applications combined. This proves how much time
> you save by using cross-platform frameworks. Their Hot Reload functionality
> also sped up the development cycle a lot.

> I was able to create the Flutter app faster than the React Native app, but
> that’s because I had more experience with Flutter than with React Native. I
> also didn’t know how to manage state properly in the React Native. That’s
> why declare both Flutter and React Native the winners of this experiment.

For performance, Bram wrote:

> It’s obvious that the CPU-usage of the Flutter application is smaller than
> that of the React Native and Xamarin Forms applications, and that’s why I
> declare Flutter the winner of this experiment.

> In the second experiment it was concluded that the Flutter application was
> less taxing on the CPU than the React Native and Xamarin Forms applications.
> This doesn’t automatically prove that Flutter is more performant than React
> Native or Xamarin Forms.

> There are a lot of features that the Cocktailr app doesn’t have, like
> caching for example. That would reduce the amount of network requests that
> need to be made and would make the app more performant, meaning that it
> could lead to different results. I also only used CPU-usage as a performance
> indicator. I don’t have any data on the memory or battery consumption for
> example. These are also an important performance indicators.

We at Wanderlog ([https://wanderlog.com](https://wanderlog.com)) are using
React Native largely because the ecosystem around it is a bit more mature than
Flutter's at the moment. It's definitely saved us time vs. writing native
code. We've definitely run into issues, and I think the main things we'd want
to test as alternate performance indicators if we were choosing a framework
again are:

1\. How performant/easy-to-implement are long scrolling lists

2\. How easy is it to animate the dimensions of Views that affect layouts of
other views

3\. How many libraries are there for things that will be dealt with native
code? Dealing with the boundary with native code is always going to be tough

~~~
bweitzman
I tried writing a small app using Flutter. It was really a fantastic
experience IMO.

To answer some of your questions:

1\. Long lists are pretty painless to implement. There a some helper views
included for building list views that aren't backed by in memory lists, and
they feel really nice and fluid
([https://api.flutter.dev/flutter/widgets/ListView/ListView.bu...](https://api.flutter.dev/flutter/widgets/ListView/ListView.builder.html))

2\. Flutter has lots of built in animation support. Almost every aspect of a
view is animatable out of the box (see
[https://api.flutter.dev/flutter/widgets/AnimatedContainer-
cl...](https://api.flutter.dev/flutter/widgets/AnimatedContainer-class.html)
for an example). I definitely got carried away with the animations because of
how fun and easy they were!

3\. I had to deal with native code for push notifications, sharing flows, and
universal links. Google publishes libraries for dealing with a lot of the
common stuff, and there's great community support as well.

------
huangc10
I scanned through your two articles (part 1 and part 2) and wanted to read
more about scope. Although I do find your experiments interesting, scope is
really the question. At small scale (single developer with a few view
controllers and models), your experiments might make sense but when talking
about scaling, I don't think your UI and performance results are relavent. How
does a project with hundreds of views, models and libraries scale with Flutter
vs. native iOS vs. React Native? How easy is the codebase to browse and learn
from 0 to 100? Sure, one can use Flutter when they're playing with a project
but when you scale towards 5-20 mobile developers, does it make sense? That's
more of an interesting question to me...

~~~
amimetic
But a lot harder to address (probably effectively impossible). This is
actually one of the best comparisons I’ve seen.

------
sleepinseattle
Measure power consumption and framerate (especially for scrolling scenarios)
rather than CPU usage before making any performance claims for mobile.

~~~
CraftThatBlock
Flutter uses the Chrome rendering engine (Skia) and scrolling is fully fluid
(in release mode). React native uses native views (if implemented correctly)
and is usually very fluid too

~~~
bsaul
I tried a flutter app i found from the sample app catalog on the iOS store on
an iphone X and the scroll wasn't really good (although the views were very
basic).

Can you point me at an iOS app made with flutter that implements this
correctly on the store ?

EDIT : it's the "veggie season" app and i've tried it again on my iphone 6.
it's almost unusable. The scroll stops completley sometimes and other times it
just scrolls randomly to places. It's just a scroll list of images. Nothing
else. That's very troubling..

~~~
dogprez
This might be worth checking out:
[https://flutter.dev/showcase](https://flutter.dev/showcase) Also this if you
want to dig deeper: [https://flutter-
dashboard.appspot.com/benchmarks.html](https://flutter-
dashboard.appspot.com/benchmarks.html)

------
eerrt
Was hoping to see a comparison with
[https://www.nativescript.org/](https://www.nativescript.org/)

~~~
hardwaresofton
This needs to be higher up -- Nativescript is Flutter's biggest competition
and IMO it's _better_ than Flutter, because it doesn't require investing in
Dart and switching to the Flutter "ecosystem" completely.

~~~
csscrack
Didn't know about Nativescript. Did you try it already?

~~~
hardwaresofton
Yup, I used it on a client application the _first time_ I used it and it
worked very well. The project was finished a while ago, and Nativescript has
made leaps and bounds in that time, it's even better today.

I used Nativescript-Vue[0] which has since been brought under the nativescript
umbrella fully, and it was a great experience. Vue is drastically less complex
than React and that translated to very easy app building.

I don't build mobile apps (I think the market is somewhat saturated), but if I
had to, I wouldn't even consider Flutter these days (I've built a small app in
that as well), or building natively (who wants to be an "android developer"
these days if you don't want to specialize in it?) -- Nativescript all the
way.

There's also stuff like svelte-native[1] -- Nativescript is a better platform
to build on than React Native. Props to the React Native team for being the
first to have the idea (same goes with the component-driven design of react
itself, though arguably backbone/marionette views were first), but
Nativescript is a much more flexible and easy to use solution.

[0]: [https://nativescript-vue.org/](https://nativescript-vue.org/)

[1]: [https://svelte-native.technology/](https://svelte-native.technology/)

~~~
FlyingSnake
How's the development experience? Can you debug/step-in to the code?

~~~
hardwaresofton
You can[0] -- that's one of the upsides to the web as a platform, you get to
use some familiar tools to debug the JS side of things.

Also, I'd honestly argue at you that development is _so fast_ for Nativescript
(especially when you start using Hot Module Replacement[1]) that you could get
away with print debugging.

And again, another really awesome thing is that nativescript integrates
_really_ well with native code -- you can write your game/native-feature-heavy
screen in native java/kotlin/swift/objc and just write _every other screen_
with nativescript. Flutter makes that just a smidge harder to do because of
how it integrates (drawing every pixel) -- it's possible[2], but my money is
on Nativescript being better at it.

[0]:
[https://docs.nativescript.org/tooling/debugging/debugging](https://docs.nativescript.org/tooling/debugging/debugging)

[1]: [https://www.nativescript.org/blog/nativescript-hot-module-
re...](https://www.nativescript.org/blog/nativescript-hot-module-replacement)

[2]: [https://api.flutter.dev/flutter/widgets/AndroidView-
class.ht...](https://api.flutter.dev/flutter/widgets/AndroidView-class.html)

------
wiradikusuma
"If you were to Google how to make network requests on Android you would
discover all kinds of different packages and documentation." — my experience
with Android: I will find 10 totally different ways to do it, and mostly not
working, and the one that works you realize that it's outdated.

------
jrs95
I've been considering trying out Flutter, but mainly due to my frustrations
with React Native and I'm not entirely sure if others have had similar
experiences or if Flutter would be any better. I have all kinds of issues with
React Native tooling stability: code randomly reverts back to previous
versions with hot reloading, things only partially update when I make changes,
the same styles sometimes have inconsistent behavior, Flex doesn't always work
the way that it should (justify-content is sometimes simply ignored for
example) and things that should look the same on iOS and Android sometimes
don't. So I guess my questions to those reading this are: 1\. Have you had
similar experiences using React Native? 2\. Have you had these kinds of
problems using Flutter as well?

I'm seriously considering rebuilding a prototype we have at work in Flutter in
my spare time but I'd hate for it to be a similar situation to React Native
where it appears to save me time at first and then fucks me over and only
makes everything take more effort to get right.

~~~
dickjocke
Please, please try Flutter. I had _literally_ the same issues with React
Native and gave Flutter a test run late last year. I will never go back.
Flutter is so stable and honestly my frustrations with Flex made consider
giving up on mobile development. I think as a backend dev i really struggle
with the layout aspects of mobile dev and flutter makes it so easy for me.

I'd say spend two nights playing with flutter. It took me that long to feel
comfortable with Flutter's version of Components and state, but now it's a
breeze. Hot reloading works great, it's easy to plug in native code if you
need it, it's just amazing. I haven't been this excited about a language in
years.

~~~
jrs95
Exactly what I was hoping to hear, I'll get started with it this weekend :)

~~~
dickjocke
Did you do it?

------
babesh
I think it would be an interesting experiment to have people with more
expertise in each platform/tech write the code and then measure the developer
time and performance.

This is because, based on what the author mentioned about cell reuse, they
barely have any expertise in iOS. It would be hard to trust the code. Perhaps
the author has provided access to the code?

------
novok
One thing missing from the benchmarks was one on iOS. I'm curious how the
cross platform frameworks compare to iOS native, since iOS apps are not
garbage collected typically.

Also startup time is another interest to me, I've heard flutter apps tend to
have slower startup times.

~~~
afro88
Me too, on both counts.

About a year and a half ago I compared native iOS tableview scroll performance
to the Flutter "startup name generator" tutorial app. Flutter would noticably
stutter occasionally, whereas native iOS was silky smooth.

Things may have changed since then..

------
yuchi
There are some issues here and there (JSX is not a language!) but this is
definitely a very good comparison. It is indeed a little bit too shallow (give
animations! Full app navigation stack management!) but gives practical
insights.

Props to the author.

~~~
crucialfelix
JSX aka JavaScript XML. It is technically a language.

~~~
yuchi
It’s an extension to a language. Would you call generics a language? Is TSX a
different language from TypeScript?

------
braindongle
<fanboy>Looking at Flutter vs React Native, the only comparison of interest
for, perhaps most of us, Flutter for the win! Lower dev resources and way
lower cpu usage. Dart is lovely, the docs are great, wide array of great UI
widgets, and easy animation. As for hot reloading, well, you just have to
experience the difference.</fanboy>

~~~
siquick
> Lower dev resources

Learning a completely new language in Dart to even get started with Flutter
doesn't seem like low dev resources.

With React Native you are using:

\- Javascript which most devs have a grasp on in 2020

\- JSX which really isn't much different to HTML

\- Styling is practically just CSS with slightly different property formatting
and naming

If you've decided to go down the RN then theres a decent chance that your devs
have used React before and there really isn't much between React and RN.

~~~
bananabreakfast
Learning Dart is definitely not a large dev hurdle.

Most people (esp. js devs) can read dart and understand what it is doing
without ever having even seen the code before.

I've found it takes an experienced engineer about two weeks to learn enough Go
to be productive and Dart is honestly easier than that.

~~~
tatersolid
I have 20 C#/JS/SQL developers I want to put in a mobile project. So I’m
supposed to eat an employee-year of salary to even consider Flutter+Dart?

Not gonna happen, especially with Google’s track record. Already been burned
by the Angular v1 -> v2+ nightmare.

------
on_and_off
ouch The Android code indeed looks like a copy paste of bad stack overflow
answers.

I can't really hold it against the author .. learning several platforms at the
same time is a bit much.

~~~
e12e
Could you elaborate, or do you know of a better example of an idiomatic kotlin
Android app?

~~~
on_and_off
sure.

Again, I want to stress out that this is not an attack against the author.

I started learning Android roughly 10 years ago now. I actually anecdotally
recently started teaching it to my SO and it finding the right approach to do
so was a challenge. The sources I use to keep up with the latest tech are not
the ones you want to push to a beginner.

> know of a better example of an idiomatic kotlin Android app?

off the top of my head, I am not sure what open source app I would direct
somebody to. There is always
[https://github.com/google/iosched](https://github.com/google/iosched) . The
big downside is that for very long they shied away from using some common libs
like rx or dagger in order to show off what you can do with just the base
google libs. I know that they have revised their approach but to be honest I
haven't checked out the code source of this app in 2 years (they always do a
big refresh around io)

Android is also in a spot that must feel like a catch 22 for its maintainers :
the platform has for very long had an approach where very little was
irrevocably decided for you by Google. Which was great since it allowed to use
whatever pattern works best for your usecase but also means that this freedom
can be very intimidating for newcomers. This has changed in the past 1 or 2
years from 2 different reasons :

\- initiatives like jetpack provide an opinionated way of doing things on
Android.

\- we can't have nice things. Some APIs are progressively closed off. In some
cases it is because of performances (since devs are too often not going to
care a lot if they have a rogue foreground service siphoning the user battery
as long as their feature works), security or privacy.

Looking at `createTableRows()`

Removing all the views before adding them again is extremely unidiomatic. As
well as handling all your layouting in kotlin/java instead of xml.

A clean way to handle what op is doing would be first to define a ViewState :
a model representing the UI. In itself, it is nothing fancy, just an immutable
kotlin data class looking something like this :

data class IngredientsModel( val title : CharSequence, // "ingredients" val
ingredients : List<IngredientModel> )

data class IngredientModel( val name : CharSequence, val text : CharSequence )

next up would be to apply it to the UI

a simple method like bind (model:IngredientsModel) should be in charge of
that.

Using a previously inflated xml layout for the whole screen

And a RecyclerView (abstraction similar to iOS UICollectionView ) to display
the ingredients

stuff like

tv1.setPadding(32, 6, 6, 6) -> padding applied manually instead of being done
through a layout definition and moreover using raw pixel values instead of dp
ones.

if (index >= cocktail!!.measurements.count()) -> you don't do this kind of
logic in the view layer, ever. This is why I have defined an IngredientModel,
so that what to display can be defined in the business logic, not in the view
layer.

Reading the article "create layouts declaratively like with Dart,wasn’t around
when I created this project"; it looks like the author tried very hard to
write idiomatic flutter code (and not necessarily good one) in place of
Android one.

------
cauchyk
A lot of the power that flutter has comes from hot-reload. Dart + JIT powers
this. I noticed that SwiftUI does this too. I wonder if SwiftUI composits and
paints onto an underlying CALayer just like flutter does.

~~~
novok
Swift UI hot reload i'm guessing is less flexible than flutter's

------
dep_b
It's a pity both Jetpack and SwiftUI / Combine weren't available / release
worthy enough at the time of writing. Not sure about Android but a lot of the
problems on the native iOS side would be fixed with that. The only difference
is the cell reuse, which can be a real head scratcher indeed for a starting
developer. It's definitely a part where you will find the performance vs ease
of use decisions of early iOS. Got to say I often work around it by creating
new ViewControllers and adding/replacing them every time a cell gets (re)used
but this might not always work in places where performance is still a
constraint.

~~~
jamil7
I love SwiftUI, rewrote my side project in it and hope it takes off. That
being said I don't think it's anywhere near ready for mainstream use and
therefore wouldn't be particuly helpful in a comparison like this. The
requirement of iOS13 alone means it's a non-starter for a lot of business
cases.

~~~
dep_b
Well if iOS 13 adoption keeps growing like this I think any project released
mid 2020 could use it - unless every % of missed users really means a lot of
missed income.

------
sandov
The buttons floating at the right side are really annoying.

------
jcelerier
Would be interested to see a comparison with QtQuick as it uses the same model
than Flutter - reimplement everything and render it on the GPU (but with an
additional decade's worth of optimizations)

------
Abishek_Muthian
I'm really interested in learning Flutter for future app development as I
could really use the time saved in development. But, one thing which really
concerns me is the volatility of Google w.r.t products which doesn't get
enough adoption i.e. in other words 'I'm afraid Google will kill Flutter'.

~~~
tessting
I know this happened with Angular 1, but I am curious why I never hear this
sentiment for GoLang which people seem nuts for. Is it because Google is
responsible for maintaining the actual UI Widgets in this case?

~~~
Abishek_Muthian
I use GoLang regularly and so consider this my personal opinion for your
question;

•GoLang filled up a need gap of simple yet high performant server side
language which could scale up with the developments in the compute power.

•By the time GoLang stable release was made, it was widely used by Google
itself within its production infrastructure. Docker, Kubernetes, Youtube using
Go was a huge confidence booster.

•Of course it's been a decade since release, so it has stood the test of time
even though there are criticisms regarding language design and Google's
oversight on language development; even though major development comes from
Google, I don't think there is a chance that they will pull it off just
because they are heavily invested in it.

As for Flutter,

• It's been just two years, so we cannot compare it directly with current
GoLang reg adoption and also this is a framework. I think Flutter didn't
really fill any need gap Google had, it just seems like they waited to see if
Cross-platform app development would still be a thing by the end of the decade
and rushed in with a framework to compete with Xamarin/React Native.

• Google already has two first level language support for its android
development Java, Kotlin but Flutter requires one to use Dart which wasn't
originally created to be used in such a framework. So both android and iOS
developers need to learn another language to build cross-platform apps using
Flutter.

• Google claims it uses Flutter for some part of Google Assistant for Google
Home devices and it is expected that Fuchsia uses Flutter as primary
development framework; that's all in the future, if Google wants to inspire
confidence they need to release a major app written using Flutter for
android/iOS.

In short, I don't see Google loosing much in stopping development on Flutter
as much as it stands to loose if stops development on GoLang and lately that's
how Google has treated its projects. Of-course both are open-source, may be if
Google stopped development on Flutter, the UI-widgets can still be developed
by the community but I doubt whether the core-framework can be developed by
just the community.

------
arielm
Ultimately it’s hard to evaluate using a single simplistic app. It’s not a
matter of setting up a better evaluation but rather real life.

A different way to look at this is adoption, and flutter isn’t at all popular.
I don’t believe that’s only a matter of visibility.

React Native is the 5th and Xamarin is the 7th most used frameworks for iOS
while flutter is 15th, and similarly among Android apps where it’s 10th.

Source: [https://appfigures.com/top-
sdks/development/all](https://appfigures.com/top-sdks/development/all)

* Requires a free account to see beyond the top 5 results.

We just recently shipped an Android app built with react native and while we
ran into a variety of challenges to keep the UI smooth the rest was very easy.
If flutter was as easy I’d imagine it’d see more adoption.

~~~
virtualwhys
By some measures Flutter is taking off [1], and it's Github repo has certainly
drawn some interest [2]. At any rate, Flutter is far from unpopular, and is
iirc the youngest of any of the competing frameworks.

[1]
[https://trends.google.com/trends/explore?q=%2Fg%2F11f03_rzbg...](https://trends.google.com/trends/explore?q=%2Fg%2F11f03_rzbg,react%20native,%2Fm%2F0gtv959,%2Fg%2F1q6l_n0n0)

[2] [https://github.com/flutter/flutter](https://github.com/flutter/flutter)

~~~
arielm
It’s really interesting to see so much interest in flutter is coming from
China. But keep in mind, that’s search traffic not apps using flutter.

------
ajdegol
Perhaps it comes down to personal preferences and there is no correct answer.
I rewrote one of my apps in Flutter to test it; there were some things that
were better, and some things much worse. I mean when React Native goes wrong
on some build it's like 24 hours of trying to recompile and the pain is
palpable.

Ultimately I decided against using flutter, personally. Dart is okay, actually
I quite liked it, but the flutter syntax is verbose is a special way; when you
effectively require your IDE to code for you that to my old bones is a certain
type of code smell and something is fundamentally amiss.

I may have been doing it wrong, but centering and styling text didn't feel
like it should be a widget for each single thing.

------
lazyjones
That's some admirable persistence by the author... I gave up on Flutter (for
now) right after installing, having to accept (and supposedly read first)
about 10 licenses during the process and then failing to start basically the
default app in the Android emulator with obscure error messages. What a
terrible UX developers have to put up with these days... At least it was funny
to let Android Studio analyze the code (the default app), yielding these:

    
    
      FlutterBinaryMessenger.h
      Typo: In word 'FLUTTERBINARYMESSENGER'
      Typo: In word 'Implementated'
      Typo: In word 'commuication'
    

Doesn't look like people actually use all these features much.

~~~
hamaluik
That’s weird.. aside from accepting licenses (which to me is fine), Flutter
has always been a buttery smooth development process for me—much more so that
trying to wrangle Xcode or Android Studio.

~~~
lazyjones
So, you use Flutter from some other IDE and avoid Android Studio altogether?
I'll probably try that next, I just did what flutter.io suggested and didn't
have any other suitable IDE or editor set up for Dart etc.:

    
    
      Flutter relies on a full installation of Android Studio to
      supply its Android platform dependencies. However, you can
      write your Flutter apps in a number of editors; a later 
      step will discuss that.
    

Is the general consensus that IntelliJ-based Android Studio isn't really a
good choice as IDE?

~~~
dragonfax
I used flutter from Android Studio and from VSCode, and neither ever gave me
any gruff.

------
sandGorgon
This whole commentary will change in about 6 months when Jetpack Compose goes
live.

Compose is basically android-native SwiftUi equivalent - a reacty way to write
apps. Officially sanctioned and tuned by the core Android team

~~~
yuvalr1
Flutter is also cross platform, a big advantage. No matter how well the
Jetpack Compose experience is going to be, it's still only Android.

~~~
sandGorgon
Nope. That boat has already sailed. And kotlin will most likely supersede
Flutter because of the tooling.

[https://www.jetbrains.com/lp/mobilecrossplatform/](https://www.jetbrains.com/lp/mobilecrossplatform/)

(That links points to Yandex , etc who are using it in production)

~~~
socceroos
That's only business logic, you still have to entirely reimplement the UI
layer for each platform. Cross platform business logic isn't the killer
feature that cross platform Devs are looking for.

~~~
sandGorgon
sure. but that's going live in a couple of months. EAP was in KotlinConf.

------
Rochus
This is a very useful article (both parts), many thanks to the author.

------
thorum
Have people found Dart to be a useful programming language for purposes other
than Flutter? Does it provide a benefit over existing languages for other
kinds of tasks?

I like a lot of what Flutter offers for cross-platform development, but it's
hard for me to justify the cost of learning a separate language just for one
tool, versus (for example) React Native which uses a multipurpose language
with a massive ecosystem of existing libraries and tooling.

~~~
markdog12
We've been using Dart for years on a successful web app, front-end, back-end,
and tooling. It's simple to learn. We've had devs experienced in C++
contributing to the codebase in a couple of days without any prior exposure.
It's a great general purpose language, and with recent addition of extension
methods and NNBD coming soon, it's getting even better. Ecosystem isn't as
extensive as JS world, but it's pretty good. (As someone else in this thread
stated, I too dislike the required semicolons, but no biggie, and there's an
issue to perhaps remove or make them optional, maybe it'll happen eventually)

Give the language tour a quick look:
[https://dart.dev/guides/language/language-
tour](https://dart.dev/guides/language/language-tour)

I've been using Dart since the start (~8 years ago), and follow language
development very closely.

Let me know if you have any more questions.

~~~
dickjocke
I discovered Flutter recently and love it! I want to buy in all the way. Could
you go more into your experiences, especially with backend and tooling? I'm
pretty sold on it for web dev, as I spent a ton of time trying to get into
react/react native and am ready to move one. I guess my main concern is
support for libraries. I don't recall seeing Dart libraries for most GCP/AWS
services. And what about all of the bajillion clients and neat stuff that has
already been written for say Python. I feel like it's a tough pill to swallow
to say goodbye to that stuff.

~~~
isoos
There is a package for gcloud (and also googleapis), and we are closing in to
generate AWS API client libraries from the API definition JSONs.

------
The_rationalist
Would have been nice to benchmarck ionic, especially since it has react
support.

------
xwowsersx
I've been out of mobile development since about 2013. What's the adoption rate
of things like Flutter, are a significant % of apps built with it these days?

------
jasondclinton
Don't miss the link at the bottom of the article to CPU utilization numbers.
tl;dr: Flutter and React Native are dramatically easier to develop for than
native toolkits and Flutter CPU utilization is better than native toolkits.
That... is not what I was expecting.

~~~
hanniabu
With native toolkits being around for so long, why do they still suck to build
with?

~~~
anaisbetts
Because they carry around 10+ versions of compatibility debt

~~~
hanniabu
Why can't they release breaking changes under a major release?

~~~
novok
Because there are many, many angry people with existing codebases that they
would break, and you would get something like the python 2 to 3 saga.

iOS already pushes way too many breaking changes with every major swift
release. A real break would be too much. They do it incrementally via things
like jetpack compose or swift UI.

------
csscrack
Interesting take on mobile dev frameworks but unfort. with some flaws:

\- OP compared dev time but he is more experienced in Flutter, not expressive

\- Xamarin Forms is included, not sure if anyone really uses it anymore

\- Left out new Iconic React which allows 100% same codebase on all platforms

\- OP didn't mention that Flutter has no production-ready web version or at
least he could have looked into the beta

However, nice that he took the time to give some basic infos.

------
mindfulplay
Slight tangent but why is the bottom portion of this article covered with
social media icons? Hard to read and is distracting.

------
brobot182
This performance analysis is not very useful. How taxing an app is on the CPU
is not a user-visible metric, unlike, for example, the time it takes from
tapping on an app to it being responsive. The taxing of the CPU is only
valuable to think about when thinking when analyzing battery impact (and it
takes a lot more analysis than what was given). I’d be much more interested to
see:

\- startup time

\- time to transition between screens (and ideally with more views on each
screen, eg make two copies of each view)

\- differences in network performance, if any

------
betoharres
just learn WebAssembly, it's the future :o

~~~
tracker1
It's not a matter of "just learn WebAssembly", nobody (with some exceptions to
those working on tooling) is going to learn raw WebAssembly, it just won't
happen.

I would suggest that Blazor (C#) and Yew (Rust) are probably two of the most
usable frameworks currently. There are some commercial libraries for Blazor
and even some open source, but more is needed. There are ongoing and breaking
changes that will be painful if you start adopting now.

Beyond all of this, is the fact that you still are interacting with the DOM
via a transport layer that will generally not be great for a lot of use cases,
you might do well with a canvas and animation frame events, but that won't
have good accessibility.

Even then we're talking about native applications for portable devices, which
likely won't see a good WASM story for a few years and in the case of Apple,
if ever.

I'm not saying that WASM isn't cool... it really is, and you can do some very
cool things with it as a target both browser and in dedicated runtimes... it's
just not ready/baked for application targets (yet), and you shouldn't be
betting a startup, or long-lived application on it just yet.

------
papito
Considering that the lifespan of a Google product is 4 years, would you really
invest the time to become an expert on Flutter? Right now about 190 Google
products are slated for retirement. They are even going to start killing the
Google Cloud after 2023. It's a YUUGE bet.

~~~
throwno
Also, do you really want to invest time into learning Dart?

~~~
verttii
It takes like a few days to pick up and you can easily be productive from day
1. Dart's been around for some 8 years already, I'd assume Flutter bites the
dust sooner than Dart will.

------
jpincheira
If you’re a small startup, just like we are doing at ours [1], you want to
share as much code as possible between your web and mobile apps, and also
backend, so sadly due to Dart, I don’t see us anywhere in the future using
Flutter.

[1] [https://standups.io](https://standups.io)

~~~
markdog12
Not sure what you mean. Small startup here and we share code between frontend
and backend just fine, using Dart.

~~~
jpincheira
What are you using for web? We're using react, and are planning to move to
react-native-web for better web + mobile code sharing, and for Catalyst for
having a native macOS app — not sure also if Flutter will work for that.

But it's key for us, since we started with JS, to stay in JS due to the
knowledge out there and within our team — already. It, of course, depends on
your team and in your hiring options.

I feel Flutter/Dart is still too immature to be deployed all across the stack.
Maybe if you're today starting from scratch it would be doable, like it is for
you. Mind sharing your landing page? I'm interested in seeing your product.

~~~
ipodopt
I built a web prototype in Flutter. I started in May and was using a web
specific branch then Flutter's master branch. Doesn't run well (and I haven't
optimized anything) but I am on stable now and its getting better.

Sent you an email with a link to it.

~~~
jpincheira
Sure! Send it over to jp@standups.io :) Cheers!

------
hota_mazi
> Creating the Flutter application only took approximately ⅓ of the time it
> took to create both native applications combined. This proves how much time
> you save by using cross-platform frameworks

No, it absolutely doesn't.

This is like saying "Writing 'hello world' in Python took three times less
time than writing it in C, therefore Python is three times more productive
than C".

If that's what the author of the article genuinely believes, then they are
clearly not qualified to comment about language productivity.

------
shubham_sinha
X vs Y thing is always fun to read. We would all agree that Native apps are
still better than RN and Flutter ones. So choosing either platform is a
decision you need to take whether you want something fast and compromise on
few thinks like look and performance or you want something solid. Secondly the
issue with flutter is Dart. If you're a startup with 3 guys, working on Go
lang for backend APIs, React / Svelte for frontend would you rather choose Js
/ TS for your app development or Dart. The whole time taken to build X using Y
goes for a toss here. I would rather keep minimum moving parts if I'm small.
If you're an enterprise and you've got resources you can experiment with
Flutter + Dart, work for 2 years and when the project gets shelved ( just like
other Google projects ) start migrating to Native or Js. After that you'll
question yourself why did I learn Dart in the first place ? Did Flutter
provide enough features that React Native didn't, etc.

~~~
dcow
Flutter isn’t going to get shelved. It is _the_ UI framework for Fuchsia. I
agree Dart is its biggest problem but Fuchsia prides itself on not having a
single system language so I’m sure you’ll be able to target the flutter
framework from kotlin and swift and rust and go soon. Also Dart isn’t hard.

~~~
throwno
Flutter is just a cheap Google copy of React just like now shelved Google Plus
was a cheap Google copy of LinkedIn/Facebook. It can and will be discontinued.

~~~
dcow
It’s not cheap at all. It does things the right way. It’s the closest thing UI
engineers have to a “write once”, deploy everywhere framework. Try it out if
you haven’t. It’s definitely not _cheap_.

