Still plain old Swift (or when the itch strikes, Objective-C) and AppKit. I don’t really build for platforms other than macOS because I haven’t found toolkits that feel right elsewhere. I would do just about anything for multiplatform AppKit.
Ask HN: What toolchains are people using for desktop app development in 2025?
81–90 of 136 posts
Re: Ask HN: What toolchains are people using for desktop app development in 2025?
#82Re: Ask HN: What toolchains are people using for desktop app development in 2025?
#83Re: Ask HN: What toolchains are people using for desktop app development in 2025?
#84Flutter is a super compelling framework ( https://flutter.dev/multi-platform/desktop ), but I’d live in fear of it randomly being sent to the Google graveyard.
Re: Ask HN: What toolchains are people using for desktop app development in 2025?
#85Re: Ask HN: What toolchains are people using for desktop app development in 2025?
#86Topping my list of GUI toolkit requirements are cross-platform and native look & feel. As far as I know, Qt still beats everything else in these areas on the desktop. It's mostly excellent. 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 o…
Re: Ask HN: What toolchains are people using for desktop app development in 2025?
#87Re: Ask HN: What toolchains are people using for desktop app development in 2025?
#88Earlier quoted context omitted.
Which embedder did you guys end up using, Toyota or flutter-elinux
flutter-elinux -- By the Sony guys yea? We use that one!
But in hindsight I think flutter-pi or the Toyota one might have been a better investment. The lead engineer in Sony behind the elinux project left for Nvidia. The Toyota one uses Wayland, you can't make it directly hook into DRM. So you'd need a minimal compositor to get it running.
Re: Ask HN: What toolchains are people using for desktop app development in 2025?
#89Earlier quoted context omitted.
https://caniuse.com/native-filesystem-api Looks like Firefox does not support it currently.
It's even worse than that. If you click on the resources section, you can see that Mozilla considers the proposal harmful[1]. They say there's a subset of features that they may consider. Safari seems to be in the same boat, but I can't find an official standards position. [1] https://github.com/mozilla/standards-positions/issues/154
In place of this, Firefox recommends using the origin private file system (OPFS)[2] which is basically a sandboxed filesystem that the users cannot access. Though I agree from a security perspective it kind of makes sense (not particularly for my usecase), but it removes the ability for the user to have realtime changes on local files.
An example of this is using the web based tool as an intermediary step or a processing step in a bigger pipeline; I save it using my web tool and then native applications automatically handle file updates. This just creates an extra step for Firefox/Safari to replicate changes locally by having to manually update local files.
Also neither Firefox nor Safari support showDirectoryPicker() which also creates blocks for building a web based editor.
I love Firefox and I hope they can add support for this. I have stopped caring about Safari/Webkit completely because it's hellish to try and maintain feature parity while NOT sacrificing innovation and ease of use.
[1] https://developer.mozilla.org/en-US/docs/Web/API/FileSystemO...
[2] https://developer.mozilla.org/en-US/docs/Web/API/File_System...