
Ready for Production Apps: Flutter Beta 3 - grigy
https://developers.googleblog.com/2018/05/ready-for-production-apps-flutter-beta-3.html
======
hliyan
I've been playing around with Flutter for a few weeks now and I'm convinced
that this is the future of cross platform app development. I was initially put
off by having to learn an obscure language (Dart), but the reality is, it's a
lot easier to learn than learning all the semantics, tools and practices that
come with a massive ecosystem like React.

~~~
everdev
I'm evaluating it. Why do you think it's the future? What's the feature you
value most?

~~~
hliyan
I've been a React fanatic for several years, so my opinion is colored by that:

1\. Great DX (developer experience) - a single language (Dart); no need for
JSX, JavaScript, JSON, Flux/Redux and various other libraries. You can focus
on the business logic rather than battling the ecosystem.

2\. A single set of components (no iOS or Android specific navigator
components etc.)

3\. No longer need a JS engine to run - truly native

4\. As fast as promised

~~~
grigy
Being agree with all 4 points I see two drawbacks:

1\. Not using OEM widgets. Even the rendered widgets may look good, they can't
beat the native widgets optimized for the particular platform.

2\. The choice of Dart as the main language.

I can understand both points though

~~~
quangio
I don't think using non-OEM widgets is a bad thing because it's not like
Electron; Flutter uses Skia to render widgets, and it's fast. There is an
article [https://medium.com/flutter-io/why-flutter-doesnt-use-oem-
wid...](https://medium.com/flutter-io/why-flutter-doesnt-use-oem-
widgets-94746e812510)

~~~
foepys
I'm always concerned that accessibility is being left behind. Android and iOS
both put great efforts into making their UI accessible, why do the work again?
Chances are that the accessibility of those third-party components will be
worse or maybe doesn't even work at all.

~~~
egeozcan
The problem is that the accessibility work already needs to be done on every
platform (for now we have two really popular ones but nobody can be sure what
the future brings).

Also, if you could just recompile your app for a new platform and release
(more or less), it would remove the biggest barrier to entry for possible new
platforms: Adoption.

~~~
foepys
That's not what I meant. Android and iOS already have their own widgets with
accessibility features in place. iOS even better than Android. It took years
for them to develop to where they are now.

Now Flutter is making its own widgets that look and handle like the
corresponding native widgets. So they need to implement accessibility all over
again in the same way that is already present on the platforms. Google is thus
redoing all the work they already did in Android.

A lesson from modern software development is that software is developed
incrementally and because accessibility is never high on those priority lists,
it will lack in quality at first and take multiple iterations to get up to the
same level as the native accessibility of the OS, if it even gets there in the
first place.

