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.
"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.
Thanks for the feedback! We are working on improving our accessibility now, which is required for our business-critical Google users and others. For example, you can follow this issue if you're interested: https://github.com/flutter/flutter/issues/12311
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.
> However, the question is whether a .. [Flutter, Cordova, React-native etc app] .. will be Good Enough when the alternative is writing two separate apps
This is a more important consideration than is often given credit for, perhaps because the perspective we most often read about is the high end of the industry. But vast amounts of software is written to extremely tight budgets, often for small businesses, where there is flat-out zero chance of two native apps being written. It's choose-your-platform, or something cross-platform.
For very many of these kinds of apps, which are pretty much invisible from the blogs/HN/medium world, RN/Flutter/Cordova etc are perfectly appropriate. The fact that these may not be the best platforms from which to use the very latest, most hardware-entwined OS features, or to do highly custom 'delightful' bits of UX, is often in this world quite irrelevant.
I don't like the approach either, and the point about accessibility is an important one that's very much non-trivial (but developers often ignore it completely at first).
It's like making a web page that renders everything inside Canvas elements. If that doesn't seem like a good idea to you -- why would you build your mobile apps that way?
The interesting part of Flutter for me is that it powers Fuchsia.
IF Fuchsia becomes a major thing, like the future of Android (and I can't emphasise enough how much it is uncertain right now) then it might become very interesting as a way to publish your new app on Fuchsia while being able to publish it on Android as well in order to support `legacy` devices (again, supposing that Android is abandoned in favor of Fuchsia)
Otherwise, it is 'just' another hybrid solution with the usual caveats.
I also use a cross-platform framework that "renders every pixel". The two major problems I had are the lack of native input and the integration with native ad SDKs. I solved the input with overlaying a native input view on top of everything but it's very clunky and have to be careful to keep it the topmost in the view hierarchy. I haven't found a solution for native ads.
Most of the other things are relatively easy to solve if they come up as actual problem.
In fairness Qt also gets this right: It renders every pixel and it has a fast rendering architecture. Having used Qt, flutter is very attractive to me for the case where you have to work with a team. It can be hard to get together enough people nowadays who will want to work with even a little C++. The Qt libraries make it very easy IMO (most stuff is ref counted) but not everyone is going to buy that.
Qt is one of those things that I've heard of before, but did not know was still used for mobile development today.
The monthly commercial license fee is a bit of a downer though. I feel that a lot of software development agencies (my workplace included) are just not gonna bother with it and just use something free instead.
I agree about the C++ point with you. I have to confess I'm also one of those people who generally want to do things on a higher level. Would definitely give Qt a try if it was free for commercial purposes though.
The free license for Qt is the LGPL, which, although more restrictive than a fully permissive license like BSD or MIT, is still suitable for many commercial applications. (You can't ship proprietary modifications to Qt, but you can ship a proprietary app that includes Qt as a dependency. Your app can use a modified version of Qt if you open source your modifications.)
It's native in the sense that it doesn't bundle an entire Chrome browser runtime with it. But it does not interact with native APIs; it re-implements the native platform's look and feel.
You're applying the word "native" to the wrong thing.
"Native" in the context of GUI frameworks doesn't have to do with code being interpreted vs compiled. It means the framework creates UI using the toolkit that ships with the OS you're targeting. It means Cocoa on MacOS and UWP or WPF or WinForms on Windows.
It means when you scroll past the end of the text in a textbox you get a bouncy effect on macOS just like every other Mac application, because it's ultimately calling the same function that every other Mac application calls.
If someone made a JavaScript library that wrapped Cocoa and UWP, it would be called a "native" toolkit, because it wraps the controls that are shipped with each OS. That's why React Native is called what it is - it's actually creating dialogs and views on iOS with the same functions you would call if you were doing it in Swift.
There are pros and cons. One of my big concerns around something like Flutter is accessibility.
When you render everything on your own you lose the ability to hook into system-level frameworks for accessible content discovery. Their FAQ mentions it briefly but looking at the API support seems pretty sparse.
We're working on accessibility right now, it's incredibly important to us and our users. A big driver here is Google's usage of Flutter. There are business-critical teams at Google right now using Flutter, and they can't launch until a11y is finished. So we're working to finish and ship it. Stay tuned!
At least on Android, it turned out that if you claim that specific portion of the screen is, for example, android.widget.ScrollView, the system believes it. This can be verified with the HierarchyViewer. Some people in Flutter's Gitter group were confused because of this, since they thought Flutter doesn't draw its own widgets. While in fact it was the early accessibility implementation.
> 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?
Another issue is when your customer (or boss) ask you for this very simple feature that's found everywhere ( because it's a native sdk feature) and you suddenly realize you'll have the spend days if not weeks implementing it. I wouldn't be surprised if maps weren't as powerful in flutter as in native android or ios sdk for a long time.
Still, i think the "low level / pixel level" approach that flutter took is the only one that makes sense. You can't abstract away GUI layers like the android one or the iOS one. it's just way too big, and they are themselves trying to abstract away discrepancies between OS versions. I don't understand how could anyone expect to get something of professional quality with a layer on top, knowing how hard it is to get it right even with the default tools.
I’ve been writing a new project in Flutter and so far it’s been dramatically faster than writing an app with either of the native SDKs. The issue you mention here is the key downside though. For example, as far as I know there is no map component or video player. I don’t happen to need those, but if you did it’d be a deal breaker probably.
Thanks for the feedback. We're currently exploring how to do inline video, which we think will teach us about techniques for inline maps. These are very top requested features. Stay tuned! :)
> 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!
Not to diminish your amazing work. I'm not sure brand-first is user-first. Its most user-friendly to use the standard phone OS controls that they are already familiar with.
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.
The problem with building your own UI toolkit is that you can never make it feel native. You can get 90% there, but it always feels a bit off to the user. The more you make things look like native controls, the more users expect them to act like native controls and tiny differences get amplified.
I'm not sure 100% fidelity to native look and feel is so important to users, as long as the UI is fast, responsive and looks good. Spotify doesn't seem to have a problem with users despite its garish black and green appearance.
You're also only going to get any of the perceived benefits of the choice to build a custom UI kit if you're only solving the same problems that the framework authors were solving.
If you suddenly need, as an example that I've come across, a list of stats to update with a high tick rate which is unusual in an app so no one optimises for it you'll likely find you're no longer anywhere near a native experience.
I know that's not a unique problem with opinionated frameworks, but it's usually a programming issue to solve in the background, not a deal-breaker due to how every customer suffers.
Fair points. It's worth stating though that this only matters if you have a requirement to look 100% native. Many apps don't have this requirement whether mobile or desktop and so they may use a web ui. In our case we didn't have the 100% native requirement and used Qt. We still had a really slick user interface, it just wasn't native.
Note that our customers are primarily concerned about the functionality of the app: They are not drive by consumers, they come to the application because of it's functionality. I understand that not everyone has this kind of customer.
It's not just about the look, it's about the feel.
From looking at the "gallery app" on android:
Flutter's input-text has their own custom mark text handler - no double tap, long press opens a custom menu that is missing native options (Such as translate text).
Changing the font size in the OS does nothing in the app.
Clicking on buttons doesn't make a tap sound if the "sound on tap" option is set.
I'm guessing no accessibility support - or very poor one.
There's probably many more tiny issues that customer's will complain about when you a product is shipped to production that will make it clear that this isn't a native app.
A lot of those are things we've fixed since we published that app. We're just not very good about publishing updates to the play store. I'll see if we can get an update out soon.
Thanks for your feedback! I opened https://github.com/flutter/flutter/issues/12438 to track the "not playing a sound when tapped". We're currently working on improving our accessibility support.
> 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.
Indeed it is the much harder road to travel. It all depends on who is developing the platform however. Google can pull it off, which is why Flutter is worth considering.
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:
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:
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.
>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.
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.
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.
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.
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.
Some implementation features related to a few points in comments here so far, from Flutter faq here: 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.
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.
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.
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.
"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.
(disclaimer: I'm on the Flutter team)
Thanks for the feedback! We are working on improving our accessibility now, which is required for our business-critical Google users and others. For example, you can follow this issue if you're interested: https://github.com/flutter/flutter/issues/12311
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...
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.
> However, the question is whether a .. [Flutter, Cordova, React-native etc app] .. will be Good Enough when the alternative is writing two separate apps
This is a more important consideration than is often given credit for, perhaps because the perspective we most often read about is the high end of the industry. But vast amounts of software is written to extremely tight budgets, often for small businesses, where there is flat-out zero chance of two native apps being written. It's choose-your-platform, or something cross-platform.
For very many of these kinds of apps, which are pretty much invisible from the blogs/HN/medium world, RN/Flutter/Cordova etc are perfectly appropriate. The fact that these may not be the best platforms from which to use the very latest, most hardware-entwined OS features, or to do highly custom 'delightful' bits of UX, is often in this world quite irrelevant.
I don't like the approach either, and the point about accessibility is an important one that's very much non-trivial (but developers often ignore it completely at first).
It's like making a web page that renders everything inside Canvas elements. If that doesn't seem like a good idea to you -- why would you build your mobile apps that way?
The interesting part of Flutter for me is that it powers Fuchsia.
IF Fuchsia becomes a major thing, like the future of Android (and I can't emphasise enough how much it is uncertain right now) then it might become very interesting as a way to publish your new app on Fuchsia while being able to publish it on Android as well in order to support `legacy` devices (again, supposing that Android is abandoned in favor of Fuchsia)
Otherwise, it is 'just' another hybrid solution with the usual caveats.
I also use a cross-platform framework that "renders every pixel". The two major problems I had are the lack of native input and the integration with native ad SDKs. I solved the input with overlaying a native input view on top of everything but it's very clunky and have to be careful to keep it the topmost in the view hierarchy. I haven't found a solution for native ads.
Most of the other things are relatively easy to solve if they come up as actual problem.
In fairness Qt also gets this right: It renders every pixel and it has a fast rendering architecture. Having used Qt, flutter is very attractive to me for the case where you have to work with a team. It can be hard to get together enough people nowadays who will want to work with even a little C++. The Qt libraries make it very easy IMO (most stuff is ref counted) but not everyone is going to buy that.
Qt is one of those things that I've heard of before, but did not know was still used for mobile development today.
The monthly commercial license fee is a bit of a downer though. I feel that a lot of software development agencies (my workplace included) are just not gonna bother with it and just use something free instead.
I agree about the C++ point with you. I have to confess I'm also one of those people who generally want to do things on a higher level. Would definitely give Qt a try if it was free for commercial purposes though.
The free license for Qt is the LGPL, which, although more restrictive than a fully permissive license like BSD or MIT, is still suitable for many commercial applications. (You can't ship proprietary modifications to Qt, but you can ship a proprietary app that includes Qt as a dependency. Your app can use a modified version of Qt if you open source your modifications.)
I use the PyQt Python bindings to Qt for exactly that reason(?) It works very well for my file manager [1].
[1]: https://fman.io
> It renders every pixel
I thought Qt was "native"? That's what's parroted around here when comparing it to Electron.
It's native in the sense that it doesn't bundle an entire Chrome browser runtime with it. But it does not interact with native APIs; it re-implements the native platform's look and feel.
> It's native in the sense that it doesn't bundle an entire Chrome browser runtime with it.
So it's not native.
Live and learn.
https://www.quora.com/What-do-software-engineers-mean-when-t...
> Native (machine) code is code that is ran directly by the processor, in contrast to code that runs on a virtual machine or through an interpreter.
You're applying the word "native" to the wrong thing.
"Native" in the context of GUI frameworks doesn't have to do with code being interpreted vs compiled. It means the framework creates UI using the toolkit that ships with the OS you're targeting. It means Cocoa on MacOS and UWP or WPF or WinForms on Windows.
It means when you scroll past the end of the text in a textbox you get a bouncy effect on macOS just like every other Mac application, because it's ultimately calling the same function that every other Mac application calls.
If someone made a JavaScript library that wrapped Cocoa and UWP, it would be called a "native" toolkit, because it wraps the controls that are shipped with each OS. That's why React Native is called what it is - it's actually creating dialogs and views on iOS with the same functions you would call if you were doing it in Swift.
There are pros and cons. One of my big concerns around something like Flutter is accessibility.
When you render everything on your own you lose the ability to hook into system-level frameworks for accessible content discovery. Their FAQ mentions it briefly but looking at the API support seems pretty sparse.
(disclaimer: I work on the Flutter team)
We're working on accessibility right now, it's incredibly important to us and our users. A big driver here is Google's usage of Flutter. There are business-critical teams at Google right now using Flutter, and they can't launch until a11y is finished. So we're working to finish and ship it. Stay tuned!
At least on Android, it turned out that if you claim that specific portion of the screen is, for example, android.widget.ScrollView, the system believes it. This can be verified with the HierarchyViewer. Some people in Flutter's Gitter group were confused because of this, since they thought Flutter doesn't draw its own widgets. While in fact it was the early accessibility implementation.
> 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?
Another issue is when your customer (or boss) ask you for this very simple feature that's found everywhere ( because it's a native sdk feature) and you suddenly realize you'll have the spend days if not weeks implementing it. I wouldn't be surprised if maps weren't as powerful in flutter as in native android or ios sdk for a long time.
Still, i think the "low level / pixel level" approach that flutter took is the only one that makes sense. You can't abstract away GUI layers like the android one or the iOS one. it's just way too big, and they are themselves trying to abstract away discrepancies between OS versions. I don't understand how could anyone expect to get something of professional quality with a layer on top, knowing how hard it is to get it right even with the default tools.
They are taking on a gargantuan task though..
I’ve been writing a new project in Flutter and so far it’s been dramatically faster than writing an app with either of the native SDKs. The issue you mention here is the key downside though. For example, as far as I know there is no map component or video player. I don’t happen to need those, but if you did it’d be a deal breaker probably.
(disclaimer: I work on Flutter)
Thanks for the feedback. We're currently exploring how to do inline video, which we think will teach us about techniques for inline maps. These are very top requested features. Stay tuned! :)
(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!
Not to diminish your amazing work. I'm not sure brand-first is user-first. Its most user-friendly to use the standard phone OS controls that they are already familiar with.
Thank you for replying in this thread.
Another question. Why is there no desktop support?
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.
Yeah, been there, done that.
The problem with building your own UI toolkit is that you can never make it feel native. You can get 90% there, but it always feels a bit off to the user. The more you make things look like native controls, the more users expect them to act like native controls and tiny differences get amplified.
I'm not sure 100% fidelity to native look and feel is so important to users, as long as the UI is fast, responsive and looks good. Spotify doesn't seem to have a problem with users despite its garish black and green appearance.
You're also only going to get any of the perceived benefits of the choice to build a custom UI kit if you're only solving the same problems that the framework authors were solving.
If you suddenly need, as an example that I've come across, a list of stats to update with a high tick rate which is unusual in an app so no one optimises for it you'll likely find you're no longer anywhere near a native experience.
I know that's not a unique problem with opinionated frameworks, but it's usually a programming issue to solve in the background, not a deal-breaker due to how every customer suffers.
Fair points. It's worth stating though that this only matters if you have a requirement to look 100% native. Many apps don't have this requirement whether mobile or desktop and so they may use a web ui. In our case we didn't have the 100% native requirement and used Qt. We still had a really slick user interface, it just wasn't native.
Note that our customers are primarily concerned about the functionality of the app: They are not drive by consumers, they come to the application because of it's functionality. I understand that not everyone has this kind of customer.
It's not just about the look, it's about the feel.
From looking at the "gallery app" on android:
Flutter's input-text has their own custom mark text handler - no double tap, long press opens a custom menu that is missing native options (Such as translate text).
Changing the font size in the OS does nothing in the app.
Clicking on buttons doesn't make a tap sound if the "sound on tap" option is set.
I'm guessing no accessibility support - or very poor one.
There's probably many more tiny issues that customer's will complain about when you a product is shipped to production that will make it clear that this isn't a native app.
A lot of those are things we've fixed since we published that app. We're just not very good about publishing updates to the play store. I'll see if we can get an update out soon.
(disclaimer: I work on Flutter)
Thanks for your feedback! I opened https://github.com/flutter/flutter/issues/12438 to track the "not playing a sound when tapped". We're currently working on improving our accessibility support.
> 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.
Indeed it is the much harder road to travel. It all depends on who is developing the platform however. Google can pull it off, which is why Flutter is worth considering.
The other issue is if this middle layer decides to stop supporting older os releases. We cannot force the users of our app to upgrade.
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...
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...
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.
>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.
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.
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...
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.
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.
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.
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.
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
Flutter itself seems nice but I can't stand Dart. It's an okay language but isn't expressive enough for a modern language.
> but isn't expressive enough for a modern language.
What do you miss?
Some implementation features related to a few points in comments here so far, from Flutter faq here: 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.
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.
This article could use some serious grammarly love. Its painfull two reed!
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.
Yeah, Snapchat would have been successful if only they used native widgets...
You're insane if you think that most users are like that.