Flutter desktop isn’t there yet

Hello, I&#x27;m from the Flutter desktop team. Thank you for the excellent feedback, this is truly invaluable.<p>Here are some updates from our side:<p>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!<p>2. Multi-window - This is a high priority for the Flutter team, we have several engineers working on this project currently. Here&#x27;s a video that gives an early preview on multi-window support: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=vtB-teu57vw">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=vtB-teu57vw</a><p>Feel free to let us know if you have additional feedback; this helps us prioritize on what&#x27;s most valuable for our community!

If there&#x27;s anything I&#x27;ve learned from using Google projects it&#x27;s this: It&#x27;s not going to get fixed.<p>It almost doesn&#x27;t matter what it is.<p>If you&#x27;ve used any Google OSS project seriously you&#x27;re going to come across an obvious defect and run to GitHub to open an issue. But, there&#x27;s already an open issue for the problem.. And it&#x27;s been open for almost as long as the project has existed.<p>It will have an inscrutable priority and day after day new comments will pop up saying &quot;Hey, I&#x27;m having this issue too. Can I contribute a fix?&quot; But, a pull request with a fix has sat, unreviewed, for almost as long as the issue has been open.<p>And then it comes: &quot;This issue has been automatically closed due to inactivity.&quot;

For me, Flutter mobile isn&#x27;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.<p>Flutter could be a fantastic solution if it supported native controls and used JavaScript. I don&#x27;t understand why Flutter&#x27;s creators are so seemingly religious about Dart and reimplementing OS UI capabilities.

The more &quot;solutions&quot; 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&#x27;t be crossed.<p>They&#x27;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&#x27;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 &quot;one codebase&quot; makes management of so many companies salivate.

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 &quot;not there yet&quot; feels like my overall experience. Sadly for a project of Flutter&#x27;s age one has to wonder whether the &quot;yet&quot;-phase will ever end (just like some libraries are bound to always be buggy due to their architecture, while others feel smooth).<p>In onboarding to the tooling, there are so many paper cuts that it&#x27;s not really a &quot;I&#x27;ll try this out for fun&quot; thing like e.g. Next.js is, that you would recommend to your co-workers.<p>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.

Last year, I built a desktop app with Flutter with native-looking UI, for both macOS and Windows: <a href="https:&#x2F;&#x2F;blog.whidev.com&#x2F;native-looking-desktop-app-with-flutter&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.whidev.com&#x2F;native-looking-desktop-app-with-flut...</a><p>Indeed, multi-window support is absolutely missing right now, but it&#x27;s the Flutter&#x27;s team top priority. Context menus are now available with 3.7.<p>Generally, I found Flutter&#x2F;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&#x27;s not even the leading solution for cross-platform development for mobile let alone desktop. It&#x27;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&#x27;t exist either. Everyone does something custom right now and there&#x27;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 <a href="https:&#x2F;&#x2F;rive.app&#x2F;downloads" rel="nofollow">https:&#x2F;&#x2F;rive.app&#x2F;downloads</a> - curious on others&#x27; thoughts of how that compares to Electron or other choices that are out there.

Multiple windows is on the roadmap and high priority.<p>For me the best use of desktop is testing mobile apps without having to use my phone or an emulator. It works really well.

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.

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 &#x2F; iOS &#x2F; android side project.<p>It&#x27;s a Spotify music player that turns your device into a jukebox at <a href="https:&#x2F;&#x2F;getjukelab.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;getjukelab.com&#x2F;</a>.<p>As a hobbyist I couldn&#x27;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.<p>I tried Flutter Desktop but hit an immediate show stopper that the flutter Spotify SDK doesn&#x27;t support it. There&#x27;s no &quot;Mac Spotify SDK&quot;, so it would have to wrap the web one somehow. All the UI bits worked as expected.<p>But watching the trajectory of Flutter and the community over the past couple of years I&#x27;m cautiously optimistic it&#x27;ll get good.

I&#x27;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.<p>Why are 3D, game engines, and WASM more important than good JSON serialization, improved runtime safety (removing &quot;late&quot;), multi-window support, extension structs, webview support, exhaustive maps, and other core issues?<p>I really don&#x27;t understand these priorities.

