Everything else is pretty much a license key you purchase online to allow you to download/register something you grabbed from the company's website.

Looking at you, Tower

https://www.git-tower.com

Personally there are loads of desktop apps I want, maybe after getting Beekeeper Studio profitable I'll make some more :-).

1. Low initial investment: Disposable cameras were cheap to buy and so are most SaaS subscriptions, at least in the beginning.

2. Nearly-frictionless termination: Disposable cameras go away when you're done with them and most SaaS can be canceled— and navigated away from quickly.

3. Ease of use: Disposable cameras were simple point-and-shoot devices and most web apps are constrained by the expressibility of WWW UI/UX, so they often cannot easily be made as complex as their desktop counterparts.

4. No maintenance: Disposable cameras were made to be thrown away (at least from the user POV), so users didn't have to worry about protecting and maintaining an e.g. fancy 35mm camera. Similarly, SaaS shifts the burden of maintenance to the company providing the service and is ongoing.

For desktop software…

For #1. You have to install it and, possibly, pay an up-front cost to do so. Furthermore, you have to trust that the software is not malicious.

For #2. You have to uninstall it if you no longer wish to use it and you have to trust that it will clean up its tracks and not leave e.g. broken file associations.

For #3. You have to navigate an UI built under far fewer constraints than UIs designed for the WWW, so you may have to invest time learning its ins and outs.

For #4. You (may) have to keep it up-to-date, usually if you upgrade your OS, but especially if there's a security vulnerability present in the version you're running.

The UI for webapps is worse than for desktop apps, but not degrades enough to compensate for the better deployment story. (For most apps.)

If my laptop is connected to the Internet, it's fast. That isn't as universally true on mobile. (Desktops are also more reliably connected to the internet when on.)

In general there’s plenty of performance to go around. For many things I don’t see a big difference between an M1 Pro MacBook and 6 yo machines.

Performance, measured in human units--e.g. time to load, refresh, et cetera--is fine. That's what ultimately matters. The customers are the humans. Not the machines.

Are these genuinely useful apps or cynical efforts to clone popular games/apps and monetize via ads? If the latter, volume says more about the business model than demand for novel functionality.

I feel that it doesn't make sense to expect the exact same transition desktop went through to happen on mobile, mobile is just different and has a different set of constraints.

Meanwhile, making a webapp that will work on all platforms (including Linux, Android, and iOS, as an added bonus) is the default. Just create it somehow, and it'll work on all of them.

Technically, you can run a MacOS VM on Windows, also, but it isn't an easy process, and many would give up.

Seems like, if we follow your argument, the Mac is the best purchase because we can develop for all platforms on it.

Your argument, fundamentally is "I bought the wrong computer." Or as you put it, "I already bought a PC and I don't want to also buy a Mac". That's very different from "Mac is too hard to develop for because you need a Mac".

Also, consumers are forgetting how to buy regular software. The Windows App Store is a thing, but it still feels weird to do that on a desktop/laptop as opposed to a phone or tablet.

Steam, however, is doing very well.

Just looking at my own apps: IntelliJ, Bitwig, Bear, Renoise, ...

I think there's a huge market need for good desktop apps, many folks prefer them to online tools. Bonus: It's never been easier to build a cross-platform desktop app.

I know there's a lot of hate in here for Electron, but it truly makes cross-platform desktop app development achievable for small companies and indies.

I used to hate native-apps-that-are-actually-web-apps, but I'm a full convert after using VSCode, that's what encouraged me to take the leap with BKS.

Electron is the market leader, so maybe Flutter will end up better, but at this point I'm skeptical.

To answer (my interpretation of) the question, there are still plenty of good native desktop apps for MacOS. I don't have data to back this up but I wonder if Mac users are more willing to pay for native desktop apps than Windows or Linux, which makes it easier for indie devs to support themselves full time writing these niche apps.

All the assets (css, html, js) are bundled in the app, nothing loads from the web, it is truly 'local', and works 100% offline. It's possible to change styles based on what OS you're running on, and there's the full suite of native APIs you can call.

To weigh in on who pays for software -- I'll let you know once I've sold more copies of my paid version, my guess is that more MacOS using individuals pay for apps, but more businesses running Windows pay for bulk licenses.

Maybe Peldi from Balsamiq will weigh in here.

Where do you draw the line exactly?

edit: spelling

UI guidelines from Apple.

