Ready for Production Apps: Flutter Beta 3(developers.googleblog.com) |
Ready for Production Apps: Flutter Beta 3(developers.googleblog.com) |
“Build once, compile everywhere!”
They all come and go, but native seems to always win in the end. It seems like the hierarchy over the last couple decades in terms of “market share” for successful projects is: web > native app > hybrid app. I really doubt any framework is going to change that, or become all that dominant within what is basically a small niche.
The native UI toolkit that powers 85% of all mobile devices will then also be usable on the remaining 15%. That changes the equation for all but the most high profile iOS apps.
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
I would say the best part about it is the hot reload, which maintains application state. It's compiled to native code so it's going to run faster than ReactNative which is a javascript bundle that runs besides your app. Compile times are fast, but not instantaneous and you have to trigger the reload manually.
I think it also has the most complete implementation of Material UI out there. It implements widgets that are not implemented in iOS, Android nor Web. It's like having something like bootstrap that makes it easier to build a good looking app. I feel like you really need a mock first to build a reactnative app, but you could get away with just writing code in flutter.
Unlike ReactNative there is no way of trying it without installing the Android or iOS development environment. Initially that was a bit of a barrier for me as a first-time mobile dev, but not a big deal eventually.
It's not as mature as ReactNative. There was no build-in way to do audio, something I need for the app I am trying to build. However, I found a plugin for it on github.
I know Google has a reputation of canceling projects, but Flutter is used to develop the Google AdWords app so I don't think it will go away anytime soon.
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...
Simple ability to run in the browser, even not perfectly, would still add a lot of value though..
I suspect adding ability to run in browser imperfectly would just invite demands for Flutter to become a web dev framework entirely.
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.
If I'm going to take the time to learn a new skillset, I'm going to learn the one that gives me the most marketability and pays the highest that would be iOS/Swift, then Java/Android and then I might play around with Dart/Flutter.
I usually prefer to start with the fundamentals and then learn abstractions/frameworks. Take front end development for example. While frameworks change every six months, knowing the fundamentals of JavaScript/CSS/HTML is valuable long term.
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.
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!
Issue 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.
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/ , but I would also like for it to be open source. :P
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.
There was web UI framework churn in Dart's early years, but last I heard, Google has settled on AngularDart.
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.
I'm still hesitant to put my hand on it for side project until it's more popular. Chicken and egg problem I guess.
As a user, I don't. Sure, on Android Flutter looks OK, but on iOS it looks out-of-place.
I wrote a post to that effect here: https://harveynick.com/2018/05/21/an-ios-developers-opinions...
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.
I'm curious which AWS APIs you'd want to connect your mobile app directly to. S3/ SQS?
If there's a better way, please let me know! I loved Flutter, and I loved Dart.
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.
https://docs.flutter.io/flutter/widgets/CustomPaint-class.ht...
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.
> 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.
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.
That’s a really promising stack.
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.
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.
https://github.com/flutter/flutter/issues/730
Nope. Still no inline webview component.
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
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.
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.
You also communicate to Java through serialization, rather than through shared memory.
Oh, and any communication goes through a Future, which is annoying.
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
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.
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.
"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)."
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.
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.
I am surely not a language expert.
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
Then again, this is more of an outlier (today) with the GPU present almost on any mobile device, but still something to know about (e.g. flutter won't be of good use there).
> In other words, in today’s market, a branded, custom UI is king.
Does a custom UI per app not make it more difficult for people to learn each new app? Didn't the platform developers write their human interface guidelines for a reason? Or was that level of consistency only necessary in the early days of Mac and Windows, when the temptation was to port a DOS app straight over rather than redesigning it as a GUI?
Really the only downside is that it is a ton of work to make it match the look of the native widgets. They've done a good job though. I really doubt 99% of people could tell at all.
Dart is ok. Better than Java or Javascript at any rate!
However, my experience has been that most people want a heavily customized and styled UI that looks similar on both iOS and Android because a generic stock UI doesn’t have enough visual bling to attract users or establish a strong brand. And it looks like doing that kind of customization should be a lot easier with Flutter than it is with either native platform’s native APIs.
I’d say that’s one of the most attractive things about Dart to compensate for yet another language.
If platform developers cared so much about consistency, they wouldn't change their UI design just to freshen up their image or because design trends have changed. Maybe looking and behaving like everyone else really has a major influence on user adoption, but it usually seems to be ignored in favor of branding.
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.
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.