
Initial experience creating cross-platform apps with Flutter and Dart - charris0
http://www.harrischris.com/article/flutter-initial-experience
======
roughike
As a native mobile developer of several years, I've always been somewhat
skeptical of the various cross-platform solutions that have emerged over the
years.

The WebView-based solutions weren't fast enough and sometimes behaved
differently across devices because of different WebView versions. With React
Native, the impression was far better because the performance actually can be
quite good. But it's still hard to abstract the UI layer away when even the
native Views on Android behave differently across devices and Android
versions. I had to use almost a half of a day for fixing invisible drop-down
menu items on some specific Samsung device on Android 4.1.2. Not to mention
when you have to abstract the UI for both Android & iOS, which brings its own
set of problems. It's one of the reasons why such a fundamental thing as
navigation has been so hard to get right.

I feel Flutter is the first cross-platform SDK that gets something
fundamentally right. Since every pixel on the UI is rendered by the framework,
we as developers have better control of everything. It's going to have much
better performance because there are no bridges between native and cross-
platform land. Additionally, Samsung can't fuck up our UIs: once the UI works,
it works the same on every device.

As a bonus, they also keep tremendous care of their codebase and they have the
best documentation I've ever seen. My really simple, quick 4-line fix didn't
go through until I wrote 30 lines of automated tests to go with it. After all,
Flutter is going to be the native SDK for developing apps for Fuchsia, and I
think Google has learned not to repeat the same mistakes that happened with
Android again.

~~~
Illniyar
"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.

~~~
MarkMc
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...](https://play.google.com/store/apps/details?id=com.hamilton.app&hl=en)

~~~
Illniyar
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.

------
yawn
> So Flutter is actually pushing pixels itself, sounds strange, but it works

The siren song of cross-platform development sounds so sweet to the ears and
I've fallen for it quite a few times only to get bitten in the end.
Introducing another layer between you and the source has several drawbacks:
it's an additional source for bugs, it makes you reliant on the middle man to
be timely with updates to keep pace of the native changes and bug fixes, it
can prevent you from using time-saving tooling for the native environment,
etc.

What happens when the native controls change? What do I see when I'm running
an older native version?

~~~
sethladd
(disclaimer: I work on the Flutter team)

> What do I see when I'm running an older native version?

You will see exactly the pixels that your designer intended and your developer
coded. :) Apps built with Flutter ship the renderer and framework inside the
app, which helps ensure consistency and fidelity across devices, OEMs, OS, and
platform. This is particularly important for brands that want a brand-first
design delivered consistently to all their users. Hope that helps!

~~~
Numberwang
Thank you for replying in this thread.

Another question. Why is there no desktop support?

~~~
kjksf
I'm not on their team but the answer is rather self-evident.

There are 100x mobile developers than desktop developers which is why there's
so much more investment in mobile tools than desktop tools.

Also, this is Google-led project and Google doesn't write desktop apps (modulo
few exceptions like Chrome). As every team, they have more work than they can
manage, so they have to prioritize things that are important to them.

------
htormey
I think the article would have been much better if the author had left out the
section about RN. Failing that I would have liked to see him dig into why RN
was slow for his use case and what he tried to do to fix theses issues.

"While it uses the same React paradigm, there’s still a lot of differences.It
seems performance is reduced significantly as your application and the react
framework is controlling all the high level rendering functions from within a
JavaScript control thread."

It really seems like this person didn't spend a lot of time looking into
performance when assessing React Native. Facebook have some really nice docs
on this:

[https://facebook.github.io/react-
native/docs/performance.htm...](https://facebook.github.io/react-
native/docs/performance.html)

They have a whole section on how to handle performance for user
interactions/animations/etc which is well worth reading. Many RN related
performance issues boil down to not being mindful of how javascript interacts
with the native bridge. Tal Kol from Wix wrote a really great article about
this, which you can find here:

[https://hackernoon.com/moving-beyond-animations-to-user-
inte...](https://hackernoon.com/moving-beyond-animations-to-user-interactions-
at-60-fps-in-react-native-b6b1fa0ba525)

I'm sure Flutter/Dart are great tools. It's just a little odd to see someone
who know's React dismiss RN off handedly for performance reasons without
making much of an effort to read the developer docs.

~~~
fauigerzigerk
_> Many RN related performance issues boil down to not being mindful of how
javascript interacts with the native bridge._

Yes, but being mindful of this architectural choice doesn't make it go away.
It will always have to be worked around, which may add complexity depending on
the specifics of the app.

I haven't made my mind up about whether or not to use RN for an actual
product. RN has a lot going for it, but this particular architectural choice
is a negative in my view.

The other concern I have is the lack of JIT on iOS. Or is that already a thing
of the past?

None of what I'm saying should be taken as some sort of firm assertion. My
experience with RN is minimal. I'm keeping an open mind.

------
programmarchy
Side story...

I wish you guys hadn't killed Apportable. It was such an awesome product! From
what I could gather, Google acquihired the Apportable team, which then pivoted
to Flutter.

For anyone that doesn't know, Apportable was an Obj-C to native Android
compiler. It bypassed the JVM, compiling directly to the native architecture,
and actually ran faster than comparable Java apps. As a compromise, it also
had a Java bridging interface to hook into Android APIs. It was mainly
targeted at games which used Cocos2D, but a UIKit bridge was in the works...

When I first heard about Apportable, I was incredibly wary of their claim, but
it worked like absolute magic. I was able to successfully port several Cocos2D
apps directly to Android with almost no intervention.

Anyway, assuming the core team is still intact, if there is anyone that can
pull off what Flutter is claiming to do, it's these folks.