If the choice is between an Electron app and no app at all? I would rather the Electron app not lie to my face that it's a real application. No one expects a website in your browser to follow system conventions perfectly or behave like any other app on your system would. That expectation instantly and reasonably changes the moment it has its own application icon and windows, and Electron apps don't give a shit. I would rather not need to have Teams and Slack both installed and chewing up my CPU and GPU at work just because they both decided they're special enough to try and claim all of my resources.

Can you point to the parts of the program (source) that implement such optimizations? I'm curious, in particular, about how other editors solve the performance problems.

At an example, let's look at Dropbox desktop programs. In Windows is made mixing Qt, Python scripts, and native solutions (just have a look at the installation folder), resulting in both a worse performance an a use of RAM.

As a user the underlying technology does not matter to me. I just need to be able to get stuff done without a WiFi or wired connection.

I've litterally done this I'm puzzled myself as to whether I consider it hybrid or native.

I don't have a hate on for Electron apps as such, and use quite a few, but they really are the worst of all worlds, particularly from the security point of view: you have all the ability of an Internet-connected web app to execute arbitrary code, but without any of the work that a full browser puts in to try and sandbox the ability to fuck up your machine.

Personal opinion - this has never been not achievable. It just requires making it a priority.

And it's not as if creating and maintaining an Electron app is somehow free. This "not free" aspect is compounded if you care about making it fit in with the rest of the desktop environment. Which, being fair, most developers (PMs, Managers, Execs) don't, even when their customers do.

One way I think of Electron is that it's fine if it's a primary app I'm using, but when it's a side thing that I have to leave open (Spotify, Slack), it can annoying. I agree that I'd rather native apps for better performance and resource usage, but I understand the developer's plight.

Free Pascal / Lazarus is a FOSS cross-platform language and GUI IDE. I'd recommend trying that in stead.

Found via: https://news.ycombinator.com/item?id=19754073 -- Thanks, @DonHopkins!

So does Qt

Also Qt GUIs look like garbage, but it's hard to quantify why.

Sure it is.

>Also Qt GUIs look like garbage, but it's hard to quantify why.

No more garbage-like than you're getting with Electron and just as style-able (with arguable superior layout engines). Qt has a number of style palettes; perhaps you're used to using applications which chose to use non-native/standard palettes.

Learning Qt means figuring out a whole new stack and build chain. Maybe the result would be better, but with only a few hours a week I didn't feel like it would have been worth the time investment.

See for example:

https://nklayman.github.io/vue-cli-plugin-electron-builder/g...

I think the reason you consider the web app publishing pipeline the “regular” pipeline is the reason we’re having this discussion =p

Thanks!

I have also found that as a consequence a lot of modern languages are very light on GUI support if at all. Rust, Go etc etc do not have robust GUIs of their own and you end up bridging across to other languages and working in odd ways or with very bare bones implementations like fyne. On Windows at least your best bet for a GUI remains either C/C++ with Visual Studio or .net and the other choices are a long way behind. We are seeing the rise of the web interface via Node and such as a result, its cross platform because its just embedding a web server as a control but its providing a local application but as people often point out they don't run well and they lack native feel and performance and its not a great experience. There are technical issues here too but I think its really more that few people are looking at these types of applications and a few big companies maintain most of the big commercial applications and buy up anything new to include in their suite.

Also, PC games... though, a great majority of them are connected to the internet for multiplayer access or DRM purposes, so I'm not sure if that counts. This market seems to be falling off, though. Steam has launched a hardware specific platform (though, I doubt they'll abandon PC's).

Rust supports GTK just fine, not sure what the point is here. Is each language supposed to create and maintain its own cross-platform UI framework?

Maybe it's just the major applications (e.g. video editing, audio editing, image editing) are good enough that it's difficult to compete without substantial resources.

The user experience may be better for a well-made native app than an average web apps, but the developer experience for the web has some major advantages: 1) You don't need to ask permission; 2) web apps works cross-platform; 3) updates are easier; 4) less obligatory updates to accommodate changes in native OS APIs/SDKs. Etc.

Who said they aren't?

But you wont find people talking about them on HN. Unless it's some UNIX app or development desktop tool.

However, for some reason, many consumers will happily subscribe to SaaS apps. So developers go where the customers are.

Because consumers value not having to install, not having to backup, and not having to sync devices. They want immediate access to the thing they want, when they want it, on the device they want to access it on, with zero friction.

Apparently, broadband internet is sufficiently reliable (at least download bandwidth), that consumers do not value local redundancy, and they have not experienced sufficient losses by not having their data restricted to local devices, or are not cognizant of any losses.

