This got me thinking: My own experience with desktop development dates back to the late 90s using Turbo Pascal 6 in Delphi, and I'm out of the loop on modern practices. With the evolving landscape, I'm curious about what tools and workflows developers are actually using today.
Some questions to spark discussion:
- What programming languages and frameworks are popular for desktop apps? - Are there any go-to IDEs, build tools, or libraries that make development easier? - Do the above answers change if you care about code performance or efficiency (whatever that means to you)? - Is native desktop app development still viable as a career, or are most greenfield projects shifting to web-based alternatives?
I'd love to hear from folks with recent experience—success stories, pitfalls, and recommendations would be great. Thanks in advance for sharing!
[0] https://news.ycombinator.com/item?id=44841291
I've been using Visual Studio Code and Github Copilot together, and it seems to work ok. I've not used it heavily, though, as I'm retired.
Before that, handling files in the browser was cumbersome. You had to offer download and upload links for users to manage files. And handling whole directories was impossible.
But now web apps are like native software tools that you can use to edit and manage files on the file system.
And the bonus point is that it is fully functional on mobile too. Without any changes. At least on Android.
I wouldn't really recommend a career out of it.
Still supported in latest .net versions.
Normally with the Windows DX12 backend, sometimes with the SDL+OpenGL backend if you want cross platform support.
Other frameworks are sort of disappearing. C++ all the way although some use it with C#.
For Mac only: new apps use Swift, legacy ones use Objective-C, both with AppKit.
Linux only: these are quite rare and there is a broad mix of them: C++, Java, etc.
Cross-platform: C++ with Qt seems to be the standard. Go and Rust seem to be rising. Rising UI libraries are Tauri, Slint and Iced.
Would consider flutter for smaller apps as I had a great experience before.
Been developing mobile apps for over 15 years. This is by far the best stack for developing mobile apps. Speed, total control, native UI's. Love it.
With that being said, I'd like to try the modern .NET stack sometime. Shame that the UI side of things is still largely Windows-only, and even Microsoft themselves don't know which UI framework they're using this week.
Rust as a statically linked library where it makes sense.
Rust + Egui for special cases like DAW plugins.
Quite good, I've been building this Pomodoro:
https://github.com/reciperium/temporis/
I've also used nix to build the packages when possible.
One of the things I like about slint is that it has native components. They also have experimental support for Android and iOS.
The language is quite simple as well. Though it could benefit from something like flex
Earlier I was HTMX, Jinja templates, Flask, Tailwind and little vanilla JS. It was too inelegant for my taste.
I am considering moving to either Swift, or JS/Svelete
Outside of work, I'm out in left field using Common Lisp for most of my projects, so I'm not sure how helfpul this is, but...
In the past, I used Qt4 because there was an amazing Common Lisp binding and it worked well on Linux, FreeBSD and OSX. It's increasingly hard to use Qt4 any more, though, and changes in the Qt project made the technique used by the Qt4 bindings impractical for Qt5 or Qt6 - at least that was my understanding when I looked into it.
For newer things I've tried LTK but don't really like the looks of it and I wouldn't say it's "modern". It seems to work across platform well enough, though, and for simple stuff it's okay.
More often than not I'm using a combination of the Slime tools in Emacs in combination with an GLFW/OpenGL window. Often I'll use the inspector to display data and make changes that show up in an OpenGL window, or run some commands in the REPL and pop up an image in an external viewer or load something in a browser. It only works for certain types of applications, and I won't even pretend it's practical for end users, but it works pretty well, and it's flexible as a developer.
I'm curious to see what other people say. It's been a while since I madea full blown GUI application.
- What programming languages and frameworks are popular for desktop apps? - for me - Blazor Hybrid / MAUI / Avalonia UI / WinForms
- Are there any go-to IDEs, build tools, or libraries that make development easier? - I use MSVS 2022, VSCode for .NET, IntelliJ for $$$ at work. There are of course UI control libraries, I am using MudBlazor for Blazor WASM / Hybrid, other than that I use built-in controls that come with each framework. I try to use as little as possible of 3rd party libraries b/c my apps are security-sensitive.
- Do the above answers change if you care about code performance or efficiency (whatever that means to you)? - in my case no, I am able to find what I need in .NET ecosystem. Modern .NET supports ahead-of-time compilation compiling to native code, and that helps to reduce start-up time which is important for Desktop / CLI. Ironically, for a long running processes, like a web service, the just-in-time compilation sometimes produces code running faster than ahead-of-time compilation, b/c it learns most common execution paths at runtime, and is able to recompile on the fly, optimizing for most frequent execution paths, giving a non-trivial performance boost in some cases
- Is native desktop app development still viable as a career, or are most greenfield projects shifting to web-based alternatives - depends on the app/use case. For my project, desktop is the first class citizen, but I am building E2EE apps, i.e. end-to-end-encryption apps, aka client-side encryption, and native / Desktop / CLI is a better fit for E2EE in most of the cases compared to web apps. For those Web apps that I have it is still E2EE but in the browser (still client side encryption)
I worked in WPF for a decade. I wouldn't go with it for a new project since it's Windows-only and doesn't support AOT.
At work we have a Blazor MAUI hybrid desktop app because it also has to run on the web. If we only needed a desktop app, I'd go with Avalonia.
[1] https://linklever.net/ [2] https://github.com/endurabyte/FitEdit
However, I find The Qt Group's commercial licensing (and their tactics as reported by various people on HN) a little scary. If I were to go commercial, I think I would stick with LGPL Qt and link dynamically or give customers my object files for re-linking, because I get the impression that accepting a commercial Qt license that might restrict my ability to use open-source Qt elsewhere. I suppose there might be some other way to safely navigate those waters, but from what I've read, The Qt Group has a reputation for making this far from hassle-free. It's not an immediate problem because I currently use Qt only for open-source and personal tools.
I have grown tired of C++, so I've been using Python to drive Qt. The bindings are very good, mirroring the C++ API so closely that I just use the C++ docs when I need to look something up.
I've also been watching for Qt bindings to other compiled languages, mainly for distributing non-Linux GUI apps more simply than Python allows. Such bindings often turn out to expose only Qt Quick, which lacks functionality that I sometimes need, but there are a few that expose Qt Widgets. For example, these Go bindings:
I hope we'll eventually see a cross-platform GUI toolkit rivaling Qt in a language more pleasant than C++ (and ideally easier to bind to other languages). The one being developed for internal use by the Zed editor has some promising ideas about how to render native-looking text, which I think is a good start:
- For C# I like AOT assemblies using Uno or Avalonia.
- For Go I like TCell (which does cross-platform console mode text GUIs [with cursor positioning, colours, mouse, etc]).
- If you're doing vibe coding I find it tends to work best with Electron.
- The big omission here is anything Python; I don't do desktop apps in Python so can offer nothing. Same for Ruby, though Hotwire Native looks interesting.