I like flutter and would definitely pick it if I had to make a mobile app, but if you have to write a conditional at every step to pick the right component for each platform, I don't see the point of keeping one codebase any more. You're writing code twice, and you have to test it twice, and each underlying implementation can have its own quirks. It can only get worse if you have to work with platform-specific layouts that mean your larger views have to be conditionals as well. I can understand the impulse to have one common codebase for the logic, but these days you can do that with many languages - like Kotlin or Rust - while using the native UI toolkits. If you're writing what is essentially two view layouts, you might as well write them in the native toolkit and skip the overhead of flutter altogether.
> I like flutter and would definitely pick it if I had to make a mobile app, but if you have to write a conditional at every step to pick the right component for each platform, I don't see the point of keeping one codebase any more.
I agree that wrapping every single UI widget in conditionals and writing it twice is not a good practice, but I'd still want one codebase.
Any reasonable application architecture will separate UI presentation code from application logic code. You'd still benefit from a single, shared backend to the codebase.
I managed a dual-platform software project a few years ago. I made the call to build native apps for each because our use case didn't work well with the cross-platform tools.
Writing the UI code on each platform was not difficult, but it was surprisingly challenging to make sure the application logic behaved the same on both platforms for every possible edge case. It's easy in a small app, but as complexity grows so do the edge cases. Having a shared codebase, even if the UI code had to be special-cased, wouldn't be too bad.
That said: The app in the article appears to have equivalent layouts for most screens on Mac and Windows. It seems that a single UI library could be constructed to handle both without special-casing every single thing. I'd much rather have a library that made a best-effort guess at the right thing for either platform and then add platform-specific exceptions.
Yes! OP here, and I fully agree with your comments. Indeed, it should be trivial to make a separate package to handle picking the right UI component for each platform.
And yes, the main advantage of my approach is that I use the exact same business logic in both versions: database calls, models, settings, application behavior are shared in the codebase.
Sure, you can keep things common with one codebase, but why does that codebase have to be flutter? IMO dart is a pretty meh language, and as others have pointed out flutter doesn't even use native controls. There's tons of options for common logic in native apps these days that don't mandate a choice of view layer.
And IMO if you’re going to pick on Flutter, it’s surprising to me that you’d start with Dart. :)
I know JS is a lot better than it was 20 years ago and even half a dozen years ago, but it gave me enough PTSD over the years that compared to using JS for hybrid apps, Dart was such a breath of fresh air when I built my first Flutter app! I felt it made sense and just got out of the way so I could focus on what I wanted my app to do, and I didn’t even have to read any docs to start using it in Android Studio. And this is coming from having a lot of experience with compiled languages and a lot of Ruby in addition to JS.
Oh sure, I wanted to talk more about the "one codebase" idea - and with the state of FFI being what it is today, if you can pick anything, why pick Dart? is my thinking.
And I don't particularly hate Dart. It's fine. I've written a lot of Java so it's not much worse. But if I had free reign to choose, I'd much rather take Rust.
But for most users, do you really think they want to deal with manual memory management like with Rust? It's a UI framework not a backend performance critical one, I don't think Rust would make much sense. Dart is also compiled and gets good enough performance, at least way better than JS which is JIT not compiled to machine code.
Stateful hot reload is pretty awesome when doing UI work. On desktop that is pretty hard to find.
Also, as a TypeScript/Swift/Kotlin person, Dart is fine; sure I’d like algebraic data types but overall it is good. The tooling (auto completion etc) is great. And it has a few cool unique(ish?) features like cascade and every class is an ‘interface’.
(…Here comes the wizard of…) Just hide those system specific components behind a factory and make sure all components conform to a polymorphic API/contract.
The situation described above, abstracted, happens all the time in software. Littering the code with these system specific conditionals is a pain so encapsulate those system specific concerns in objects/components/whatever-you-call-your-lego-blocks and then use a factory to encapsulate which system specific thing you get.
The trade off is your code is a little harder to understand, but the benefit is now you can design a common ‘core’ and contain the platform specific details in bundles.
>> Just hide those system specific components behind a factory and make sure all components conform to a polymorphic API/contract.
But the entire point of having a "cross-platform" GUI toolkit is that you don't have to do that. This guy wrote two bits of code for a text input box which is one of the most basic GUI components there is after buttons.
>> But the entire point of having a "cross-platform" GUI toolkit is that you don't have to do that.
That's still true for flutter but it all depends on the requirements of the project. In the OP article, the point was to make something that is "native-looking" to Mac OS and Windows OS. This requirement does imply a requirement for different looking and behaving UI. Lose that requirement and then you can get the non-fractured code base back.
Perhaps you may reply "the framework should do that translation for you," to which I would respond "maybe you're right." It would be nice as a framework user to offload this type of work to the framework authors. Conversely, from the perspective of the framework authors they get to work on other features if they offload this type of work to the framework users.
I suspect the deeper questions for both framework users and authors is "who owns this work?" "what tradeoffs are users willing to make to gain this framework features?" and "what does joint ownership of this requirement look like?" Different framework communities will arrive at different answers.
At the end of the day as a pragmatic programmer you just kinda have to hack around the edges to smooth everything out for the end user.
In my projects when I need independent UI per platform I just extract the logic to a new component that renders the right thing for each platform. That way my views aren’t filled with conditionals the component handles it.
And this is why I think the goal of a cross-platform toolkit is misleading. If your language/library/compiler make it really ergonomic to conditionally target code for a platform, then you get the benefit of keeping your business logic in one place, and the pain only with testing the application.
Usually this is not the case, since interfacing with Cocoa is so different from Win32, for example. However, one shouldn't conflate that difficulty with the difficulty of testing an app across platforms.
Note that whatever solution you choose, you still need separate tests for every platform. Ignoring the differences between them and assuming everything is going to work the same way is a recipe for disaster.
I know modern programmers are raised to disregard design patterns because some blog said they’re dumb, but I hope nobody actually writes code like this.
It wasn't that hard to handle the conditional logic for the UI components. It can also be encapsulated in a separate package, something that is already available for Flutter on mobile (iOS and Android UI): https://github.com/stryder-dev/flutter_platform_widgets
I could also not strive to make it look native, but go with the default UI (Google's Material UI). As I explained in the post, I decided to take some extra steps and use the two UI packages (macos_ui and fluent_ui), to make it adapt to the platform.
Please bear in mind that I am a single developer, with ~1 year of working with Flutter and Dart, and my main background is web development. I think that teams with more members and experience can certainly do this for even larger in scope apps.
We find that most developers want their apps to look and feel the same on multiple platforms, with some relatively minor tweaks. Flutter itself handles many platform specifics automatically, e.g. scrolling physics, adding scrollbars, button press effects, etc.
You write components at the lowest levels with the if/then, or maybe at the page level if the pages are completely different, but many of your UIs are going to share the same code.
I think you would end up writing applications that look native, but not behave in a native way at all. We have a lot of those already. Just some thoughts:
- for an application that modifies files (e.g. a text editor), are changes applied to the file immediately or is there a separate "save" action? Platforms differ on this. Basically your internal data handling becomes platform-dependent.
- define a set of keyboard shortcuts that is consistent and intuitive, but plays well with the platform's shortcuts. You'll basically define a separate set of shortcuts per platform.
- whenever functionality overlaps with existing native applications, cooperate with them instead of duplicating their functionality (especially in an incompatible way)
> I like flutter and would definitely pick it if I had to make a mobile app, but if you have to write a conditional at every step to pick the right component for each platform
Looking at the examples given, perhaps it would be relatively trivial to wrap both these libraries into a single one where the library does the if statements for you.
My main background is web development (JS, jQuery, Vue, WordPress, etc.) and I have been using Flutter for the past year or so for another mobile app (iOS and Android).
If you want to keep one thing from this, is that Flutter enabled me, a developer with no prior desktop dev experience, to:
- Build on my own a desktop app for macOS and Windows (Linux is also possible, and I will try it).
- Solve my own problem (that's where the idea of the app came from), and the problem of a few hundred users in the past two months. Also bear in mind that it's a paid app.
- Get it accepted and published on both platform stores in a short timeframe.
- Make it look native on both platforms by using two community packages and some conditional logic. Of course, I could use the default UI design (Material) or adapt my own design system, but, as I explain in the post, I consider it a huge advantage to feature an adaptive app design.
- Do this from a single codebase, with the same business logic: database calls, models, controllers, settings, etc. are all shared between the two versions.
Thanks for the great writeup. Can you clarify if Flutter is like QT in that it uses its own GUI library to emulates the native UI of the OS, or does it actually render the UI using the native OS UI library?
Flutter provides its own widget implementations and does not rely on those provided by the underlying OS. This gives us the ability to give you complete control over scrolling, animation, theming, etc. while still running at native speeds across multiple platforms.
That's a great writeup. However, am I correct in understanding that the UI packages are not bindings for SwiftUI or UIKit? Would this "native" package then truly benefit from OS integration of keyboard shortcuts, accessibility settings etc.?
The biggest downside of Electron (or Cordova/Capacitor for mobile apps) is not necessarily performance (as proven by VSCode), but the non-standard implementation of UI controls.
For example, if I change some accessibility settings on the OS level, all UI elements in all apps implementing truly native UI components would inherit the OS-level settings. The toggle button on iOS could be set to have an I and an O for the ON and OFF state. A web-based app would not respect that setting.
So, if we talk about native, the most important part is OS-level integration of the UI. I'm not sure if Flutter really is an alternative, if the only thing you get is a bit less memory consumption and a smaller download size.
Flutter is much closer to a "game engine" as it draws it's components using Skia [1] compared to e.g. React Native that creates platform native elements. So you are right, you won't get the underlying platform's widgets. Flutter should act as an intermediary and make this as frictionless as possible though so OS level changes will be propagated or exposed by Flutter or your app directly accesses them but I have no practical experiance in this.
This is not always so cut and dry awful as you might think though. The platform native widgets also have limitations and expectations that might not fit your vision of the app so even fully "native" apps might re-invent the wheel in a couple of places to make things work as they want. Also I've hardly ever come accross an application that works by just combining the basic platform widgets and not look and feel pretty basic.
Also cross platform apps not respecting e.g. Zoom, Resolution, Orientation, A11y, etc. is more often than not, just the developer's not implementing the required things. The framework might support all of these use-cases but not fully automatic in some cases.
No, you are right. Flutter isn't really native since it uses Skia to render native platform look-alike components (as opposed to react-native which really use the platform)
As I’d guess most people spend most of their time in Chromium browsers and electron apps probably a case to make that ‘native’ in the sense you imply is Chromium!
> For example, if I change some accessibility settings on the OS level, all UI elements in all apps implementing truly native UI components would inherit the OS-level settings. The toggle button on iOS could be set to have an I and an O for the ON and OFF state. A web-based app would not respect that setting.
There's no reason (in theory) that electron shouldn't support something like that, and it could (and should) be fixed at the electron layer, which would be ideal!
Maybe a stupid question for Flutter users, but why are there two versions for every UI element in the source code? I'd expect that I initialize the theme once at application startup, and then the widget and layout engine works in "Windows" or "macOS" mode (or whatever else the theme decides to implement). What's the point of using a cross-platform UI framework if I need to duplicate the code for each platform?
> Maybe a stupid question for Flutter users, but why are there two versions for every UI element in the source code?
The author is using 3rd-party UI libraries that have each been designed to be platform-specific.
Traditionally a Flutter app would use the built-in UI components that are not platform specific, but then you end up with a Material-style look and feel.
There's not actually anything stopping the app from running with the macOS style UI on a Windows machine or using the Windows-style app on the web platform because they're all inherently cross-platform. In fact, the Windows-style UI package actually has compiled to Flutter web and you can use it straight from your browser: https://bdlukaa.github.io/fluent_ui/
The decision to build separate UIs for each platform was the author's choice, but it's not a traditional Flutter practice.
If you're happy with the UI looking the same on each platform then you don't need any duplicate code. E.g. I used to have a Android+iOS app that was Material UI, so on iOS it looked like a Google thing and less like something that was Native Apple.
If you want it to look native on each platform (and this is key) you need to write different code anyway. MacOS and Windows design rules behave sufficiently differently that some of your UI logic will need to be different on each platform - it's not just a different skin that can be abstracted away.
Flutter itself doesn't magically do anything for you - it doesn't care what platform you're running on because it does all its own rendering. It'll perfectly happily let you build a Mac looking app on Windows. It's then up to the libraries that you use (or create) to do whatever you want and abstract away whatever cross platform details.
The point I am trying to make is that Flutter is doing the right thing here, but the ecosystem is still maybe a bit limited.
It makes sense if you have significant code that's not UI-related.
IIRC, Photoshop is implemented this way - there is little code reuse at the UI side, but the bulk of the program is platform neutral. I had Photoshop (2.5) running on IRIX on my desktop for some (very fun) time.
I too had Photoshop running on IRIX way back when. As a matter of fact, it saved my butt on a job where I had a massive file for a poster design, and it would keep crashing on my PC whereas on the O2 with an older version of photoshop it just chugged along slowly but surely. It was an exercise in patience, for sure, but it also ensured I could deliver on the job and ultimately get paid!
The peer widgets seem to have many differing properties. Compare the two AlertDialog widgets. You'll see they are very similar, but not at all the same:
There are some UI elements you cannot generalize, yes. But there are definitely some that you can. There is no reason you cannot have an abstract text input control with different native widget implements. wxWidgets has been doing it successfully for decades now.
I've been doing some work with Flutter on Linux and I've been really impressed. I like Dart as a language, the VSCode support is superb, and Flutter seems well thought out. The two UI packages mentioned in this post look great too.
Dart (2011), TypeScript (2012) and CoffeeScript (2009) and arguably Haxe (2005) all competed in the same space. Google made a optics mistake embedding Dart into Chrome - people feared antitrust, but it is a significantly better language to use than JavaScript.. it's disappointing how that played out. Usability wise, Dart is similar to TypeScript, in many ways better (real type safety, null safety, not being hamstrung by down compiling to JS). Dart feels closer to C# in syntax, style and language features.. TypeScript is also trying to travel that way, but syntax is different, and it's still hamstrung by JS.
Dart as a platform provided the unique ability to target both JIT at development-time to enable sub-second hot reload and AOT for release apps, providing native performance when it comes to scrolling, animation, etc.
In case you're wondering why 2 separate widget sets, it's only needed if you want to follow each platform's look and feel.
If you don't care, or if your app has its own L&F (e.g like Spotify app), you only need 1 widget sets (which you can adjust the theme).
As others have pointed out in the comments, Flutter is drawn like a game engine, as in everything is drawn on a canvas, so at the end of the day it's just drawings, not native widgets.
> Flutter is drawn like a game engine, as in everything is drawn on a canvas, so at the end of the day it's just drawings, not native widgets.
How well does that work with accessibility features from the different operating systems? I never used Flutter or an application written with it, I just remember the horrible experience of using Gimp and Inkscape on macOS, and the lack of support for native accessibility features can be a pain.
There's ongoing work on the Windows implementation here, which is tracked in https://github.com/flutter/flutter/projects/209, but this is supported on macOS, Linux, phone and web platforms.
I appreciate the time and knowledge that went into this, but I feel like I need to say that when the time comes I am absolutely going to start avoiding Flutter-based "native" apps just like I'm currently avoiding Electron based ones. I don't like what they're doing and I won't be willing to spend any money on them.
Same. I know I'm probably just being a grouchy crank, but I wish there was a "Awesome Not Electron" list featuring only true native apps. I've recently migrated back to Linux after 10 years full-time on Mac. I am often looking for an open source replacement for something, e.g. Apple Notes. I cannot believe how many "native" note-taking apps there are and how few of them aren't a shell wrapping a web app. At this point whenever I'm considering adopting a piece of software, I first check if they have a "native" app for all three major platforms (sometimes plus web), and if they do, I take a peak at the git repo. If it's mostly written in JS, I assume it's an electron app and de-prioritize it on the list of options.
Almost all cross-platform apps that are available on linux these days are electron, so that makes it tough to do what you say. I tried it myself - I can't stand apps taking up resources in the background disproportionate to what they're worth - and had to go back on it pretty quick. It's either cross platform electron apps or linux-first native apps.
Yep. I've been learning the same lesson. I'm actually rediscovering all the things I loved and hated about Linux 10-15 years ago when I was on Ubuntu full time. The janky, unpolished, hodge-podge look and feel, but super snappy and configurable apps are more endearing this time. The inconsistent UIs between Qt, GTK, etc don't bother me so much after a decade of web-first UIs.
Good news for companies, bad news for the users that have reduced responsiveness and uniformity. Many people might not have the vocabulary or knowledge to distinguish native from quasi-native apps, but they certainly feel the laggy and inconsistent UI.
The only claim is in that post is "I won't buy or support Flutter based pseudo-native apps" and I believe in this case "I don't like what they're doing" is very valid, since the whole post is clearly highly subjective.
On the Mac side the traffic lights have no anti-aliasing
On the windows side the maximize widget is messed up and there is a stray 1pm border top left.
If "native looking" is your goal then please take screenshots of your faked window borders and widgets and overlay them over the real thing and see where you went wrong.
If you want to go this route, I recommend exploring react-native as well.
Microsoft maintains desktop versions for Windows and macOS which are pretty functional. And you don't need to create 2 entirely different UI layers (which kind of defeats the purpose IMHO) - you'll be able to share 90% + (closer to 99% if you don't care about re-arranging content but still getting native controls for each platform).
+1. The main advantage of Flutter is the write once run everywhere, which is apparently not taken advantage of here.
If you’re gonna try to emulate native on multiple platforms, go with React Native and not Flutter. Especially on Apple’s platforms flutter is always going to feel a little bit off compared to native applications.
Building can be a hassle, as you can only produce the release version on the host machine. This means there is a bit of back and forth between my Windows laptop and my iMac, but it's expected.
I have had pretty good luck banging out a glorified calculator app for one of my products using flutter. Started from zero with flutter/dart and had a workable app in a couple weeks.
The code is pure crap since it was written while figuring out the framework. But easy enough to refactor into something more reasonable.
Now to add OTA updating over bluetooth for an ESP32 device to the app.
It may not matter in this context but did the flutter team ever figure out jank on iOS especially first run? Something always seems off with that vs native. This was an old issue, but they seemed to struggle with addressing it / or it wasn't needed for their use cases.
> Hi all. Flutter engineering lead here. Thank you for the bug.
> ...
> I've retitled the bug to specifically target the blinking cursor issue. I don't expect us to attack this soon, but it's on our radar. The best way to indicate your support for this or any other issue is to use the +1 button.
I don't get prioritizing based on 'popularity' contests. To me, 'a blinking cursor' taking up 10% CPU and 50MB RAM doesn't sound like a bug that needs one.
Imagine having 1000 open bugs that are all of that level of severity/urgency. When the house is on fire and being knocked down by a tornado and a meteorite is coming for it, you really need some other criteria besides "disaster" to decide which disaster to address first.
That's a bit silly as web browsers are already using dirty texts and the system compositor to reduce power usage and they have to deal with arbitrary HTML, while flutter apps mostly(?) use standard widgets which they control. Though I think the response was less "it's unfixable" and more "it will be an enormous amount of work so it isn't happening any time soon."
I've been pretty excited about the possibility of using Flutter in the future potentially, once it gets good, that issue got my hopes down a lot. You know a project is not in good hands when they say spending 6~10% of the CPU for rendering a blinking cursor is justified.
I was excited about using Flutter "when it got good" almost 2 years ago now. At this point I just go for React Native if I need an app for mobile and web, and React if I just need a web app.
That's a practical solution, but IMO React is playing a fundamentally different game here, they have Native for mobile apps, and third-party (!) support for Windows and Mac (what about Linux?). Native doesn't even support the web, like React and React Native are two different things, they just share a somewhat similar UI framework basically.
Flutter on the other hand is architected as a solve-it-all solution. They even went as far as designing Dart rather than hacking a decent solution on top of JS and the current mess of web standards. IMO that's a much more interesting and powerful approach, that isn't fully ready yet, but if it ever becomes actually good I'll personally probably jump ship and use it for everything.
And that’s the biggest issue that Flutter has IMO. They first launched the mobile platforms, which where in decent shape, then they came out with Flutter Web, which the last time I checked is still not in any place where it is actually usable, then instead of fixing it they just started adding desktop support.
Like man just calm down and stabilize for a moment, it’s not an arms race.
In my mind Flutter isn’t native to any platform rather than all of them, so I like React Native much more these days.
React Native Web exists [0]. But I agree, having parts be third party doesn't mesh well with being a complete framework for building apps (on whatever platform you need).
It exists, but it's a third-party thing, the value proposition here is not the same, Flutter plans to address to entire problem itself, React Native is only concerned with mobile basically, for everything else you are at the mercy of a third-party, which among other things may just stop maintaining the very platform you depend on, how can one build anything serious on top of that?
Yep agreed. I tried to once wrangle together all the React frameworks to make something like what flutter offers, but in the end I gave up and used Flutter just because of how easy it makes it to run everything cross platform. Since the RN versions for desktop are third party, I didn't have much confidence in them being supported well, as you said.
The Facebook team has alluded a number of times about making some of the “third party” platforms become first class members of react native. They haven’t officially announced anything but I’m guessing Microsoft’s work on react native for Windows/macOS will be folded into the main repo at some point in the near future. Facebook (seemingly based on git commits) has a number of full time employees collaborating with Microsoft on the Windows and macOS ports. Facebook messenger for desktop is already built with it.
I haven’t seen any type of movement on react native web becoming something official, but it works amazingly well at the moment and is in use in production at Twitter.
We just need a Linux port and the react native ecosystem will be pretty complete.
RNW actually has about three teeny tiny customers that no one has heard of except for the Microsoft Store on Xbox. So much for Microsoft's "Universal" Windows Platform! Lmao
I've seen the same posts you have linked and can only conclude that they've currently been using either React Native for Web or are using a React website in an Electron app, and are planning on releasing a RNW app. The current app could perhaps be using RNW but targeting win32.
There's some suspiciously React Native macOS looking components in Messenger for macOS (native macOS text boxes, native macOS blurred backgrounds, etc). I'm thinking this is either fully React Native, or they have some sort of RN/Electron hybrid going on (which is a thing, apparently).
yeah idk about the macos app personally but i can say that the windows app is definitely electron. at least last time i checked.
by 'react native' i'm guessing you're referring to RNW, although a port of their iOS app is possible
Facebook had previously just used a port of their iOS for their Windows app too.
I think we need a new acronym. RND (React Native Desktop)? Microsoft is doing React Native for macOS alongside of React Native Windows. The macOS port is a little bit behind the Windows one, but actively being worked on by Microsoft and Facebook employees, afaik.
I've never seen a Xamarin app running on the browser, is that a thing? As far as I'm concerned the web is the most important platform I care about, if a framework doesn't support it at all, like perhaps the language used isn't even compatible with the browser, then I'm not personally interested in it.
I think that's why a lot of people are hoping for strong Blazor/MAUI alignment. I wish I liked Blazor better myself but I don't, it reminds me too much of the bad parts of ASP Classic wearing the skin of ASP.NET. Seeing the turduckens some of the hopeful are building of Blazor Razor Pages hosted in MAUI are interesting for sure, but partly in that way that I'm expecting a horror jump scare to follow.
(ETA: Sorry, that sounds way harsher than I intended. Waiting for coffee to kick in.)
I love the idea of Flutter, but tying it to Dart just seems like a way to guarantee it'll have a long slog to getting larger-scale usage. It feels like Google had a language that had no users and had to use it for _something_.
Dart as a platform provided the unique ability to target both JIT at development-time to enable sub-second hot reload and AOT for release apps, providing native performance when it comes to scrolling, animation, etc.
I'm kind of curious why they haven't tried to bring Go to more domains. Back in 2015 I thought by now they'd have released a framework for building Android apps in Go.
Dart came out the same year as Kotlin.. it's not like this decision was made this year (they're both 10 years old).
Re: Sibling comment it really is an order of magnitude better than many other languages. It's worth giving a try. Null safety alone is worth it (although other languages like C# now support this too).
I think Flutter is going into the right direction. I developed some apps with it, it has rough edges but it gets you there. Dart is ok language, no issues for me going with it.
My only complaints are as follows:
- the dart formatter which is a cancer that wants to do things in only one way. The forced 2px indentation for example is unbearable for me. The maintainers are close-minded and refuse to understand that some people cannot operate with 2px indents. They will even delete your issues/comments at this point.
- Flutter is backed by Google which likes to anihilate, sometimes without warning, projects that don't go as planned. It is open source but still, without Google backing it, it would have never left the ground maybe.
I always thought spaces are either tabs or spaces. Wym 2px indents? Also Flutter is a framework based on dart. Its like saying Django doesn’t support braces instead of indent based syntax. Its how language decided it works no cancer there.
Also even I was sceptical about google cemetery. But at this point flutter is widely used and is fully open source and licenses.
It will not drop dead like Google services. May be no more bugfixes after its final release.