I want a purpose built native app that is close to the metal on that specific platform. Not cross platform. Platform specific, using all the latest apis and features of that platform.

2) Businesses and other organizations have a bunch of reasons to at least be OK with using web-apps or tightly-integrated-to-online-services Electron shitware, and maybe even to prefer those things to native applications, and other businesses have a bunch of reasons to want to sell them web-apps (subscription vs. single sales, especially). That's what happened to B2B desktop software.

https://videohubapp.com/en/

https://github.com/whyboris/Video-Hub-App - MIT open source :)

There definitely exists a market for desktop apps. But they need to be superior (especially in the "sparks joy" department) to the opensource/multi platform alternatives.

However, it's hard. Very hard. Everyone in our industry has moved towards Electron but we've resisted it for a long time. I have always believed that native experience is the best in the long run. The downside is that it takes more time to build the same feature across two different platforms but this is a risk we're willing to take to provide a superior user experience for our customers.

EDIT: for why you should reconsider blacklisting Relay, one of Relay's developers gives a good answer at https://github.com/wesbos/burner-email-providers/pull/339#is...

Another request: if you used a blocklist found on GitHub I'd really appreciate a link to it so I can make my argument for why Relay deserves to be spared.

* "Time to ship"

Going the "native" way for desktops means doing specific work for Windows X, Windows Y, Windows Z, MacOs Whatever, than MacOs Whatever-Beta-Plus.

Even using the "write one, use everywhere" framework entices such work, because of the dirty secret no one talks about : they don't really work besides simple apps.

The choice of leaving those problems to the Chrome team is _really_ tempting.

* Availability

Popular Desktop OS have not historically integrated "app stores" or "canonical way to install an app".

Asking them to "Install" stuff is great if they're nostalgic geeks like us ; but real people learned long ago that anything asking the right to "install" on their computer is malware from a shaddy gambling website.

* Discoverability

People don't care about your app. Really, they don't.

But they have chrome on their computer (it came preinstalled, and they need it for Facebook), so at least you get a chance to grow your user base if you manage to put a link to your website in your facebook feed, or, if they're high-tech users, as an ad on the top of their google search result (also knows as "the internet".)

The only exception, as usual, is games, because: * they need to run native code and can't afford the dozen layers of inderection of a browser * their users are dedicated nerds who will happily glue toxic chemical products to the CPU of their opened motherboards in order to get 1 more frame per seconds * the install process of game exists, it's called Steam

Or just the limitations of permissions. A business team can adopt a SaaS unilaterally. Anything installed involves IT.

We don't even really get that with Electron either; all of those apps are 'fat' in that they ship the entire standard library for doing anything with 'Hello World'.

That's changing with SSO. Security and compliance teams are cracking down on rogue BUs buying SaaS products willy-nilly.

- create user accounts at LittleApp, with your personal email, and have to remember a password.

Then, you're potentially giving sensitive corporate info to the SaaS app, with your personal email, and you risk getting fired for that.

Plus,new passwords are annoying !

- so you try integrating with the SSO solution from your MegaCorp, which means you have to talk to IT. Which means:

A/ you're going to have to wait because they're busy telling people to switch it off an on again ;

B/ they're now in a position to exert power over a decision you would like to make. Politics will ensue.

And that part: you're potentially giving sensitive corporate info to the SaaS app, with your personal email, and you risk getting fired for that

If that one part is real, than SSO isn't adding any power to you (or to the DSO anyway). If it isn't, then the only thing SSO changes is the password one.

As to "availability", desktop app stores have become more prevalent over time, not less - which means that if this actually were a contributing factor, you would see more developers and people using desktop software, not less.

And as to "discoverability", there's no mutual exclusion between a webapp and a native application - in fact, the two values add. Making both makes your application strictly more discoverable.

All of these reasons seem somewhat disconnected from reality. I'm pretty sure the reason is simpler: companies want to get the highest ratio of revenue/users to development costs that they can (regardless of the negative externalities toward users e.g. performance and UX), and the trifecta of Android+iOS+webapp (combined with the fact that consumers now accept web applications in lieu of desktop ones) allows them to do that.

In my experience at a FANG company, it turns out that building and supporting three separate code bases is (counterintuitively) faster and more productive than a unified code base.

We took a stab at this using Reactive Native and C++. It’s been a couple years at least since we did this, and so disclaimer: this might not be the case today. I am also no longer with that company.

