HACKER Q&A
📣 sirjaz

Why aren't devs making desktop apps any more?


I was wonder why aren't devs making desktop apps any more, especially since everyone is buying laptops and desktops again? With all the tooling out there for cross platform, a native experience, and better privacy/security than a webapp.

For example, Here are just two frameworks/tool kits that are easy to use and to build desktop apps with.

React Native for Windows and MacOS: https://microsoft.github.io/react-native-windows/

Avalonia UI: http://avaloniaui.net/

Also, If they do use frameworks like the ones mentioned above they will still only release the app for mobile and then rebuild the code for a webapp which is slower and does not have the functionality.

John


  👤 mschuetz Accepted Answer ✓
> better privacy/security than a webapp.

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.


👤 phtrivier
Because "time to ship", "availability" and "discoverability" are much more important concerns to many business than "consistency with the UI conventions of a given desktop operating system".

* "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


👤 orcasushi
Because desktop apps are harder to make money with. They are easy to crack / pirate. Also making a monthly subscription is harder for a desktop app (you would need still also a webapp to check for the monthly subscription).

It is on the other hand very hard to pirate software that only runs on some server. Also quite easy to force a monthly subscription if you simply hide app behind a login screen. Additionally your webapp also has the data of the user hostage so the user can not switch to a competitor.

So basicly I think webapps are a dark pattern. The user of course prefers desktopapps but due to above reasons there is hardly incentive to build them.

Will this change? I think so yes. Eventually this whole Saas bubble will burst, because - Chrome filesystem API will make building a desktop app as easy as a webapp - Open source and crowd funded software will pay the bill for those making desktop apps and users will be more then willing to switch.

When will this happen? If we are lucky within 5 years, but more likely 20 or 30 years.


👤 rathboma
Some of us are. I make https://beekeeperstudio.io.

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.


👤 jvanderbot
In engineering land, I want to point out that 90%+ of the applications I use are actually desktop applications. Perhaps the majority of developers work on web apps (questionable), but certainly the majority of tools I, my team, and colleagues use are desktop apps.

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


👤 drusepth
I think good desktop apps are infinitely better than good web apps.

However, I pretty much only build web apps. Here's some reasons why:

* Getting pixel-perfect design is SO MUCH FASTER&EASIER on the web (and using web-first tech like React Native, in my experience, has largely just met a stigma of not-really-native and sometimes suffers on perf for the sake of design). [FWIW I've been doing "web" stacks for almost 20 years, but I've also done C# for ~10, Java for ~5, and C++ for ~5]

* Even if you're not doing anything particularly resource-intensive, it's way easier to target a single machine spec (your server) and know everything just works, rather than worrying about resource-related bugs on lower-end/oddball machines, antivirus, hardware issues (out of ram? out of HD space? etc)

* Similarly, shouldering heavy load/cost on a server lets my apps be usable by more people who might not have up-to-date or capable machines

* Barrier-of-entry is significantly lower on web apps: someone can click a link and immediately demo whatever I made, rather than worrying about marketing and landing pages trying to convince someone that it's safe and OK to download/execute a random binary

* Web apps are a single codebase that's also usable on mobile, tablets, and other devices without having to worry about even more build targets as long as your design is reasonably responsive. I know these "native" libs also technically support that, but it seems there's always custom build configuration per device and/or lower-level per-platform code for e.g. IO/native functionality

That said, I wish desktop apps were easier to design for. I could probably get over all the other "downsides" if I could make native apps that looked and felt as smooth & nice as web ones.


👤 choeger
Because they unlearned how to do it. Their managers unlearned how to even think about a product being shipped and installed on many different clients that are (gasp) not under our control.

Seriously, it's a loss of skills. Everyone is doing the "single installation target" SaaS nowadays, so naturally most developers lost (or never acquired) the skill to think in terms of installable software. I even met managers that had visible problems to contemplate a world in which different customers would run different versions of our product at the same time.

As a side effect of this loss of skill, software that actually has to be installed nowadays tends to come with ever worse installation methods. It's not unusual to see the installation method for software A make it impossible to install or run B.


👤 dinkblam
We are working on MacUpdater: https://www.corecode.io/

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.


👤 kitsunesoba
A lot of people will give a list of technical reasons (e.g. native platforms are "bad"), but in my opinion those tend to be exaggerated to a considerable degree – Cocoa/AppKit, Win32, etc aren't sexy or buzzwordy but they are deeply capable and in the hands of a knowledgable developer, can save a lot of time by virtue of no need to write a bunch of widgets from scratch (or contend with all the caveats and gotchas of a bunch of half-baked widgets from third party libraries).

I think the biggest driver is actually a shift in software licensing models. Web apps are eminently more compatible with subscriptions and SaaS; access given by one-time purchases is easily revoked or diminished, they can't be pirated, and user data living in some datacenter somewhere makes it a cinch to keep customers locked in. In short, it strips control from the user while giving more to the developer. This by far has greater implications on developer profit margins than tech stack alone does.


👤 pimterry
> better privacy/security than a webapp

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


👤 PaulKeeble
I suspect its mostly a change in the types of applications being written. Most of the trends today are about interconnected sharing of data or aggregating data from across sources, internet applications for want of a better term. There aren't many new commercial applications being developed because its inherently a single user experience creating or editing data locally. They are still being created in the open source community however, non linear video editors have come quite a way in the last few years as have some interesting learning tools like Anki and IDE stuff like VSCode, I have added 10 or 15 applications to my list in the past years for all sorts like cartoon drawing. But the desktop isn't perceived as profitable for a new application and a lot of the tools have ended up with obnoxious DRM and charging schemes like Adobe. It is just not a hot area of innovation and its not being pursued.

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.


👤 mooreds
It's so much easier to deploy and update web apps: https://daringfireball.net/2004/06/location_field

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


👤 Dotnaught
Is there data that indicates devs aren't making desktop apps any more?

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.


👤 brimble
1) Private individuals do ~everything on phone and tablet operating systems. Tellingly, those have lots of native development going on. The main exceptions are PC gaming enthusiasts, and, as one might expect, there are tons of PC games released every year. That's what happened to B2C desktop software.

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.


