
What It Was Like to Write a Full-Blown Flutter App - timsneath
https://medium.com/@seenickcode/what-it-was-like-to-write-a-full-blown-flutter-app-330d8202825b
======
nevi-me
Flutter is good, I echo the author's sentiments. I wrote a Flutter app for
Android in a very short period, relative to my Android Java attempt.

The use of widgets saves a lot of time, leaving one to focus on connecting
everything together. It's also easier to learn than React Native (for me at
least).

The current downside for me has been the lack of maps (I'm aware of current
efforts). I also hit a weird Firebase Messaging bug that leads to an infinite
loop of the app opening itself [0].

I agree with the author regarding the strong Firebase push. The community
doesn't yet seem large enough, so outside of wine of the Google supported
plugins, it's sometimes a struggle.

I am building a second app in Flutter, using the new Material stuff that
Google announced this year.

[0]
[https://github.com/flutter/flutter/issues/18524](https://github.com/flutter/flutter/issues/18524)

~~~
thosakwe
For me, as a long-time Dart user, the emphasis on Firebase for Flutter
surprised me at first, given that there are several existing server-side
frameworks in Dart that could be used to create full-stack apps. I personally
found myself frustrated at the difficulties and breakages that sometimes come
with upgrading native plugins between versions of Flutter, so for some time I
was confused.

But it actually makes sense on a closer look. Dart on the server is not
officially supported, as the primary focus of Dart is use as a client-side
language, so it would be a bit confusing for the Flutter documentation to
recommend using Dart for a backend.

That being said, I think Flutter is a great platform for quickly building
apps, and getting consistent behavior across different vendors. I think that
it can only continue to get better.

~~~
isoos
> dart on the server is not officially supported

It is more nuanced: Dart on the server side is supported, but the development
focus is on the client-side stories (Flutter and Angular).

Google's Dart team develops e.g. the Dart VM which is great for server
workloads too, they do provide some server-side libraries, but they themselves
don't work on third-party database drivers (for now).

Think of it as the question of focus: they want to focus on the client-side
story, get it right, and then deal with the rest. Spreading thin won't help
either.

~~~
bsaul
I'm extremely surprised to hear that dart server doesn't have any database
driver. Are you sure about that ?

To me , dart on the server , with their agent / isolate based concurrency as
well as async await language support, provides ( in theory ) one of the most
exciting environment to develop backends on.

~~~
isoos
Dart has database drivers, and I'm using the Appengine and the Postgres one in
server-side Dart apps.

But Google's Dart team is not actively involved in developing e.g. the
Postgres driver, it is done by an independent company who is building their
stack on server-side Dart.

Btw. I agree: the isolate-based concurrency + language tools is really great
for server-side Dart apps. I use it in a highly concurrent data setup, and I
wouldn't switch to other language.

------
gkya
I really want to get into mobile development, but I have major obstacles with
default platform APIs: I don't have a Mac (and cannot afford one ATM), the
Android Studio is unusably heavy for my decent laptop, and writing Android
apps w/o the studio seems prohibitively difficult. In this situation, Flutter
is a liberating force for me. I have recently started learning it, and I can
just keep writing my code in Emacs, while running the app on a phone with hot
reload, and without my laptop melting. Thanks to whomever created it.

~~~
mwcampbell
Why do you say writing Android apps without Android Studio is prohibitively
difficult? I did it. You just use Gradle from the command line to build the
app, and adb to install it on your device to test. I only tested with an
emulator when I didn't have a device.

~~~
vorg
You forgot to mention the slow build times when using Gradle. If Android
Studio is too heavy for his laptop then Gradle's hardly going to be much
lighter.

Unfortunately, even Flutter requires it when building the production-ready
Android version of the app. Perhaps it's time Google switched to their own
Bazel as the default for building Android apps. As a bonus, the syntax is a
lot lighter than Apache Groovy's.

~~~
gkya
My CPU is "Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz" par lscpu(1), and I have
4Gb RAM. I should not have to struggle running end-user desktop software
except inherently-heavy tasks like video editing and similar memory-heavy or
very CPU-intensive stuff. And running a text editor, a compiler and a debugger
is definitely not so. I'll go as far as saying that most desktop software that
I can't run easily is just plain bloatware. Android Studio, definitely checks
out.

I don't know Gradle, I'll try when I have free time. I have one project which
can be better off as a Java API app (based mostly on Intents). WRT Flutter, I
have not experienced any performance problems with it so far; though I haven't
built a "production-ready app" yet. But given it'd mostly be a rare task,
that'd be bearable.

------
abalone
Can someone compare their experience with Flutter or even React Native, versus
writing separate platform-native Swift/Java versions for iOS and Android?

I don't often hear about the true accounting of time spent learning and
grappling with the limitations of cross-platform frameworks, including
debugging and workarounds, versus just using the platform vendor tools.

It just sort of seems like it's assumed that it's a huge time waste to
maintain separate codebases. But I wonder if you gain other advantages that
might outweigh it, like not having to "fight" the intermediary layer and
getting first-class access to the underlying APIs, platform features and
debugging tools. Thoughts?

~~~
rhodysurf
I’ll bite. I write a simple free surf forecast app for my local region with
around 1000 active users. I am currently rewriting the app because I have time
and ideas.

I am writing the same app in both Flutter and Swift/objc simultaneously, and I
will grant that I am much better iOS dev than Android. The previous version of
the Android app was written in Java.

Honestly, Android dev for me is very not fun, there is so much mental load
that is probably necessary for large apps but for me it’s just a time sink.
Flutter on the other hand gives me Material widgets our of the box and easy
declarative layouts. I will say this is my first experience working in the
react paradigm and it’s been a learning curve. Flutter is super fun to play
with though and making user interfaces is actually pleasant.

I decided to also write the new version natively on iOS because some of the
most important parts of the app for me are the Today Widget and Watch
Complication. Now with Flutter you can add this manually in swift or objc or
whatever, but they can’t talk to Dart code. So I would have to essentially
write the networking client code twice. That, and the iOS widget support just
isn’t good enough for me in Flutter.

So I am using Flutter to develop and Android version of my app, while keeping
the option that it could eventually become a full cross platform version
someday if I choose.

Also if Dart ever gets extensions like Kotlin and Swift that would be a game
changer for me, since I use generated specs for my API schemes.

------
baby_wipe
I totally understand the upside of writing one app for both platforms, but at
the end of the day they are still two different platforms. It seems unlikely
you’re going to make a high quality app unless you give each version the
individualized attention they really need.

Maybe these dual platform frameworks are fine for something like a company
internal app where it’s okay if you don’t get everything “just right”. But
otherwise I’d rather just go pure native, even if it means alienating half my
user base or spending 2x resources. It’s worth it in most cases IMO.

Granted I’ve only spent a couple weeks with React Native about a year ago, so
maybe I just need to give it another go.

~~~
hactually
I'd really recommend taking a dive into flutter. It's leaps and bounds better
than working with React Native IMO.

Treating Dart and Flutter as one 'SDK/Language for Apps' made it a lot easier
to avoid the uncanny valley effect I had with react native vs normal react.

------
vlucas
Flutter looks interesting. As a React/React Native dev, I found this doc page
particularly useful and enlightening:

[https://flutter.io/flutter-for-react-native/](https://flutter.io/flutter-for-
react-native/)

~~~
spiritcat
It's def an interesting philosophical comparison between it and RN, will be
interesting to see where it goes.

------
mixmastamyk
I'm wanting to try Flutter for a new app I'm planning. But a blocker is that
it doesn't (yet?) run on Linux, which is a deal breaker for me.

~~~
jonkirkman
I assume that you're referring to the fact that you cannot create iOS builds
from Linux. Otherwise the toolchain works just as well on Linux as it does on
Mac.

~~~
mixmastamyk
Sorry no, I’d like to run a media kiosk app full screen on a PC.

~~~
sebe
With chromeos support for android apps, I wonder if a chromebox, that has
android support, could fire up a futter/android app in kiosk mode.

Maybe it's possible to do with a pc running chromium os.

------
sandov
I didn't know what Flutter was and from the title I assumed it was abandoned
(how it _was_ to write a flutter app).

So, I just got that excitement from having something cool to learn.

------
karmakaze
The article mentions removing simple elements, e.g. "‘Center’ widget is nice
for a Hello, World container but I never understood it. Why can’t ‘Container’,
something that’s way more prevalent have a property to do the same thing?"

I'm perfectly happy with the nesting of simple elements. Having a single
'Container' also handle various layout rules is what makes all the positioning
options of CSS difficult. Similarly for constraint systems. Composable, single
function components are easy to learn and use. I'm just presuming that it has
good runtime characteristics and haven't run into any issues yet.

------
TimMeade
Interesting this is on the front page, yet no comments. I'm very curious as to
others thoughts. We are about to start a new react native app and are
considering flutter. It will be webrtc based also. Extensive experienced
design team, but no dart experience. Any thoughts?

~~~
sunw
CodePush was the main reason why our team went with React Native instead of
Flutter. Being able to push bug fixes to all of our users in real time is
incredible.

~~~
cbnotfromthere
"CodePush was the main reason why our team went with React Native instead of
Flutter."

If so, why not Ionic?

~~~
slow_donkey
Imo the only serious contenders for crossplatform apps are react native and
flutter. There is no good reason to use other frameworks when you get similar
dev speed, better community support, and a relatively fast product with these
2.

Probably 6 months ago flutter wouldn't be on this list but Google has
surprisingly shown strong support

~~~
mwcampbell
> Imo the only serious contenders for crossplatform apps are react native and
> flutter.

Why not Xamarin? It also has the backing of a top software company.

~~~
slow_donkey
True if you're a c# shop Xamarin might actually be a better choice. I just
haven't seen many good apps come out of the Xamarin community and I'm
implicitly biased because they don't support developing on Linux

~~~
mwcampbell
> if you're a c# shop

I prefer not to think of myself as an X-language programmer. And yes, when I
was developing mobile apps, I did it solo. I preferred to choose the right
tool for the job, and learn a new language if needed.

And I think Xamarin is better than React Native or Flutter, because Xamarin
makes it easy to use each platform's full set of native widgets in the native
way, while still sharing non-UI code. In contrast, React Native does use a
subset of native widgets, but doesn't give you access to the full set of them
(at least out of the box), kind of like the old Java AWT. And like Swing or
JavaFX, Flutter throws out the native widgets entirely.

------
unlimit
I am working on an Flutter android app, I find it still very laggy. Even the
official Gallery app from flutter team laggy. I am hoping they will sort it
out by the time they release it from beta.

------
HillaryBriss
there's a lot of enthusiasm, yet, i feel less enthusiastic about Flutter after
reading this.

i had not thought about this right in the past. i hadn't factored in the
reality of needing to maintain two separate UI trees, one with Material Design
widgets and one with Cupertino widgets. this makes me think one of the really
big advantages i thought Flutter had -- a unified UI -- is not really
realistic.

i must be misunderstanding this

~~~
seenickcode
Hi there, I'm the author of the article. I'd like to clarify that it's not bad
at all. Libs exist out there, such as offering a cross platform nav bar,
seemless where you wouldn't have to maintain two separate codebases. Also for
things like forms, if you have a custom design, you won't be having a lot of
"if/else" statements, you'd simply use one set of widgets since they'd be
custom.

~~~
HillaryBriss
Thanks for your clarification. I'll have to give Flutter a try some time.