The developers hated using RN. In 80% of the use cases, everything worked ok. The other 20% of the use cases consumed 90% of the teams time, and we effectively had to hire engineers who were experts in iOS, android, AND now react native. Meanwhile, the total amount of time to launch a new feature did not decrease.

Our C++ path had its own problems. Building dependencies across different architectures was a nightmare at times. My organization didn’t really have C++ developers. Surprisingly this didn’t really slow us down, and we quickly worked around the learning curve. This worked for us because we weren’t writing low level system code but just business logic.

When it came time to integrate into our iOS applications and several android applications, we again ran into build issues. We had many copy and pasted CMake scripts, which no one really understood and no one really wanted to maintain and own. This was frustrating enough that we experienced significant turnover, and we lost very valuable teammates.

In hindsight, we took both of these paths inorganically. These decisions were made by senior staff engineers and upper level management. It pissed off a lot of developers and lead to a lot of turnover. I have friends at that company, and they are again thinking about going back in the same direction.

> When it came time to integrate into our iOS applications and several android applications, we again ran into build issues. We had many copy and pasted CMake scripts, which no one really understood and no one really wanted to maintain and own

Seems like the lack of C++ developers did slow you down. C++ developers knows how to make proper build scripts and wrap platform specific code to make their codebases portable.

Indeed, for mobile, there are different scenarios : if your mobile app is the core driver of your service, than your problem is having them on play store and app store.

The "cross platform mobile" APIs are less than stellar,but maybe you can get by with one codebase. Otherwise two is just a requirement.

On the other hand, if mobile is just an afterthought, than a WebApps with a few media query is the reasonable choice.

"Most companies" are not FANG.

> consistency with the UI conventions of a given desktop operating system

Desktop conventions sort of exist for macOS but definitely do not exist for Windows or Linux.

I won’t go into Linux because I don’t want to deal with that energy right now, but Windows is an absolute mess:

- WPF - WinUI (2 and 3, totally different) - WinForms - MFC/Etc - WebView2 (basically electron but being promoted as first class for some reason)

Even within Microsoft’s own apps they can’t agree on UI conventions (e.g. are things round or square - Maps and other built ins use both).

On web you have to totally create UI from scratch, which usually means bootstrap or your company’s design system. Turns out windows desktop is basically the same, because apps have to create their own look from scratch - even Microsoft’s own native apps (Office, Visual Studio, etc) don’t use out-of-the-box UI.

Of course for new work Microsoft is mostly using Electron or WebView2, which should be telling (Teams, VS Code, etc). On the developers side, they’re pushing blazor, which is relying on electron or webview2 for the desktop story.

Rendering a webview using the OS should have much lower disk & memory overhead than bundling chrome + node. In theory, there's no reason it should be higher than the cost of a tab in a browser. I'd love to see some benchmarks though.

They often don't. Loads of companies ship on iOS first and Android later. There are also widely used frameworks for building your app in javascript so it is the same code on both iOS and Android just living in WebViews.

You'll make your life much more difficult doing an Android app in a language that's not Java or Kotlin, or doing an iOS app in a language that's not Swift or Objective-C, so that's why most apps which are the same between Android and iOS are mainly web views.

Because if you develop for the web and handle the REST/other APIs well, it can be trivial to work on the mobile frontends that connect the interfaces (whether on Android or iOS). It becomes more a matter of plugging the right pipes.

Whereas the backend for desktop apps across systems may be completely different; you may create more work to handle the idiosyncracies of different OSes.

Do you have examples? I'm not using many apps I guess.

Windows XP apps run fine on Windows 11, AFAIK, so that's a totally bogus argument.

Now if developer tooling wasn't trash, the transition from one to the other wouldn't be a giant hurdle. But, it is trash, so, we are where we are.

For example I work as an iOS developer but I've done desktop (macOS) software and prefer it. You know how many job postings there are for macOS devs? Zero.

But you're kind of right. Another company would be trying to build this as a web app, but the sensitivity and security required for dealing with healthcare data makes it a no-brainer to build a desktop app.

I'm curious why you think this. Disclaimer I have worked for a cloud based EHR system as well as a HIPAA compliant mobile/web app. We haven't had any issues with sensitivity or security, (obviously following best practices). A password on a physical computer only goes so far, I would venture to say that our systems are *more* secure than a desktop app.

Although, in one case they were happy to use an Enterprise web based solution, but the feeling I got was that there was a year long buy in process that ticked all the boxes before that got approved. Everyone's worries put to rest and such.

Can you elaborate on this?

