Live data from Hacker News

Ask HN: What toolchains are people using for desktop app development in 2025?

news.ycombinator.com

81–90 of 136 posts

Re: Ask HN: What toolchains are people using for desktop app development in 2025?

#81

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.

AppKit is indeed great. Pity Apple doesn’t give it much love anymore.

Re: Ask HN: What toolchains are people using for desktop app development in 2025?

#84

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

I do have to wonder if decoupling dart from flutter would boost flutter. Flutter and typescript, dart is fine but you know most people have another major language with tooling and what not

Re: Ask HN: What toolchains are people using for desktop app development in 2025?

#85
post #80

Earlier 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!

does it support webview?

Re: Ask HN: What toolchains are people using for desktop app development in 2025?

#86
post #62

Topping 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…

Gpui is not on crates.io. This is a problem with Rust UI in general that they are not stable and often change API. The only exception here is Slint which seems stable in 1.x for some years.

Re: Ask HN: What toolchains are people using for desktop app development in 2025?

#88
post #80

Earlier 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!

Okay so we ended up using that too, it was really well done and documented.

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?

#89

Earlier 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

I have been evaluating and testing the Filesystem API for a local first web based CAD editor and having direct r/w access to the filesystem is a great way to make such a thing, couple with the FilesystemObserver[1] API this makes building proper editors on the web a breeze.

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

Post reply on HN