------
MarkMc
If you have an Android phone, a good demonstration of flutter is the gallery
app:
[https://play.google.com/store/apps/details?id=io.flutter.gal...](https://play.google.com/store/apps/details?id=io.flutter.gallery)

There doesn't seem to be an equivalent iOS app, which is kind of strange for a
product whose whole purpose is cross platform development. But maybe it's not
allowed on the App Store because it's alpha or just a demo.

------
bsaul
I'm amazed at the number of original projects i see done with Dart. Yet it
always seems to be ambitious prototypes as if the language was still looking
for its "ruby on rail" moment.

Not that there would be anything wrong with that, but when you combine this
impression with reading titles like "google coding its next OS with dart", you
wonder if this language is google's secret weapon, or if all of it is just a
marketing attempt.

------
Zigurd
Life is hard for cross-platform environments. Cross-platform apps, never mind
runtimes and sdks, don't have wide use. React Native is the only notable
exception. While tools like Xamarin can make a living, that's mostly outside
of mass market apps.

Web apps on JS are the most compelling example of an app ecosystem that has
come unmoored from underlying OSs, but iOS and Android have brought back the
dominance of native apps, because the underlying platforms and their
capabilities are interesting and useful.

Maybe Flutter is a good UI stack for Fuchsia, and maybe easy Web app
compatibility would be a boost to both Flutter and Fuchsia, but it will be
tough sledding to get Flutter apps accepted by Android and iOS users. Flutter
needs to find a place where it is essential, not a compromise for developers
searching for a panacea.

The reason Java is the most widely used language is that Android turned Java
into a platform-specific, UI-stack-specific app language.

The irony is that, because of the mountain of highly capable modern mobile
apps, I'd bet that the Android runtime on ChromeOS quickly becomes the most
widely used cross-platform runtime, in terms of the number of apps actually
used by people and running on multiple platforms.

------
mamcx
The thing I want for this kind of tools is to be a TRUE REPLACEMENTE of
webviews.

I don't wanna code in JS. No in Dart, but I can accept to use it ONLY for UI
rendering. SO I can use F# or Swift or any other language.

ie: I wanna to have a webview-html-css-alike "render screen" and let me use my
own language in the back.

------
chickenbane
Coincidentally I just saw this video by Eric Seidel (the lead of the Flutter
team) talking about the stack of Flutter:

[https://www.youtube.com/watch?v=VUiVkDpikDI](https://www.youtube.com/watch?v=VUiVkDpikDI)

------
oweiler
Flutter itself seems nice but I can't stand Dart. It's an okay language but
isn't expressive enough for a modern language.

~~~
mraleph
> but isn't expressive enough for a modern language.

What do you miss?

------
brett40324
Some implementation features related to a few points in comments here so far,
from Flutter faq here: [https://flutter.io/faq/](https://flutter.io/faq/)

How does Flutter run my code on Android?

The engine’s C/C++ code is compiled with Android’s NDK, and the majority of
the framework and application code is running as native code compiled by the
Dart compiler.

How does Flutter run my code on iOS?

The engine’s C/C++ code is compiled with LLVM, and any Dart code is AOT-
compiled into native code. The app runs using the native instruction set (no
interpreter is involved).

Does Flutter use my system’s OEM widgets?

No. Instead, Flutter provides a set of widgets (including Material Design and
Cupertino (iOS-styled) widgets), managed and rendered by Flutter’s framework
and engine. You can browse a catalog of Flutter’s widgets.

We are hoping the end-result will be higher quality apps. If we reused the OEM
widgets, the quality and performance of Flutter apps would be limited by the
quality of those widgets.

In Android, for example, there’s a hard-coded set of gestures and fixed rules
for disambiguating them. In Flutter, you can write your own gesture recognizer
that is a first-class participant in the gesture system. Moreover, two widgets
authored by different people can coordinate to disambiguate gestures.

Modern app design trends point towards designers and users wanting more
motion-rich UIs and brand-first designs. In order to achieve that level of
customized, beautiful design, Flutter is architectured to drive pixels instead
of the OEM widgets.

By using the same renderer, framework, and set of widgets, we make it easier
to publish for both iOS and Android concurrently, without having to do careful
and costly planning to align two separate codebases and feature sets.

By using a single language, a single framework, and a single set of libraries
for all of your UI (regardless if your UI is different for each mobile
platform or largely consistent), we also aim to help lower app development and
maintenance costs.

What happens when my mobile OS updates and introduces new widgets?

The Flutter team watches the adoption and demand for new mobile widgets from
iOS and Android, and aims to work with the community to build support for new
widgets. This work may come in the form of lower-level framework features, new
composable widgets, or new widget implementations.

Flutter’s layered architecture is designed to support numerous widget
libraries, and we encourage and support the community in building and
maintaining widget libraries.

What happens when my mobile OS updates and introduces new platform
capabilities?

Flutter’s interop and plugin system is designed to allow developers to access
new mobile OS features and capabilities immediately. Developers don’t have to
wait for the Flutter team to expose the new mobile OS capability.

~~~
bsaul
thanks for that, i completely missed the interop and plugin part. Although i
doubt this approach would work with something like "iOS 11 new navigation bar"
that's really integrated to all the rest.

------
bitwize
No.

You use native UI widgets or you gtfo. This may seem strange to us Linux
folks, who are used to making do with any old UI. But Apple users are UI
supertasters. If anything is a tiny bit off -- a bounding box one pixel too
short, a response to button click one millisecond too laggy -- Apple users
will notice, and Apple users will complain, and it will be reflected in your
app's sales/metrics.

At least on iOS, it's worth it to use the native widgets.

~~~
symlinkk
Yeah, Snapchat would have been successful if only they used native widgets...