If I got funding or this becomes sustainable I'd be interesting in building native versions.

https://github.com/multiprocessio/datastation

So it makes sense to only make new native applications for productivity and development only (think IDEs for example). Of course it's not a fixed rule.

> Some build-time tools will send telemetry to Microsoft by default.

can we please stop collecting telemetry by default and ask instead? i think it's a relatively easy feature to do and not much friction for users.

Its 100% native Objective-C code on the client, plus a mixed Objective-C and Python pipeline for maintenance and backend - around 60 kloc in total. The other major components are a 50 kloc config-file and a 800k row database.

In addition to being fully desktop native, we also don't sell subscriptions.

> why aren't devs making desktop apps any more

we have a unique insight into the market, having seen every Mac app published in the past 20 years. i don't think your assertion is correct, there are a lot of desktop apps around. there are a few thousand apps under active development, and the majority of them are actually native, not electron (we count 25.000 native sparkle-feeds URLs versus 4.400 electron-feeds). i'd phrase the question the other way: why are there still so many native apps when most end users would never spend a dollar on software? i believe there are quite a few hobbyists out there, developing for fun or out of hopes of being able to make a profit later on. that further contributes to the expectance that software needs to be free, further destroying an already very weak market.

I work exclusively on desktop apps nowadays, creating https://lowtechguys.com and https://lunar.fyi and I can say there are a few very annoying issues with this desktop ecosystem.

    1. Auto-updating
    2. Payments and licensing
    3. Friction on trying the app

On desktop, all those things have to be solved by hand with various combinations of frameworks/libraries.

The macOS App Store for example solves all the above issues, but its sandbox limitations can make an app impossible. Lunar for example is not allowed on the App Store, and my rcmd app switcher is still missing window switching because App Store restricts apps from fetching windows of other apps.

Of course, all those issues can be seen as advantages by other people:

    1. Immutable code (no auto updating means the dev can't break or rip out features from a working app)
    2. Free apps (licensing being so hard, a lot of small apps are released for free because the devs have capitulated on the payment front)
    3. Works offline (installing apps is not that hard really)

a lot of spaces are totally dominated by entrenched players (office)

While there's benefits to writing a web app which can do everything for a user, the main desktop app I develop and share with colleagues sits on top of user permissions that they have to negotiate themselves.

The reason for it: Compliance. Having a self-service tool which just automates work a user can do themselves using their existing permissions, instead of a centrally managed one where there's a service account used for the work is less likely to be killed off because of compliance issues, or identified as "shadow IT", or just outright denied the right to exist because I can't get a corporate sponsor to host it.

My personal projects I also prefer writing the same way, with scripts, commandline tools, or desktop apps. For example: I wanted to download every episode of a podcast in one go recently, and discovered that most podcatchers suck these days and the one I used to use is broken on Win10. So I banged out a script in an hour or so do to the job, rather than use some half-functional bloated mobile or web app.

https://wasm.continuation-labs.com/d3demo/

(Just kidding. I hope they stay "desktop apps" but wrapped in a browser-ish runtime for max crossplatformability.)

It's expensive (time and money) to build apps for multiple platforms even if you use cross platform toolkits like React Native. The tooling just isn't there to make it easy enough to share code between platforms and create compelling products. It generally doesn't make business sense.

I'm working on this problem. Leave a reply and I'll invite you to test when I launch. ;)

Is this true? Desktop apps have far more power to create privacy or security concerns that web apps do. The web sandbox isn't perfect by any means, but it's very good and far stricter than anything else on desktop.

We all get annoyed by websites that set tracking cookies and send telemetry on the web for example, but there's a lot more of telemetry & tracking in most desktop apps that simply gets ignored - Firefox's DLTOKEN id for each download being just one recent example: https://www.ghacks.net/2022/03/17/each-firefox-download-has-....

What's needed is to go beyond the browser - we should be able to execute many kinds of apps inside portable sandboxes, not just HTML.

Sure, but the point is that you have no idea if a binary is sandboxed before you execute it.

> because they process data locally instead of uploading it to a server to process

No, they do whatever they want, which includes regularly transmitting all sorts of data over the internet, with far less restrictions and visibility compared to a browser.

> these SaaS services are getting hacked left right and centre these days and that's before you take national borders/sovereignty issues and spying into account.

And individual users get hacked far more often, primarily by being tricked into downloading and executing an arbitrary binary.

