Is there some tech that's making it easier? (Maybe easier memory management, big enough market on each platform, React Native on the desktop, or many native-mapping frameworks, or Swift UI on macOS) Maybe people are tired of Electron?
I'm only talking about devs because many users won't really explicitly notice.
They notice, but "devs" tell them that software just gets more complex so they need to buy beefier machines, which is actually shitty advice in a world where you can't upgrade ram or anything.
devs are lazy, and don't care about the end users. "Works on my machine (64GB RAM and a zillion cores)"
The bigger the audience, the more impact performant software has
It's not even a contest: unless you're a corporation making tons of money, you either pick an OS and write a native application ignoring other OSes, or you use Electron (or some alternative).
I have 4,000 people who purchased the app and not one complained about RAM or some other nonsense people keep hurling as insults at Electron.
https://videohubapp.com/en/ & https://github.com/whyboris/Video-Hub-App (MIT open source)
Re: Electron comments: don't take those comments on Electron personally, it is just a means to an end. Personally I avoid Electron because the JS ecosystem makes me sad every time I touch it. But that's just me. :)
TypeScript makes coding a super-pleasure, it's not your grandma's JS ;)
Just curious, how much RAM does your app typically use?
Are you using correct way to measure memory usage? I think that the correct way is to measure all physical memory mapped into all Electron processes (there are several of them), making discount for shared pages and adding swapped out pages (because they can potentially be loaded back into main memory).
In Linux I usually add PSS and swap usage parsed from /proc, which should give correct numbers (PSS is an additive value). For example, all processes of Skype on my system take approximately 459 Mb in RAM and swap file.
If you are only measuring one process memory instead of all and only private memory pages (excluding shared pages and swapped out) then you get the wrong number. I tried to search online what "Memory" column represents in Windows Task Manager and Mac Activity Monitor (which people often use to estimate memory usage), but couldn't find any information. So I cannot be sure that they show true values and that those values can be added to find total memory usage by several processes.
Yes, I picked up SwiftUI last year initially because Electron/JS/TypeScript just never felt fun. Yet, I wanted to build out a few desktop/work-related ideas.
Then, after going through the Apple Developer tutorials I noticed how easy and satisfying working with SwiftUI actually is.
So, oddly enough, native macOS with SwiftUI is now one of my go-to for most of what I want to build (that isn't web-first).
Native apps feel and fit better and consume less resources. Unfortunately for people like me, market forces mean they'll remain niche relative to cross-platform apps.
Building for Electron / Web is so much cheaper considering the frameworks, transferable knowledge and virtually free support for all platforms. People have never not hated on Electron though, and that's because it's also always going to be a worse experience.
I do think that we're starting to understand the costs of "write-once-run-anywhere," better, too.
There are endless amounts of developer chatter about using / not using Electron.
As a user ... I really don't care what they use, the app runs well or it doesn't and I don't care why.
Well, Facebook almost lost the game completely because they were using a hybrid app.. Users cannot articulate why something si ruining performance (maybe not their app, because it simply has a higher priority set..)
PWAs, for example, can have downloadable bundle sizes < 5 MB, run in < 50MB ram, and have plenty of headroom for lots of features. You only need electron with it's own copy of a browser if the browser sandbox is unacceptable for your use case.
Electron wouldn't even be able to run on it.
While I haven't used SwiftUI directly (only reviewed some code recently) it looks like it makes it simple to build good-looking native desktop apps.
Unfortunately SwiftUI is not very cross platform and the other toolkits (Gtk, Qt, Swing, etc) are lagging behind in terms of polish and controls.
My general conclusion is: Native desktop applications are not dead yet as shown by the popularity of Electron and SwiftUI shows that if the toolkit is good, developers will build native desktop apps. Now it's up to the other (cross-platform) toolkits to step up their game and we can get rid of the electron-based memory hogs.
And although you credited the MacOS specific applications boom entirely to the good toolkit, I think the GTK/Gnome app resurgence comes from a synergy of three factors:
1. The rise of more ergonomic programing languages (Rust, Go, ...) that make desktop app development more fun (GTK programing in C works, but it is like pulling teeth, soo much boilerplate).
2. The rise of new app distribution channels on Linux (e.g. Flathub)
3. And the improvements to the toolkit.