> We describe Flock as "Flutter+". In other words, we do not want, or intend, to fork the Flutter community. Flock will remain constantly up to date with Flutter.
That was the first fear when I saw the title - splitting community and having two incompatible versions. Good to see it addressed in the post.
The second was just a fear of how it would complicate the development process, but it seems to be a drop-in replacement (just configuring FVM - Flutter Version Manager):
Configure .fvmrc to use Flock:
{
"flutter": "master",
"flutterUrl": "https://github.com/Flutter-Foundation/flutter.git"
}
Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell. And the frustration described in the post is felt by many CTOs and developers. Especially those who use Flutter for desktop and web. Flutter provides an amazing experience for desktop apps, and precisely because of that, it feels so frustrating when you stumble upon some stupid bug that has been open for a year or two and never gets prioritized. Usually, it's nothing critical, but still requires workarounds and wasting time.
I don't know, the idea of Flock sounds good, the main question is engaging the community. Hopefully, the author (who seem to be an ex-Flutter team member himself) have a good grasp on the state of the community.
Wishing luck to the project and going to keep an eye on the progress.
> Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell
You can't be serious. Maybe on Android, but on other platforms—especially iOS—they stick out like a sore thumb.
A number of them just look like Material Design Android apps awkwardly transplanted over, but I know that's down to the developer so I won't hold that against Flutter. But scrolling through the Flutter showcase[0] and calling those apps up to look at screenshots on the App Store—none of them look like native iOS apps. They don't look bad (mostly), but they don't fit in.
Don't get me wrong, I don't expect anyone else to care or even notice. But for those of us that do care, you can absolutely tell.
Sure, but not every cross-platform app developer wants their app to look "native to iOS". Especially if you want your app to look the same on all platforms and/or have some creative design.
I can appreciate that as a developer, but as a user I don’t particularly care that some company wants to ship identical looking apps on every device under the sun.
I would prefer the apps I use to work and behave in a consistent way, using the same platform idioms I am used to. The software available and how it works was a large part of the reason I chose the platform I did.
Of course, I recognise that, a. most people just don’t care about platform idioms, and b. the choice is often a non-native app or no app at all.
Pretty sure most large succesful apps have their own UI and UI design teams. Cant remember the last time i saw anything cupertino in an app. Even Apples own 'Home' app only loosely use cupertino. Id say the most noticable effect is the bottom modal sheet slide up effect. on ios the original screen animates into the background a little bit. Apps that dont implement this can be spotted but thats not unique to flutter at all and flutter even offers a pretty good cupertino scaffold package that does this animation.
"cupertino" is the name of a Flutter widget set, not of the native platform controls or L&F.
Few Flutter apps are going to use cupertino because the whole goal of using Flutter is to create cross platform codebases to save development effort. To use an alternative widget set per platform is a huge amount of additional work, and having a cupertino app running on Android is even more of a sore thumb than a material app on iOS.
The two things that stick out the most to me are navigation behavior and text fields. Cross platform frameworks seldom get either right, with react native being particularly bad on the navigation front.
There are variances between Apple’s apps but they’re all using some combination of UIKit and SwiftUI regardless which limits how “wrong” they can be.
You’re completely right, but that doesn’t change the fact that I think it’s a bad idea. For a company that used to care so much about user experience, Apple has been throwing a lot of it out the window in recent years.
Only on HN do I hear anyone talking about platform native controls versus unified UI across devices. I have not once heard of such a complaint in the real world and indeed, I have more often heard users wanting a unified UI over one that changes with each platform, simply because these days we have multiple devices where we expect apps to work the same.
You have to listen to the details, like "where is the back button", "Why does text work differently". There are some people that understand that it is different from the standard, but most just get annoyed. The discussion here is from a technical perspective why it is better, conformity of the app on different platforms vs standard behavior between different apps. There are very few people that care about the technical reasons why, but when you talk about the annoyances it is easier.
I'd also like to meet all these mythical users that have devices from every platform and want all their apps to look the same across all platforms. 99% of people I know IRL are in one ecosystem, with the exception of some that have an iPhone/iPad + Windows PC
In a previous company when we were looking at precisely this problem, building out multiple platform support, we did UX studies where this question in particular came up. The vast majority of people said they wanted apps to act consistently across devices. Most people on the planet use Windows with Android, statistically speaking, which are not similar devices at all, at least on Apple platforms you can use Swift for desktop and phone but not so for Windows and Android, so you have to make a choice at that point.
> The vast majority of people said they wanted apps to act consistently across devices
You shouldn’t trust what users say they want. It many times doesn’t correlate with what they want. Certainly, I would try and figure out what they mean with “act consistently”. My suspicion (for which I have zero evidence) is that they’re more talking about high-level similarity than about nitty-gritty details such as how many milliseconds to hold your finger down to select and edit text, how scrolling works, etc.
Also, I suspect they want devices to act constantly across apps, too: copy-paste should work, text editing should behave identically, sharing controls should be the same, etc.
In the current world (and, I think, in any world where there is competition in any form between platforms), they cannot get both, so then, it boils down to what is more important.
For me, that’s platform consistency. For example, I find it easier to get used to text editing being different on a phone and on a laptop than to get used to a zillion minor inconveniences/annoyances in typing and editing behavior between apps.
I also find it less of a problem if text and emoji look slightly different on a different device than when they look slightly different between apps.
If you have zero evidence against the mountains of evidence I do have, why should I be convinced of your argument. It seems like it is you who are talking subjectively about what you want and then applying that to everyone else.
I find it very hard to believe that majority of people prefer app consistency over platform consistency.
One example, I'm pretty sure there are thousands more: Why does every UI detail, except the logo, of Spotify looks and feels different in Android, Android Auto and PC/laptop? Because Spotify did not study what the market wants?
Spotify looks much similar between devices than it does to any specific platform. Does it use Material on Android and Fluent on Windows? No, it uses the same sort of styling on both. Don't mistake UI changes for screen size responsiveness, for actual platform specific nativity.
> The vast majority of people said they wanted apps to act consistently across devices
... which you can absolutely do while using native UI controls. "Act consistently" (UI controls are in similar places and present themselves with similar UX) is not the same as "look consistently" (UI controls are drawn using whatever system theme or drawing style is in use).
Certainly there is some overlap between look & act: a platform-native "dropdown menu" looks and acts a little differently on Windows vs Android vs iOS. But I think these differences are not in the majority, and when users say they want apps to "act consistently" across platforms, you an absolutely achieve that with native UI controls, and it's not even that difficult.
This is a big problem I've run into when doing user studies myself: you need to be very precise with your language when asking users questions, and even then you often need to dig in and ask for details about what they mean by their answer. And of course having visual examples and functional mockups for users to play with helps a ton.
Another problem is the leading nature of questions you might ask during a user study: if you simply say "do you think it's better if the app acts consistently across platforms", of course users are going to say "yes". Saying "no" to that question feels kinda stupid, TBH. But if you were to give a user an iPhone and Android phone, with the same app, using native controls on both platforms, and ask them if you believe that the apps "act consistently" with each other, users are probably going to say "yes", as long as the design and UX of the apps in general are consistent with each other.
(And even that's a contrived test: very few people use both an iPhone and Android phone regularly!)
You can achieve them with native controls but only at the bottom-most layer, if you actually want consistency. Spotify for example does not use Material on Android, Human Design Guidelines on Apple, and Fluent on Windows (well, they use Electron, bypassing native desktop entirely), they use their own custom controls that may at the very bottom layer be based on native text inputs, but they rebuilt all the actual UI stuff from scratch to achieve a unified look and act.
This is all well and good but the people I see on HN are ones that say that the app should actually look native on each platform, ie Material on Android etc. This opinion is what I'm pushing back on, not the fact that ctrl + C works on Windows and CMD + C works on Mac.
Of course, this is the reason why cross platform frameworks are so popular, if you're already gonna have to rewrite the UI for every platform, why not just do it once and save yourself the effort? After all, users won't care, as they've shown, because they care much more about new features coming out. There are always tradeoffs because time is finite.
> This is a big problem I've run into when doing user studies myself
Sigh, do you really think that all of these weren't considered when we did user studies? This is like 101 material, frankly almost insulting to imply that we didn't, therefore it can justify your priors, even though I agree with your points to some extent as said before.
It's not the end users that care about the uniformity but the fact the corporate design team wants there to be uniformity across all their platforms they support. This is part of branding and user experience. I'm not arguing for or against, just stating that is where the push for this comes from. It would make support, for example, easier, if all versions of your app user experience were similar.
This is very true, and it's a PITA when the corporate design team doesn't know anything about mobile design and thinks mobile apps are just "Honey, I shrunk the web app" with some Figma plugins to help. It can be an uphill battle to get them to compromise.
It's because while it's true on the company side, this comment is making it seem as if the company is doing this against their users' will, while in reality, most users genuinely want a unified experience across platforms for their apps, as seen by some of the comments here.
It doesn't seem to mention it being done against anyone's will. It's definitely true that a company can save money by only needing to maintain one set of help instruction screenshots, for example.
Ever since the release of the M1, the number of Android users who now use Macbooks as their laptop has sharply increased. Even moreso for work purposes.
Hello! I use three platforms on a daily basis. I vastly prefer my apps to be reasonably consistent with themselves rather than trying too hard to adhere to the platform.
My wife is on two. Most of my friends are on either two or three. In fact, I'm pretty sure my parents and a few coworkers are the only people I know who are exclusively on one platform.
Many (most?) people don't have a clue as to what the particulars of any given platform even are. They know how to get around in each app they use, and maybe the web browser, and that's it. Lots of gestures go completely unused.
> I'd also like to meet all these mythical users that have devices from every platform and want all their apps to look the same across all platforms.
It's not even a single person that has them, but I think we have all had the experience of family or friends that need assistance with something but they have a different type of phone whose organization and workflow is completely different because it's native. You literally can't help in this scenario without having physical access to the device.
I've genuinely never heard of such annoyances from actual users (at least not from most users, who aren't power users, and even then, not even from the power users), and most cross platform frameworks already hook into the native APIs like for the back button, so it'd work the same either way.
Out of interest, do you know many seriously vision-impared people?
Windows, and Mac OS X in particular, have quite good support for accessibility if you use their built-in GUI systems, and unified UIs are often (not always, vscode and chrome are quite good, for example), very bad, sometimes just a black square as far as accessibility goes.
Many cross platform frameworks have good accessibility support, not sure what that has to do with native platforms, as the cross platform solutions simply hook into the native platform accessibility APIs anyway.
I didn't know flutter had such good support, and I'm very happy to hear about it!
Unfortunately, most cross-platform frameworks have awful accessibility support, I've looked at various in the past and just found failure after failure. I am now going to look harder at flutter.
People have multiple devices, sure, but in my experience (among non-HN people) it's iPhone+iPad or iPhone+mac dominating, with a decent contingent of iPhone+Windows, and rarely Android+Windows. (This is of course US-centric; the iPhone is more popular as a mobile platform, and that often entices people to buy into other aspects of the Apple ecosystem.)
It is exceedingly rare for the multiple devices to span the UI toolkits of more than one or two company-platform. For people in the Apple ecosystem, they don't want to see something that looks like it belongs on Android.
Regardless, "unified UI" doesn't mean it can't use native controls. More important from a UX perspective is that controls are in the same places and behave similarly, and that the app is organized in a similar manner, plus or minus what might naturally change because of differences in screen size and input method. And that's another useful point to make too: mobile, tablet, and desktop experiences are often quite different, and that's normal and expected at this point.
Another consideration: it's a lot more difficult to make an accessible app when you draw your own custom UI controls with your own custom behavior. If you use the native UI controls, you get a lot of the accessibility features for free, and have to do much less work to make sure everything works for people who are vision or mobility impaired. From what I understand after reading about blind people's experiences on various platforms, most companies that do custom UI don't bother, and the accessibility of their apps is atrocious.
I think you made the same points twice so refer to my other reply regarding your first few paragraphs.
> For people in the Apple ecosystem, they don't want to see something that looks like it belongs on Android.
I have not seen evidence among normal people that this is true, given that the most popular apps all have custom UIs that don't necessarily follow Apple's HIG, TikTok for example. Regardless, the point is that if you're making an app for every platform like iOS, Android, Windows etc, you must make a choice lest you exclude all non-Apple users for example. ByteDance does therefore indeed use Flutter, based on this (at least in some capacity).
> mobile, tablet, and desktop experiences are often quite different
Don't conflate unified UI to mean non responsiveness. Look at Spotify, their UI is essentially the same in design except it is responsive among mobile, tablet and desktop, all while not looking native at all on any of them.
Regarding accessibility, many frameworks can be robust in that simply because they hook into the native implementation anyway, so I'm not sure where this trope of not having accessibility comes from. Here is Flutter's for example, with a dev in this thread also having talked about how they have one of the most robust implementations of accessibility that they have found among any framework: https://docs.flutter.dev/ui/accessibility-and-internationali...
I think the problem with the same app following native app idioms is that now the support and instructions behind that app will have to be different on every platform.
E.g., if you have Instagram on your iPhone, an Android user won’t be able to tell you “just click on this, this, then this to change your XYZ setting” because it will be in a different place than the Android app if developers follow native conventions 100% of the time.
The fact that Spotify or Instagram or any of those other platform-agnostic apps look and function the same on every platform is a huge benefit to practical usability.
I think the only time when nativeness matters is when you have an app that’s doing stuff that’s closer to being “low level” to operating system features. For example, an app that performs file system management, I don’t want that to have the exact same UI on Mac, Windows, and Linux, because those platforms have different conventions for where things go and how files are represented.
> I would prefer the apps I use to work and behave in a consistent way, using the same platform idioms I am used to. The software available and how it works was a large part of the reason I chose the platform I did.
There are DOZENS of us!!!
I try my absolute best to find apps that use the native Apple language, both design and code. I can't stand these framework apps. I will Pepsi challenge this with anyone who asks, I can smell a framework app.
> I will Pepsi challenge this with anyone who asks, I can smell a framework app.
The platforms ship with things like keyboard shortcuts for navigation and text entry, minimal accessibility features like screen reading of text and navigation, common idioms like drag and drop and the clipboard - none of which are typically handled by cross-platform widget frameworks by default.
Only gigantic projects like Chrome and VS Code will take on the effort of (partially) reimplementing these in their codebases to match platform behavior.
Do you only use Apple devices? That may be why, because statistically most of the world's population uses Windows and Android where there really isn't a concept of "native" because they each have a few different UI frameworks.
Do you hear people complain that __websites__ have different aesthetics?
I used to share your opinion but since the web I think it is great that designers can have original designs and I started to worry about more important things.
I agree. What doesn't get enough attention in these often dogmatic debates is that there are some native conventions that are hugely important for usability while others are mostly irrelevant.
E.g, I have to use a Java app on the Mac that uses Ctrl+V rather than Cmd+V for paste as well as other Windows/Linux keyboard conventions. This is extremely jarring.
Web apps never do that. Browsers are pretty good at using native conventions where it matters by default. Of course web devs sometimes go out of their way to vandalise the browser's perfectly good defaults - e.g. by overriding scrolling behaviour.
Surprisingly, some of Apple's own native apps (such as Numbers) break platform conventions in ways that makes the app extremely inconvenient to use.
The web is interesting because we never had rich components provided by the browser to begin with. Web applications have always had to draw everything but the most basic inputs themselves, and the design of web apps has evolved accordingly.
In an alternate universe, where web apps were embraced by the platform from the start rather than something people had to shoehorn into a document sharing mechanism, and we had rich components built-in, then yes I would probably be annoyed if people insisted on rolling their own versions. After all, I am annoyed when people use a span with a click handler instead of a proper anchor tag, because it usually breaks middle clicking or opening a link in a new tab—a platform convention I have internalised and expect to work.
Note this only applies to web apps, not sites. Much like how I do not have any problem that magazines don’t share a common layout.
> Of course, I recognise that, a. most people just don’t care about platform idioms
This is the big one. HN commenters are not representative of the average user. You'd have to specifically point out the differences for them to even notice, and even then they simply don't care.
Casual users do care about app behaving wrong, though.
If you can't copy or paste things, or if the navigation is backwards, or if the calendar looks weird etc etc - it all causes some minor frustrations, when things don't behave as user wants them to behave.
They don't know what "native" means, obviously - they don't have that knowledge. They just know crappy apps from well-behaving apps, because they have a frame of reference (vendor-supplied native apps).
Is there a concrete example of this? I still only hear this on HN where some mythical user gets annoyed about copying and pasting (most apps don't allow that, even, like TikTok or Instagram, which are the apps where most users spend the most time). Like the sibling commenter, I only have seen whether the app does what they want or it doesn't, most don't notice any annoyances unless they're really looking for them, which they're not.
> I still only hear this on HN where some mythical user gets annoyed about copying and pasting
Perhaps they're not complaining because they've just accepted that it probably doesn't work and so don't even try anymore.
My SO has stopped trying to copy/pasting stuff, I now always just get screenshots, both from mobile and her PC.
At work, almost none of the customers I interact with copy/paste stuff, they send screenshots as well. Like, "can you send me the order number?" will result in a screenshot of the order number control, or often just the whole order window.
The trouble with this is most users only use one platform and so don't care. They just see the app as badly implemented as it does not match other apps on the platform.
What kind of users/apps are these? I'm genuinely curious about this, actually. I have a couple of apps with 100K+ installs, and I talk to people who are actual users from time to time. I have never ever heard the claim that they don't like UI because it doesn't feel native. Like ever. But I can imagine that in some niches/demographics/app types it might be different. Can you share some evidence or explain how you built the understanding that users dislike non-native UIs?
I've built apps with pretty high retention rate so even if they're annoyed, it doesn't seem like they really stop using them. Mostly though, based on user feedback we collected, not once have I heard anything about UI complaints. It really feels like this is a common refrain on HN about what HNers think happens in theory versus what actually happens in reality wrt user preferences.
Note, this has nothing to do with your app or this specific discussed GUI, but this is something I have noticed over time...
I think that what is commonly seen by devs as complaining and being overly concerned with details that don't matter is instead a some of the time advocacy for doing things the right way for the sake of it. It is totally possible to build things that meet the bare minimum requirements for user retention and for people to not complain, but that doesn't mean that it is optimal. You can build Soviet style housing blocks that people live in that are completely functional and that no one will have any problem with, but the quality of life is degraded as opposed to what could have been built.
It can be tough seeing through the grumpy nerd 'I want it my way because my way is best' and finding what is actually 'this is a good thing that we should be doing, and if we did there would be a marked improvement for everyone', but I would not forsake one due to the other.
It's more than there is no evidence of an issue, so why pretend that there is? The "right" way is entirely subjective, unless you can give me some objective criteria for what it should be.
The issue in this case is pretty plainly that the application does not subscribe to the conventions of its host UI. I'm sure there is no objective reason why we need to conform to any convention, except that there is one.
Then that is subjective too and not really worth caring about, because it comes down to a matter of taste. You like platform conventions, but most people we surveyed simply don't care, the fallacy of vocal minorities and all.
Perhaps so, as different cultures have different tastes anyway. That you don't like Soviet styles is no indication of whether people in the Union did or didn't like them.
Not all non-native-looking apps are badly implemented, but a huge number of apps that use cross-platform frameworks do so primarily as a means to cut costs because the goal is to make development as cheap as possible, and that shows in other aspects of these apps too. This creates an association between cheap/lazy apps and cross platform UI frameworks.
It’s kind of like the difference between VS Code and MS Teams. Same company, same underlying technology (Electron), but Code is good while Teams is awful because MS invests so much more in Code. Even so, Teams-type apps are what tends to come to mind when people think of Electron apps because those are so much more common.
You could not be further from the truth regarding the size of the Teams vs VS Code teams. Teams has multiple times more developers, it's not a problem of funding that makes it suck.
In those cases, those app developers aren't doing cross-platform development, but are just trying to dump their app in as many places as possible. In such a case, why not just make a PWA and call it a day? Don't need an app if you aren't going to go native, especially with most apps being either content readers or CRUD apps anyway.
In most cases, I personally rarely want an app, and I'll use a website unless they happen to have created a great native experience. And since most apps don't, I don't use them, and I don't have a lot of apps as a result.
That is exactly the reply I was hoping for. Because that brings us straight back to the native issue; users also expect the app to work in a way that is comfortable and known to them.
As an on-again off-again (currently off-again) cross-platform app developer, I always want my app to look like it fits in with the rest of the apps on whatever platform it's deployed to.
As a user, I hate it when some app developer thinks they're cute and wants to skin an app differently or draw their own ad-hoc widgets.
Developers who think that way have no clue what their users want. Most iOS users want a native experience, not something else. When I see an app that doesn't have that, I quickly lose interest. Having the app look the same on all platforms is a dumb idea to start with.
I noticed the SNCF Connect app for France's rail was using it in their showcase which explains why the scroll views are so weird and busted feeling. They still stutter on a new iPhone. As a native iOS developer I'm somewhat biased and a lot of people likely don't care but it still feels off to me even for apps that use a complete custom design. I hope they can optmise away those kind of issues more as it's IMO always better to have alternatives.
Side note: Is anyone using Flutter just for Android? I'm kind of tempted to try this as dealing with the Android build system and packaging is bit of a pain, despite Kotlin and Compose being quite nice.
You still have to deal with the Android build system, `flutter new` just generates initial config for it and all the other necessary metadata (and that config can change between versions - I ended up manually diffing the generated stuff against a new app every time I upgraded).
At some point I made the mistake of not touching the code for too long and upgrading Android Studio when suggested, and I was never able to (find the time needed to) get that app working again.
> but I know that's down to the developer so I won't hold that against Flutter.
That is absolutely an issue with Flutter, which throws away the underlying platform UX and draws to a canvas. It gives you relatively few tools to target "native look" controls for each platform without maintaining multiple UIs in parallel composed of entirely different widgets.
Typically people just make the app look and work the same in all platforms, like how you might expect a responsive web app to be like; no one is implementing Notion with a platform specific UI, for example, using Apple stuff on Apple devices or Windows stuff on Windows devices.
You may notice that the first reference is from java, and i bet js lifted it from there. They may have been aware of java because they lifted the name too.
That is good to hear and hopefully gets fixed. It has been some years now, but I did use flutter for some toy projects and liked using it - I am used to using ReactJS I found there was a lot of transitive knowledge coming from that background.
Ultimately what dissuaded me from pursuing it for any bigger projects is a lack of examples of great looking production apps with complex requirements. When I was looking, I was seeing a lot of CRUD apps - display a form, click an upload button, ect. This was probably 2018/2019 when I was taking a serious look at it.
All of that is to say: Quality app showcases do matter for whether or not devs will trust a solution enough to pull the trigger.
I don't know how to fix the showcase problem. With web apps, it's easy – just scan HTML, deduce what framework is used, and add it to your showcase list. With Flutter mobile/desktop apps it's not possible. And there are zero incentives for developers to send their apps for screenshots. You just ship the release and move on to the next tasks.
I also discovered Flutter in 2018, and it kind brought joy into UI programming for me. I rewrote all web apps I had with Flutter and published a bunch of mobile apps, but the coolest thing is that I routinely make apps for my own (or my team's) use.
For me, Flutter lowered the costs of UI app development so much that I could just spend a weekend making some neat, small, practical tool for my own needs. I really love making these "private" apps – no need to care about all corner cases for all users, no need to polish design for all screen sizes/font sizes. Don't even need to be released (TestFlight at max, if doing it for a team). It's just fun, and I wish more developers could have the same experience.
This is trivial for any team that provides a framework/platform and spends any amount of time engaged with their customers - you know who your prestige customers are and you show off examples of the products they have built with it. The state of the showcase is just reinforcing the points made by the OP.
> With web apps, it's easy – just scan HTML, deduce what framework is used, and add it to your showcase list. With Flutter mobile/desktop apps it's not possible.
I think they're referring to the extra frame of latency when scrolling on Android. But then again, I've literally never heard anyone complain about that, I honestly don't think anyone notices, I believe the GitHub issue had to use a slow motion camera to even capture the issue.
Sorry, but do you really develop your software as a professional engineer based on "I heard X from few people"? With all the bias and filtering your brain does for this kind of "metric"?
Do you not? Engineering is a tool for solving human problems. If humans don't have a problem, then there's nothing to solve. Engineering is not the end in itself but the means to an end.
A lot of users do care for fit and finish, but stick around with crappy UI because it’s not worth rage-quitting over.
They do move when better UI + same-ish functionality comes along.
The one sort-of exception to this is Enterprise Sales, where the people buying the software don’t always use it. But even there, corporate purchasers do get flak in annual reviews / feedback cycles for especially crappy enterprise software — so even there, especially crappy UI will catch up with you.
But the question is will they move from a Java UI to a native windows UI, all else being equal. What if the Java UI is better ? What if the Java application is better
I think you are correct, but I think your example is a bad one. Most people do not have a realistic (their employer will use it at work, it even occurs to them that they could use something else) alternative to MS Office so will use it whatever MS does.
I miss the days when applications had their own look and feel. If your idea of great design is identical rectangles to all the other apps, I guess Winforms solved that use case 20 years go.
It’s perfectly possible to still have a unique look and feel without completely forsaking all the platform affordances. You get a lot of stuff for free or very cheap building using the platform toolkits: stuff that people internalise and expect to work without even realising it. I think it’s a bad idea to throw that all away.
Just like a lot of the "web application packaged as mobile app" frameworks did in the past, except with ugly iOS styling that also completely mismatched the expected navigational patterns.
What's worse, there are new applications with custom look and feel that do the same navigational sins today
I think people might be talking past each other on this issue. If you are on one platform only, then yes having apps behave the same is nice for muscle memory. However, if you're using multiple devices and platforms, then I want Slack to work the same regardless of device, I don't want iOS native navigation on the iPhone and Windows native navigation on the laptop.
> Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell.
I was a Flutter early adopter going on for like 7 years ago now, and Flutter has its place, but I don't know if I could repeat your sentiment with a straight face. Especially when comparing it to Qt.
flutter's custom canvas render on web means so much of the web stops working or is slow. type anything non ASCII like an emoji or CKJ and eat while it downloads a font. No other pages do this. Text fields are missing all the standard context menu options like define, translate, etc... Things that would be selectable on any other page are not, etc....
If you care about the web at all as a target, you must not use Flutter. It’s awful. They used to have a DOM renderer which you could use and everything would be fine, but apparently no one used it because it wasn’t perfect, and they’ve recently deprecated it and will remove it sooner or later—they’re doubling down on the pure-canvas direction where it’s completely impossible to produce a good result. And I do mean impossible, design limitations of the web platform that in some cases fundamentally cannot be relaxed and in others are very unlikely ever to be. With this direction, scrolling will never be good, text rendering will never be perfect, input and manipulation will never be acceptable, links will never work properly.
Flutter Web is for web apps, not web sites, so much of those concerns don't necessarily apply. And it's not "impossible" simply because Chrome itself runs on Skia which until recently Flutter did too, so clearly they were able to implement scrolling at least one time correctly.
When you want to draw this distinction: most web apps will still suffer heavily for many users if they use Flutter. To begin with, few web apps don’t use text, scrolling, or form fields. Games are almost the only thing that may not suffer, or only barely suffer. But beyond that: well, that’s what they say its purpose is, but at least two of the three times I’ve encountered Flutter in the wild on the web, it was inappropriate, and frustrating; regular DOM should certainly have been used. (The third, I’ve forgotten what it was. It was probably similarly inappropriate.)
Skia is not the bottleneck. The web platform is. Scrolling is limited on two counts: ① what browsers expose in events is insufficient to match the native implementation (which varies by platform) in scrolling amounts, overscroll behaviour, and related things; and ② the browser is a compositor, and your code will never get access to that layer, because it’s way too deep in performance-, security- and implementation-detail–land, so you’ll always be stuck at least sometimes at least one frame behind “native”, and janky.
Could you be more specific with what the browsers aren't exposing properly? Because in my experience, targeting WebGL+WebAssembly is pretty much exactly the same as targeting OpenGL+GLFW. I use my own renderer made with bare OpenGL + C++ though, not Flutter. All the things you have mentioned (scroll amount, overscroll behavior) are under the control of the GUI library and don't have much to do with what the browser exposes. The compositing of the whole scene is done by the gui library itself
I use Firefox, Sway, Linux, laptop with precise touchpad.
Normally, I get smooth scrolling at such-and-such a rate of pixels-per-centimetre, with momentum so-and-so, and since comparatively recently, particular overscroll behaviour.
On that site, I get janky scrolling at a somewhat slower rate, with no momentum, and no overscroll. (… and scrolling leftwards in the carousel triggers go-back-a-page rather than scrolling left, so you need to scroll right a little first to “unstick” it, but I believe this is something Flutter could have worked around.) It’s painful. Very painful.
It’s not possible to fix this within the scope of browser mouse events. They’re just the wrong primitive. The consequence is that you can only get native scroll behaviour if you use an actual scrolling area. Which you could do, with mild compromise to the pure-canvas approach, just an invisible one and watch what happens with it, rather than paying attention to scroll events. And that’s pretty much the approach you need to use to get good results: compromise on pure-canvas, and do bits and pieces with actual DOM. For scrolling. For links. For images. For text. For inputs. Oh… huh, look at that, we actually just want real DOM stuff everywhere. Fancy that.
Now you might not immediately get such a bad experience for scrolling: I seem to recall hearing that Safari on macOS basically implements inertia before sending the events, and sends the events with inertia applied. That solves some problems, but causes others.
Actually, I meant two distinct things by “overscroll behaviour”:
① Does it let you scroll past 100% a little and then pull it back, as is increasingly normal, or show some indicator that you’ve reached the end, like Android has historically done, or just do nothing, like all computers historically did?
② Scroll chaining, the CSS overscroll-behavior property, to do with nesting scrolling areas. And note that different platforms behave differently. If you do pure-canvas rendering, you’re stuck: the browser has some of the details needed (and is unlikely to ever tell them: they’re involved implementation detail that varies by platform), and you have some of the details needed, and you can’t really collaborate, it’s just not a good mixture.
When I speak of the browser being a compositor, I refer to how scrolling is no longer implemented in a blocking fashion in the UI thread; these days it’s in a different thread, so that it can implement viewport scrolling independently of content rendering, in order to maintain consistent frame rate even in the presence of slow drawing. Also to do various other tricks to avoid missing frames, mostly platform-specific and involved. Web content will never get that power.
Not sure why it's downvoted, I think it's quite an important distinction to make. I've heard people saying "Flutter is bad for web because it's not indexable by Google". And reply "do you expect your app - like a food delivery app - to be indexable by Google" if it's run on the web?
Existing food delivery apps are not only indexable by google but actively make sure to spam the top google results for all possible food related searches. You couldn't have choosen a better example to disprove your argument if you tried.
This. They can have all the deviations they want, but “input core” must be native. If a framework ignores it, users will notice and frown upon it immediately.
When flutter came out publicly, first I thought no way it can get away with custom everything. But it turned out some developers don’t care about that at all.
1. I shipped more than five Flutter web apps with actual users for a couple of years, and it's been a great experience so far.
2. "Native" web core should burn in hell, and I hope Wasm will finally contribute to it. Amount of developers who do not realize that "native web" is a typesetting engine from 80s with a pile of hacks on top of it, is too large to fight the opinion, of course. And yet, as a developer, I care about using the right tool for the right task, and no amount of browser engine optimization can change the fact that XML-based markup language is not the right tool for modern performant cross-platforms UIs.
you know that zero texting apps nowadays use native input anyway right? even native apps will implement their own input and it's always awful, but the pm needs those style previews... (you're still right thought)
Checked my whatsapp and tg, both use absolutely native inputs. The selection handles & menu, the hold-spacebar movement, the hold-to-magnify feature on ios is the same as everywhere else. If that’s not native, they did a great job for nothing.
Too lazy to check on android rn, but I recently worked with the apps/chats on it and entered text, it didn’t feel different.
Styles are possible with native text view, otherwise we couldn’t have fonts and colors and contenteditable and selection within <p>. I think you mistake “input core” with “web input element” here. The core I’m talking about is a text cell with characters on it that has no concept of own border. Controls like NSTextField, Win32.TextBox, GtkEntry - they all have platform text input (and output) system underneath. In case of gtk it implements it itself, cause X has none. The thing that implements all the familiar behaviors of the text input that you know.
So yes, compared to HTMLInputElement these are absolutely custom. But for a platform, absolutely native.
> Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell.
Flutter implemented its "native" looking UI widgets by literally having teams of designers eyeball the native designs and reimplementing, starting from drawPixel. This can't be done on a volunteer basis alone. Many open source attempts have tried this route and failed because they don't have the sheer designer resources needed to get there.
> Flutter implemented its "native" looking UI widgets by literally having teams of designers eyeball the native designs and reimplementing, starting from drawPixel.
Those widgets are then stylized wrong on every subsequent platform release, such that your iOS 18 phone might seem like it is launching an iOS 7 app.
IMHO if your goal is to have a cross-platform codebase act like the underlying platform, React Native is a much better approach. Flutter exists for people who don't intend to take on the effort of targeting platforms with specialized behaviors.
I’d much prefer they’ve gone with their own design system. People are already used to bespoke ones (web), badly done ones just remind me of scammy sites.
but flutter was probably sold internally as a trojan into ios dev experience. the carrot was multiplatform... and to sell it they needed to at least market that it was "true multiplatform" with native look. which is ironic since they go out of their way to make it pain to build to both in the same app
> we do not want, or intend, to fork the Flutter community.
I can't reconcile that statement with the rest of the blog post. Good intentions aside, this is exactly what they are on the path to doing.
From the post:
> By forking Flutter, we get to decide what gets merged.
I'll allow myself to be naively blunt since I just learned of this and I don't have a stake in this battle, but it seems like a nice little coup attempt that Google can squash by putting more resources into Flutter if they feel the pressure.
>Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell
I agree with you that Flutter has been a boon for cross platform development, but to say it's impossible to tell you're using a Flutter app is a bit of an exaggeration. I have no problem identifying Flutter apps. Not that I care as they often have a genuinely nice UI and are performant.
I worked on the GPay flutter rewrite and our standard for accessibility was higher than almost any other app I've seen, and was a significant amount of effort spent on that. What accessibility shortcomings does flutter have?
This may be a silly question, but how do I install the Google Pay app on my iPhone?
I'd like to try it out since it's the first app listed in the Flutter Showcase, people keep mentioning it in this thread, and it probably works as well as a Flutter app can, given that it's first-party from Google.
But when I search for it on the App Store, it's nowhere to be found (or at least not in the first 20 results).
It's only for the Indian market. As Google often does, they released Google Wallet for the US market. But that's not a failure of Flutter itself of course, only internal Google politics.
Google pay was never able to fix the pre-compiled animation rendering issue on iOS where the first transition or animation is always janky and then it gets cached and no longer has jank.
Can you elaborate? What's missing that makes you feel confident saying "complete lack of" despite well-documented accessibility functionality (including testing for accessibility)? [1]
How do you do that? I just opened my phone, and the last app I used was a food delivery app.
How can I figure out if it's a Flutter app or a native one?
It’s more difficult to distinguish if an app is Flutter or some other cross platform framework, but “native or not” is very easy on iOS. Even React Native, which is the least foreign, has tells.
On Android it’s more difficult, partially because it’s kind of like Windows where Google/Microsoft uses 50 separate reimplementations of Material/Fluent and there’s no consistency to be found anywhere.
Ah, so we talking about two different things here:
a) with any given UI design, distinguishing if it's implemented using native UI framework or with Flutter
b) Flutter app providing 100% indentical look&feel to Cupertino/MaterialDesign/WinForms/Cocoa/etc.
I was talking about a). Assuming that the app developer wants to have a consistent app design across platforms, which probably came from a design department – there is virtually no way to distinguish. Ultimately, it's just a bunch of pixels spit out onto the framebuffer.
For React Native it’s common for navigation to be weird compared to UIKit/SwiftUI apps. Also common for things like padding/margins to be off since standard layout facilities aren’t being used, and devs of RN apps will often visually customize controls (web style) that native devs don’t.
For Flutter, the most visually obvious thing (aside from usually using Material Design) is that its animation curves are all totally different from those of UIKit/SwiftUI and interact with gestures differently. The Cupertino theme is a poor facsimile of UIKit and lands squarely in the uncanny valley, which is arguably worse than Material Design. Flutter on iOS also tends to hitch where UIKit/SwiftUI don’t.
There's likely things we missed but we'd love to find examples you might have. We try to be scientific as much as we can https://github.com/flutter/flutter/pull/122275 [coincidentally a community contribution from someone who didn't have to fork :)]
Disclaimer: used to work on some of these animations
Yep, same. For me the animations are a dead giveaway if an app is using flutter. That, and the scrolling just feels _off_ in a way I can't quite describe and is a little clunky.
I had been building stuff with flutter for a while when GPay migrated to it and I could straightaway tell from the performance that it was flutter.
There are obvious tells an app is non-native. One of the easiest is to view the settings screen. Setting screens on native apps usually all look the same. I haven't seen one Flutter app that has replicated it.
Haha. Oh, most people know! They might not be knowing it’s Flutter to be specific but they sure know it’s some hybrid/non-native crap.
I recently started using Ente migrating from Authy and goodness it feels and looks awful. I wish 2FAS had a desktop app. There was a native alternative that allows exporting codes. (This is not against Ente devs. I am sure they are a small team bringing out a FOSS product. This is just my preference)
I can’t imagine using Flutter for desktop development if only because like most newer UI frameworks, it’s mobile focused and doesn’t come with important desktop widgets like tableviews/datagrids and treeviews.
Depending on widgets external to the toolkit is a no-go for me. It unnecessarily bloats dependencies and there’s a high risk of the widget eventually being abandoned.
I totally get your sentiment and also try to instill the culture of "add dependency only if it's absolutely not possible to avoid it". For small widgets, I often just copy the code into my tree. And I absolutely hate when library authors break API for no reason (something that the Dart ecosystem inherited from the web one).
But limiting yourself only to standard widgets seems to be extreme.
It’s not that I limit myself to standard widgets, it’s more that the toolkits I use have a full enough complement of standard widgets that any custom needs are easily met by tweaking one of those.
In UIKit for instance I typically build custom buttons by subclassing UIControl, which gives a nice “blank slate” control that has all the basics of interaction covered without the specifics of UIButton. It’s easy to build a custom button that’s as well-behaved as a standard UIButton that way.
Depends on what's being developed, I guess. No tables/trees is probably ok for a lot of lighter end-user sorts of apps but doing without them for many desktop-first apps and utilities would be rough. Desktop file managers, media library apps, and email apps for example would be quite a lot less useful without multi-column tables at the minimum.
I almost never use email on anything but my phone, and Gmail doesn't use a table. They do some tree stuff for the conversation threads, but conversation threads are obnoxious anyway and I have no idea why anyone likes them, they don't reflect face to face conversations well and always create mistakes where someone forgets to reply to all.
I've replaced a lot of tables in my apps with modal dialog UIs, it's nice to have them behave exactly the same on mobile and web, to not have any risk of mistakes due to filling in a box on the wrong row because the label is too far from the box, and it's just generally more pleasant for us non-ADHDers without very good native multthreading support in our minds.
Android style UI is all about encapsulation and reducing the mental context window to the bare minimum, and it really makes a lot of desktop stuff look pretty clunky and confusing by comparison.
VS Code would definitely suffer a lot without the sidebar tree view though, and it does seem like a lot of people prefer the more open instant access to everything that a table provides, rather than clicking through dialogs.
This is something I have a difficult time agreeing on. I expect a certain level of information density and configurability in desktop UIs, which shoehorned mobile-style UIs don't do well to provide. Deep modality is also a peeve; on desktop there's often no benefit to burying things in mulitple layers of modals — within reason, the most important things should never be more than one click away and great consideration should be put into putting upwards of 2 clicks between the user and their destination.
That said, I do think it's fine to have a simplified mobile-ish UI as an option, but it shouldn't come at the cost of more classical desktop style layouts for those who can leverage them well.
As a sidenote, this is part of why apps like the mac version of Apple Mail and Thunderbird have a considerable number of hardcore adherents, particularly among power users.
There's a number of users who can really make great use of the power user tools, but adding multiple UI options can greatly increase work, because a fully modal workflow might need a completely different frontend, and some apps are meant for the mass market.
Degrading the experience for the majority just to make things better for the power users doesn't seem like it's always the best plan unless you're specifically targeting power users.
In the extreme case, UI for power users can result in production databases being destroyed, or someone getting served food allergens because the menu system made it easy to assign wrong items to wrong customers, or someone's entire family photo collection getting deleted by a single command.
My comment was related to mobile apps. Web apps built on Flutter definitely can be distinguished. The thing is, with web apps, people have developed feelings for the "nativeness" - because browsers make a lot of UI choices for them.
A typical example is a selection of the text. Because web apps are built using XML-based typesetting language from 80-s, everything is selectable by default. No matter how many layers of abstraction you put on top of that hackish foundation, you are still running it in the program (browser) designed to show text. So you can select buttons, navigation controls, images, sound players, etc. And it feels very native to web users.
But when you actually think about it, it's an insanely stupid UI choice that neither of proper UI frameworks would even consider. Sure, you can "opt-out" with recent CSS controls for selection, but it's again, a hack - the default choice of "everything is selectable" is made by default for you by the browser. What does it even mean - select button widget? Why would you enable this complicated selection functionality for your UI that allows users to select navigation buttons with a blue selection box? Of course, if your app needs this functionality - you can add it. But otherwise, it would be labeled as a very stupid UI choice. Yet, feels native to web.
Another example is zooming. Because UI apps written in web stack can't completely hide the fact that what they are doing is essentially trying to morph text primitives into complicated UI widgets (makes sense for 2024, right?), and the browser is essentially a text viewer, everything is zoomable and feels "native" to be able to zoom a web app. And yet, this rarely works as intended. In any other UI framework, making zoom functionality requires thinking about what and how you want to zoom and why. OS text size preferences are well handled by flutter, but sometimes you do want to add your own zoom functionality. In web though you just blindly zoom everything, often blowing off the layouts and that feels very "native" to web.
My point is, that I don't think UI frameworks should try to match the nativeness of web, especially when they start targeting the wasm platform. These couple of decades of proliferation of web frameworks built on top of HTML/JS/CSS should just wane in history as a dark period of software engineering.
> But when you actually think about it, it's an insanely stupid UI choice that neither of proper UI frameworks would even consider.
You say "insanely stupid", I say wonderful.
Everything you apparently hate about the web is what makes it good for users. Content is primary, and my user agent can resize it, restyle it, copy it, extract it, link it, read it to a blind person...
If you want to make a binary blob app, just make that. Stop trying to break the web.
Yes, that's the most common response. I've heard stories about "how wonderful when you can select everything" multiple times, and that's, of course, just shows how human rationalization works.
And yet, this "feature" or "UI choice" is not even a choice. It's just a byproduct of using the wrong stack for the task. Like, nobody ever sat and asked, "Do we want our apps to have everything as a selectable feature?" before shipping this "feature". It just happened, and then, of course, millions of humans, having no actual choice over it, naturally rationalized that as a "wonderful" feature.
It didn't "just happen" the early architects of the web designed a system to make it easy to share and remix content and subsequent generations of companies and their UX designers have so far failed to fully claw back user freedoms.
Content as in significant text and media content, not selecting the text off a button element. I agree, seems like this is just a post facto rationalization of a mistake from a system that was originally designed for content, not application functionality.
Maybe I need to copy-paste the text from the buttons so I can accurately ask which one I should click. Maybe I have a screen reader that needs to access that text to read it out loud. Maybe I want to copy-paste the UI elements into a translation program so I can understand them in my own language. Maybe I want to copy the UI text so I can make a better re-implementation of your site...
Those are some of the most niche use cases I've ever heard, and that is stretching it even on HN, much less anyone in the non HN bubble. Things like screen readers work just fine on non browser apps that don't have selectable text, for example.
Copy-pasting UI elements to ask for help on support forums is absolutely not a niche use case. You're asking for a world of even more terrible screenshots in support channels. Truly cursed software.
Who exactly is copy pasting UI elements? I have literally never heard of anyone copy pasting UI elements of all things over just taking a screenshot of the page, so please provide an actual example. And even if you were able to copy and paste, how would you preserve the layout of the UI since only text is selectable?
Selecting everything is what every UI toolkit should support. In the 90s it may have been acceptable to show an error MessageBox with a non-selectable message but it shouldn't be acceptable today. What needs to be selectable is defined by users not developers and the union set of those requirements is "everything".
Browser zoom also only ever breaks if you are fighting the Browser's layout engine instead of embracing that. Just don't do that and it works fine.
Of course most web "apps" shouldn't be apps in the first place but if they must be "apps" at least stop reimplementing a crappier version fo the native browser functionality.
Bolt [1] and Bolt Food [2], for example. One of the apps is built with Flutter, another one is native. Can you tell which one and explain how you noticed it?
Bolt Food is on the showcase page, not Bolt itself, which would be odd not to add both if indeed they were both RN, so seems like one is RN and the other is not, which is basically what the above commenter was saying initially. None of what you said really invalidates their point, because again if you search for RN jobs for Bolt, why would you not also assume it's for the one on the showcase, ie, Bolt Food? Bolt is the company name after all, not just the app name.
You were right. After your comment, I went back to my friend at Bolt and asked again. Bolt Food is on RN, Bolt is native. The conversation we had about Flutter back then was about his other project and not Bolt Food.
The only thing closeish to a native UI is macOS and iOS AppKit and UIKit. Winforms aka Win32 is still a thing, but Microsoft has been undogfooding that and putting out alternatives for years, now WinUI3 will definitely kill off Winforms for good! What is native on Linux? Gtk, Qt, Motif (lol)?
And then Android? Ironic then that Google is the one behind Flutter.
The concept of native outside of MacOS/iOS is pretty busted at this point. At best it just means something non-web.
Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there. Yes, the same vendor provides other toolkits.
Linux is a kernel project, and different distributions are for many purposes best considered to be different OS's. Desktops based on Linux mostly are either GTK or QT, and so the native toolkit depends on the desktop you are using.
Is this too much fragmentation for users on those platforms to realistically expect commercial software to support them natively? Yes, of course, but that doesn't mean there is any confusion about what it would mean to do so.
Win32 is no longer the native GUI toolkit on Windows, given how much of the OS GUI itself is not using it (new Settings etc). If the argument is that it ships in the box, well, so does UWP XAML.
Is that useful pedantry? From context, you really think that's my confusion here? I didn't include *BSD either, but it isn't any different for the relative handful of people using that for a desktop system.
> Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there.
Except for Microsoft's numerous attempts to supplant it and the fact that the base OS doesn't even use it consistently for their own system. Microsoft's own File Explorer and Settings app that only had to live along with Control Panel for a decade, was that not native? They aren't "Win32".
If you insist on pedantry, you should know Win32 isn't a GUI toolkit either, it's an anachronistic term for the Windows API. Nobody casually calls it USER though, and the bulk of people still targeting it do so through .NET these days via Winforms.
If native just means provided by the vendors base system, ok, but then if there are 10 different forms of it, other than the distribution issue there isn't some great intrinsic benefit over just targeting Qt or Flutter. Especially when someone like Microsoft can't settle on a consistent design language through the years.
> If you insist on pedantry, you should know Win32 isn't a GUI toolkit either, it's an anachronistic term for the Windows API.
I don’t think it is “anachronistic” - as far as I am aware it is still the official name. And I don’t think calling it the “Windows API” is right, since Win32 is just one of the APIs that Windows offers. If I’m calling CreateFile, I’m using the Win32 API, but if I’m calling NtCreateFile, I’m not using the Win32 API, I’m using the native NT API instead. If I set the subsystem as NT instead of Win32 in my executable’s PE header, calls to native NT APIs such as NtCreateFile will still work fine, attempts to use Win32 subsystem APIs won’t. And there are other APIs Windows has which aren’t (strictly speaking) part of either the native NT API or the Win32 API - COM and the many APIs built on top of it, .Net, WinRT, DirectX, etc.
But you are right that Win32 isn’t a GUI toolkit. It contains a rather basic and old-fashioned GUI toolkit (USER), but it contains a lot of non-GUI APIs too. I’m reasonably familiar with those parts of the Win32 API used by services and console mode apps, but if you asked me to write a Win32 GUI event loop I’d be asking ChatGPT to remind me how, because while I’ve read tutorials I’ve never actually attempted it.
The name itself is anachronistic, what does the 32 stand for? You call CreateFile with 64-bit pointers, it was still considered Win32 (until they officially changed it).
"Using the Windows API, you can develop applications that run successfully on all versions of Windows while taking advantage of the features and capabilities unique to each version. (Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)"
The API provided by ntdll is semi-officially called the "Native" API and much of it is subsumed into the Windows API. The PE subsystem names you are referring to are IMAGE_SUBSYSTEM_NATIVE and IMAGE_SUBSYSTEM_WINDOWS_GUI/CUI, so it's somewhat consistent.
Microsoft officially refers to that API as Native System Services in the documentation for the DDK.
Microsoft’s docs are a self-contradictory tangled incomplete and sometimes even downright erroneous mess, I wouldn’t put too much stock in what they say.
If I say “CreateFile is the Win32 API analog of NtCreateFile in the NT native API”, everyone experienced with low-level Windows development will know what I am talking about. If I started talking about “Native System Services”, I’m not sure as many would.
Similarly, the distinction between APIs which are easy to call from C code (and simpler FFI frameworks from scripting languages, e.g. libffi) and COM/Automation/.Net/WinRT APIs which are a lot more difficult to use from C (as opposed to C++), and which require more advanced FFI support, is still important in Windows development (or at least some parts of it.) And in practice the term “Win32 API” is often defined to exclude those higher-level harder-to-call-from-plain-old-C APIs.
It goes back to the original design of Windows NT, where you had a primary environment subsystem (Win32), secondary environment subsystems (OS/2 and POSIX), and integral subsystems (local security authority, session manager, etc). The primary environment subsystem is still called Win32, and the Win32 API is its public API. (It also has private APIs, most notably the CSRSS LPC interface, but that’s unstable from version to version.). As I said “Windows API” is insufficiently specific because (especially nowadays) Windows has lots of other APIs. WinRT and Win32 are both Windows APIs but very different. WinRT is largely built on top of Win32, but some documented WinRT APIs are built on undocumented Win32 APIs, leaving WinRT the only officially supported API to access certain functions.
Microsoft intentionally didn’t rename Win32 to Win64 when they added 64-bit support because it is 99% the same API just with some highly regular changes (mainly widening pointers). By contrast, Win32 was a much more radical change to Win16 - the Win16 API directly incorporates notions of segmented memory, which it uses to implement movable memory blocks (rather similar to Classic MacOS, albeit that did it in a 24/32-bit flat memory model rather than a 16-bit segmented one). Microsoft could have done a more straightforward port of Win16 to 32-bit x86, e.g. using a 32-bit segmented memory model instead of 32-bit flat memory, keeping movable memory; but (thankfully) they didn’t. It would have made it a lot harder to move to 64-bit or non-x86 platforms.
GTK 3 or 4? Xfce+MATE+Cinnamon are still popular enough options and I used the former for years.
GTK itself isn't even a well defined target.
And GTK3 apps of which there are plenty do not appear native in a modern GNOME desktop much more so than a decent Qt app does.
The thing is that people in the real world talk about Linux support for an app, as in Desktop Linux support, and the only common denominator there for years was basically X11. I have heard exactly no one ever ask, oh when is that app going to be available for KDE or GNOME. For example, to take something recent here, do the people writing the Zed editor promise a particular DE support - no it's available for "Linux."
As to earlier mentioning distros - for a GUI app, there’s more pain from intra-distro variation than inter-distro, both across configurations and supported versions.
Now the big thing, the even bigger thing is probably native Wayland vs X11, but no one says, oh vendor will you please bring your app to KDE or GNOME, specifically. 99% of the time you are happy if you get anything at all.
So the concept of native on Linux (Desktop Linux) just isn't something usually worth discussing.
Linux is not something that encompasses a GUI, so this is a misguided way to frame the underlying concern. One might as well ask what toolkit is native on smartphones, or what language is natively spoken by humans.
We should instead ask what is native on Plasma, or on GNOME.
"Oh, bother. That would mean I have to think of four things instead of three."
Well, yes, Pooh. But the things that make them different are the things that make them, them.
"Just build native UIs. I don't know why cross platform UI has been such a hobbyhorse for so many for so long: it's a stupid idea."
The stupid idea is thinking that building native UIs is targeting a clean, non-moving target and implying it is not astronomically harder than doing something cross platform that is between mediocre and good enough for everybody.
Whenever someone says “just do native” it always turns out they have a cockamamie definition of native, otherwise they would realize the gravity and general unreasonableness of what they were asking.
On a side note, what’s a major* reasonably complex app that isn’t a music player or an IRC client, or something with a simple shell around a canvas like a browser, that targets both Plasma and GNOME natively.
* And whether anyone likes it or not, few people care (as revealed by $$, not bitching on a forum). Blame electron, the web, but even Microsoft cannot even define and maintain a native LnF for their core operating system. As I alluded to, the only small community that cares are those on MacOS and iOS, where there is a HIG that more than 2 people have read and give a shit about, and there is a small market of people that value well integrated Mac apps that will actually spend money.
Targeting Win USER32 +/- XAML, Qt, GTK, and AppKit is costly and thankless when you probably could have just used Qt, JavaFX, or Flutter, etc.
So that means one has to target both GTK and Qt to be native on Linux. Fat chance of that on anything but yet another music player or other relatively trivial UI app.
In any event, that still doesn't answer what it means to be "native"? And my point is I think most definitions are dumb or useless.
If I'm running a GTK desktop, Qt apps are generally not "native" no matter how much theme fuckery one tries. Native can also speak to other common UI affordances and design guidelines, and there sure as hell is nothing like there is in the MacOS world for linux. Some core GNOME and KDE desktop apps maybe, but overall there isn't much adopted standardization in Linux world.
90% of the work I get done involving a GUI outside a browser on Linux usually involves Java, whether it be Intellij, ghidra, etc. Maybe I'll pick up blender from time to time. Audacity, there's a good one, targeting (for now) a cross-platform toolkit that pretends you can have your cake and eat it too - wxWidgets never fooled anyone - they sure as hell don't look native on MacOS, and they invariably look much closer to what they riffed off of, a 90s MFC app. (And wxWidgets wraps GTK and AppKit, so is it native? If so, native is meaningless IMHO. If not, why not?)
> So that means one has to target both GTK and Qt to be native on Linux.
Doesn't it mean that you can target _either_ and be considered native?
Also, I'm not sure I buy the claim that of "GTK and Qt are native" in the first place. I'd say either that there is no native UI, or if I must call something native, it's the toolkit the desktop environment uses. And yes, that does mean that there is no "Linux nativeness" like there is Windows nativeness, as every DE is different. And rightly so, because one could in principle write a different DE over the Windows kernel, whose UI would behave differently.
> Doesn't it mean that you can target _either_ and be considered native?
Well, no because I was agreeing with you, if you're going to grudgingly accept your definition for native, the toolkit the desktop environment uses, that means you would have to target both Qt and GTK unless you want to draw a line in the sand and say fuck it to one of GNOME or KDE as assume they don't exist. Sorry GNUStep. And this is nothing to say of GTK 2-4.
I agree that just saying GTK or Qt are native in a vacuum outside of DE is a completely useless definition, and even taking DE into account is a tenuous one.
As for Windows, what GUI toolkit does the desktop environment there use? That's a trick question.
How is Qt within a GNOME or Xfce environment any more "native" than Qt on Windows or Mac?
You have reduced the definition of "native" to merely compatible with X11/Wayland (that's the only common denominator). Well now, Tk, FLTK, Swing, and even Wine are all native.
Both Qt and GTK have facilities for integrating into each other’s desktop environments (see [1]). Sometimes they blend in nicely, sometimes they stand out a bit, but I think it works out pretty okay.
GTK doesn't much care about integrating into a Qt environment and doesn't really implement anything to make that work besides in some cases implementing the same Freedesktop standards. Even for basic things like the look of widgets you need a style that has implementations for GTK - there is no compatibility layer to use Qt styles. Gnomies in general don't care about anything outside their world.
The other way around is a bit better, e.g. there is QGtkStyle but AFAIK it is stuck at GTK2 and does not support using GTK3 styles. Still, behavior between GTK and Qt applications is very noticeably different.
It would be great if there was a shared ABI applications could use but GUI toolkits are too complicated for this to be feasible.
> Both Qt and GTK have facilities for integrating into each other’s desktop environments
Neither Qt nor GTK are desktop environments and Qt certainly isn’t defined by a dominant desktop environment - KDE isn’t even what pays their bills.
You’re still proving my point. The common denominator here (on Linux) is just X11/Wayland. If it works out “pretty okay”, then score one for a cross platform toolkit. Still no idea what über alles “native” means.
Let’s go back to the original comment I responded to… why should I not just continue with the Qt “stupid” “hobbyhorse”
You missed the sarcasm. If all can exist together, which one is the “native” one? If the answer is all of the above, then the consistency argument for native doesn’t hold much water.
Do you see any reasons why many companies/teams/devs don't want to "just build native UIs" and instead are looking for cross-platform solutions designed from ground apps for modern UI development needs?
Yeah I do see why they don't want to do it and I see it as a critical failure of risk management.
If you think pinning your entire product on a cross platform UI kit when every single one (except maybe QT) had proven a failure... then yeah I think maybe you should consider actually just eating the cost of building native UIs.
The risk analysis of building against supposed cross platform "solutions" just doesn't work out. Why do we keep trying to do it?
The idea of cross platform UI is frankly "f*cked from the jump" and should never have been a goal. I think it's only a goal because it's intellectually satisfying, not because it's really desirable.
Cool, none of that is remotely relevant to what we are talking about here.
Your anecdotes are dated and you should think about updating them so you don’t talk so confidently on things you don’t actually seem to know much about.
I mean that sincerely not as some internet gotcha there’s just no need to sit there defending a position that is based on old info just for the sake of it.
As someone desperately fighting to keep their company's main product to stay using a native desktop UI, Microsoft makes it real hard. WinUI3 hasn't even officially launched and it already feels like it's on life support. QT is good, but even qt seems to be starting to use a web renderer.
It's really something I know nothing about so I googled WinUI3 and the 3 first results are microsoft website and github, and the next two are "is winui3 dead ?" and "Oh winui3 is really" dead. So it doesn't inspire confidence :)
I suppose it was incorrect of me to say it hasn't "officially" launched then. But one would certainly seem to get that impression, considering it's missing major features (data table support?) isn't anywhere near feature parity with either WPF or winforms, and doesn't even have a visual editor (which should be table stakes for a modern 1.0 release from a company as large as Microsoft).
> Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell.
Electron-based apps are also everywhere and they are through and through bad and a step backward. I would take caution to not do appeals to authority. I would extend this assertion over any javascript-on-a-webview-based GUI framework. Awful concept from start to finish.
The fact that you failed to give any specifics to support your superlatives leads to suspect that the comparison with Electron is well suited.
Not OP, but what makes Flutter good IMO is drawing directly to native canvas, a very good hot reload implementation and AOT compilation.
There are three ways cross-platform UI frameworks draw UI. 1) wrap platform controls, 2) use webview or 3) use low-level graphics API.
Option 1 has to design controls to cater for the lowest common denominator. And there is a higher chance that an OS update might break things that in options 2 or 3. Being based on wildly different APIs (for each platform) increases complexity of creating and maintaining custom controls.
Option 2 has to render UI through a high-level declarative language made for documents.
Option 3 uses same APIs as native UI frameworks use. It's basically alternative implementation of an UI framework. Downside is that it has it's own look and feel, which is mostly an issue, if native UI framework is more polished.
Flutter, being option 3, is more similar to a game engine, than to Electron. Low-level graphic APIs maintain good backwards compatibility, so OS updates don't affect the framework much. Less maintenance is needed.
Good hot reload makes use of XML unnecessary and allows to declare UI in an actual, more powerful programming language. Overall, this removes another layer of complexity. (MS take a hint)
AOT compilation enables fast startup times and less pauses. Which is good as end users are opening and closing applications all the time.
You are right, sheer popularity is not the argument for the quality of the framework. I wrote those two sentences separately for different purposes (the second was more of a reflection of other comments in the thread. I should've put it in a separate paragraph or elaborated more.
I recently started Immich and also say the awful lag. But apparently this is due to a slow "album sync" running often on the main thread. Not the fault of flutter.
I don't know how syncing my 200 albums can be that slow but they are a big project to move it off of the main thread.
I'm suspicious of those because it shows an ebay logo but then shows an app I've never heard of or used...is this the same for all the other logos? Where does NYT use flutter?
I recognize that as the NYT Games (formerly NYT Crossword) app.
It has some very annoying non-native behavior, like bringing up the text selection/highlight menu in inappropriate places (in a word puzzle with no selectable text).
That was the first fear when I saw the title - splitting community and having two incompatible versions. Good to see it addressed in the post.
The second was just a fear of how it would complicate the development process, but it seems to be a drop-in replacement (just configuring FVM - Flutter Version Manager):
Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell. And the frustration described in the post is felt by many CTOs and developers. Especially those who use Flutter for desktop and web. Flutter provides an amazing experience for desktop apps, and precisely because of that, it feels so frustrating when you stumble upon some stupid bug that has been open for a year or two and never gets prioritized. Usually, it's nothing critical, but still requires workarounds and wasting time.I don't know, the idea of Flock sounds good, the main question is engaging the community. Hopefully, the author (who seem to be an ex-Flutter team member himself) have a good grasp on the state of the community.
Wishing luck to the project and going to keep an eye on the progress.