In many cases that's fine because there are lots of ways to get trust other than sandboxes. MS Word or first party Apple apps don't really need to be sandboxed other than as defence-in-depth because they're from trusted brands, for example. Steam doesn't sandbox games as far as I'm aware and in reality nobody cares because Valve keeps scams and malware off the store.

"No, they do whatever they want, which includes regularly transmitting all sorts of data over the internet, with far less restrictions and visibility compared to a browser."

The browser transmits every detail of every interaction by design. Meanwhile it's not actually true that desktop apps constantly upload data. Many don't. The norms are totally different: not only can they operate telemetry free by their nature, even when companies do collect this they almost always let you opt-in or out. That's why telemetry in Windows is a constant source of controversy whereas for websites everyone has given up caring a long time ago - even the "best" privacy approaches on the web still generate detailed server logs of every button press and page navigation.

"And individual users get hacked far more often, primarily by being tricked into downloading and executing an arbitrary binary."

No, not any more. Maybe in 2003 but even many years ago this "tricking" was mostly about piracy. Nowadays? I don't even remember the last time I was asked to clean someone's computer of viruses. The average user has been impacted far worse by data leaks, hacked email and social media accounts, bank phishing etc in the past decade and that's not because desktop apps went away (they did not - games alone are an industry bigger than Hollywood).

I'm not arguing against sandboxes. We should have a great cross platform mechanism for sandboxing non-web apps. But the web vs non-web privacy discussion is way, way more complex than just "web=good".

This isn’t inherent.

If every program could run in in its own container then this wouldn’t matter.

There’s zero interest by anyone in doing so in yhe desktop, since the money is in selling services.

But virtualization approximates this.

Shameless plug

I am working on loadjitsu, a desktop app for load testing. https://loadjitsu.com

- Mobile completely eclipses desktop in active userbase. With the pandemic, desktop has made gains, because people have been stuck at home, but nobody expects that to last forever, and even with the gains, mobile is far more popular. Compound this with the fact that, for years, mobile experiences have been held back because developers were on desktop, even when most of their customers were not. It's difficult or impossible to develop on mobile, and a pain to test on a separate device, so most developers worked and tested on desktop, leading to things being too small or non-functional on mobile. This gave rise to the mobile-first push, mostly from managers and developers who understood the market importance of mobile. In many organizations, I suspect it was such a slog to get everyone on board, I doubt they want to risk undoing that effort by creating new desktop apps.

- Desktop frameworks have not just stagnated, they've degraded. This is most true on macOS, least true on Windows. Even as Apple has invested in updating AppKit, the results have been uneven. There are still some controls using cells, and some controls that were updated to use views, but then haven't been updated to match newer framework conventions. At the same time, new bugs get introduced in every major OS, making desktop apps buggier over time, and forcing app developers to constantly keep on top of things.

Apple has tried to hit this from multiple angles, from running iOS apps on Mac, to SwiftUI, but I think it's telling that SwiftUI works best on Watch, then on iOS, and finally on Mac. The desktop is the lowest priority for that framework. Catalyst and running iOS apps are largely throwing in the towel, replacing desktop development with mobile development, but even then, they're not perfect.

Linux has faced less-extreme versions of these issues with both GTK and QT, though at least these aren't strictly tied to OS version. There's also issues around licensing drama with QT, and the fact that selling software on Linux is a very difficult sell.

On Windows, Win32 and Winforms remain relatively stable, if somewhat unpleasant to work with. WPF and WinUI seem to always have some issues, not to mention WinUI is limited in what it can do, which is why Microsoft eventually opened their app store up to Win32 applications. But it's not always clear which framework you should be using for a new project.

There are, as you pointed out, always cross-platform frameworks like react native, but not to disparage those who are developing those frameworks, they just don't match up to true native frameworks once you get past very simple apps. There are issues with cross-platform design, of course, but also with performance. These issues can be overcome in cross-platform apps (see VS Code, Discord), but I don't think I've seen a cross-platform app that was "good enough" except for electron apps.

- The desktop is in a weird place, design and quality wise. Traditionally, the table stakes have been higher for desktop apps. You needed to have more features and more polish. You needed to be compatible with other desktop software and more hardware peripherals. There's also always been the fact that OS paradigms have traditionally been different. If you ship a cross-platform app that did things the Windows way, Mac users would complain, and vice-versa.

But that's becoming less important as more people migrate OSs more often, and platform conventions are becoming both less important and more homogenized, especially as users who grew up on mobile start using desktops for the first time. That's part of the reason VS Code can get away with so many Windows-style keyboard shortcuts on the Mac.

