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.

[0] https://flutter.dev/showcase

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 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.

Seems like it is: https://play.google.com/store/apps/details?id=com.fluttersha...

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.

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.

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.

That is a bizarre fact.

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.

Maybe 40% of the developers I know use MacOS + Android.

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.

How should I interpret the following four paragraphs where you say what you want?

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?

... 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!)

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 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.

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.

https://docs.flutter.dev/ui/accessibility-and-internationali...

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.

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.

> 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...

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.

Granted this is my personal experience, I can't say this is the case for every single user out there.

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).

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.

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.

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.

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.

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.

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.

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 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 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.

Every time I've ever mentioned it to anyone they really didn't seem to understand or care

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.

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.

You seem to say this like it's a bad thing?

But in this specific instance I was referring to OP’s claim that it’s impossible to identify many Flutter apps, which I dispute.

What's worse, there are new applications with custom look and feel that do the same navigational sins today

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.

Frame buffer? Canvas is the javascript term.

There is a world outside the browser. For now.

[1] https://tkdocs.com/tutorial/canvas.html

Random examples from the (desktop) Java/Android/iOS world where the same semantics is used:

https://docs.oracle.com/javase/8/docs/api/java/awt/Canvas.ht...

https://developer.android.com/reference/android/graphics/Can...

https://developer.apple.com/documentation/SwiftUI/Canvas

The other two are too new to be relevant.

The sometime subjective aesthetic reasoning doesn’t mean the application can’t succeed. office ribbon is an example

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.

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.

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.

Please keep your comments civil

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.

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.

So success?

I mean, Google could also punt and let Flutter die. They've killed greater investments for less.

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.

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.

whatsapp is the poster child of this technique btw.

So yes, compared to HTMLInputElement these are absolutely custom. But for a platform, absolutely native.

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.

Partially agree on the web sentiment, it just lacks a proper model, both positioning and styling, for what we call apps.

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.

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.

I think you are grasping at straws because you know you are wrong.

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)

But limiting yourself only to standard widgets seems to be extreme.

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.

I like headers and sections more that tables for most things anyway.

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.

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.

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.

https://flutter.dev/showcase/ebay

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).

I've solved thousands of daily crossword puzzles in that app.

I can't tell if the same applies to Square or American Airlines but I would not be surprised.

I don't think that's the developers fault though, I don't have that issue with any other android app.

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.

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.

https://docs.flutter.dev/ui/widgets/cupertino

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

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.

No wonder it's not accurate.

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'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).

That is quite a non-starter imo

[1] https://docs.flutter.dev/ui/accessibility-and-internationali...

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.

When using the apps on my iPhone, I just don't see how I could tell the difference.

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.

Disclaimer: used to work on some of these animations

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.

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.

You spotted a few correctly so you assume you always spot correctly - but there might be more you miss.

https://rationalwiki.org/wiki/Toupee_fallacyhttps://rational...

It's just not that good?

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 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.

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.

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.

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.

I don't know what could possibly confuse anyone about the role of GTK and QT in the Linux ecosystem.

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.

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.

But take it up with Microsoft: https://learn.microsoft.com/en-us/windows/win32/apiindex/win...

"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 URL still has win32 in it, lol.

Though this naming goes back nearly 2 decades https://learn.microsoft.com/en-us/previous-versions/tn-archi...

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.

https://learn.microsoft.com/en-us/sysinternals/resources/ins...

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.

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?)

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.

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.

  > So that means one has to target both GTK and Qt to be native on Linux.

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.

[1]: https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK...

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”

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.

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?

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.

I also want to live in the world where risk management is the only variable that determines how CTOs and devs choose the stack for the software.

I think your anecdotes are a bit out of date and irrelevant.

People much better informed than you looked at this problem in a lot more detail in real life situations and came to very different conclusions.

And yet, I can't think of a single app I depend on for anything on Linux that relies on it.

How'd Snap go for Canonical?

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.

? It officially launched with version 1.0 and it's now on 1.6?

> At this time, there are two generations of WinUI: WinUI 2 for UWP and WinUI in the Windows App SDK (WinUI 3).

> https://learn.microsoft.com/en-us/windows/apps/winui/

You suggest to build and maintain same logic in at least C#/C++ + Swift + Kotlin + JS + C++ and you ask why crossplatform UI is a popular idea?

Do you mean https://wallet.google/, which says “only available on Android”?

Your parent comment asked for “on desktop or web”.

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.

https://www.youtube.com/watch?v=3X8COSnscbQ [1]

https://www.youtube.com/watch?v=VOgrdt5WQcI [2]

Just Google "bolt react native" they have jobs and articles about their usage but also any library inspector will tell you that.

I don't know what to say but you're massively mistaken.

Uber use React Native too BTW. Lots of other big tech companies also, I don't know of any that use Flutter in a big way. Just some toe dipping

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.

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.

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.

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.

Which programming languages have a good developer experience with flutter beside dart ?

I know I use exactly one and it sucks. It’s all janky and weird compared to the rest of the system.

Maybe if you've never worked with TS/React and more generally HTML/JS/CSS, then it may be OK for some use-cases.