👤 rhl314
The most important reason i think is that the web has progressively become good enough for majority of the usecases. However there are still a few areas where good desktop apps are needed.

Shameless plug

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


👤 joeld42
For me:

- Cross platform UI is hard. (I'm learning to use Avalonia, and that's getting better but for now it feels pretty hard to get into, especially for someone coming from outside the XAML/dotnet ecosystem)

- Downloading an app presents significant friction to users. If you can solve it with a web app, you'll get a much wider reach (though converting that to paying customers might be a challenge)

- Platforms are making it HARD (signing, lots of "run this app from an unsafe source? open anyways?") It's doable if you already have a large, established app but just throwing together little utility apps is much harder than it used to be.

- Cloud Data. Users expect their projects and data to be available on the cloud. Platforms offer good ways to do this (like CloudKit) but there's no cross platform way to do this. Also this means that you're going to have to deal with auth/login at some level, which is a pain.

- No marketplace. If you build a standalone app, with no subscription nonsense, where are you going to sell it? Build your own store page and payment processor?

- The elves have left for the undying lands. The golden days where an app could exist as a standalone thing is just over. Our world is so interconnected that apps need to be connected to lots of other things -- even standalone apps end up talking to a bunch of apis. This interconnectedness is significantly easier in a browser or server-based app, even though it's quite possible in a desktop app.


👤 Robotbeat
Way more money to be made ensnaring consumers into web-based subscription software.

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.


👤 nakodari
We're building native desktop apps at https://jumpshare.com.

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.


👤 kube-system
Because supporting 4 platforms is harder than supporting 1.

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.


👤 snarfy
As a user I absolutely do not want your cross platform 'native' app.

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.


👤 xdfgh1112
I use Flutter so I make mobile apps and get desktop apps for free. Otherwise I wouldn't bother investing the effort for Windows/Mac/Linux when we have the web.

👤 CyanLite4
Too many paper cuts with a desktop app.

I’ve had issues where the user has run out of hard drive space and now the app randomly crashes. Or when the antivirus scanning software locks down the DLL and the app hangs. Or the user wants to just make a quick change on their iPad while traveling on a plane.


👤 divan
Distribution is 10000x easier with webapps.

As a developer of PC-oriented app you have basically two options:

a) desktop app b) web app

Option a) is obviosly much better in terms of UX, performance, complexity etc. You have(had) tons of decent options, you can chose language you like, you have native support for many OS operations, etc. But the downside is distribution – you have to compile Windows/Linux/Mac versions for different platforms (32bit/64bit/Intel/ARM/etc). It's painful, hard, long and whenever you have a tiny update, you go all over this process again.

Option b) allows you essentially to distribute app immediately. Your clients just need open URL and that's it. In 80% of cases this is exactly what's needed. All the bells and whistles of distribution platforms like AppStore are just a burden for majority of apps for small/medium software shops. Of course, you'll have to sacrifice a lot - performance and safety, most of all. Even worse, as web ecosystem is just a huge pile of hacks on top of hacks, you forced to use the worst "framework" for UI development – literally the typesetting engine from 80s (HTML), some hackish global classes thing for styling and most underthought scripting thing called Mocha (renamed to javascript later). So the quality of the web apps are typically many times worse and dev experience is terrible, but it's a new norm these days.

Fortunately there is a progress. We have Flutter these days, which is the best thing that happened in UI development worlds for the past 20 years. I do decent Desktop apps with it, and get as a bonus native iOS/Android and Web versions.


👤 Melatonic
I believe we had another interesting thread on this recently here on HN

I think the main reason is that mobile apps often provide a more immediate return on investment - especially on apps designed for the consumer space. You can potentially track much more and then sell that data, ping people with notifications wherever they are, and there is a huge userbase of both technically savvy and less technically savvy


👤 RajT88
I write mostly desktop and command line tools for my day job.

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.


👤 nottorp
Well the question contains the answer. The OP thinks React Native is how you build desktop apps.

Thats why no one builds desktop apps any more.


👤 Justsignedup
So... I guess here we go:

I wrote and write a lot of software for internal users at my company.

What is easier?

- Test on firefox, ie, chrome, safari

or

- Test on windows 10, windows 11, 3 different versions of osx, and whateverthehell the CEO has installed at home?

Oh, and what about updating? Oh man that's a fun one. I was once part of a company with an auto-updating java installation. It was great, and we spent a non-insignificant amount of time making that not break every time, and it still broke depending on the machine privileges. We also had to make it work on 4 different versions of java because admins weren't willing to upgrade anything without a 6-month cycle.

What feature would I get? Desktop notification? Okay that's one (ish). Oh buuuut then a client would want to run it on their Android. And iPhone. And on that iPad. And what about on their fucking Kindle.

I think I'll stick to web :P And with React and other modern frameworks and sockets, there's very little that my SPA can't do.


👤 sgtaylor5
User here (self-employed computer technician); I'm not a programmer.

I have a beautiful little accounting program written for macOS called Corona. It took me two years to find it, because all of the web app-based accounting software crowded it out from visibility. My needs are simple and I don't need to share that data with any other device.

Definitely don't want my company accounting data held hostage by anyone other than me. No way to know if the hosting company is selling my data behind my back, no matter what they say in print. Besides, I only had to pay once for Corona, vs. paying constantly for cloud based SaaS. QuickBooks is another story...

For me, in this case, desktop software is much better than a web app. My laptop is older and Keep It (native app) is far better in performance and usability than Evernote (v.10x Electron app) was. Not everyone has a newer laptop.


👤 sylens
I would say that consumer purchasing behavior has veered away from desktop software to mobile applications (due to not having another choice of app distribution) and subscription based services.

In the past, an app like Spotify may have been a desktop app that somebody developed and then sold in a retail box to manage a music library and generate playlists; now they give away the app for free to draw people into the subscription model.