However, it's still an issue. Just look at the 1Password beta forums right now to see how many contradictory changes are being requested now that 1Password shares a UI design between desktop platforms.

- Important Web apps have gotten to a place where they're good enough. See: Figma vs. Sketch. Performance and polish-wise, Sketch beats Figma hands down, but Figma is good enough, and it makes collaboration much easier than Sketch. It's cross-platform, and since it's a Web app, it's easier to get your collaborators to use it, since all they have to do is click a link you send them.

There's a similar scenario with Google Docs. Native versions of Office are still technically superior, and Office 365 exists, but most college students and younger are using Google Docs. It's free, it works well enough, and it's easy to collaborate. If you try to write an entire book in it, you're quickly going to get bogged down with performance problems. Seriously, word processors from the 1990s outperform Google Docs once you get beyond a few hundred pages, but few people push it that hard. It's not uncommon to see college students with top-of-the-line Macbook Pros that have exactly third-party apps or personal files on the device. They're nothing but Google Docs and social media terminals.

Desktop conventions and integrations are still important to a large but slowly shrinking subset of users, but foreign to a large but growing subset of users. It's tough to know exactly how to design a desktop app to appeal to a large enough audience.

- The market. Desktop app stores have tried to push desktop software along the same pricing trajectory as mobile, but have only succeeded in splitting the market. There are lots of Mac users who won't download any software outside the App Store, but the App Store on the desktop sucks. The sandboxing requirements make a lot of software impossible, the pricing is in a downward spiral, as on Mobile, but unlike Mobile, few people actually browse the app store, so it doesn't lead to any discoverability. The story on Windows is similar but less extreme. Microsoft has opened their app store up so basically any app can be on there, but there's not really an incentive to put apps there, and people don't browse it.

There's no good places people go to browse for desktop software anymore, perhaps because of a lack of interest, and that can make deciding where to sell your software and how to promote it a difficult decision.

I'm using a new, still-in-development electronics CAD software called Horizon EDA which is a desktop application written in C++. It's nice and snappy and I never have had any inclination to do PCB layout on my phone.

https://horizon-eda.org/

So the web is like a second language. It's a second Look And Feel for users, and users appear to be comfortable learning the native UI LAF and the Web LAF. For developers, it's a second language in that it's JS/TS/CSS that works across all platforms.

It's just easier and cheaper to write for the Web LAF than it is to write for all proprietary LAFs and the results are pretty good, sometimes better.

Third party stuff like java, avalonia (cross platform WPF), Qt just suck in my experience. Might as well just use electron.

Even a boring business application will have users across 4 platforms: Windows, MacOS, iOS, and Android. It’s easier to point them all to a URL in a browser than to debug issues on an end user PC.

True, and yet completely irrelevant, because every moderate-size app (and even many small ones) have at least three clients already: iOS, Android, and web (which may then be bundled into a desktop psuedo-app using Electron), and so they already have three different platforms to support and end-user devices to debug, in the exact scenario you said that they're trying to avoid.

> supporting 4 platforms is harder than supporting 1

and

> It’s easier to point them all to a URL in a browser than to debug issues on an end user PC

...except that neither of those are valid, because (1) companies already support more than a single platform and (2) they already implement non-web clients for iOS and Android, so the debugging ease argument doesn't apply either.

Companies already shown that they're willing to invest in n+1 platforms to get more profit - that is, they've already decided that 3 is better than 1, so why would 7 (or 4) not be better than 3?

People get upset if you try to charge them a monthly fee for a desktop app. Yet they are happy to rent a SaaS solution.

Also, lower support costs. Making your app work on everyone's computer is surprisingly annoying, because some of your users will have Trojans, damaged system files, or an aggressive IT department.

So don't. Set a fair price and sell me a license. I don't want you in my checking account. I don't want you looking over my shoulder. I find the privileges which purveyor's of web/phone apps have arrogated to themselves to be creepy for the most part.

Then, again I'm pretty sure I've turned into a grumpy old man.

It's something I wonder about as well. We're building real-time performance critical software, so we don't have much of an alternative. Given these constraints, we also ruled out Electron, Avalonia, React Native early on.

We're using Qt Quick which doesn't get nearly the love it should. I was a web developer for 5 years in a past life, and I'm pretty blown away by how pleasant and well-designed Qt Quick's QML language is. One of our team members created Canonic, https://www.canonic.com to explore how the web might look if QML was used as the document markup for the web.

