[olliej]

You can't write good UI apps with cross platform code. The basic idioms of each platform are different.

You can write your core application logic once and share it, but you need to have the interaction with the actual UI/window manager be per-platform. The reason electron apps are so bad on Mac is not that the core application logic is bad, it's that a whole bunch of basic Mac platform behaviors are broken.

"modern" cross platform UI toolkits are no better than Java. To paraphrase Ford: "you can do any platform you like, as long as it's windows".

[edit: to be very clear, I include "catalyst" in the cross platform toolkits that make noticeably worse apps on Mac. Trying to share a single interface "language" for different platforms just leads to what is at best mediocre UI.]

[amelius]

Can you give an example of something can only be done in a native app?

And why wouldn't a hybrid approach work? I.e. the majority of the code using the cross platform toolkit, and a small amount of code per platform using the native API.

[astrange]

> Can you give an example of something can only be done in a native app?

Accessibility, text field behaviors, control animations looking right, window resizing behaviors, any system settings related to UI applying properly, printing, export to PDF, rich text copy and paste, normal power and memory use, the engineers working on the next OS release being able to fix your app if they break it, your app updating to the next OS version's UI changes automatically…

[tcfhgj]

afaik not a problem with apps written in something like react native which use platform specific widgets and common business logic.

[astrange]

There's more to a UI layer than individual controls. Like spacing between them fitting platform conventions, and window resizing and text size needs them to coordinate.

[obrhoff]

It actually is. Fortunately, the quality of apps dropped significantly, allowing these technologies to compete.

[smoldesu]

To the contrary. Developing native apps is so painful that the average S&P500 company will treat it like a root canal. Given how meaningless native functionality is to them, they won't hesitate at the opportunity to serve you a shitty Electron app. Many of them are only successful because they didn't waste time writing native apps for each platform.

[tcfhgj]

why should it? it makes no sense to me; you can do anything

It just might be that you don't go all the way, because you think a 80% sufficient result is enough for you

[olliej]

First off, I was not talking about native vs non-native, I was talking about toolkits. native vs non-native is a different though related problem.

> And why wouldn't a hybrid approach work? I.e. the majority of the code using the cross platform toolkit, and a small amount of code per platform using the native API.

I literally said you could/should do that?

Answering your actual question though. The issue is not "something can only be done" in X, it's a "is your app consistent with the platform it is on". And that's where "cross platform" apps are invariably annoying - none of the electron apps correctly do find on the Mac (this is largely because chrome/blink intentionally removed the correct logic from webkit and as these apps just do whatever blink does that's what we get).

The problem is that cross platform toolkits (Qt, Wx, etc) primarily target windows so all the behaviors are geared to that platform. It is very obvious whenever you are using a Mac app that is written using a cross platform toolkit, as their are just many different little ways that things behave incorrectly - a death by a thousand cuts problem.

Electron is just a special case of this: because your "app" is just a web page you don't have an actual ui toolkit, cross platform or otherwise, to handle all the usual UI behavior and have to reimplement it all yourself. That's a lot of work and very hard to get right, so generally electron apps don't even attempt to, but they're "popular" because there's literally no choice. People on Mac use discord, slack, teams, etc because there is no option - if your employer decides they're using slack or teams, that's what you have to use. The fact that the UI is janky, the cpu is high, basic key commands don't work, it doesn't handle drag and drop correctly, etc is not relevant: it's what you have to use.

[criddell]

Cross platform toolkits are a way of getting something good enough, quickly. Our standards may be different, but I would say you can get something good. You likely won’t get something great though.

I agree with your statement about modern toolkits being no better than Java, but Java is pretty good. I’d have no problem starting a new project with it today.

All that said, I’d much rather have a well written native application than a well written cross platform application.

[pjmlp]

If anything, many of them are much worse in capabilities.

https://www.oreilly.com/library/view/filthy-rich-clients/978...

[batmansmk]

Yet among the most used apps a lot of them are cross platforms: chrome, ableton live, vscode, figma, any game under the sun, slack, discord, … I would even argue that very few still develop directly with native ui toolkits directly.

[olliej]

You mean the slew of electron apps that are well known to be annoying to use and inconsistent with the rest of the software on a Mac? Games not so much because they aren't using any platform toolkit.

But also "developers using cross platform toolkits because it's cheaper" does not undermine my argument "you can't make good apps", I could make the exact same argument about cross platform Java apps.

[lost_tourist]

You can write "good enough" ones though, and I've been doing it for years.