I like and use Flutter myself, I recommend others use it as well if you see other comments in my profile, but one thing that annoys me is that it feels as if the major updates are coming too fast, in a way. As in, they say things like Flutter Web are now "stable" but if you actually use them, you'll find that they are clearly not stable. Windows was mentioned to be stable in the last release, but it too has issues. I am now wary of just how "stable" these macOS and Linux versions really are.
I think the marketing is getting ahead of the actual development of the framework. If parts are truly not stable, why call them stable, if not for wanting Flutter to be in the news cycle every so often?
People are talking about a better developer experience, but hardly anyone is talking about the user experience with apps built with this tech.
I don't feel it's great, especially on older devices. Take google pay, a showcase flutter app. It's a laggy mess on an iPhone SE 2016, whereas the "old" google pay ran perfectly fine. On top of that, many google apps I use these days will just freeze and stop accepting touch inputs. I have no idea if it's all flutter, or just the weird stuff google does on mobile platforms, but other apps don't suffer from this.
I think flutter is good for a resource-scarce team trying to create mobile apps for multiple platforms, but otherwise it creates an inferior end product compared to a native app (let's please not get into the definition of "native", for iOS and Android you know what I mean). For google, who has enormous developer resources, I'm not sure why they would ever use it themselves unless it's for apps they don't care about.
I'd just like to chip in with my (opposite) experience:
I semi-recently developed an app using Flutter and used an iPhone 6, a 6s, and my old Redmi Note 5 as a baseline for performance testing. While I'll admit I wasn't doing anything particularly graphics heavy (at most: sliding modals and some animations), I wasn't able to get things to dip under 60fps on either platform.
As for the GPay app, the only performance issue I could notice from testing just now was a dropped frame while quickly scrolling through the "explore" page. Otherwise it works perfectly on my Z Flip 3.
On the other hand - have you considered upgrading devices? I always hate whipping out the iPhone 6s (same A9 CPU as your SE) because it runs like hot garbage in most cases... a recurring theme in the iOS space.
> I semi-recently developed an app using Flutter and used an iPhone 6, a 6s, and my old Redmi Note 5 as a baseline for performance testing. While I'll admit I wasn't doing anything particularly graphics heavy (at most: sliding modals and some animations), I wasn't able to get things to dip under 60fps on either platform.
I think that's great if you're testing for performance on older phones! Many of them are still quite capable devices. I suspect google isn't doing much of this.
> As for the GPay app, the only performance issue I could notice from testing just now was a dropped frame while quickly scrolling through the "explore" page. Otherwise it works perfectly on my Z Flip 3.
That's a pretty modern phone, right? Have you tried it on your 6 or 6S?
> On the other hand - have you considered upgrading devices? I always hate whipping out the iPhone 6s (same A9 CPU as your SE) because it runs like hot garbage in most cases... a recurring theme in the iOS space.
I haven't, because I think the OG SE is one of the best phones ever made. And I'm not a phone power user in the sense that I'm gaming on it, or doing lots of graphically intensive things. I just replaced the battery on it after using it for 5 years, and it runs everything I want to do perfectly...with the exception of google pay and some of google's other apps.
The issue I have with these basic CRUD apps running with tons of jank is that they're essentially just a UI with some text labels and buttons. For google pay, I want to open it up, navigate a list of people, select one, enter a number, and press "Pay". A computer from the 80s could do this no problem, it's not a graphically or computationally demanding thing. Certainly a computer from 2016 (iPhone SE) is up to the task, and before the google pay transition to flutter, it totally was.
Creating this software that runs slower, with no tangible end-user benefits, is simply pushing us towards more e-waste as people upgrade their devices unnecessarily.
Its equally bad on Google's flagship Pixel 6 Pro. There are three tabs in the gPay app and its about 2FPS as it animates between the tabs. Scrolling is janky.
I find Google’s iOS apps to be thoroughly mediocre and frustrating to use, whether they’re Flutter or not. They just don’t behave like iOS apps.
It’s even worse when you’re in a less common set up, like using an iPad with a keyboard case. I can’t even use the arrow keys to move between search results in the YouTube app.
I know most people don’t care, but it’s the endless little details that make me thoroughly dislike cross-platform toolkits.
I was hoping to see better HTML rendering. Using a single canvas to render web apps was my one turn off. Flutter is the right choice for many apps, but not for apps primarily accessed over the Web.
It is not production ready for web and I don't have much hope it ever will be. I love it for mobile, even desktop apps. But I feel they chose the wrong direction at the beginning for web and it's just trying to dig back out of that hole since then.
For desktop and mobile, Flutter renders over OpenGL, why do they need to embed chrome ?
The websites that are exported from Flutter use the HTML canvas (used for games, animation, etc) instead of trying to generate HTML. This means accessibility and SEO are on existent for those sites. GP is complaining about this.
Although it may render faster, it comes at a cost, as it completely circumvents what browsers are good at.
Flutter is basically just painting pixels on a canvas manually, meaning no CSS, no text selection, no text wrapping, no responsive elements, no elements without JS enabled. Many accessibility tools rely on CSS and text in HTML in order to work too.
It's a huge trade-off to make, and something to be aware of.
FYI there is a SelectableText widget included in Flutter[1] but the developer has to explicitly make text selectable just like iOS and just like Android apps. Desktop is a different story... many text selection paradigms that I'm familiar with on desktop (like double-click and hold and drag to select whole words) simply don't work right. It's not a great experience, but neither is the vast majority of non-Flutter mobile apps when it comes to selecting text too.
wrt accessibility, Flutter does actually generate elements with aria attributes for screenreaders to consume[2]. You're right that the canvas is inaccessible, which is why the aria labels have to be generated adjacent to that.
We're using Flutter for mobile development at my workplace.
This right here should tell you why you shouldn't use Flutter for Web. The Web is pretty great for accessibility out of the box until us devs mess it up, we shouldn't use a technology that needs to completely build it from scratch to get it to work.
I'm going off of memory here but I think it's approximately correct. They were playing around with the idea for a while of creating "virtual trees" to handle accessibility and ultimately had to abandon it for privacy reasons because you would be able to imply that anyone who was using the virtual tree was differently abled and that was a whole can of worms that couldn't be resolved.
I believe the spec you link is a future proposal at the moment. And I trust a consortium of folks from a variety of browser vendors along with folks from other interests over a single product, when it comes to trying to figure out a better way to make things more accessible. And maybe Flutter can just use AOM in the future when it's available in browsers.
As of Feb, 2022:
> While still in draft form within the Web Incubator Community Group, the Accessibility Object Model (AOM) intends to incubate APIs that make it easier to express accessibility semantics and potentially allow read access to the computed accessibility tree.
Are there declarative and performant ways to synchronize a canvas with a DOM tree? Maybe the answer here is obvious but this seems like quite a bit of overhead, both for developers and the browser.
Do they need to be synchronized? I can’t imagine that a screen reader would be sensitive to millisecond-level discrepancies between canvas updates and DOM updates.
I’m not concerned about the delay between updates, it’s the correctness of the DOM and the canvas and managing interactions between the two. I might be misunderstanding the problem (or lack thereof) because I haven’t dealt with accessibility and canvas.
When it comes down to it, I have no idea how you’d indicate something is selected in the canvas and have a screen reader correctly read out the current selection from the DOM. Would DOM events communicate to the canvas how to modify state, functions to call, etc?
How would you manage focus between the canvas element and the rest of the DOM? Apologies if I’m not making sense; maybe there’s a well known pattern people use for things like this.
My understanding of accessibility relies heavily on the DOM behaving as a single document, and the idea of a sort of meta-document within it which coordinates pieces of the documents seems very complex and hard to get right.
Because it destorys native browser features. For example find-in-page, hove to see where a link goes. Right click a link to bookmark, open in private window or copy the URL. If the page has anchors I can get a link to them. If I save or print the page it is an image rather than text (with all of the above features).
Some of these can be reimplemented easily, some of them with effort, but some just aren't possible. Plus the exact behaviours depend on what browser you are using, so you can't reimplement them because you don't know how the user's browser behaves.
For games or image editors this is probably fine. But for most apps this is a huge depredation in usability.
no canvas are slower for UIs. The difference is between immediate vs retained mode rendering, and the later is order of magnitude more energy efficiency and is more performant, for well behaving not chaotically changing content.
I worked with React Native for 3 years before jumping over to Flutter and this was the biggest reason why I made the switch. Its exponentially better on Flutter. The only time builds break for the team are when we made a code change that broke it. Its consistent and non-flaky (looking at you RN). Not that you won't run into the occasional issue but with React Native easily 20% of my time developing was "this just stopped working and there's no reason why". React Native was configuration hell. With Flutter, I haven't struggled with that at all past the initial setup.
This has been my experience with RN too (admittedly, a few years back). So much time wasted on troubleshooting random glitches that occur for seemingly unrelated reason. Some minor library version update? Boom, your breakpoints no longer work. Why? Noone knows. The "turn it off, turn it on" approach seems to be the go-to fix in this environment. And there's always another surprise around the corner.
I can't really contrast it with Flutter, because I only toyed with it a little bit, but at least the docs were of much better quality - and this being a few years back as I said, the fact that Flutter was the newer framework (and still provided better quality at least in this area) was even more pronounced.
I never coded React Native, but I have a lot of experience with Flutter. You can definitely run into build issues, but it's almost exclusively when doing precarious things like upgrading third party packages, SDKs or Flutter versions. As soon as you've traversed the depths of dependency hell and it builds, it builds without a hitch repeatedly in my experience.
As the framework is maturing there have been some major transitions between APIs and project structure. My main app that was scaffolded two years ago has had no shortage of duct tape fixes and tweaks to especially Gradle/Cocoapods config to keep it building.
I guess it's a fair price for what has otherwise been a fantastic developer experience. All in all I'd strongly recommend it.
As someone with a lot of Flutter experience, I can second this. It usually works pretty reliably until someday you upgrade and cocoapods keeps complaining even when you clean everything and rebuild.
For mobile apps (not web), I think yes - Flutter solves a lot of these kinds of issues. As with any project, don't just blindly add a lot of dependencies as they may vary in quality and stability, but overall you deal with two things; Dart and Flutter, and it's quite refreshing.
Not as good as native, but if you're going to go cross platform due to various reasons such as development costs, then it's the way to go.
In case any Flutter engineer/PM is watching this thread, any update on when the Material 3 components will be released?
I have an iOS Flutter app that's getting pretty popular in its niche, but I'm waiting on the Material 3 components to be there to release an Android version.
Maybe I missed it? It seems like they got some working but got a bunch on their roadmap still [0]. I just talked to someone over there and all he could say is that they're working on it.
Congrats! Flutter is such an amazingly crazy concept that when I started my current job it was on the condition that I could learn and use it for our app. I'm not regretting it in the slightest. In fact I get more impressed with it the more I use it. Great job!
I'm not aware of any planned/possible way to do copy exactly as you would an HTML page with HTML tags, but there's a big project to make selection and copying much simpler and more powerful (design doc [1], in progress PR[2]).
With that PR it should be easy to just add one SelectionArea to the root of your app in order to make everything selectable, like it would be on a web page. You don't need SelectableText widgets. There's an example of this in the PR [3]. No built-in support for multimedia or rich text copying yet though.
Text input fields should already do copy/paste pretty much the same as native.
Kind of crazy all this effort is being put into just recreating something that has been around, and works fine, for 20 years. What a waste of resources.
Does Flutter have a complete Material UI components implementation? I'd prefer to use Flutter for multi-platform support over learning new Android Compose and figuring out what to do for other platforms later.
Does anything have a complete Material components implementation?
I always got the vibe from Material that it's just a bunch of designers pumping out docs for an ideal world, and then the various libraries try to implement a bunch of those things as they change faster than they can be implemented.
Indeed. It wasn't that long ago that Material components for Android finally got proper support for Material 2 in a stable release of the library. But everything started too look too nice and consistent, so now we're getting steamrolled with Material 3.
I'm not sure I can say it's complete but it's better than Android in my experience. There's also more built for you already, like button styles and page layouts.
Thanks for sharing! The design looks really slick.
As a hobbyist Flutter developer who hasn't figured out how to make Flutter apps look remotely appealing yet, it's been cool poking around your code and trying to learn from it. Bloc and Cubit look especially interesting.
thanks! here’s another Hacker News client made with Flutter from another dev that has a much better looking UI, but it is only available on FDroid. (though you can build it yourself for iOS):
Not sure if you’re new to the Flutter / Dart ecosystem but one of the nice advantages that comes as a side effect of having “Google scale” backing it is how nice the upgrade experience is.
Generally you just run a single command of dart fix and it will statically analyse the code and automatically rewrite anything that’s outdated to use the latest syntax for you.
This is really nice for testing. It uses most of the pretend-native components I was interested in.
Right off the bat, I notice stuttering animations everywhere: Scrolling, swiping back, etc... This is on an iPhone 13.
In one section, the keyboard opened on top of a text-field so I couldn't see what I was typing.
The components are _just_ different enough that I feel something is wrong, but for the most part, I can't tell what it is.
Then there's a bunch of minor stuff. Switches become slightly larger when they change. You cant swipe down modals. You can't drag & release over options in the sheet. I feel like I'm missing buttons more often.
Overall, I get a vague cheap feel. Not so bad that I would outright dismiss the app as a customer, but I would definitely look for alternatives.
This isn't a critique of the app. I think all of these issues are flutter-related.
Just trying to be honest here, but using this as an example on my iPad Pro with magic keyboard... flutter apps do not feel great on iOS IMO. Animations have an initial low fps/jerkyness to them. Lot of weirdness when trying to use an the iPad trackpad, horizontal directions seem to be inverted. Scrolling inertia and feel just feels off in general to me. I'm sure flutter is great on Android and all but it still feels like they have a bit of work to do on iOS in order to really cross that uncanny valley gap.
Regardless I'm sure what you have is a great app here so hope you don't feel like I'm targeting you or your app directly here, and at the end of the day if flutter allows you to make your customers happy more power to you and hope it works out the best for you.
Doesn't appear to based on the website, which is just sad considering it's almost zero effort to create an Android build as well. I'd consider using this app also.
I could indeed build it for Android, but since I'm using the Cupertino components, it would look and feel like an iOS app. As I said replying to the parent comment, I'm currently waiting on the Material 3 components to be available before I do that.
Sounds good, although a bit sad I can't try it out, even if it felt more iOS-like. But you gotta prioritize your app and what's best for it. Good luck!
Every action requires waiting. Its so frustrating. Open the app, spinner. Click themostat, spinner. Change the temperature, spinner. Its so frustrating. I use Home Assistant now as my primary home control app.
Coming from a django/python background, flutter/dart was easier to understand than react/js. It has been fun to work with, esp. with Vscode and extensions, on a side project.
Flutter is a mature option for mobile development, esp. for small teams developing for multiple platforms.
as an early and aggressive adopter of Google tech it was completely infuriating to watch them announce Flutter + Firebase integration as if it was new or interesting.
that should have been working day 1. maybe day 2. flutter has been out for years, and the fact that you can’t successfully use Google software with Google’s other software is starting to be a wart they can’t excuse because of internal build chain differences.
Ha nope, just occasionally playing around with it. No video acceleration, but still usable for web browsing and development. It's amusing to drag a window around and see all the CPU cores spike to 100% as they frantically pretend to be a GPU.
From their What’s New: “ Flutter now supports variable refresh rate on iOS devices with ProMotion displays, including iPhone 13 Pro and iPad Pro. On these devices, Flutter apps can render at refresh rates reaching 120 hz, which were previously limited to 60 hz. This results in a smoother experience during fast animations such as scrolling. See flutter.dev/go/variable-refresh-rate for more details.”
Not yet, but they have a beta thing that you can enable to smooth that out
> Impeller precompiles a smaller, simpler set of shaders at engine build time so that they won’t compile while an app is running; this has been a major source of jank in Flutter.
That is a reason to avoid cross platform frameworks. But there are big reasons in favour of using then as well. It's a trade-off depending on your use case.
For the vast majority of (mobile) apps, the benefit of being able to be built from a single code base outweighs being slightly behind vendor capabilities. Particularly things like there where it doesn't come up in some apps and relatively few people actually notice/care about it in those it does.
> The company’s official guidance to past developer users is to “follow Apple’s Human Interface Guidelines and consider using modern UIKit components or SwiftUI instead.” That said, it also plugged Flutter as the way to “get a Material look and feel across all platforms.”
Doesn't seem like the article you linked accurately represents your statement.
This wasn’t anything to do with Futter for the record and they even called it out in a quote saying that they continue to recommend Flutter in that article.
I haven’t really had a great experience with Flutter in the past, in my opinion I think React Native provides a better user experience. Developer experience is okay.
The best experience for users would be a library that handles business logic, as well as describes how the UI should be laid out, then building native clients that use that library.
I found it a bit difficult to work with, and I also wanted to code my UIs from the back-end. So I wrote DocUI which will be released in the next month or two. https://nexusdev.tools
@tosh submits a great amount of posts. Most do not reach a great audience but a number do, and he has gained a large amount of points in a short time (despite being from 2010 he has only started this mass-posting recently). What's that about?
I have an irrational annoyance when projects claim to support "desktop UI" but then only have the most trivial of widgets commonly used in desktop applications. Where is my tree view? Data grid view? Charts? Native file dialog window?
From my perspective, while I'm sure Flutter is wonderful, it fits squarely in the "mobile" UI toolkit and "basic" desktop application category.
Hey there! I work on Flutter for desktop. I'm happy to provide a little background.
We made a decision early on to focus where those of us who work on Flutter could deliver the most value, and for Desktop that meant getting the runtimes and platform integration for each of the desktop OSes in good shape (international text input, accessibility support, rendering performance, etc.) as well as core integrations like the menu bar, file chooser dialogs, etc. These are things that need to land in the runtime itself and are significantly more painful for the community to contribute, or author and publish on pub.dev.
We're working on filling in the gaps for widgets that are part of the Material spec, and I expect the community to make and publish widgets on pub.dev that continue to surprise me; I'm blown away time and time again at the beautiful widgets and the community continues to produce either in packages or as pull requests. You should be able to find community-authored packages for treeview, datagrid, and charting on pub.dev today in the meantime.
With limited resources you have to choose. If flutter focused on UI elements before Mac OS + Linux stability, the top comment would be "Flutter is a solid option for Windows but without Linux or Mac support it is useless."
The flutter team has proven generally capable of developing UI elements on mobile across iOS/Android. Getting platform stability is a welcome step and i trust them to continue to build out the desktop element set.
Flutter has been my go-to for mobile app dev for years and i haven't considered returning to react native, pure native or cordova since i swapped.
All that being said, i have spent my afternoon debugging an issue with Flutter's first-party camera plugin, so it isn't all roses.
This is a big gripe I have with WinUI. How on earth do you create a desktop UI framework that lacks something as basic as a tableview/data grid… it's only slightly less bad than a UI framework not having a button widget. One should not need to import a third party dependency or write your own for something so basic.
I'd love to see a "Back to the Future" desktop UI toolkit that has roughly the capabilities of AppKit circa 2003 but in a modern language, clean unified API, cross-platform, with seamless native UI integration, and of course not carrying hundreds of megabytes of Chromium gunk in each app like Electron does.
That would be wonderful. AppKit is the closest to perfect I've found in desktop UI frameworks. If it took some of the improvements found in UIKit and was cross platform I'd never use anything else.
I think a tree view was promised (listed on a presentation) when Flutter 2.0 was released, but no details were provided, and I haven't heard of it ever since.
You might be thinking of this package, authored by Google, mostly by people on the Flutter team but it's not an official Flutter project (as far as I know): https://pub.dev/packages/flutter_simple_treeview
who builds desktop applications anymore? it feels weird to say but i am starting to like them again after transitioning to basically 100% thin client/cloud services for the past 15 years.
I did in the early days when the web sucked, then dhtml and web2.0 started and I completely swapped. Now I'm starting to again. I like them more the web apps. But no one is making them anymore
What qualifies as a "desktop application" these days?
Is it any application designed primarily to work on a laptop or desktop form factor? A web application like SketchUp would qualify.
Is it an application whose code is only stored locally, even if they don't work well with a laptop/desktop form factor? Any number of native mobile apps would qualify.
What about a PWA that is cached locally but initially loaded via a URL?
Rows [0], a spreadsheet app, has its Windows and macOS versions built in Flutter. It's quite fast from my usage. The marketing video they did for Flutter [1] goes into a little detail as to how they did it but they also have a tech talk that goes into more detail [2]. Their spreadsheet engine is open source as well [3].
Google Flutter Team: You launched Flutter Desktop and got your promotions. Now can you please go back and finish Flutter Mobile? Specifically, please add:
- Integration testing [0, 1]
- Location [2]
- iOS dark mode [3, 4]
- iOS keyboard dismiss decoration [5]
- iOS keyboard scroll-to-dismiss mode [6]
- iOS NavigationLink widget [7]
- iOS checkbox widget [7]
- Android camera that doesn't randomly crash (unfixed for 3 years) [8]
- Android date-time picker (Requested in email to Flutter Team. They refused.)
- Usable documentation for Navigator 2.0 [9, 10]
- Debugger visibility into Dart async tasks
- Stop HTTP requests on timeout [11]
- Testing on physical devices for apps that use flavors [12]
- UI inspection tools that don't randomly stop working
- iOS keyboard dismiss decoration - Not sure on this.
- iOS keyboard scroll-to-dismiss mode - This is trivial to setup, just listen on scroll and hide keyboard. You could even create a generic handler that can be reused everywhere for this.
- iOS NavigationLink widget - Not familiar with this construct but easy to build yourself.
- iOS checkbox widget - Totally agree but also easy to build directly.
- Android camera that doesn't randomly crash (unfixed for 3 years) - We've got a couple application that use camera and never had this issue.
Just an additional note: Integration testing was indeed completely broken for a while, with the docs stating otherwise. They reworked it a few releases ago and since then it works well for us (limited usage, but completely stable for what we do with it).
Do you have tests that run on your host machine, can start an API server and interact with it, and also drive the Flutter app? Or do your tests run on the mobile device?
The tests run on the mobile device, or rather mostly the emulator. No API server to interact with (and I would not know why?). The shop uses integration tests for three things: 1. Testing some migrations 2. Click through the app, as part of a release checklist 3. Run crypto operation to check multiple plugins for continued compatibility.
Integration testing supports only running tests inside the device. If your test needs to start an API server, then you must use the deprecated and broken flutter_driver module. See the bug I linked.
Flutter's Cupertino dark mode support is broken. Some text is invisible. Some widgets are unusable. Cupertino Dark mode theme support is completely absent. See the bug I filed, with a comprehensive reproduction with screenshots. It's like the dev who added it just decided to stop half-way.
> - iOS keyboard scroll-to-dismiss mode - This is trivial to setup, just listen on scroll and hide keyboard. You could even create a generic handler that can be reused everywhere for this.
Please use an iOS device and notice how nicely one can dismiss the keyboard in iMessage, FB Messenger, Instagram, etc. Getting that behavior in Flutter requires using a third-party package.
The Material date picker is not a date-time picker. Letting the user pick a date & time requires a lot of extra code. For example, I spent many hours writing a widget that displays the date & time and lets one click to change it, like in Google Calendar.
See the bugs I linked about Navigator. The docs have multiple omissions. I lost a day and a half on them.
Yes, you can debug tasks with a breakpoint. You cannot see which async tasks are running. You cannot pause a task. I needed to debug concurrent RPC problems and tried using print. Unfortunately, print provides no visibility into tasks running in standard library code, like timed-out HTTP requests that continue running.
You can timeout waiting for an HTTP request to finish, but the request still continues in the background. If it's a large upload then it can continue for minutes, draining the device's battery and transferring data. See the bug I linked.
> - Testing on physical devices for apps that use flavors - We do this regularly across 5 different flavors on both iOS and Android.
How do you install on iOS? I tried `flutter build --flavor staging --release` and then `flutter install` which fails saying that I must supply `--flavor`. But when I supply `--flavor` it says the parameter is not supported. See the bug I linked. I spent a few hours and figured out how to first do a Flutter build and then use XCode to build again, then use Devices & Simulators to manually install the archive. But this requires that I remove the app from the device first, which destroys the app state. This makes manual testing extra slow. The process is noxious.
Flutter Inspector in Android Studio on macOS breaks 1 out of 5 times I try to use it. I often waste a few minutes trying to figure out why my code changes did not have the desired change on the widget tree. Then I finally realize that the widget tree pane is broken and I need to restart Android Studio. It's been like this since 2018 through multiple upgrades of Flutter, Android Studio, and macOS.
The only way I will get what I need from Flutter Team is if Sundar fixes the company's incentive structure to align employee incentives with long-term profitability. I do not expect that will happen. But if it did, I would probably immediately go back to work at Google and buy Google stock.
I think the marketing is getting ahead of the actual development of the framework. If parts are truly not stable, why call them stable, if not for wanting Flutter to be in the news cycle every so often?