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
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.
* "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
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.
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.
- 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.
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.
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.
Its 100% native Objective-C code on the client, plus a mixed Objective-C and Python pipeline for maintenance and backend - around 60 kloc in total. The other major components are a 50 kloc config-file and a 800k row database.
In addition to being fully desktop native, we also don't sell subscriptions.
> why aren't devs making desktop apps any more
we have a unique insight into the market, having seen every Mac app published in the past 20 years. i don't think your assertion is correct, there are a lot of desktop apps around. there are a few thousand apps under active development, and the majority of them are actually native, not electron (we count 25.000 native sparkle-feeds URLs versus 4.400 electron-feeds). i'd phrase the question the other way: why are there still so many native apps when most end users would never spend a dollar on software? i believe there are quite a few hobbyists out there, developing for fun or out of hopes of being able to make a profit later on. that further contributes to the expectance that software needs to be free, further destroying an already very weak market.
I 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.
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-....
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.
The UI for webapps is worse than for desktop apps, but not degrades enough to compensate for the better deployment story. (For most apps.)
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.
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.
Shameless plug
I am working on loadjitsu, a desktop app for load testing. https://loadjitsu.com
- 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.
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.
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.
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.
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.
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.
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.
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
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.
Thats why no one builds desktop apps any more.
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.
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.
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)
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.
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.
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.
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.
What's the point of building an app if you can't convince anyone to install it?
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/
- 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.
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.
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.
- 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...
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://apps.apple.com/ca/app/judo-in-app-experiences/id1564...
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.
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.
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.
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.
Can you elaborate on this?
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.
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. ;)
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.
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.
If I got funding or this becomes sustainable I'd be interesting in building native versions.
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.
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.
However, for some reason, many consumers will happily subscribe to SaaS apps. So developers go where the customers are.
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.
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.
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://github.com/whyboris/Video-Hub-App - MIT open source :)
"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".)"
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.
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/.
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...
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.
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.
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.
- 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.
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?
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.
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.
> 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.
Plus Microsoft screwed the pooch from Windows 8 onward.
a lot of spaces are totally dominated by entrenched players (office)
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.
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.
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.
I had some ideas for desktop apps (with electron and nwjs), but that's where I got stuck (and lack of time of course).