The popular opinion around Qt Quick is that it is best suited for mobile or embedded projects with a dynamic UI, animations, etc. But over the last few years, it has really become a great desktop solution – to the point where Qt put Widgets into maintenance mode and is focusing efforts on Qt Quick across desktop, mobile and embedded targets.

With Qt 6, the GUI is drawn using native graphics acceleration: Metal on macOS, DirectX11 on Windows, Vulkan on Linux. This makes it really easy to bring in a texture you're drawing in some other piece of code outside of Qt. As a result, the QtMultimedia framework in Qt6 is zero-copy on most platforms with the FFmpeg backend. Frames get decoded if a GPU HW decoder is available, then this texture can be read directly by QtQuick and then rendered by the display server without ever being copied. I don't think there's a single other cross platform framework out there that achieves the same level of usability, performance and easy access to platform native APIs.

Here are just a few non-trivial desktop apps that come to mind using Qt Quick:

- Denon Engine DJ - https://enginedj.com/

- Mixxx - https://mixxx.org/

- Spark AR Studio - https://sparkar.facebook.com/ar-studio/

- Gyroflow (written in Rust, with QML frontend) - https://github.com/gyroflow/gyroflow

- MuseScore 4 - https://musescore.org

I definitely see Qt and Qt Quick technologies as a competitive advantage for us. We can develop the frontend quickly with QML / Javascript. We get full graphics accelerated GUI performance. Our app running under an average use-case idles at 100MB of RAM, which is basically equivalent to what a running instance of Finder on macOS uses. A full 1/5 of what Discord, Slack, Steam, etc use.

If you want to build real-time, high performance, native desktop apps, we're hiring. Email in profile.

- editors for code and text

- presentation and writing tools

- CAD software

- Music software

- Schematic / EE software

- Voice/Video chat applications

- All IM clients

- Web browsers for casual reading

- All games

In B2B or management land, most the applications are, indeed, web-based.

- Google drive

- Internal business tools @ my place of employment.

Still, I "use" those much less than 10% of the time, and most of them are simply web forms.

That said, as web browsers get better at memory management and safe hardware access (e.g. WebGL / WebGPU) I expect this list of tools that "must" be thick to dwindle.

"Many" ?"even"? You make that sound like "many, as opposed to most", and "even, i.e. an exception".

I haven't had a job yet -- at least not this century, can't quite recall before -- where the standard e-mail client was anything other than the Outlook desktop client. The Web UI, if in use at all, has always been distinctly secondary, "If the real Outlook doesn't work, try this"-style. (Hmm, how old is Outlook? Must have been something else in the 90, at least the early ones...? And as a TA at Uni before that it was a TUI-thingy from IBM, but then OTOH maybe that doesn't count as a "real job".)

> I expect this list of tools that "must" be thick to dwindle.

The reason daliy-use tools must be "thick" is that in such tools you want a nice UI with some flow to it, so that it becomes in effect invisible. And fucking Web pages that masquerade as "applications" just don't have or do any of that. So let's hope this mania ends soon and your list, far from dwindling, starts to expand again.

90% of them are various clunky ticket systems, (at least) one of which will invariably be JIRA. Preferably at least three or four of them in the same <10k staff corporation to do slightly different but basically similar things, which could all be done in any one of them.

I had some ideas for desktop apps (with electron and nwjs), but that's where I got stuck (and lack of time of course).

SaaS gives you recurring revenue that one time install is not giving, because for desktop single install even if you release new version people might or might not buy it. So it is far easier to earn money with web-apps than desktop.

For certain complex tasks (e.g. image/video/audio editing), desktop has advantages. But for the bulk of what most people do on their computers, web apps are good enough and much more convenient. Convenience wins.

It's the complete opposite and one of the reasons I prefer to use a comparable web app over a native desktop app. Installing an app requires way more trust into it than using a web app that runs inside a heavily restricted sandbox.

As for why I also like to prefer developing web apps, that's because the available tools make web development more productive. Checking changes to the source is near-instant by simply pressing F5 in the browser, and the dev tools in browsers are some of the best you can get for debugging.

My passwords are between me and my eMail server. No-one else should get that data, for any reason whatsoever.

There is a reason Reddit insists on you downloading their app.

There isn't even an option on Android to block notifications except when explicitly allowed in settings. Each time you install a new app, you need to turn off its notifications.

Whether users have already fallen into the same cycle as cookie consent pop-ups and, more recently, GDPR pop-ups, just clicking "allow" by default because it's the easier option, is a different question.

PWA