Ask HN: 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
334 comments
[ 5.5 ms ] story [ 378 ms ] threadEverything 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.