Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere. Apart from Qt , but the licensing issue is a hindrance. And yes, the web backend isn't ideal, but it will improve over time.
I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages.
Dart isn't horrible and is getting better, but it is still a somewhat awkward mish mash of Java and JavaScript, and I don't really enjoy using it.
The only reason to use Dart is Flutter, which really hurts ecosystem health / library availability and prevents code sharing with the backend.
I have been developing in Flutter for a few years now, and I really enjoy the ecosystem. It is the only mobile development environment I have every really enjoyed using.
When I started, flutter worked on mobile, and web support was in beta. Now, my app works on iOS/Android/MacOs/Web. If you are a small developer with limited resources for cross-platform development, its an amazing environment.
As for Dart, it is actually one of the things I like most about flutter. I really like the parameter passing/naming syntax. It is flexible and expressive. If you are looking for something that will challenge all your basic assumptions about what a language should be, you'll be disappointed. But if you come from any c-syntax background, you will pick it up almost instantly, and find a lot of nice ways to make code more concise and maintainable that previous languages.
In my experience, Flutter is a great environment for getting things done with limited resources.
Is the Web version of Flutter still using canvas? I tried it a while back and it was just a canvas rendering everything. That makes SEO impossible. It's also useless for accessibility/screen readers. Please correct me if I am wrong.
I thought I would hate Dart since it seems like such a bland language but after working in it for a year and a half its easily one of my favorites. Its straightforward and tailored directly for Flutter's use-cases. It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages. It is also incredibly readable without hiding how it works behind decades of syntactic sugar. All that to say, I definitely see how it can be disliked and I also disliked it when I started working with it but it definitely grew on me.
> It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages.
Doesn't this mean that you are currently simply in the sweet spot where the language is usable but also not bloated yet? As in, it could all change in a decade and therefore isn't an intrinsic quality of the language itself, but merely the passage of time.
I recall this blog post exploring the possible correlation between the age of any programming language and the developers' disposition towards it: https://earthly.dev/blog/brown-green-language/
I was enjoying the frog book (The Dart Programming Language, Gilad Bracha & Erik Meiker) but that was 2015, and now very out of date. Its strange to see there is no up to date book from major publisher, like the Rust book at https://doc.rust-lang.org/book/
Picking it up is really easy if you have any experience with Java or C# and the QOL improvements compared to the former make it seem like a treat for me. What language are people who hate it coming from?
> Flutter is the only realistic option for true cross platform UIs that run everywhere.
I understand that argument but 100% disagree. The web is the cross platform that runs everywhere (as in in a browser or webview). True it has many issues and some forms of it (electron) are not ideal for some use case but I believe it’s a better platform than flutter in almost every way.
You say “true” cross platform and could argue that the web isn’t “true” cross platform. But really is anything?
I have yet to see a world in which local file access, background services, local notifications, timers, alarms, native media controls, etc, works as well on web as in native apps. A lot of it is there "in theory", but web tech has the achilles heel of only allowing stuff that would be safe to have in a random website that some asshat links you on twitter.
Of course this is only relevant if that deeper plumbing into the OS is needed, and of course it's quickly changing. Perhaps the day comes when web apps can truly be first class citizens in all major OSes, but it ain't here yet.
This 100%. Also, Flutter Web is still pretty much an abomination (right now), IMO. Sure, it "works". So did Flash. (edit: Just wanted to add, I love Flutter for mobile, even think desktop might work. Just don't think it's for web. Maybe for very specific app types.)
> The web is the cross platform that runs everywhere (as in in a browser or webview).
I understand that argument but 100% disagree. Development is horrible, it's anything but standard, comes with a lot of baggage, the performance is atrocious. It doesn't even run anywhere, it runs in a browser. A huge, bloated, hungry browser.
You say Electron is not ideal, I say it's the worst thing that had happened to desktop computers ever. It's bad for the planet too. Some argue that without "js on desktop" we wouldn't have these amazing apps. I think it's not worth it to have those apps if they are built using those technologies. They make me miserable every single day. It's the only thing that forces me to upgrade my computer. It's so bad. Things that were possible 20 years ago are suddenly an unachievable goal. Stop it.
I came here to say this too. Build your app as a website, then just use a simple browser window of an app that loads your site. Then you only develop in one place, and have nothing to compile or build. Hardly ever have to update your "app" builds even. This won't replace every app of course depending on what you're trying to do and if it requires specific hardware features, but I'd say about 99% of apps don't need to be native.
> The web is the cross platform that runs everywhere (as in in a browser or webview)
Yes, but the web is crappy system for designing UIs in.
As a community we've got good at designing UIs with web technologies (HTML+CSS), because we have no other choice if you want to build web-apps. But the level of experience we've gained with those tools has hidden the fact that they have some real issues - mostly due to the fact that they've developed piecemeal over many years. Getting the layout of your page to behave correctly under all the circumstances it needs to requires a lot of experience with CSS, a lot of simple page behaviour we'd now expect as users require adding JS sprinkled around (and I'm not talking app logic, just UI logic).
I freely admit that I'm not great with CSS - I'm not a web developer although I have done some web development. If I do any at work (e.g. web UI for embedded device) I need a pro to come along and make things look nice. But when I did app development in Flutter it took about 2 days to be able to build screens that looked good, did complicated dynamic behaviour, and behaved reliably regardless of screen size and shape.
I wish this were true, but in my (admittedly limited) research I'm not sure it is.
For one, you mention Electron. That targets all desktop platforms, but not mobile. Mobile development from webapps is absolutely possible, but you need to use something else for that. Meanwhile, on the flutter side of things, if you want to target desktop platforms, you use flutter. If you want to target mobile platforms, you use flutter. There isn't a need to learn a whole new framework to target a new platform.
Aside from that, local file storage and offline use can also be a bit finnicky with Electron. Absolutely possible, but its another thing you have to figure out that Flutter just does by default.
If I'm wrong on any of this, please do let me know, I know web dev far better than I know Flutter so it'd make my life a lot easier, but the above reasons are why flutter hasn't budged from my todo list
Other than what sibling comments said, I have to add that flutter is much more approachable for new developers than web is. Most widgets are built-in, and development workflow is also simpler. This is what I heard from college students.
"I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages."
Exactly. Dart is a deal-breaker. I was tasked with choosing a cross-platform development solution, and rejected Flutter because nobody at my company (including me) knows Dart or has time to learn it. Nor would any contractors we were likely to find know it.
After quite a bit of research on other potential solutions, I determined (as did a crowded and lengthy thread in this forum) that Qt was the only viable one for now.
The recent proliferation of languages has been pretty annoying. Google should have at least used Kotlin. Alienating their own community of Android developers and making Flutter a pain in the ass to integrate into a development organization was dumb.
The other problem people cited with alleged cross-platform solutions is the need to write native code anyway if you need access to system/hardware resources (Bluetooth, USB, what have you).
I think that's pretty short-sighted. Dart is hardly an esoteric/niche language like Haskell or Futhark, anyone familiar with Java/Javascript/TypeScript should be able to pick it up in a day or so.
Flutter's performance issues, on the other hand, is a separate story.
Flutter and Dart seemed to have been internal tools built by engineers looking for an interesting project to spend their time on while at Google.
Kotlin swelled up around the limitations of Java 8 in outside organizations and took over the ecosystem so Android devs could be productive while Google was fighting with Oracle
I wrote extensive amount of Dart without even reading documentation and any prior Dart experience. Knowing dart is never an issue if you know basic Java/Php/JavaScript.
The only thing I really hated about Dart was poor enum support. Now that's fixed.
> Dart isn't horrible and is getting better, but it is still a somewhat awkward mish mash of Java and JavaScript, and I don't enjoy using it.
All anecdotal:
I've only met one person who was excited to work with Dart, huge Google fanatic/fanboy. Otherwise it's sorta seen as a unique language choice that makes other devs go, "oh..."
The Java/ECMA ergonomics are weird, it's hard to find devs who have experience with the lang, and due to the language popularity there's a lot less community/3rd party deps available.
I really tried hard to give it a fair shake back in the day but I just ended up sticking with Node (and now +Deno), Typescript, or Go if I need performance/types. There are way better ecosystems around these and I find the tooling/ergonomics much less awkward. Also, if/when I need to hire devs onto my teams I will have a much easier time.
Also, I can actually write a serverless function in these tools (GCP Functions, AWS Lambda) - as far as I know there's nothing like this available for Dart.
---
EDIT: It's worth mentioning I've only had Dart jammed down my throat on the backend (API's, data transforms, jobservers, etc). It may be a fine tool in regards with Flutter, but it felt like a really awkward tool for where it's come up in my career.
As an early Flutter adopter, the ecosystem was a big problem, and while it seems to have progressed, it's still pretty anemic compared to other language's ecosystems.
I still maintain that Flutter Web is not production ready. It could have a nice niche, like games. But for real apps, it's just not as good as web. They are still re-implementing things that have existed in the web for ages, and are not going to be able to keep up. It's basically good for an applet style usage IMO. I'll keep trying it out, I think Flutter is pretty great for mobile, even desktop, but every time I use a web app example I find issues and just shake my head at what they did.
FWIW I kind of agree and I’m a big fan of both Flutter and the web in general.
There are a couple of web platform technologies that I think are going to take Flutter web from ok to great in the next year or two including.
WASM Garbage Collection is going to allow them to move from compiling to JS to WASM. They have already built a WASM compiler ready to go when it lands.
WebGPU is another obvious one. Flutter is by definition a canvas optimised framework rather than strictly DOM based (although they support that too as a target). But they should be able to get blazing fast canvas rendering with those two technologies alone.
The other big one that I think will help them is going to be AOM. Lots of the built in browser accessibility stuff was built for a DOM based world, the web platform needs better primitives to support canvas frameworks too.
The way it atleast used to be framed is that web is a fallback target. Meaning if the target device isn't running Linux, Windows, macOS, iOS or Android (unlikely), then hey, you can atleast build a passable version that will run in a browser.
I don't know if this has changed, but I know only a mad man would try to build a proper website in Flutter. It's not the tool for the job.
I think the decision of which cross platform technology to use mostly depends on a team's preferred tech stack.
C++ -> QT
C#/.NET -> MAUI/Blazor
JS/Web -> React.Native/Electron
Dart -> Flutter
This is what I think is holding back Flutter -- that it wasn't built on an incumbent technology. Because Dart doesn't have quite the following, it has to evangelize itself a bit more than the other options.
That's the thing. Dart is useless for my preferred style of programming. A modern language without ADTs and pattern matching is not even meeting my bare minimum for acceptable to use. Not just this, but the docs explicitly said the don't want these basic features.
It's not remotely a realistic option. CJK is all second class citizen. I just tried their latest demos. Tried to enter 日本. It utterly failed. First it's still trying to draw on it's own so you get to see some placeholder □ while typing. Then, it effup and typing n-i-h-o-n kept producing Nいほん on this example
Thanks for reporting this. IME-based input is super important to me -- we only speak Japanese at home. I've filed a bug [1].
I manually tested on each of Windows, macOS, Linux, and iOS (where I've done a lot of work specific to CJK input) and was able to correctly input Japanese, Chinese, and Korean text [2], so looks like this is likely an issue specific to Flutter's web runtime. I work on Flutter's desktop embedders, but if there isn't someone who's a heavy IME user on the web team, I'll gladly give em a hand to help get this fixed.
> Apart from Qt , but the licensing issue is a hindrance.
Most of Qt is available under the LGPL. Some application specific libraries are available under the GPL, but there's no reason you'd need to use them unless you have special use cases that their libraries would make easier to handle.
> I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages.
Agreed, I figured that was the direction Flutter was going to go, with wrapper APIs for other languages, but it seems it never happened.
Dart is okay, but it's not a language I'd choose to write anything in. The only reason to use it is because of Flutter, as you've said.
In practice, it isn't just UI code that ends up getting written in Dart + Flutter, but the entire application and client code, excluding things like REST backends.
With Qt's QML, you're very much just writing UIs in QML and JavaScript, leaving a clean separation between the UI, core, and application and client code.
We just built a desktop app with QML in a CMake-based Qt project, and I've been pleasantly surprised by the experience.
Our brief experimentation with Qt Widgets, on the other hand, revealed a shocking level of dysfunction in basic UI-layout implementation, in what is supposed to be a very mature UI toolkit. But it seems that they're basically abandoning Widgets at this point, so ¯\_(ツ)_/¯.
I've had to bounce around from Mac, Windows and Linux for work, the main programs I use everyday are all Electron based (Postman, VS Code, Spotify etc), they all behave basically the same just everything is slower in Windows on my laptop. Egui (immediate mode GUI) and Tauri (like Electron but Rust backend) have worked well cross platform just messing around with them, but I haven't used any big apps yet to know for sure.
Flutter and Dart have co-evolved to the extent that separating them would be difficult.
One problem would be expressing the Flutter API as a Go API. For example, Flutter has lots of constructors with lots of keyword arguments. Flutter is doing things with keyword arguments that would be expressed as props in a React-style UI. A similar thing happened with JavaScript and JSX - while you can write a React-style UI without JSX, you probably wouldn't want to.
Maybe you could define props using structs in Go, but the result would be awkward, particularly because Go doesn't have an easy way to bulk-copy fields from one struct to another, like you do with spread arguments in JavaScript.
Also consider that Flutter uses class hierarchies extensively and Go doesn't have inheritance.
Maybe look at how web development is done in Go when it's compiled to WebAssembly. Is that how you'd want to do web dev?
> realistic option for true cross platform UIs that run everywhere
I switched from Flutter to JUCE and haven't looked back. Its a far better user experience, and a far better developer experience too.
People often overlook it, because its pitched as a framework for Audio developers, but the work to make a truly operational cross-platform GUI has pushed it into 'suitable for normal application' territory, imho.
Anyone looking to solve the platform issue would be very wise to do a few workbench sessions with JUCE, and to a lesser degree, the Godot gaming framework as well. These are perfectly cromulant ways to build high-performance, cross platform, accessible applications...
I quite like Dart. I can't remember what they're called, but I remember it has something that lets you declare a stream (actually, maybe that's what it's called) that I thought was pretty ergonomic.
> Flutter is the only realistic option for true cross platform UIs that run everywhere.
Do you really want cross platform everywhere? You might want it but what you inevitably get is something that is huge and just okay everywhere instead of something truly great anywhere. Is that a trade off you are happy with as a user?
That said, I do happily use a couple of cross platform applications. PyCharm and SublimeText which are great and Fusion 360 which is powerful but awful to use.
I disagree, Flutter is probably the worst choice. React Native is the all around best choice for targeting all platforms natively, otherwise use pure web tech (Ionic + Electron)
The desktop and web targets for Flutter are laughable in their current state. Completely unusable so I consider Flutter to be a mobile only platform at this time.
Another downside is Flutter's emulated UI, it doesn't bridge to native controls like React Native, it's noticeable on iOS especially and will be hard to maintain the fake physics / styling.
React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst.
Then there's the question as to why would you choose a Google only language and framework with their track record.
With React you can use TypeScript or JS, you don't have to learn a new language or get locked into a framework.
Every experience I had with React Native was truly horrible.
Gigantic, messy JS dependency tree. Constant build breakages after minor version updates. Random flakiness. Unmaintained or buggy native plugins. Questionable support for issues that didn't affect FB.
> React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst.
All platforms ... except Linux. React-native-gtk is abandoned as far as I know.
How is it not a problem if you want to sell closed-source software? I guess you can dynamically link desktop applications (although I'm not sure how this works in Apple's Mac app store), but you can't do that with mobile apps.
I tried Flutter in 2020 for a side project but decided not to use it. It felt clunky and slow. I later ditched the side project also since I decided to not build any mobile Apps for now. Maybe I'll revisit Flutter if I ever consider building a mobile front end for any side-projects.
There's definitely competitors opening up and realizing the space is worth the investment. C# Maui for example, especially with Blazor, is extremely cross platform as well(including web), but it has full party support in C#.
Take a look at this video from the team that talks about this exact topic. After watching it initially it became very obvious to me why and I agree it was the right choice https://youtu.be/J5DQRPRBiFI
TypeScript isn't a language that can compile to machine code. It must be converted and distributed as JavaScript bundle, which is slow compared to Dart.
Ionic is pretty awful too, though I can't fault them. It's just that papering a web interface on top of a native app is gonna be a poor experience no matter what.
Runs on Mac, Windows, Linux. Delivers on all three, plus iOS and Android. The underlying language is patterned after HyperTalk and people either love it or hate it, but I haven't seen any other tool where you can open the new installation and within 2 minutes deliver single-file executables for three platforms. (Disclosure: I build a developer tool for Livecode)
I was recently tasked to build a mobile app at my work, that would have maybe 5% of the feature-set of our gargantuan web product. However, this 5% was mission critical. Coming from React-TS, building with Flutter was a bit weird at first (where's my CSS???) but the productivity gains came quickly. The Pub ecosystem is fairly mature, in that all the third party packages are pretty high quality and address most common use cases. Unlike npm where there are 10+ solutions for the same problem, there will only be one - maybe 2 in Flutter land.
I was very pleased to find out, that Flutter supported web as well. Now, it's not as good as mobile yet - some of the animations are render blocked by the JS main thread - but it is a very nice 'middle' solution to somebody who needs to use the app who doesn't have iOS or Android (for example, Surface tablet). Also great for internal testing - push up the latest changes to a dev web environment, and everyone can test without installing APKs or using TestFlight.
In my use case, I was actively discouraged against making something that looked beautiful or pretty - the software is designed to be spartan, minimalist and essential. Flutter is perfect for that.
All in all, Flutter is awesome. Is it the right answer for everything? No. But when you only have one developer to spare whose job it is to build a mobile app, it's perfect for that. The web support is a nice bonus - haven't tried any of the desktop stuff yet.
Dart, as a language, is nice. Not spectacular, but certainly tidier than Java or JavaScript. I've gotten used to functionality programming, so writing everything in classes was jarring at first.
Having used Flutter web in production, I would overall advise against it. It can be brilliant for building forms with elaborate validation logic - and quickly so, but once the site gets heavier and you add more complexity to it, the more issues will pop up. There are still major issues they haven't sorted out yet like occasional odd behavior with input fields and autofocus on Safari etc.
I'm also used to functional programming. The only thing I can not stand about Dart is that types are coupled to classes. If you want to use stateless functions and typed data shapes, you're out of luck. Compare this to TypeScript that truly allows both paradigms and has a very expressive type system.
Doesn’t `typedef` let you specify arbitrary type aliases for pretty much anything in Dart? Or are you talking about something else? For my own curiosity, can you provide an example of Typescript vs Dart in this case?
Flutter 3 comes with an upgrade to Dart 2.17 [1], which has quite a few improvements as well... including state on enums.
While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants.
Well, at least there's quite a few other small but useful improvements... and they showed how they really listen to the community by implementing the new syntax for passing on constructor parameters to a super-class... and by improving the docs of the 200 most popular packages with lots of examples, as requested by the people.
I like how they're listening to the community as well to implement meta-programming (like macros) [2] to solve the main pain point, currently, in Dart, which is how verbose it is to generate code for things like serialization and data types.
Once they get that, Dart will be a really good language to work on (it's already quite ok IMO, despite most people, usually those who don't actually use it much, hating on it).
> While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants.
Yes, the enhanced enums we shipped in 2.17 are like Java enums.
I say "style" here because object-oriented languages like Dart can already mostly model sum types using subclasses. What you need to get the rest of the way there is basically just:
1. Sealed types so that the compiler can check for exhaustiveness when you match over all of the subclasses.
2. A nice pattern matching syntax to let you discriminate between the subclasses and destructure them.
3. Ideally, a nice lightweight syntax for defining a sum type family as a superclass and set of subclasses, though this is relatively less critical.
We're hard at work on this, but pattern matching in general is a pretty large feature and retrofitting it into a language whose syntax wasn't initially designed around it is a challenge.
I'm very excited about macros too. That's another large, difficult feature, but one that I hope will provide a lot of power to users and make the entire ecosystem more valuable over time.
Any thoughts on the freezed package [0]? That's what I use currently for ADTs and exhaustive pattern matching on them, would be cool to see similar syntax in the official implementation.
That feels like quite an awkward way to squash tagged unions into a class structure... But maybe it will work. I would say special syntax for it probably is critical because defining an entire class for each variant does not sound like fun!
> While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants.
As much as I like Rust’s enums, I think they messed up on the naming. Java (and according to your comment, Dart) gets enum rights. What Rust has under this name is sum types, which is a separate (more expressive) concept and the two only correspond with each other in the case of a sum type where each component is of a zero-arity type.
I disagree. "Sum" and "product" types are really really unclear names that only make sense if you've studied some advanced CS and even then they're bad names - not descriptive at all.
Enum is much better - you just enumerate all the values the type can be (plus optional associated data).
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.
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.
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.
Readit News
I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages.
Dart isn't horrible and is getting better, but it is still a somewhat awkward mish mash of Java and JavaScript, and I don't really enjoy using it.
The only reason to use Dart is Flutter, which really hurts ecosystem health / library availability and prevents code sharing with the backend.
When I started, flutter worked on mobile, and web support was in beta. Now, my app works on iOS/Android/MacOs/Web. If you are a small developer with limited resources for cross-platform development, its an amazing environment.
As for Dart, it is actually one of the things I like most about flutter. I really like the parameter passing/naming syntax. It is flexible and expressive. If you are looking for something that will challenge all your basic assumptions about what a language should be, you'll be disappointed. But if you come from any c-syntax background, you will pick it up almost instantly, and find a lot of nice ways to make code more concise and maintainable that previous languages.
In my experience, Flutter is a great environment for getting things done with limited resources.
Doesn't this mean that you are currently simply in the sweet spot where the language is usable but also not bloated yet? As in, it could all change in a decade and therefore isn't an intrinsic quality of the language itself, but merely the passage of time.
I recall this blog post exploring the possible correlation between the age of any programming language and the developers' disposition towards it: https://earthly.dev/blog/brown-green-language/
Deleted Comment
I understand that argument but 100% disagree. The web is the cross platform that runs everywhere (as in in a browser or webview). True it has many issues and some forms of it (electron) are not ideal for some use case but I believe it’s a better platform than flutter in almost every way.
You say “true” cross platform and could argue that the web isn’t “true” cross platform. But really is anything?
Of course this is only relevant if that deeper plumbing into the OS is needed, and of course it's quickly changing. Perhaps the day comes when web apps can truly be first class citizens in all major OSes, but it ain't here yet.
Nope, The web is The Platform. And while it offers numerous benefits it has plenty of flaws / inability to do some things as well.
I understand that argument but 100% disagree. Development is horrible, it's anything but standard, comes with a lot of baggage, the performance is atrocious. It doesn't even run anywhere, it runs in a browser. A huge, bloated, hungry browser.
You say Electron is not ideal, I say it's the worst thing that had happened to desktop computers ever. It's bad for the planet too. Some argue that without "js on desktop" we wouldn't have these amazing apps. I think it's not worth it to have those apps if they are built using those technologies. They make me miserable every single day. It's the only thing that forces me to upgrade my computer. It's so bad. Things that were possible 20 years ago are suddenly an unachievable goal. Stop it.
Yes, but the web is crappy system for designing UIs in.
As a community we've got good at designing UIs with web technologies (HTML+CSS), because we have no other choice if you want to build web-apps. But the level of experience we've gained with those tools has hidden the fact that they have some real issues - mostly due to the fact that they've developed piecemeal over many years. Getting the layout of your page to behave correctly under all the circumstances it needs to requires a lot of experience with CSS, a lot of simple page behaviour we'd now expect as users require adding JS sprinkled around (and I'm not talking app logic, just UI logic).
I freely admit that I'm not great with CSS - I'm not a web developer although I have done some web development. If I do any at work (e.g. web UI for embedded device) I need a pro to come along and make things look nice. But when I did app development in Flutter it took about 2 days to be able to build screens that looked good, did complicated dynamic behaviour, and behaved reliably regardless of screen size and shape.
For one, you mention Electron. That targets all desktop platforms, but not mobile. Mobile development from webapps is absolutely possible, but you need to use something else for that. Meanwhile, on the flutter side of things, if you want to target desktop platforms, you use flutter. If you want to target mobile platforms, you use flutter. There isn't a need to learn a whole new framework to target a new platform.
Aside from that, local file storage and offline use can also be a bit finnicky with Electron. Absolutely possible, but its another thing you have to figure out that Flutter just does by default.
If I'm wrong on any of this, please do let me know, I know web dev far better than I know Flutter so it'd make my life a lot easier, but the above reasons are why flutter hasn't budged from my todo list
Deleted Comment
Exactly. Dart is a deal-breaker. I was tasked with choosing a cross-platform development solution, and rejected Flutter because nobody at my company (including me) knows Dart or has time to learn it. Nor would any contractors we were likely to find know it.
After quite a bit of research on other potential solutions, I determined (as did a crowded and lengthy thread in this forum) that Qt was the only viable one for now.
The recent proliferation of languages has been pretty annoying. Google should have at least used Kotlin. Alienating their own community of Android developers and making Flutter a pain in the ass to integrate into a development organization was dumb.
The other problem people cited with alleged cross-platform solutions is the need to write native code anyway if you need access to system/hardware resources (Bluetooth, USB, what have you).
Flutter's performance issues, on the other hand, is a separate story.
Kotlin swelled up around the limitations of Java 8 in outside organizations and took over the ecosystem so Android devs could be productive while Google was fighting with Oracle
You should have decently qualified developers be productive within a week.
But forcing a new language on people usually doesn't go well.
The only thing I really hated about Dart was poor enum support. Now that's fixed.
All anecdotal:
I've only met one person who was excited to work with Dart, huge Google fanatic/fanboy. Otherwise it's sorta seen as a unique language choice that makes other devs go, "oh..."
The Java/ECMA ergonomics are weird, it's hard to find devs who have experience with the lang, and due to the language popularity there's a lot less community/3rd party deps available.
I really tried hard to give it a fair shake back in the day but I just ended up sticking with Node (and now +Deno), Typescript, or Go if I need performance/types. There are way better ecosystems around these and I find the tooling/ergonomics much less awkward. Also, if/when I need to hire devs onto my teams I will have a much easier time.
Also, I can actually write a serverless function in these tools (GCP Functions, AWS Lambda) - as far as I know there's nothing like this available for Dart.
---
EDIT: It's worth mentioning I've only had Dart jammed down my throat on the backend (API's, data transforms, jobservers, etc). It may be a fine tool in regards with Flutter, but it felt like a really awkward tool for where it's come up in my career.
I don't think I've ever seen Flutter in the wild.
(I personally don't know if it's this good, but it's plausible)
So what is this made in then? [0] Hint it is not Electron.
[0] https://rows.com/download
There are a couple of web platform technologies that I think are going to take Flutter web from ok to great in the next year or two including.
WASM Garbage Collection is going to allow them to move from compiling to JS to WASM. They have already built a WASM compiler ready to go when it lands.
WebGPU is another obvious one. Flutter is by definition a canvas optimised framework rather than strictly DOM based (although they support that too as a target). But they should be able to get blazing fast canvas rendering with those two technologies alone.
The other big one that I think will help them is going to be AOM. Lots of the built in browser accessibility stuff was built for a DOM based world, the web platform needs better primitives to support canvas frameworks too.
I don't know if this has changed, but I know only a mad man would try to build a proper website in Flutter. It's not the tool for the job.
It’s like they took all the good things about JS and Java and cut out all the bad parts. What’s left is basically Dart.
C++ -> QT
C#/.NET -> MAUI/Blazor
JS/Web -> React.Native/Electron
Dart -> Flutter
This is what I think is holding back Flutter -- that it wasn't built on an incumbent technology. Because Dart doesn't have quite the following, it has to evangelize itself a bit more than the other options.
That's the thing. Dart is useless for my preferred style of programming. A modern language without ADTs and pattern matching is not even meeting my bare minimum for acceptable to use. Not just this, but the docs explicitly said the don't want these basic features.
https://gallery.flutter.dev/#/demo/cupertino-text-field
As long as they keep insisting on rendering everything themselves instead of relying on the OS/DOM Flutter will always be a poor choice for UI
I manually tested on each of Windows, macOS, Linux, and iOS (where I've done a lot of work specific to CJK input) and was able to correctly input Japanese, Chinese, and Korean text [2], so looks like this is likely an issue specific to Flutter's web runtime. I work on Flutter's desktop embedders, but if there isn't someone who's a heavy IME user on the web team, I'll gladly give em a hand to help get this fixed.
[1] https://github.com/flutter/flutter/issues/103645
[2] https://www.youtube.com/watch/0Bt-c9-h92c
https://github.com/Tensegritics/ClojureDart
(and in turn, clojure itself is a highly opinionated thing which isn't gonna turn into a blub that everyone uses...)
Most of Qt is available under the LGPL. Some application specific libraries are available under the GPL, but there's no reason you'd need to use them unless you have special use cases that their libraries would make easier to handle.
> I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages.
Agreed, I figured that was the direction Flutter was going to go, with wrapper APIs for other languages, but it seems it never happened.
Dart is okay, but it's not a language I'd choose to write anything in. The only reason to use it is because of Flutter, as you've said.
In practice, it isn't just UI code that ends up getting written in Dart + Flutter, but the entire application and client code, excluding things like REST backends.
With Qt's QML, you're very much just writing UIs in QML and JavaScript, leaving a clean separation between the UI, core, and application and client code.
Our brief experimentation with Qt Widgets, on the other hand, revealed a shocking level of dysfunction in basic UI-layout implementation, in what is supposed to be a very mature UI toolkit. But it seems that they're basically abandoning Widgets at this point, so ¯\_(ツ)_/¯.
Any chance that someone will build a transpiler from e.g. Go or even Rust to Dart? Or is Dart too exotic to be used like that in a practical way?
One problem would be expressing the Flutter API as a Go API. For example, Flutter has lots of constructors with lots of keyword arguments. Flutter is doing things with keyword arguments that would be expressed as props in a React-style UI. A similar thing happened with JavaScript and JSX - while you can write a React-style UI without JSX, you probably wouldn't want to.
Maybe you could define props using structs in Go, but the result would be awkward, particularly because Go doesn't have an easy way to bulk-copy fields from one struct to another, like you do with spread arguments in JavaScript.
Also consider that Flutter uses class hierarchies extensively and Go doesn't have inheritance.
Maybe look at how web development is done in Go when it's compiled to WebAssembly. Is that how you'd want to do web dev?
I switched from Flutter to JUCE and haven't looked back. Its a far better user experience, and a far better developer experience too.
People often overlook it, because its pitched as a framework for Audio developers, but the work to make a truly operational cross-platform GUI has pushed it into 'suitable for normal application' territory, imho.
Anyone looking to solve the platform issue would be very wise to do a few workbench sessions with JUCE, and to a lesser degree, the Godot gaming framework as well. These are perfectly cromulant ways to build high-performance, cross platform, accessible applications...
Dead Comment
Do you really want cross platform everywhere? You might want it but what you inevitably get is something that is huge and just okay everywhere instead of something truly great anywhere. Is that a trade off you are happy with as a user?
That said, I do happily use a couple of cross platform applications. PyCharm and SublimeText which are great and Fusion 360 which is powerful but awful to use.
The desktop and web targets for Flutter are laughable in their current state. Completely unusable so I consider Flutter to be a mobile only platform at this time.
Another downside is Flutter's emulated UI, it doesn't bridge to native controls like React Native, it's noticeable on iOS especially and will be hard to maintain the fake physics / styling.
React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst.
Then there's the question as to why would you choose a Google only language and framework with their track record.
With React you can use TypeScript or JS, you don't have to learn a new language or get locked into a framework.
Gigantic, messy JS dependency tree. Constant build breakages after minor version updates. Random flakiness. Unmaintained or buggy native plugins. Questionable support for issues that didn't affect FB.
I wouldn't touch it again.
All platforms ... except Linux. React-native-gtk is abandoned as far as I know.
Qt is LGPLv3, which is really a problem only if you plan to develop embedded software.
Sure, there are a few GPL v3 modules here and there, but it's mostly very specific stuff (virtual keyboards, Wayland compositors, ...)
What are your thoughts on flutter vs react native?
(assuming you're only targeting phones)
The majority of Google’s revenue is directly tied to their Ads platform.
Their mobile app is written in Flutter and the web interface is written in Dart (not flutter as flutter web support is like around a year old).
Facebook uses React on the web and abandoned react native on mobile.
Both are responsible for billions of dollars but only one passed the test.
https://news.ycombinator.com/item?id=31346887
Why did they tie Flutter to Dart anyway?
Sounds like they should have used TypeScript?
Dart is horrible and the sole reason i don't touch Flutter
wtf.. Ionic/electron is the true cross platform, no debate. Flutter web is dog shit.
Depending on your needs, Livecode has you covered. https://livecode.com
Runs on Mac, Windows, Linux. Delivers on all three, plus iOS and Android. The underlying language is patterned after HyperTalk and people either love it or hate it, but I haven't seen any other tool where you can open the new installation and within 2 minutes deliver single-file executables for three platforms. (Disclosure: I build a developer tool for Livecode)
I was very pleased to find out, that Flutter supported web as well. Now, it's not as good as mobile yet - some of the animations are render blocked by the JS main thread - but it is a very nice 'middle' solution to somebody who needs to use the app who doesn't have iOS or Android (for example, Surface tablet). Also great for internal testing - push up the latest changes to a dev web environment, and everyone can test without installing APKs or using TestFlight.
In my use case, I was actively discouraged against making something that looked beautiful or pretty - the software is designed to be spartan, minimalist and essential. Flutter is perfect for that.
All in all, Flutter is awesome. Is it the right answer for everything? No. But when you only have one developer to spare whose job it is to build a mobile app, it's perfect for that. The web support is a nice bonus - haven't tried any of the desktop stuff yet.
Dart, as a language, is nice. Not spectacular, but certainly tidier than Java or JavaScript. I've gotten used to functionality programming, so writing everything in classes was jarring at first.
While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants.
Well, at least there's quite a few other small but useful improvements... and they showed how they really listen to the community by implementing the new syntax for passing on constructor parameters to a super-class... and by improving the docs of the 200 most popular packages with lots of examples, as requested by the people.
I like how they're listening to the community as well to implement meta-programming (like macros) [2] to solve the main pain point, currently, in Dart, which is how verbose it is to generate code for things like serialization and data types.
Once they get that, Dart will be a really good language to work on (it's already quite ok IMO, despite most people, usually those who don't actually use it much, hating on it).
[1] https://medium.com/dartlang/dart-2-17-b216bfc80c5d
[2] https://github.com/dart-lang/language/issues/1482
Yes, the enhanced enums we shipped in 2.17 are like Java enums.
We are also working on support for pattern matching and algebraic datatype-style programming: https://github.com/dart-lang/language/blob/master/working/05...
I say "style" here because object-oriented languages like Dart can already mostly model sum types using subclasses. What you need to get the rest of the way there is basically just:
1. Sealed types so that the compiler can check for exhaustiveness when you match over all of the subclasses.
2. A nice pattern matching syntax to let you discriminate between the subclasses and destructure them.
3. Ideally, a nice lightweight syntax for defining a sum type family as a superclass and set of subclasses, though this is relatively less critical.
We're hard at work on this, but pattern matching in general is a pretty large feature and retrofitting it into a language whose syntax wasn't initially designed around it is a challenge.
I'm very excited about macros too. That's another large, difficult feature, but one that I hope will provide a lot of power to users and make the entire ecosystem more valuable over time.
[0] https://pub.dev/packages/freezed
As much as I like Rust’s enums, I think they messed up on the naming. Java (and according to your comment, Dart) gets enum rights. What Rust has under this name is sum types, which is a separate (more expressive) concept and the two only correspond with each other in the case of a sum type where each component is of a zero-arity type.
I guess the name was just a historical artifact.
Enum is much better - you just enumerate all the values the type can be (plus optional associated data).
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?
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.
https://flutter.dev/showcase/google-pay
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 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.
Google doesn't even support its own devices from 2016, so I doubt they'd optimize their apps for the iPhone SE 2016.
Interesting thread from a year ago may interest you: https://news.ycombinator.com/item?id=26333973 (it's a flutter lead talking about Google pay).
I'd be interested to know how much the team tests with an iphone that old.
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.
Deleted Comment
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.
You can't even select and copy text. And canvas is inaccessible to screen readers
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.
This is easy to verify - just open up dev tools and look at the DOM structure.
I'm just sick of the NPM/Javascript bullshit.
Does Flutter avoid all of these kinds of issues? I'm this close to scrapping the whole thing.
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.
Flutter has its fair share (and to be fair, so do the native toolchains).
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.
Amen
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.
https://github.com/flutter/flutter/issues/91605
Feel free to upvote any issue that you would like to see prioritized, as it helps us with planning.
Deleted Comment
[0] https://github.com/flutter/flutter/issues/91605