Not surprising.<p>Here&#x27;s my quick criteria for whether I should use a new framework for my app:<p>- look at other apps that are using that framework, esp. the signature&#x2F;first class app touted as a consumer by that framework<p>- how similar is my app to that signature&#x2F;first class app?<p>- if my app has similar UX&#x2F;UI usage then the dev experience will be much smoother&#x2F;easier&#x2F;doable<p>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...<p>for mature, stable frameworks like native mac OS&lt;=9, macOS, Win32, most GUI apps are straight forward, it&#x27;s when you push the limits of the UI where things will hit hurdles.<p>So what&#x27;s the signature&#x2F;first class app for Flutter Desktop?

A couple of thoughts (doesn&#x27;t address all the concerns):<p>1. I write in Rust, so my plan was to write the UI in flutter and use the rust&#x2F;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)<p>2. There is a new lib out called platform ui that wraps mac&#x2F;windows&#x2F;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&amp;f for desktop<p><a href="https:&#x2F;&#x2F;pub.dev&#x2F;packages&#x2F;platform_ui" rel="nofollow">https:&#x2F;&#x2F;pub.dev&#x2F;packages&#x2F;platform_ui</a>

I have 2 LOB on the desktop. Is Jank an issue? Only to those who have 100+ refresh rates.<p>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&#x27;t try to animate the animation.<p>Desktop ready? Corporations yes. Make the next unreal 5.x game with it? nope.

i am greatful for Flutter if only to motivate the React Native team

Not being troll-y, but …<p>NOTHING IS THERE YET<p>“There” is Utopia.<p>“There” is a language being ergonomic, ubiquitous, fast and with libraries that are awesome!<p>That is too much to expect.

I’m surprised anyone would trust their UI core technology to be something from Google. They kill projects left and right, and that was before the layoffs.

I think the guys at Rive would disagree with this sentiment. <a href="https:&#x2F;&#x2F;twitter.com&#x2F;FlutterDev&#x2F;status&#x2F;1288494688115126273" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;FlutterDev&#x2F;status&#x2F;1288494688115126273</a>

I&#x27;ve written a few Flutter apps. The problem is dart is just not a good language and not something you&#x27;d want to use in 2023.<p>The Flutter team should consider unpegging from dart and utilize JavaScript&#x2F;Typescript, Kotlin, or Swift.<p>We&#x27;ve been telling Dart team our complaints but they have been unaddressed for over 8 years now. At this point, some other thoughts include applying a garbage collection cycle and have them replaced by Carbon team or Golang team.<p>Perhaps get a new product manager, someone that will listen to the grieving (&amp; dying) dart community.

It’s been 5 years since I left my Dart team at Google. Still shocks me how slowly that world moves. There’s just no sense of urgency when AdWords revenue showers you with unlimited sums of money.

I feel like this is similar the conversations we heard about Rust and Go 5-10 years ago.<p>late edit: 5-10 years ago people were complaining about these languages having issues binding databases, network protocols, etc.

I recently tried to use Flutter to develop a Windows desktop app, and I hit a wall. Unfortunately I&#x27;m using an arm64 machine, and I ran into enough mysterious errors that I just gave up.

This article really needed to be longer and have some illustrations. What&#x27;s the point of publishing an essay about interface design without including any graphics?<p>I&#x27;m sympathetic to the points made, but as someone who has not used Flutter, I really do not have a sense of what the tooling and output is like based on this short piece.

Ok, it&#x27;s isn&#x27;t &quot;there&quot; just yet, so what? They are working on it and doing a great job so far. It&#x27;s not perfect, but nothing is.<p>I has saved me and my team countless months so far in time to ship a truly cross platform product and I&#x27;m sure there are many others like us who feel the same.

It is great to point out things that need improvement, but going so far as saying &#x27;it isn&#x27;t there yet&#x27;, seems extreme.<p>If your use case requires these specific issues to be sorted, then it is great to know about them in advance. Nothing is perfect and every single app across every single framework is going to need to make trade offs.<p>If I needed text selection to be faster than what the built in component offers, I&#x27;d just develop my own component or spend some time debugging why the existing component is slow. Flutter itself doesn&#x27;t prevent you from doing this.<p>If I needed multiple monitor support in my app, I&#x27;d probably not write it in Flutter because I looked at my app requirements in advance and realized that it doesn&#x27;t support that.<p>The rest of the post seem to revolve around not having enough built-in ways of doing things. Again... you can&#x27;t expect someone else to write your code for you and then call the whole framework lacking.

I don’t know. I have a colleague who swears by it.

2 cents from Sciter developer...<p>For the note: Sciter is an embeddable HTML&#x2F;CSS&#x2F;JS UI engine. For desktop and mobiles. By feature set it overlaps 96% with Flutter. It differs in ideology and implementation significantly though.<p>0. Dart<p>Not clear why Dart is used in Flutter. By architecture and feature set Dart is almost Java. Why the Dart then? My guess is this is an attempt to simply replace Java on Android without changing existing UI paradigms. Yes&#x2F;No ?<p>1. Desktop-first vs. Mobile-first development<p>Desktop UI is windowed one - UI may consist of multiple desktop windows: frame, dialog and popup windows. There is also a concept of &quot;kiosk mode&quot; in Desktop UI - single window spanning whole screen.<p>Mobile UI is a windowless thing - UI canvas spans whole device surface. As you see Mobile UI is Desktop UI in Kiosk Mode - Mobile UI is a subset of Desktop UI.<p>Transition of large subset system to superset system is quite hard. On top of my mind I cannot tell any success stories of that. Anyone?<p>2. Separation of concerns<p>95% of UI development these days is a Web UI that uses three pillars: HTML as a semantic UI declaration, CSS as a style declaration of UI states and JS as declaration of event flows and UI state transformations. Essentially script is a definition (declaration, again) of flows&#x2F;routes - how output of one native function is connected with input of other native function.<p>These three pillars, their purposes, are so different that their syntaxes should be different. Attempt to combine all these definition in single language is doomed to fail. If in doubts then look at WPF.<p>3. Notes on language-behind-UI...<p>If to consider #2 then such simple thing as JavaScript language and VM are quite adequate to the task. Language-behind-UI do not need to be that performant, but it must be flexible. I may express un-popular opinion but language-behind-UI should be typeless.<p>Simply put: don&#x27;t do ray tracing in language-behind-UI. But! Such a language shall have simple mechanism of adding high performant functions. There are good languages that are specifically designed for performance: C, C++, D, Rust, Zig, WebAssembly, etc. You just need convenient mechanism to expose those functions to runtime of language-behind-UI. Like here: <a href="https:&#x2F;&#x2F;gitlab.com&#x2F;sciter-engine&#x2F;sciter-js-sdk&#x2F;-&#x2F;blob&#x2F;main&#x2F;demos&#x2F;integration&#x2F;frame.cpp#L8" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;sciter-engine&#x2F;sciter-js-sdk&#x2F;-&#x2F;blob&#x2F;main&#x2F;d...</a><p>You need JITs, compilation, fat VMs and runtimes, strong types only if your language is the only mean to define algorithms in whole application. But expect that your code will always be sub-optimal - neither enough performant nor super flexible.<p>4. Conclusion<p>Flutter should be something Sciter-alike :) - use [X]HTML&#x2F;JSX, CSS and some already well known language-behind-UI. JavaScript is the natural choice. If needed you should be able to use native UI components - like in Sciter you can use existing HWND based and windowless native components inside your UI. It may not follow Web UI model on 100% (that&#x27;s impossible) but to be conceptually close so developers can reuse their skills. Web UI model is conceptually close to Mobile one - whole applications UI is constrained inside single window.

To me as someone who recently got into Flutter to make a side-project (mobile game) the most glaring problem isn&#x27;t the lack of ecosystem or little UI issues the author mentions but the language itself. You had a green field to make the best programming language for creating UIs and you made Dart? Like what.<p>I don&#x27;t have particular issue with the heavy OOP paradigm but the fact you have to write so much boilerplate feeling code (Center here, Container there) you&#x27;d imagine you could have simplified it a lot more. The documentation itself also seems like it could be improved. And some little things here and there, like the constructor syntax. I dislike semicolons as well, to me they&#x27;re just busy work.<p>Idk, you&#x27;d think an org like Google had the resources and the talent to make something truly amazing. Guess it just shows money can&#x27;t buy everything. The tooling however is quite amazing. Being able to make cross-platform apps so simply is pretty awesome (React native was a pain in the butt the last time I tried it).