It also does not help that Microsoft has been fumbling and rebooting its desktop app story repeatedly for about a decade now. The last bastion of good desktop apps has been on macOS, and now the cracks are starting to form in that dam as well with even developers like 1Password switching to multi-platform Electron and SaaS. (I actually like the new version of 1Password, but it's a canary for the state of desktop)


👤 farseer
High end games are still desktop only for the most part. But even that may change as cloud gaming becomes a thing.

👤 fxtentacle
Psychology

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.


👤 kall
On macOS, I feel like I install more new desktop apps than I have the time to play with (thanks Setapp). I barely use web apps day-to-day. When I have to, I will create a wrapper app for them and/or interact with them through Raycast. To me the landscape of new/actively developed apps feels alive and well.

A thing I've noticed lately is that a good chunk of the new apps I install on iOS show up with compatible versions in my Purchased list on the Mac App Store. That's probably due to Mac Catalyst and a little bit due to SwiftUI cross-platform. Most catalyst apps are in the same quality category as decent Electron apps. I still prefer those (both electron and catalyst) over a web app.


👤 coldtea
>I was wonder why aren't devs making desktop apps any more, especially since everyone is buying laptops and desktops again?

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.


👤 markus_zhang
I think PC is becoming the new workstation while mobile is becoming the new consumer PC.

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.


👤 simonw
Convincing people to install an application compared to getting them to visit a website is a serious multiplier in terms of friction.

What's the point of building an app if you can't convince anyone to install it?


👤 davej
Craft [0] are a Notion [1] (note-taking app) competitor that decided to go desktop app first rather than web-first. Their desktop app is beautiful but now they are implementing the webapp and it is obvious that there is a lot of feature disparity with the desktop version. To me, it's pretty telling of why the smart decision is often to go web first.

I guess it might make sense for Craft because they are in a very crowded space with a large potential market and being native-first is a differentiator over their competitors. I think in most cases though, it doesn't make sense to go native-first.

Being web-first means that you can ship a consistent UI on every platform using tools that most devs are familiar with.

- You code once, it works everywhere.

- There is nothing to install, no updates to download.

- Lots of web devs means more devs to choose from when hiring.

The accessibility of the web platform make it a lowest common denominator. Desktop does add a ton of benefits though. Some of it is intangible like "feels more solid". But there are a ton of tangible benefits too.

- Easily accessible on the dock or start menu. Once installed then less likely to be forgotten.

- Native notifications.

- More refined UI. Not just one of many tabs.

- Access to native APIs that aren't available inside the web sandbox.

- Alt-tab or Command-tab.

- Quick access, i.e. can live in the menubar/tray or can be assigned to a global keyboard shortcut which pops up the app quickly.

But... Electron can provide all of that! So, it's mighty tempting to start with a web app and then pepper in some desktop functionality later by wrapping your web app using Electron.

* Disclaimer: I'm working on this problem with ToDesktop [2] so factor my bias into your comments. :)

[0] https://notion.so/ [1] https://www.craft.do/ [2] https://www.todesktop.com/


👤 dieulot
Patrick McKenzie wrote about it in 2009, and his points still hold: https://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-...

- The Shareware Funnel Is Lethal

- Web Applications Convert Better

- Your AdWords Strategy Is Very Sensitive To Conversion Rates

- Web Applications Are Easier To Support

- The Age Of The Pirates Is Coming An End, Jack

- Phone Home vs. Google Analytics

- Web Apps Can Be Customized Per User

- Long Cycles Mean Low Innovation. Short Cycles Mean Fast Innovation.


👤 closeparen
How about: MacOS and Linux are hugely over represented among developers, but all the customers (who aren’t on mobile) use Windows.

We don’t want to switch to Windows ourselves, and we also don’t want to foreclose on the Windows audience.

Finally I don’t think it’s the case that very many of today’s web applications would even make sense as single-user desktop applications. They are fundamentally structured ways of communicating with other people, not of interacting strictly with one’s own data. The server part is essential.


👤 samatman
They are, they just don't hang out here as much.

You've got shops which make Mac apps, Windows apps, and both, and it's three fairly different cultures. The "both" shops are mostly large and well established, Macs have a lot of indie devs, and Windows has a deep culture of B2B apps that is chugging along just fine. Not to mention PC games, which are certainly desktop apps, but I consider them in their own category and figure games aren't what you meant either.


👤 omnomynous
Cynical opinion:

- Most users, regardless of whether they purport to care about their privacy or security, don't even fundamentally understand either concept thoroughly enough to even appreciate that they're missing.

- Users are lazy (prefer web app over installation process, or even just taking the time to download a compiled portable binary). Devs are lazy ("why make 3 or 4 clients when we can make 1?"), on the basis that humanity is lazy. A desire to preserve energy and "take the easy way" is hard-coded into our DNA. It's ostensibly a good thing in most circumstances, just not this one.

- Younger people (a considerable chunk of my own generation included) are increasingly not functionally computer literate[1]. While virtually everyone is smartphone literate these days, I believe the days are numbered in which the laptop and desktop computer are used by anyone other than students, technology professionals, hobbyists, and serious PC gamers.

I understand that these hypotheses taken together are a pretty bleak outlook for the form factor of the personal computer that many of us deeply cherish and couldn't imagine life without, but we are the exception in broader society at this point, not the norm[2].

[1] https://news.ycombinator.com/item?id=30253526 [2] https://www.broadbandsearch.net/blog/mobile-desktop-internet...


👤 edgyquant
During the 2000s Windows (and probably Mac but I didnt use it back then) made it way more difficult than it should be to quickly write GUI apps and allow them to be ran on multiple platforms. For obvious reasons given the time it was just another way to lock developers and their users on to a platform. Given this environment the market shifted towards the web as a way of handling this and now it just doesn’t make a lot of sense to revert back to OS specific APIs.

👤 rkapsoro
We are!

We've built a UI builder design tool, in Cocoa and SwiftUI, for the Mac. The content you produce with it is meant to be consumed (using our SDKs) on mobile, but the authoring tool itself is a native desktop app. Of course the limitation of this is our app doesn't run on Linux or Windows, but our target user persona is highly likely to have a Mac.

We've made use of the built-in Document-based apps stuff (NSDocument and friends) in AppKit and it works nicely as a good desktop app citizen.

I've personally wanted to work on a desktop app for years (after growing up during the 90s and admiring the work of many desktop software vendors). I also think that given how almost all productivity work is done on desktop computers that the native software space is rather underserved.

It's interesting how much of the built-in frameworks on desktop are oriented around a document paradigm, for productivity software. Both AppKit/Cocoa on the Mac and the venerable MFC on Windows are great examples of this.

Actually doing building a non-trivial desktop app involved our team getting up to speed on the programming paradigms that have evolved over the last 30 years on the desktop. It really is materially different from the mobile apps many of us worked on previously.

https://www.judo.app/

https://apps.apple.com/ca/app/judo-in-app-experiences/id1564...


👤 Joeri
There are too many platforms now. Back in the day people would buy into the windows or mac ecosystem and it was all they had. You could build only a windows desktop app and sell it and have enough happy customers to make a living. Nowadays people expect your thing to be on their laptop and their tablet and their phone, so in practice you have to be on windows, android and iOS at a minimum, and probably macOS too, and linux for brownie points. And people often have windows and mac devices and expect you to be on both. Oh, and you better sync their data, so you need a server also.

So you need at least a server codebase, a mobile codebase (or two), and then a desktop codebase. Having to build at least three codebases instead of one is why you see fewer solo developers making a product and earning a living from it. And then for that desktop codebase, you can either build it twice for windows and mac, or you can just build it as a web app and maybe wrap it in electron for easy platform integration. The other cross-platform approaches don’t seem all that much more productive than web dev, so most people stick to web technologies for serving the desktop.


👤 the_kLeZ
First of all: There's nothing like the dicotomy between Windows and MacOS. In fact, even if the share is still very low, there is a significant amount of other operating systems out there used by hundreds or thousands of users, and those OSes are often not covered at all or poorly covered by cross-platform tooling.

Linux is the most prominent example, not only with standard linux distributions, although highly adopted at least by developers and tech enthusiasts, but even with machines like the chromebook, which is is fact a special linux distribution on its own.

The web, on the contrary, is very well supported by any and every operating system out there, because it will be a big shame if you do not support the web in these days. So web apps come in.

In regard to the cross-platform tooling, they are often slow and poorly supported in special use cases and scenarios, so in fact you will come to the need of rewriting the desktop app in a native way, which means rewrite one hybrid app into at least three native ones, which is not really a deal I would make.

For a sample use case of when not to build hybrid apps you can turn to the Microsoft Teams app, which is slow and poorly designed and developed. This has happened because a typical native use case was ported to the web, which in fact works well in the browser, but the underlying cross-platform framework used is not well designed to support those use cases, so in fact it is really slowing down the app.

Last but not least, you still have to make a web app even if you make a desktop app because marketing, and you surely still need a mobile app, same reason. So the webapp is, for the most use cases, the first thing you make and the most universal app you can distribute to your users.

So this is, IMHO, the motivation around the lack of native (really native) desktop apps. These are my 2c.


👤 petercooper
There's definitely a trend, but yet just this morning I read a fantastic article about someone doing just that, and making some money off of it too: https://medium.com/women-make/how-i-built-a-macos-app-and-ma...

👤 o_m
For paid software piracy is still a problem. With SaaS you don't have to think about it, especially if your service uses SSO.

👤 YmiYugy
It's easier to develop and distribute. The web has by a long shot the richest ecosystem for UI development. There are tons of comparatively cheap developers available. Browsers leaks the least amount of the underlying platform through.

Part of the reason is also that cross platform alternatives all come with massive caveats. The ecosystems are tiny, except for maybe Qt. Their cross platform abstractions are very leaky. They are often far more difficult to use.

Distribution of desktop apps is difficult and users are content with web apps. Asking someone to run your untrusted code is a big ask. Big downloads and lengthy installation procedures further raise the bar.

Users also don't expect desktop apps anymore. Not having a mobile app can seriously inhibit your product, but if it works mostly fine as a web app from desktop or in a wrapper like electron few will complain.


👤 lowbloodsugar
Because Apple and Microsoft and Linux all have their own proprietary UI libraries, and their own Look And Feel, and it's just not worth implementing for both/all unless you are super large. And then, if you are super large, then you actually want to create your own Look And Feel.

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.


👤 wepple
> and better privacy/security than a webapp.

Can you elaborate on this?


👤 graycat
I write desktop apps all the time and want to learn how to write more, but the apps I write are (A) for my own use and/or (B) for helping me build my Web site for my startup! So, there is irony here: I write desktop apps to help me build a Web app!

Word to some in the computer industry: Yes, shrink-wrapped, downloadable, installable apps have problems, but a partial solution is end-user programming! Or, all over the world, kids are being taught how to program: Wellllll, they can program and write their own apps, just as macros, scripts, DLLs, or EXEs. And they don't have to go through some install process or worry about computer security! Ah, the security they invade is their own!

But, yes, more with virtual machines, sandboxes, etc. would be good.

One old approach to security was to give a hierarchical file system directory to a user/app and then say, you can do anything you want inside this directory and nothing (or be somewhat restricted, e.g., write only, read only, etc.) outside. That's now an old idea that long worked great. My understanding is the the Windows file system NTFS (new technology file system) has some or all of this functionality ready to go as a means sand boxing.

IBM's virtual machine (CP67/CMS, control program for the 360/67, conversational monitor system) gave the user a directory and a virtual machine and said, go for it, do anything you want in this virtual machine, even write machine code using privileged instructions, write and run a whole operating system -- was safe, secure, and worked great. In fact could run CP67 on CP67 on CP67 -- once as a demonstration CP67 was run 7 levels deep! In fact the reason CP67/CMS existed was as a tool for developing operating systems, but it also made a terrific time sharing system. Anything done back in those days would be just trivial to do today, trivial in the amount of code, how much memory it would need, how fast could start a new machine, how much overhead due to the virtualization, how to have the file system offer the new machine what it needed, securely, etc.


👤 jconley
I think a lot of people touched on it, but when choosing a market for your product as a small team starting out you likely don't choose desktop. Unless your users are primarily on desktop (e.g. pc gaming, software development). These days web and mobile are where the market is at.

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


👤 magicalhippo
Our primary application is a CRUD-ish desktop application, serving a niche. We have large corporations with hundreds of active users down to single-person entities.

Key factor is nobody really wants to host anything anymore. Server updates, firewalls, backups, user access managment, SANs, networks... nobody wants to deal with that stuff. They just want to enter their data, send and receive some messages, get some PDFs.

So, we're trying to get a cloud-based version of our application going. Certainly won't be easy given the abysmal state of web app UI design compared to what we're used to.

But that's where our customers are pushing us.


👤 mark_l_watson
For the Apple ecosystem, SwiftUI is looking pretty good. I wrote an app that works on iOS, iPadOS, and macOS by taking a ten hour online class to learn what I needed. Swift is also a very robust language and platform.

👤 pmontra
Developing a server rendered (traditional) web app is one subjective order of magnitude easier than a desktop one (I did both professionally in the 90s). I believe that mobile is as hard as desktop but I have little direct experience there. SPAs are about as hard as desktop apps. I have some experience on that.

Web apps are orders of magnitude easier to distribute and update.

Hence customers moved to the web and developers followed. The only big market for desktop apps is games IMHO.

Then if I build a web app for myself (I did) I can use it instantly on my phone, my tablet, my laptop. Should I build native apps? No thank you.


👤 eatonphil
I build a desktop data IDE that helps you query files, APIs, databases; script the results; and graph/export. It was important to me to be desktop-first so that you can try it out at work without needing to go through the rigmarole required of a SaaS data analysis product. It'd be as hard to get permission for as installing Sublime or DBeaver.

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

https://github.com/multiprocessio/datastation


👤 syntheweave
For me the biggest aspect of the shift is simply that web and mobile apps became the larger standard to follow, with a higher effective install base.

In the 80s and 90s there was definitely interest in consumer software, but the applications often struggled to be useful precisely because information was bottled up on the local machine, and so you had to think in terms of publishing to analog, which in turn made everything consolidate around the few apps that did those things at a professional level.

Once you got into web based experiences the possibilities for consumers skyrocketed since the information transmission could go "all-digital" - you could post on forums, write a blog, buy and sell goods, publish video and so forth. And by doing it web-first you were writing to a standard with broad implementation.

After the rise of the smartphone the picture has shifted again towards experiences that are consumer internet focused, but using the device that most people have, versus the one that has the most power. There are video editing apps on mobile now, and they're actually reasonably powerful, if not quite appropriate for pro work. Drawing and writing is likewise very accessible on mobile with the small investments of a capacitive pen or keyboard. There's a definite sense of never having to leave mobile if you stay completely in the zone of working with standardized apps to publish online.

The desktop itself has been increasingly ceded to open source projects, for better or for worse. The biggest applications of yesteryear have competition, albeit often still far behind in certain categories. The smaller niche ones often get absorbed into a library and therefore are something you can script to taste if you have a little bit of programming knowledge - much like how microcomputer BASICs worked back in the day, just with more package management cruft.

And if you go in this latter direction for your work, then you aren't writing to a standard, you're writing for a user of one and wholly defining your "information life" on your own terms - and therefore you don't need too much in the way of cross-platform compatibility goop or integration polish, and can probably build off of a terminal, browser window or game engine to provide the UI.


👤 cloudsec9
I think it's a matter of supply and demand.

Right now, more users have switched to doing things on their phones and tablets, so that is what developers are building. If enough people are willing to buy a desktop type app, then developers will sell that to them. But I think the mobile ecosystem offers a better range of possibilities -- you can charge for your app, you can go ad-supported, or you can give your app away (and have in-app purchases or extract value another way). With desktop, you have to charge or give your application away -- there is no ads or in-app stuff.


👤 jpobst
Most consumers no longer purchase desktop apps, so there's no way to support desktop development.

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


👤 phendrenad2
MacOS. "Cross-platform" really just means Mac and Windows, and Mac is too hard to develop for, even if you use a cross-platform toolkit (you have to own a Mac, and you have to install the latest XCode, and you need to figure out how to navigate XCode's bewildering and buggy GUI, and you have to digitally sign your app every time you release a new version).

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.


👤 bni
Pixelmator, Transmit, Nova

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.


👤 teg4n_
I don’t know if I’ve seen a cross platform UI development toolkit that produces truly accessible UIs. At least with HTML you can make a solid attempt to support various AT like screen readers.

👤 jbay808
Maybe at big companies it's hard to convince the team that a desktop application is the way to go, but individual developers can do what they want and many are making desktop apps.

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/


👤 yboris
I have a 4+ year commercial application Video Hub App built with Electron and Angular (it's also charityware - $3.50 of each purchase goes to a cost-effective charity).

https://videohubapp.com/en/

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


👤 b20000
people are building desktop software and have been doing that all along. it never went away. people just think that it did. also, there are mature and solid toolkits for desktop software. why not use those? i would never use a shit app toolkit with its origins in web or browser applications to build desktop software. i have used applications built using web toolkits and the user experience or performance is second class.

👤 Ampersander
There are many reasons web applications are more attractive. Web applications can't be pirated as the user does not receive the program. Users don't want desktop applications, as it's more convenient to login to a web application with a Google or Facebook account than it is to install a native application. A web application works on any device and most people only have a smartphone.

👤 kissmd
i would like to hightlight a precious insight of phtrivier:

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


👤 alexashka
Because there are barely any dedicated desktop software developers and there are a million web developers.

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.


👤 fsflover
> Here are just two frameworks/tool kits that are easy to use and to build desktop apps with.

For Linux, there is Libadwaita to make both desktop and mobile apps in one go: https://blogs.gnome.org/alexm/2021/12/31/libadwaita-1-0/.


👤 knighthack
I personally prefer desktop apps. I find most of them smoother, and more intuitive given that you get used to the controls/widgets of a particular OS and most apps will have some similarities in their GUI. But web apps are so much easier to handle, and you get less of the headaches of OS compatibility, package management, dependencies, security, etc.

👤 kkfx
IMVH because of sheep effect: Big&Powerful push for web(cr)apps because that's what they need for profit and countless others think that following them is a good idea...

Beside that "desktop" was equally abandoned by giants, reduced to a modern dumb terminal with a generic "endpoint" name, just a bootloader for a WebVM improperly named browser for legacy reasons, so develop for desktop means develop for something uncertain: classic widget-based UIs have proven to be limited and nowadays also derailed and crappy, modern document UI essentially exists only in Emacs (and classic, now abandoned, systems) and in web/notebook UI with an uncertain future. So sheep effects aside many think "if I develop a webapp today it's code can be combined with/injected in something else tomorrow", while if I choose Qt who know what can happen, same for GTk, same for non-portable UI libraries (Windows, OSX) and classic Tk are almost abandoned...

We must rediscover classic desktop tech but that means rediscover desktops, not as dumb terminals but as a single and unique system with anything ready available to the user, like classic SmallTalk workstations or actual Emacs, where the concept of "composability" web-app have it's far superior and directly available to the user. Such move can only be done by a community or a giant, since we do not have anymore a real FLOSS community, most are just unpaid voluntary workers for some giant, simply because nowadays most are on someone else computer (so called "cloud"), and giants have the opposite interest... It's unfortunately unlikely.

Everyone have came back to laptop and desktop just because with the push to remote work due to covid scenario they need something to really work or study with and so it appear clear that mobile crap is unusable for that. The mere fact that too many still choose laptop (that are craptop essentially) not because they travel but as desktop replacer clearly depict a thing: people do not have learnt the lesson. They choose "computers" just because they need them, but most still fail to understand that WFH is not put a craptop, perhaps a 14" one, somewhere in a house but dedicate a place, possibly a silent and lockable one (just to avoid Judge cat, MP who have sex in streaming, ...) PER HUMAN BEING in their own house with a proper office setup there.

We can hope for a real came back to desktop if and when WFH switch mode from an emergency push chosen to make companies pay less shifting costs to workers to a stale and developed work mode. Perhaps then enough people will realize what does they really need and so the demand will be big enough to force a change...


👤 fyzix
Slint UI seems promising and I think it'll get some traction once there are bindinds for some high level languages (Go, Python).

👤 13415
I'm currently creating a forthcoming desktop app for Windows and Linux, a special kind of project management software. It's in early alpha but already has features that no web app could possibly have such as loading a directory tree with hundreds of thousands of files within 700 milliseconds (and it's not even optimized yet).

👤 DarrenDev
I'm building one right now: https://sqlonfire.com/

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.


👤 bdlowery
Because windows users don’t buy desktop apps. If you want to develop a desktop app you need to develop it for MacOS.

http://cleanshot.com — an app like this would never make it on windows. But that app has thousands of subscribers paying monthly to use it on MacOS.


👤 amelius
Because GitHub doesn't have a GitStore.

👤 ozim
All the things mentioned in other comments are valid - but for me easiest one and biggest:

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.


👤 gobr
I like some of the patio11 reasons from here https://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-... but this may have changed since.

👤 StewardMcOy
As someone who once worked on desktop apps professionally, I've been asking myself this same question a lot over the last couple years. I think there are a few reasons.

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


👤 _3u10
Lots of us are. They’re called games.

👤 dzdt
Microsoft doesn't even want you to develop indie windows applications anymore. They are pushing Windows S mode where webapps just work and anything else has to come thru the windows app store. The solution to that extra friction is just do web-based.

👤 GnarfGnarf
We work in a field where there is hostility to Web-hosted databases. We developed an on-line version of our app, but sales were dismal.

Plus, our app needs to access databases on the user's local disc drive, which (as far as I understand) is hard with Web-based apps?


👤 eternityforest
Is any explanation needed beyond "You really rake in the cash with SaaS and nobody pirates it"?

It's not like devs own the companies. And even if they did SaaS is a steady paycheck and a load of way more interesting problems that devs seem to love.


👤 freyr
Are customers buying desktop apps?

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.


👤 ramesh31
They are. But it just so happens that now we finally have a truly universal write-once-run-everywhere VM (the browser) that makes development a million times quicker and easier, so people build for that.

👤 other_herbert
I’m making one as an internal tool to help our manual testers use playwright… and I’m using avalonia just because I want to make this thing multi platform… so far I’m impressed

👤 brodouevencode
Fast networks, "good enough" interfaces, easy deployment/portability exist for web apps. It's the lowest friction way to get a product out there.

👤 strzibny
It seems there are new apps for GNOME once in a while and it makes me super happy. I am thinking myself of writing one. They look gorgeous with the latest GTK.

👤 sirjaz
Also, if you track the up and coming chromeos ;). It has only become more widely used since the inclusion of actual apps albeit they are Android apps.

👤 westoque
as an aside, i found this bit from the link for https://microsoft.github.io/react-native-windows:

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


👤 tjr
Nearly every application I use for music production is a desktop program, and there are new ones coming out all the time.

👤 quintes
Ever deployed desktop apps to 15k end user machines over multiple locations? I don’t want to do that anymore

👤 Spooky23
A: Its hard, and web stuff is good enough for 80% of apps.

Plus Microsoft screwed the pooch from Windows 8 onward.


👤 supramouse
there are still a ton being developed in specialty domains (even searching qt c++ on job boards returns a decent amount) not much that's consumer focused a lot of those users have moved to mobile and web

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


👤 swah
What do you mean that people started buying computers again? I'm not aware of this trend.

👤 pathartl
Hot take: web apps are the best thing to happen to the Linux desktop in the last 20 years.

👤 vpbusvltsmtk
Because a web application is cross platform and much easier to develop most of the time

👤 Apocryphon
Hasn't this been the case ever since Web 2.0 hit critical mass, around 2008 or so?

👤 danamit
There isn't much ideas today that are applicable mainly as desktop applications.

👤 tuckerpo
I have to wonder if some of the comments here are satirical regarding security being better on the web.

Nothing screams secure like allowing anyone with an internet connection globally to poke and prod at your duck-typed interpreted language that has 91,324 dependencies for a TODO app.


👤 mike_hearn
We've been thinking about this and working on it a lot lately. I hope to announce our efforts on HN soon (company is in stealth mode and isn't launched yet).

There's really many different aspects to this that you can't do justice to in an HN comment. But firstly let's observe that web vs non-web isn't deeply fundamental. Steve Jobs himself tried to push web apps on mobile devs and they rejected it. Many other people have tried to push mobile web apps and generally, failed. Users wanted apps built with non-web technologies.

So why hasn't this happened on the desktop? I think it's a combination of:

- No sandbox. In turn this means, IT departments are scared of desktop apps and have to whitelist them but many IT departments are bureaucratic and slow, so this can be painful. This is exacerbated by:

- Poor deployment technologies in general, with a poor understanding of what IT departments need. On MacOS X there's no software update system out of the box except the App Store, which comes with massive downsides. On Windows, IT depts generally need some sort of consistent package management system but Windows apps all invent their own, because up until recently with MSIX, Windows has not provided what was needed. Most apps are thus painful to (re)package and control. Witness the screams of Windows network admins about Electron - it's a disaster for them. In effect every Electron apps (using Squirrel) installs into roaming $HOME meaning when users roam massive apps get copied around, slowing down login. This is all wrong but the Electron distribution systems are unmaintained, so it never gets fixed.

- Cross platform desktop UI toolkits aren't that great IMO especially for devs who want to avoid C++. Your best option is JavaFX, but it's not well known and doesn't have a wealthy tech firm who can subsidize its development (any more). Still, the open source community around it has been growing and the tech/capabilities are very solid.

That said, the alternative is HTML5 which isn't a UI toolkit at all. So, a lot of this is comparing apples and oranges.

- Conflation of unrelated aspects, e.g. a lot of people associate desktop app with pay-per-upgrade. You can do that with desktop apps, but you don't have to. You can implement subscription pricing too, c.f. JetBrains or lots of mobile-first SaaS firms. You actually have a lot more flexibility around pricing because your costs are more or less fixed.

You could go on - the web is an evolved technology with a form of evolutionary robustness that takes a lot of work to even analyze, let alone out compete.

Nonetheless, I feel strongly that the software industry should:

a. Analyze why we like the web as a technology.

b. Use that analysis to do better than it.

Here's a controversial opinion for you: HTML5 is reaching end-of-life as a technology. Google lavishly funds Chrome and they don't seem to know what to do with that money beyond try and turn HTML5 into a spec for an entire operating system, except it's one that ignores the entire history of OS design. The sheer size of the spec means it's become unimplementable! Not even Microsoft or Apple can fully implement it anymore meaning it's more or less Google's plaything. The openness was one of the big reasons to like the web; IMO that's no longer a competitive advantage especially as many competing platforms e.g. JVM+JavaFX are themselves open source and actually have multi-vendor communities around them, which Blink does not.

Meanwhile, despite the vast size of the spec, the platform itself doesn't really meet people's needs and hasn't innovated on the core tech. It's stuck in a local minima which kills progress. As a consequence many websites these days are layering many pre-processors and alternative languages on top that compile to the "machine code" of HTML/CSS/JS. Trivial example: the popularity of Markdown is more or less driven by the failure of HTML to be an ideal appearance-neutral markup format. Yet, browsers can't render Markdown sites natively.

We need new projects that try to build post-web technologies, ones that take the ideas that work (markup, sandboxing, a portable browser etc) and throws out or upgrades the ideas that aren't working.


👤 jclay
I just founded a company where we're building a cross-platform native desktop app. Perhaps given we're on HN we can scope this to ask why aren't any _startups_ building native desktop apps?

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.


👤 progrmmr646
web apps are just better. they run on anything that has a web browser in it. web devs as well as the users dont have to deal with many problems related to native software.

👤 rudasn
To those building offline desktop apps today, what database do you use and how do you handle migrations and the like?

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


👤 renewiltord
Thank god we don’t. Now I have Linux apps!

👤 WinterMount223
Deployability (or lack thereof.)

👤 greenail
better question may be: why aren't consumers buying desktop apps as much anymore?