Hello, I'm from the Flutter desktop team. Thank you for the excellent feedback, this is truly invaluable.
Here are some updates from our side:
1. Custom context menus - We just added this feature in Flutter 3.7, which was released two weeks ago. Please give this a try and let us know what you think!
2. Multi-window - This is a high priority for the Flutter team, we have several engineers working on this project currently. Here's a video that gives an early preview on multi-window support: https://www.youtube.com/watch?v=vtB-teu57vw
Feel free to let us know if you have additional feedback; this helps us prioritize on what's most valuable for our community!
Thank you for the great work! Flutter and Dart are awesome and keep getting better. I'm coming from the land of Scala, Erlang, Clojure, TypeScript, and I'm loving the general approach to the engineering and design that Flutter and Dart teams have. Kudos!
Hi! I was wondering about the coexistence of Flutter and Kotlin in Android development. Is there any good write-up to help devs to choose between them depending on the use case?
If there's anything I've learned from using Google projects it's this: It's not going to get fixed.
It almost doesn't matter what it is.
If you've used any Google OSS project seriously you're going to come across an obvious defect and run to GitHub to open an issue. But, there's already an open issue for the problem.. And it's been open for almost as long as the project has existed.
It will have an inscrutable priority and day after day new comments will pop up saying "Hey, I'm having this issue too. Can I contribute a fix?" But, a pull request with a fix has sat, unreviewed, for almost as long as the issue has been open.
And then it comes: "This issue has been automatically closed due to inactivity."
For me, Flutter mobile isn't there yet either. I can see where it might be great for games with completely custom UIs, but I find the uncanny valley of pretend native controls a very uncomfortable place to be.
Flutter could be a fantastic solution if it supported native controls and used JavaScript. I don't understand why Flutter's creators are so seemingly religious about Dart and reimplementing OS UI capabilities.
Every technology is a set of tradeoffs, including Flutter.
For me -- I am using Flutter to build internal productivity tools available on multiple platforms (web, desktop, mobile). Users do not necessarily care if the application looks pixel perfect (but, still, Flutter is definitively an improvement from Oracle Forms :)
What users and the management does care, on the other hand, is that the features can be delivered quickly and on multiple platforms.
Isn't what you're describing basically React Native? I think the Flutter devs wanted to try a different approach to address what they felt were the shortcomings of React Native which brings along its own set of tradeoffs.
Sure, but most common mobile apps ARE completely custom UIs which insist on their own branding and look. The UI designers usually really hate if they have to use standard components and are unable to express themselves.
> I don't understand why Flutter's creators are so seemingly religious about Dart
I think Dart's history might be relevant here. Flutter was unveiled at a 2015 Dart programmer conference (https://www.youtube.com/watch?v=PnIWl33YMwA) and it was originally called Sky. Dart doesn't exist because of Flutter, it's the other way around.
Dart was originally intended to be a replacement for Javascript back in 2011, but it utterly failed to gain any adoption because about a year later in 2012, Typescript came out. Typescript being a superset of JavaScript I think completely destroyed any chance Dart could catch on for its original web development goals, since you didn't have to dump JS entirely, just rename .js to .ts and gradually start type-hinting code. Even within Google, they abandoned Dart for Angular and went all in with Typescript.
In a way it's refreshing to see Google re-tool an existing language, rather than invent a whole new langauge for cross platform app development, seeing how often as a company, they kill off projects quickly and start whole new ones.
I don't think it's necessarily an error to reimplement widgets, with a caveat — the reimplementations need to be good. Really good, at least as good as native widgets and preferably better. An example of this is Sublime Text/Merge, which feel excellent despite being built with a bespoke UI framework.
This rarely happens though, and I wonder if it may have to do with the limitations of the technologies often chosen to do the implementing with, or if it's more of a philosophical thing with the projects in question not holding themselves to high enough of a bar.
> I find the uncanny valley of pretend native controls a very uncomfortable place to be
Me too, and I’m surprised how okay with it people seem to be. What are the odds that Google to continue to support the latest platform UI changes? What about five years from now? How much effort is it to get good accessibility support vs native controls, and how likely are developers to do that?
The whole approach seems wholly dependent on Google continuing to give a shit, and as we’re all aware they don’t have the best track record there.
The more "solutions" that are developed for desktop + mobile cross-platform applications, the more I see highlighted how different the paradigms are, and how the streams really shouldn't be crossed.
They're both UIs viewed on a screen that you interact with by pointing and clicking, but the similarities end there. The entire output of this cross-platform effort has been awkward applications that run everywhere but feel right nowhere. It's sad that even Apple has fallen victim to this idea that with their horrible Catalyst apps. Though I understand why the sales pitch of "one codebase" makes management of so many companies salivate.
Fully native isn't especially realistic. At the risk of sounding like a broken record, general purpose tooling written by a small team can't support multiple native UIs.
What often works for me is something like Wails, but it has its limitations. For instance there's no multi-window functionality there either, and while the new Wails supports more OS integrations there's still some aspects that need improvement to compete with native UI.
I'd love to try Flutter, but frankly I don't want to write "backend-ish" code in Dart. There's some projects to be able to build UIs in Flutter and have processing done by a separate language that all gets bundled as one, but they're mostly hobby projects.
If you have the money, make everything native, but until then I can build a Flutter app that works on 6+ platforms for the price of one, which is a real competitive advantage for a solo developer running a startup.
I think Flutter is the best option right now to release your idea on mobile, web and desktop platforms yourself without hiring additional people. The only other realistic option I know of is to use web tech. Are there other good options for single devs?
The point of seriously (key word) using x platform tools is to ship fast and solve customer problems.
If the particular experience you want isn’t supported, creativity is required to either:
A) use an alternate experience. Users literally don’t care as long as their problem is solved. They don’t care if it’s using X api or multi window or whatever. Just use tabs for all they care.
B) build the experience as a lib and maybe open source it
Well, web designing does blur the lines. You can easily create a website that is both desktop and mobile friendly by implementing responsive design. Translating that to a native experience seems to be the problem
I largely agree with this when the application will be used heavily on each platform. I think desktop + mobile cross-platform does work when one platform is primary and the second secondary (ex. IOT devices). You can then have an interface primarily focused for an embedded application, and then when data transfer or settings for the embedded device needs to be configured, configuring it from the desktop is easier, and having a similar interface all around is beneficial.
I wonder how many people Maxis employed when they made Sim City 2000? Because it had a native UI for every platform it was ported to that had a windowing and widget toolkit.
I just can't help but think that either programmers today have abstracted themselves into a lot more work than need to do, or they're just significantly less capable over all than the programmers of old.
As someone shipping an app across all desktop and mobile platforms with flutter, binding it into a native rust library, I absolutely adore it. It does what I need and is fairly reliable about it everywhere, while keeping build systems and everything else mostly managed for me. As the post mentions, it’s not a panacea, but for someone who needs a good-enough solution, it’s been great.
I most recently tried out Flutter about a month ago and "not there yet" feels like my overall experience. Sadly for a project of Flutter's age one has to wonder whether the "yet"-phase will ever end (just like some libraries are bound to always be buggy due to their architecture, while others feel smooth).
In onboarding to the tooling, there are so many paper cuts that it's not really a "I'll try this out for fun" thing like e.g. Next.js is, that you would recommend to your co-workers.
I tried it out for desktop, where I found it okay-ish (but lacking in desktop-related libraries, as the article points out), and for web, where the debugging experience compared to web-native solutions really takes a hit due to the lack of DOM.
We actively use Flutter and tend to agree with this sentiment, with the caveat that we believe it absolutely can get there (and I believe a lot more in Google's ability to stay relevant than Facebook's, even with ChatGPT in the mix).
That being said, they have a lot of work to do.
- I'm not a big fan of Dart's overall composition
- "late" seems lazy and error-prone
- Dependency on code generation for simple things like JSON serializers/deserializers
- All the other issues people have mentioned in this thread.
Luckily my team is investing a lot in our developer tooling, so we can lint/codegen a lot of the stuff away, but it's certainly a sign of it not being there yet.
Indeed, multi-window support is absolutely missing right now, but it's the Flutter's team top priority. Context menus are now available with 3.7.
Generally, I found Flutter/Dart easy to pick up and build a quality desktop app with ease. Currently, I am not convinced that it can be used for performance-critical apps yet without a lot of developer effort and experience (there is, for example, Rows, an Excel clone built with Flutter). However, it works for building general-purpose apps on desktop, without messing with the native toolkits that are in a strange place, especially on Windows.
Flutter is going to be 5 years old soon. It's not even the leading solution for cross-platform development for mobile let alone desktop. It's great to be positive and supportive but realistically, if someone had to bet months of dev work on building something non-trivial - would they really choose flutter?
Another one, desktop webviews don't exist either. Everyone does something custom right now and there's an epic vent fest in one of their GitHub issues. This causes about 1 new package to get released every few months too that tries to address it.
A good example of Flutter desktop is https://rive.app/downloads - curious on others' thoughts of how that compares to Electron or other choices that are out there.
Docking would be nice to have too! like what MSVC or Qt has (built-in in Qt is not that great, but Visual Studio is one to follow). It's a must for content creators with multiple monitors, especially if they want the layout to be preseved from session to session or create different layouts (e.g. how and where the windows are, what is docked in which other, etc) for other people as templates.
That’s because the Android emulator sucks for development.
There has never been an iOS “emulator” for development. When you built your code to test on the desktop, it was compiled to x86 and used x86 version of the iOS framework.
Of course now that Macs use ARM chips, it’s a moot point.
The basic functionality of the typical UI hasnt changed for ages. Yet technologies keep churning. There is probably a better way but apparently people are not incentivised to find it.
This is a strange take for me- people are CONSTANTLY trying to find new, better ways to do UI. Elm, React, DearIMGUI, Flutter, and Xilem are some of the more well-known fairly recent libraries.
His point stands for me as well. I saw a lot of huge potential for cross-platform mobile development but desktop feels like a bad port of a mobile app rendered on desktop.
I LOVE Flutter for a web / iOS / android side project.
It's a Spotify music player that turns your device into a jukebox at https://getjukelab.com/.
As a hobbyist I couldn't imagine getting this far on 3 different platforms if I had to go native. My favorite surprise is how much faster doing dev, deploy and QA on the web target is, vs doing mobile dev and release. I can deploy to the web 5 times a weekend, and batch those up to do monthly mobile releases.
I tried Flutter Desktop but hit an immediate show stopper that the flutter Spotify SDK doesn't support it. There's no "Mac Spotify SDK", so it would have to wrap the web one somehow. All the UI bits worked as expected.
But watching the trajectory of Flutter and the community over the past couple of years I'm cautiously optimistic it'll get good.
I've been very disappointed with the direction of Flutter recently, but I still do stand by it and will always choose it over the GatsreminextstroJS framework for VuengulembereactelteJS.
Why are 3D, game engines, and WASM more important than good JSON serialization, improved runtime safety (removing "late"), multi-window support, extension structs, webview support, exhaustive maps, and other core issues?
Here's my quick criteria for whether I should use a new framework for my app:
- look at other apps that are using that framework, esp. the signature/first class app touted as a consumer by that framework
- how similar is my app to that signature/first class app?
- if my app has similar UX/UI usage then the dev experience will be much smoother/easier/doable
i.e. for React Native: does my app behave like Facebook? If not (say, an action game as an obvious typical non-usage scenario), there be dragons...
for mature, stable frameworks like native mac OS<=9, macOS, Win32, most GUI apps are straight forward, it's when you push the limits of the UI where things will hit hurdles.
So what's the signature/first class app for Flutter Desktop?
A couple of thoughts (doesn't address all the concerns):
1. I write in Rust, so my plan was to write the UI in flutter and use the rust/flutter bridge so I can write most of the client code in Rust. Gets around _some_ of the lack of flutter libs by using Rust ecosystem instead (but not for the UI itself)
2. There is a new lib out called platform ui that wraps mac/windows/linux UI transparently (it is just a wrapper that wraps fluent ui and macos UI libs, etc). Not sure how well it works, but might worth a shot and gets closer to native l&f for desktop
I have 2 LOB on the desktop. Is Jank an issue? Only to those who have 100+ refresh rates.
Corporate wise , nah, its fine, Jank effects heavy animations. Even then the 3-4 encounters was fixed by some smart resource usage. We are trying the 3.7 solution. If not, then stick with the idea don't try to animate the animation.
Desktop ready? Corporations yes. Make the next unreal 5.x game with it? nope.
[+] [-] loic-sharma|3 years ago|reply
Here are some updates from our side:
1. Custom context menus - We just added this feature in Flutter 3.7, which was released two weeks ago. Please give this a try and let us know what you think!
2. Multi-window - This is a high priority for the Flutter team, we have several engineers working on this project currently. Here's a video that gives an early preview on multi-window support: https://www.youtube.com/watch?v=vtB-teu57vw
Feel free to let us know if you have additional feedback; this helps us prioritize on what's most valuable for our community!
[+] [-] davidkuennen|3 years ago|reply
And sorry to ask this here, but how have the recent layoffs affected the flutter team?
We're using flutter as our main framework for our app and it's quite important.
The layoffs have sparked some fears that flutter development might slow down.
[+] [-] dsabanin|3 years ago|reply
[+] [-] never_inline|3 years ago|reply
[+] [-] livinglist|3 years ago|reply
[+] [-] invpt|3 years ago|reply
[+] [-] malkia|3 years ago|reply
[+] [-] dr_kiszonka|3 years ago|reply
[+] [-] miiiiiike|3 years ago|reply
It almost doesn't matter what it is.
If you've used any Google OSS project seriously you're going to come across an obvious defect and run to GitHub to open an issue. But, there's already an open issue for the problem.. And it's been open for almost as long as the project has existed.
It will have an inscrutable priority and day after day new comments will pop up saying "Hey, I'm having this issue too. Can I contribute a fix?" But, a pull request with a fix has sat, unreviewed, for almost as long as the issue has been open.
And then it comes: "This issue has been automatically closed due to inactivity."
[+] [-] CharlesW|3 years ago|reply
Flutter could be a fantastic solution if it supported native controls and used JavaScript. I don't understand why Flutter's creators are so seemingly religious about Dart and reimplementing OS UI capabilities.
[+] [-] twawaaay|3 years ago|reply
For me -- I am using Flutter to build internal productivity tools available on multiple platforms (web, desktop, mobile). Users do not necessarily care if the application looks pixel perfect (but, still, Flutter is definitively an improvement from Oracle Forms :)
What users and the management does care, on the other hand, is that the features can be delivered quickly and on multiple platforms.
[+] [-] eberkund|3 years ago|reply
[+] [-] izacus|3 years ago|reply
Flutter just recognises that.
[+] [-] lta|3 years ago|reply
I personally dislike the whole JS ecosystem with a passion, and feel I'm not alone in this, so having an alternative is warmly welcome
[+] [-] miffy900|3 years ago|reply
I think Dart's history might be relevant here. Flutter was unveiled at a 2015 Dart programmer conference (https://www.youtube.com/watch?v=PnIWl33YMwA) and it was originally called Sky. Dart doesn't exist because of Flutter, it's the other way around.
Dart was originally intended to be a replacement for Javascript back in 2011, but it utterly failed to gain any adoption because about a year later in 2012, Typescript came out. Typescript being a superset of JavaScript I think completely destroyed any chance Dart could catch on for its original web development goals, since you didn't have to dump JS entirely, just rename .js to .ts and gradually start type-hinting code. Even within Google, they abandoned Dart for Angular and went all in with Typescript.
In a way it's refreshing to see Google re-tool an existing language, rather than invent a whole new langauge for cross platform app development, seeing how often as a company, they kill off projects quickly and start whole new ones.
[+] [-] kitsunesoba|3 years ago|reply
This rarely happens though, and I wonder if it may have to do with the limitations of the technologies often chosen to do the implementing with, or if it's more of a philosophical thing with the projects in question not holding themselves to high enough of a bar.
[+] [-] deergomoo|3 years ago|reply
Me too, and I’m surprised how okay with it people seem to be. What are the odds that Google to continue to support the latest platform UI changes? What about five years from now? How much effort is it to get good accessibility support vs native controls, and how likely are developers to do that?
The whole approach seems wholly dependent on Google continuing to give a shit, and as we’re all aware they don’t have the best track record there.
[+] [-] wg0|3 years ago|reply
This attempt to draw every single control is too much effort with apparent inconsistencies.
[+] [-] hbn|3 years ago|reply
They're both UIs viewed on a screen that you interact with by pointing and clicking, but the similarities end there. The entire output of this cross-platform effort has been awkward applications that run everywhere but feel right nowhere. It's sad that even Apple has fallen victim to this idea that with their horrible Catalyst apps. Though I understand why the sales pitch of "one codebase" makes management of so many companies salivate.
[+] [-] MrOwnPut|3 years ago|reply
But I don't agree cross-platform can't feel "right". Flutter's approach it can't. React Native's it can. Qt vs WxWidgets all over again.
If I had to duplicate my codebase for each platform and learn each IDE/language just to continue my app, it would never exist.
I solely created and maintain the iOS app, the Android app, and the web app for my company and for my side projects thanks to React Native.
I can extend any native api or view, I can learn middle out for each platform.
I can abstract and swap out any file or conditionally style based on platform.
I developed the web app first using React Native Web. It took me a month to get the iOS and Android app released to the store.
No Ionic or web wrapper crap needed... The one thing is getting the React stack and tooling just right.
So it's Expo or devote quite a bit of time in the beginning to your stack.
[+] [-] kodah|3 years ago|reply
What often works for me is something like Wails, but it has its limitations. For instance there's no multi-window functionality there either, and while the new Wails supports more OS integrations there's still some aspects that need improvement to compete with native UI.
I'd love to try Flutter, but frankly I don't want to write "backend-ish" code in Dart. There's some projects to be able to build UIs in Flutter and have processing done by a separate language that all gets bundled as one, but they're mostly hobby projects.
[+] [-] satvikpendem|3 years ago|reply
[+] [-] optymizer|3 years ago|reply
[+] [-] moomoo11|3 years ago|reply
If the particular experience you want isn’t supported, creativity is required to either:
A) use an alternate experience. Users literally don’t care as long as their problem is solved. They don’t care if it’s using X api or multi window or whatever. Just use tabs for all they care.
B) build the experience as a lib and maybe open source it
Anything else is for hobbyists.
[+] [-] augusto-moura|3 years ago|reply
[+] [-] SebastianKra|3 years ago|reply
SwiftUI has a lot of problems, but Apple has done great work building components and paradigms that adapt to the target device.
For example, check out how forms are defined: https://developer.apple.com/videos/play/wwdc2022/10052/
Defining an interface this way saves time for developers and provides consistency to users who use apps across different devices.
[+] [-] ss48|3 years ago|reply
[+] [-] AnIdiotOnTheNet|3 years ago|reply
I just can't help but think that either programmers today have abstracted themselves into a lot more work than need to do, or they're just significantly less capable over all than the programmers of old.
[+] [-] qdot76367|3 years ago|reply
[+] [-] Winsaucerer|3 years ago|reply
[+] [-] hobofan|3 years ago|reply
In onboarding to the tooling, there are so many paper cuts that it's not really a "I'll try this out for fun" thing like e.g. Next.js is, that you would recommend to your co-workers.
I tried it out for desktop, where I found it okay-ish (but lacking in desktop-related libraries, as the article points out), and for web, where the debugging experience compared to web-native solutions really takes a hit due to the lack of DOM.
[+] [-] TobyTheDog123|3 years ago|reply
That being said, they have a lot of work to do.
- I'm not a big fan of Dart's overall composition - "late" seems lazy and error-prone - Dependency on code generation for simple things like JSON serializers/deserializers - All the other issues people have mentioned in this thread.
Luckily my team is investing a lot in our developer tooling, so we can lint/codegen a lot of the stuff away, but it's certainly a sign of it not being there yet.
[+] [-] whiplashoo|3 years ago|reply
Indeed, multi-window support is absolutely missing right now, but it's the Flutter's team top priority. Context menus are now available with 3.7.
Generally, I found Flutter/Dart easy to pick up and build a quality desktop app with ease. Currently, I am not convinced that it can be used for performance-critical apps yet without a lot of developer effort and experience (there is, for example, Rows, an Excel clone built with Flutter). However, it works for building general-purpose apps on desktop, without messing with the native toolkits that are in a strange place, especially on Windows.
[+] [-] preommr|3 years ago|reply
[+] [-] robust-cactus|3 years ago|reply
[+] [-] timsneath|3 years ago|reply
[+] [-] xdfgh1112|3 years ago|reply
For me the best use of desktop is testing mobile apps without having to use my phone or an emulator. It works really well.
[+] [-] malkia|3 years ago|reply
[+] [-] scarface74|3 years ago|reply
There has never been an iOS “emulator” for development. When you built your code to test on the desktop, it was compiled to x86 and used x86 version of the iOS framework.
Of course now that Macs use ARM chips, it’s a moot point.
[+] [-] college_physics|3 years ago|reply
[+] [-] intrasight|3 years ago|reply
[+] [-] bbkane|3 years ago|reply
See https://raphlinus.github.io/rust/gui/2022/07/15/next-dozen-g... for an overview of UI libs in Rust.
See https://www.cmyr.net/blog/gui-framework-ingredients.html for a great overview of some of the challenges making a GUI library
[+] [-] xutopia|3 years ago|reply
[+] [-] nzoschke|3 years ago|reply
It's a Spotify music player that turns your device into a jukebox at https://getjukelab.com/.
As a hobbyist I couldn't imagine getting this far on 3 different platforms if I had to go native. My favorite surprise is how much faster doing dev, deploy and QA on the web target is, vs doing mobile dev and release. I can deploy to the web 5 times a weekend, and batch those up to do monthly mobile releases.
I tried Flutter Desktop but hit an immediate show stopper that the flutter Spotify SDK doesn't support it. There's no "Mac Spotify SDK", so it would have to wrap the web one somehow. All the UI bits worked as expected.
But watching the trajectory of Flutter and the community over the past couple of years I'm cautiously optimistic it'll get good.
[+] [-] TobyTheDog123|3 years ago|reply
Why are 3D, game engines, and WASM more important than good JSON serialization, improved runtime safety (removing "late"), multi-window support, extension structs, webview support, exhaustive maps, and other core issues?
I really don't understand these priorities.
[+] [-] canucker2016|3 years ago|reply
Here's my quick criteria for whether I should use a new framework for my app:
- look at other apps that are using that framework, esp. the signature/first class app touted as a consumer by that framework
- how similar is my app to that signature/first class app?
- if my app has similar UX/UI usage then the dev experience will be much smoother/easier/doable
i.e. for React Native: does my app behave like Facebook? If not (say, an action game as an obvious typical non-usage scenario), there be dragons...
for mature, stable frameworks like native mac OS<=9, macOS, Win32, most GUI apps are straight forward, it's when you push the limits of the UI where things will hit hurdles.
So what's the signature/first class app for Flutter Desktop?
[+] [-] nu11ptr|3 years ago|reply
1. I write in Rust, so my plan was to write the UI in flutter and use the rust/flutter bridge so I can write most of the client code in Rust. Gets around _some_ of the lack of flutter libs by using Rust ecosystem instead (but not for the UI itself)
2. There is a new lib out called platform ui that wraps mac/windows/linux UI transparently (it is just a wrapper that wraps fluent ui and macos UI libs, etc). Not sure how well it works, but might worth a shot and gets closer to native l&f for desktop
https://pub.dev/packages/platform_ui
[+] [-] JediPig|3 years ago|reply
Corporate wise , nah, its fine, Jank effects heavy animations. Even then the 3-4 encounters was fixed by some smart resource usage. We are trying the 3.7 solution. If not, then stick with the idea don't try to animate the animation.
Desktop ready? Corporations yes. Make the next unreal 5.x game with it? nope.
[+] [-] lpa22|3 years ago|reply
[+] [-] parentheses|3 years ago|reply
NOTHING IS THERE YET
“There” is Utopia.
“There” is a language being ergonomic, ubiquitous, fast and with libraries that are awesome!
That is too much to expect.