~~~
sebe
I think accessibility was a requirement for an internal google flutter app,
have you had a chance to look at
[https://flutter.io/accessibility/](https://flutter.io/accessibility/)

------
nevi-me
I like the direction that Flutter has taken, cross-platform without the
baggage of being a web platform.

If you know JS and Java, Dart is very easy to learn. About a few hours' worth
of tinkering and you'll be good.

I had an Android app [0] that I was trying to build with Kotlin in the
evenings/weekends. I switched to Flutter, and was able to get something out of
the door in less than the time I spent on Kotlin/Java.

I like the mix between Flutter and being able to call native APIs. The only
thing I'm missing right now is good maps support. Google and Mapbox have some
prototypes, but it's still too early to use them (for what I want to do).

[https://play.google.com/store/apps/details?id=za.co.movingga...](https://play.google.com/store/apps/details?id=za.co.movinggauteng.mytrain)

~~~
riku_iki
> cross-platform without the baggage of being a web platform.

Simple ability to run in the browser, even not perfectly, would still add a
lot of value though..

~~~
dman
From Laws of spacecraft design -> 39\. Any exploration program which "just
happens" to include a new launch vehicle is, de facto, a launch vehicle
program.

I suspect adding ability to run in browser imperfectly would just invite
demands for Flutter to become a web dev framework entirely.

~~~
bmelton
Good point, but that would still be welcomed, though I'd probably prefer it be
a diffeent product (ala the opposite of react-native).

Flutter has shown that it's possible to build a truly native implementation
from "web" tooling. I've shipped apps with Ionic and such before (but not
React-Native yet), but despite how much care goes into the application,
they've still never felt native, and Flutter bridges that gap perfectly.

If it somehow managed to also be able to deploy the same code to the web,
perhaps using a different (or providable) CSS grid, I think it's as close to a
holy grail as we'll manage.

------
alfonsodev
This all sounds very cool until you need something in your app that is not
provided as third party module yet, or numerous third party plugins that you
are using start being unmaintained or buggy or they don't support your use
case.

Then you'll need to write your own plugin in native language, but you have
been writing in Flutter and you don't know enough about the native platform.

My opinion, if you don't know native development yet, make two "boring"
applications in kotlin and Swift and learn the native platforms. Long term
you'll be a better more complete app developer. Later if you want to try
flutter or react-native you won't be locked by what plugins can do.

~~~
cutler
Learn Swift+iOS & Kotlin/Java+Android then Dart/Flutter. How many lifetimes is
that to become deeply proficient?

~~~
pjmlp
I do consulting across Java, Android, .NET, C++ and Web stacks.

I am a Language X expert that knows every little detail, surely no.

Am I proficient enough to keep costumers happy with the results and willing to
keep assignments for new stuff coming my way? You bet.

~~~
cutler
The second sentence doesn't quite make sense to me. Are you saying you hire
yourself out to customers as an expert in Java, .Net, C++ & web stack but with
only enough detail to produce work that keeps them happy?

~~~
pjmlp
Yes, in a way that is it, just I haven't stated that I am an expert, rather
that I know them well enough to deliver quality work.

Most companies don't have software as their core business, they just want
something that works for their business case, and most of the time they even
value more domain knowledge and social skills than beautiful technical
solutions.

If it works, fulfils the SLAs and the internal teams are happy with the
delivery acceptance review, that is all that matters.

~~~
dman
I think whats adding to the confusion here is the "I am a Language X expert".
I suspect the Am and I need to be interchanged there.

~~~
pjmlp
You are right, I got that part wrong.

I am surely not a language expert.

------
TheAceOfHearts
The title is a bit of an oxymoron; aren't production-ready and beta mutually
exclusive in most cases? The examples they showcase seem like pretty small and
simple apps. The musical one seems like it could've easily been a web app,
since it's just displaying information.

~~~
ericand
Amen. They are trying to have their cake and eat it too.

------
quangio
I am having a side project built with Flutter. (here:
[https://play.google.com/store/apps/details?id=zero.sleep.com...](https://play.google.com/store/apps/details?id=zero.sleep.comchat)
). The ecosystem is not as big as ReactNative (because Dart + it's new) but
the developer exerience is really good. Dart is not that bad, and I really
love the toolings even they were in the experimental state. Hot Reload, good
IDE, typed, Java-like but less verbose, stream...

~~~
slow_donkey
This is beautiful, thanks for sharing. Do you have a repo hosted somewhere I
could poke around in?

------
vijaybritto
Anyone else wants them to release flutter for desktop so that we can replace
electron?! Someone at Google please make this a possibility!

~~~
tamalsaha001
Something like [https://github.com/google/flutter-desktop-
embedding](https://github.com/google/flutter-desktop-embedding) ?

~~~
vijaybritto
Yes!! This is a great start! They have a gold mine in their hands. I hope they
understand that and make it a possibility!

------
mikece
There are several aspects of Flutter that are compelling. The two which I find
the most interesting are speed of development and the platform independence
when designing the app.

Speed of development: I've seen Flutter development referred to as a "double
hot reloading" dev paradigm: UI and app logic. Hot-reloading the UI on design
changes isn't new (React Native, NativeScript, and even Xamarin can do this)
but the team at Google made a purpose-built debugging compiler for Flutter
which separates state management from the app logic so if you're working on
code deep into an app and need to fix something in the logic, the executing
code is reloaded while the app's state and UI remain where they are so you
don't have to start over from the launch screen, log in, start your
transaction/order/process..... This process cycle -- launch, login, start an
order, get to the state of an order to test the logic I just altered -- used
to consume five to ten minutes per iteration when I was doing Xamarin work.
Being able to edit and re-run the application logic without losing state and
starting over is HUGE!

Platform independence: the UI for Flutter apps doesn't rely on the native OS
widgets of iOS or Android (or Fuchsia!) but a C++ layer that bundles and ships
with the app in question. It's akin to building a business app in game
template where you can custom-define everything about the UI and any widgets
you want to use... a lot of work but they will look and act the same on iOS
and Android (and Fuchsia) and presumably run fast. This is a massive
difference from Xamarin where cross-platform apps end up using the platform-
native widgets which is known to result in non-trivial amounts of "if
(Platform_Android) {...} else if (Platform_iOS) {...}" or just going the more
sure-fire way of not entering Xamarin-debug-hell: make the UI for your app
using the platform-specific Xamarin-tooling and move as much code to the share
logic layers which don't need to be changed between Android and iOS.

The final thing I'll say about Flutter: I told a colleague who thinks that C++
is the _ideal_ cross-platform mobile language about Flutter. Two weeks later
he came back, told me he made a demo app with it, then decompiled the
resulting IPA and APK files to inspect the assembly code and he concluded that
it was essentially the same as if the app had been written in C++ from the
get-go. I'll take his word for it since I lack the skills to verify that for
myself but it certainly speaks well for the performance potential of Flutter!

~~~
zengid
> _This is a massive difference from Xamarin where cross-platform apps end up
> using the platform-native widgets which is known to result in non-trivial
> amounts of "if (Platform_Android) {...} else if (Platform_iOS) {...}" _

Is your Xamarin experience using Xamarin.Forms? It sounds like Forms allows
for more cross-platform gui code reuse. I'm doing a lot of investigation into
Xamarin because I'm learning C# this summer for an internship and I love the
language.

~~~
mikece
Xamarin.Forms provides an abstracted UI definition of common controls across
platforms. This makes design faster since you can simply specify a Button or a
Picker without knowing or caring that the actual implementations on iOS are
UIButton or UIPickerView (eg: UIDatePicker) or that on Android they are
android.widget.Button or android.app.DatePickerDialog. All UIs defined in
Xamarin are rendered with OS-native widgets.

------
saintfiends
Biggest blocker for me is not being able to use WebView.

Issue
[https://github.com/flutter/flutter/issues/730](https://github.com/flutter/flutter/issues/730)
has been open for 2+ years with no solution.

It would be nice to know how big of a challenge this is or if there is a plan
to solve it at all.

~~~
marktechson
There are existing options for this:
[https://pub.dartlang.org/packages/flutter_webview_plugin](https://pub.dartlang.org/packages/flutter_webview_plugin)

------
hawski
How good is FFI in Dart? I mean how fast and easy is it? I see that it can
call C and C++ libraries, but that's nowadays a basic requirement for any FFI.
I'm looking maybe for an opinion and maybe some kind of numbers to back up
it's performance.

As far as I understand it on Android it's compiled to a CPU native binary and
has to use NDK and JNI to do anything. If that's a fact it's funny that on
Google's own platform it has to go through two FFIs - Dart to C to Java. While
on iOS just one - Dart to C, because what's there not to it for Obj-C?

I'm dreaming for a truly native everywhere platform. Something that would
compile to DEX or JVM byte code for Android, CLR on Windows and a binary
everywhere else. While using native widget toolkit for each platform -
practically without any FFI. Also respecting HIG of each platform. Yeah, I'm a
dreamer.

I heard about
[https://www.elementscompiler.com/](https://www.elementscompiler.com/) , but I
would also like for it to be open source. :P

~~~
geokon
I mean, if you're gunna use C++ libraries, is there a reason not to just make
the whole app in C++ (like with Qt/QML)? Seems adding a new language/toolchain
to the mix is a recipe for headaches.

That's a genuine question :) I don't do any app development so maybe I'm
missing something - is Qt not sufficient? It seems to run on everything as-is

~~~
hawski
I didn't say anything about C++ libraries, at least in case of my dream thing.

The problem with Qt is that it draws its own widgets. It is close on some
platforms like with Gtk+ theme, but most people report how it does not look
native on their platform. Also on Android it has to use JNI and NDK so it's
not native to Android as DEX/Java is. On Windows I believe that CLR or at
least COM (you can do it even C, but that requires effort) is a native
platform.

Qt is from a time when C was kinda native for everyone. It's a different world
now for better or worse.

Of course Qt has some advantage over one of many other widget toolkits drawing
their own widgets. It hooks to native accessibility APIs for example. Other
than that: dlangui, Lambda Native or even SDL2 can be seen as contenders.

~~~
geokon
I see the limitation.. but I must be missing some subtle distinction b/c isn't
Flutter doing essentially the same thing under the hood?

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

"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)."

~~~
hawski
It does the same thing, that's why my dream is not fulfilled by Dart. Or may
even have worse accessibility, but I don't know.

If it would be compiled to DEX (native for Android APIs) or JVM (compilable to
DEX) byte code it would be different. It would at least enable use of it to
make such a dream.

~~~
sebe
I posted this earlier, I think accessibility was a requirement for an internal
google flutter app, have you had a chance to look at
[https://flutter.io/accessibility/](https://flutter.io/accessibility/)

------
ajconway
On iOS it's not possible to seamlessly integrate any custom UI drawing with OS
animations (keyboard, rotation). This means that certain types of apps will
never feel right on the platform, which should significantly limit usability
of the framework outside of Android and desktop.

~~~
mwcampbell
Interesting. Can you expand on which types of apps wouldn't feel right on iOS
if developed in Flutter?

~~~
ajconway
Any app where text input is a major feature — messengers, social network apps,
email clients. Most apps with a search field — usually some parts of UI move
when opening and closing keyboard. Long time android users don’t expect any of
these interactions to animate smoothly and in perfect sync, but it is
essential for iOS UX.

------
d--b
Isn't "beta" supposed to mean "not quite ready for production"?

~~~
RyanZAG
Chicken and egg, right? If Google declares it not ready for production, then
nobody uses it for production apps, so it never gets the kind of testing it
needs to really be production ready.

If Google declares it out of beta, then people assume nothing will change, and
if things do change they complain.

So the current wisdom is to have a 'production ready beta' which indicates an
in-between period where things can change, but you're encouraged and expected
to use it in production.

~~~
vertex-four
Wouldn’t that traditionally be a Release Candidate? Something you think is
good to go, but needs wider testing before you can say that for sure?

~~~
kmonsen
I think with release candidate there is only bugfixes later, but with the beta
the door is left open for API changes etc.

------
brunoluiz
Fun fact: on pre-release Angular 2 versions, Dart was it's main language. My
hypothesis is that, if they decided to continue using Dart, probably we would
have more Dart developers and this could have lead to a faster Flutter
adoption.

~~~
hknd
angulardart (1) is still available, but probably not used by any serious
project. Still have mixed feelings about dart - apparently some of the biggest
frontends at Google (advertising) use this, so it must do something really
good.

1: [https://webdev.dartlang.org/angular](https://webdev.dartlang.org/angular)

~~~
skybrian
I'm not sure what you mean?AdWords uses AngularDart. It's the best-supported
way to build a web app in Dart.

There was web UI framework churn in Dart's early years, but last I heard,
Google has settled on AngularDart.

------
simonhorlick
Flutter is by far the best UI library I've dealt with. Its like React, but
without the nasty JSX syntax. The APIs are sane and thoroughly documented. Its
layout model is (by design) super simple, so it's really quick to prototype
and iterate. The developer tools are top-notch: great support in IntelliJ, hot
reload.

But the best thing about flutter is the rendering. It's completely consistent
across platforms because it renders every pixel itself and because of this
it's also really easy to draw exactly what a designer envisioned.

------
bartq
I liked the idea of Flutter since I saw it for the first time probably long
time ago. Dart as a language choice was throwing me back though, but in
general this language is very similar to ES6 and makes OO easier. For example
it doesn't require to use `this` in methods. I wish it was TypeScript instead,
because it has more mature tooling and community support.

I'm still hesitant to put my hand on it for side project until it's more
popular. Chicken and egg problem I guess.

~~~
hbhakhra
I get that learning another new language sucks and JavaScript would've been
nice instead but the Dart language choice actually enables some very nice
features in terms of developer experience. I don't remember the details off
the top of my head, but I believe stateful reload is one example of what
possible because of Dart.

------
saagarjha
> Alibaba praises Flutter for its consistency across platforms

As a user, I don't. Sure, on Android Flutter looks OK, but on iOS it looks
out-of-place.

~~~
ma2rten
There is an iOS theme (Cupertino), but I am not sure how complete it is.

~~~
harveynick
It’s not so much the widgets as it is the actual look and feel. Neither
scrolling nor text rendering is _quite_ right.

I wrote a post to that effect here: [https://harveynick.com/2018/05/21/an-ios-
developers-opinions...](https://harveynick.com/2018/05/21/an-ios-developers-
opinions-of-flutter/)

------
hazz99
A few months ago, I began using Flutter for a sideproject (That I wanted to
release).

Although the developer experience is absolute fantastic (And definitely the
future), the plugin ecosystem is extremely lacking. I wanted to use AWS, and
there was 0 backing for it. Since I didn't want to interact with raw AWS APIs,
I moved to React Native.

~~~
isuckatcoding
It looks like you could "wrap" native libraries using custom packages:
[https://flutter.io/developing-
packages/#plugin](https://flutter.io/developing-packages/#plugin).

I'm curious which AWS APIs you'd want to connect your mobile app directly to.
S3/ SQS?

~~~
hazz99
I wanted to use Cognito & Lambda functions (Through the API Gateway). The AWS-
Amplify library makes this super easy, but isn't available for Dart.

If there's a better way, please let me know! I loved Flutter, and I loved
Dart.

------
kyle-rb
Flutter looked absolutely perfect to me until I looked into calling C++
libraries, in order to facilitate a mobile version of a desktop app made with
Qt/C++. It turns out the only way to call C++ code is to write two separate
wrappers, one in Java (with NDK) and one in Objective-C.

It seems like a pain in the ass to have to go through two separate channels to
access code that's perfectly cross-platform to begin with.

------
zengid
Does flutter have a canvas yet? Whats the story for making arbitrary custom
components, like a draggable rectangle that can be moved around a grid?

~~~
xxgreg
"A widget that provides a canvas on which to draw during the paint phase."

[https://docs.flutter.io/flutter/widgets/CustomPaint-
class.ht...](https://docs.flutter.io/flutter/widgets/CustomPaint-class.html)

Edit: All of the built-in framework widgets are written in Dart and rendered
via canvas-like draw calls at the lowest layer (See dart:ui). Since the
widgets are available under a liberal open source license you can fork them
and customise them however you like.

------
mamcx
The part I wish to have for things like this:

> We're also working to make it easier to add Flutter to your existing Android
> or iOS codebase.

Ideally, it must just refer a single lib + provide the path to the dart
code/resources folders. Plus have a truly nice bridge/callbacks so I could
have the heavy logic inside my native code.

ie, as easy as possible like with a webview.

------
k__
How does it compare to React-Native?

I know it compiles to native, but on the other hand only the business-logic in
RN is written in JS, UI and bindings are native.

Create-React-Native-App and Expo already deliver very good UX.

My main pain points with CRNA/Expo are bundle size and in-app purchases, not
performance or DX.

------
hitlin37
Anyone has any comment on Fuse framework? Since it has been open sourced i
have been looking into it and it seems interesting to code in.

------
bsaul
Apple really need to react if they want swift to get any traction. IOS hasn’t
had any major UI update since iOS7 , and android is a mess anyway, so using a
cross platform now makes more sense than ever. The icing on the cake would be
to have a path for reusing dart business layer between flutter and angular.

That’s a really promising stack.

~~~
ryanwaggoner
Ha. This is hilarious. Most high-profile / successful iOS apps (other than
games) are native. And judging from what I’m seeing in the ecosystem, I’d
guess that most teams out there have switched to Swift or will do so soon.
There’s very little enthusiasm or innovation in the Objective-C ecosystem at
this point.

The lack of a major UI update in the last few years is a feature, not a bug.
It doesn’t seem to have held back either iOS device sales or the Swift
ecosystem.

~~~
bsaul
I don't think you got my comment right. I was advocating for apple to expand
swift to other platforms ( android, pc desktop, web, server, whatever), in
order to compete with techs like flutter.

The reason cross platform tools weren't a good fit before and are now is both
because hardware is now powerful enough, and because platforms have now reach
a stable point.

------
falcon620
I keep checking up on issue 730 once in a while:

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

Nope. Still no inline webview component.

~~~
nevi-me
That reminds me of MongoDB's infamous issues that remained open for years.
They became the subject of many blog posts and discussions.

I still remember SERVER-1243 so well because of how much I saw it. They
eventually fixed/closed it last year, after 7 years.

My main missing features on Flutter are:

* background execution * Google maps parity with Android/iOS

[https://jira.mongodb.org/browse/SERVER-1243](https://jira.mongodb.org/browse/SERVER-1243)

------
wokwokwok
This has been posted 4 times before with zero interest in it when it was
announced a month ago.

Did something change?

Did someone just want an excuse to talk about flutter for a bit?

I'm quite opposed to this 'post random link on topic X because I want to talk
about X' thing.

If you want to talk about flutter at least bother to find something which is
technically interesting to read. This is just marketing talk.

~~~
myguysi
Probably marketing, that’s the one thing that bugs me about Flutter and React
Native. They’re not as big as the hype would have you believe

