Founder/CTO @ Geostar.ai ✦ Prev. Founder Monto (acquired)
@Alonely0 Agreed. Rust's ecosystem is dramatically broader, and Swift and Rust are converging in language features anyway.
After porting the project to Swift, Rust now looks like the wiser choice, especially if we're heading toward a world where languages don’t need to be easy so much as correct, fast, and backed by large, battle-tested ecosystems.
I thought about writing the low-level parts in #Rust and then binding a high-level #Swift API on top.
But #GPUI for example all closures and borrowed state. Doesn't cross language boundaries well.
So if I actually want Swift, there’s no real GPUI alternative. Which means rebuilding a similar API on top of Skia.
And that means… way more code. Code I now have to maintain. I'm in limbo.
Many components still don't work properly, but we're close to parity with the Rust version.
Anyone wants to port a simple macOS app to Linux? Be my alpha tester.
I'm in Swift bindings hell.
Skia bindings implemented. Yoga bindings implemented. wlroots bindings implemented. libinput bindings implemented.
I'm so close to rendering a window surface!
My Ghostty shell froze for weeks.
It turned out Ghostty reloads its config, which reloads fish, which runs nvm, which costs ~500ms.
Lazy-loading nvm fixed it.
Then there's reactivity. I could switch to Iced and get it built in, or bolt a reactive layer onto GPUI myself.
To get macOS people to take Linux seriously, a Swift-based path might feel less like moving to a different planet, as long as AppLib ends up with an API that’s close enough to AppKit.
It’s early enough that I can still change direction, so I’m asking the annoying question: am I using the right stack?
Rust + GPUI is working, but I keep wondering if Swift would be a better fit, simply because the language was designed with SwiftUI-style ergonomics as a first-class idea.
I've noticed that as writing code gets easier with LLMs, I'm more grateful for Rust's borrow checker, not less.
The problem shifted from "can I write this?" to "does this actually make sense?". Strong compile-time checks help with that. They force things to be explicit.
Lately I find myself wanting even more of that: more checks, more linting, more pushed into the compiler, so that it helps me converge on something that's actually correct.
I used Jellyfin to watch a movie yesterday.
Setup was seamless. It just worked. I’d heard a lot about it, but I was still pleasantly surprised. That kind of experience is rare now.
The only hiccup was packaging: the deb and repo only support LTS, so I ended up using Docker. That took a few extra minutes. In hindsight, I might even prefer it this way.
It’s nice when software stays out of the way and does what it says.
Is anyone rolling their own docs system on top of Next.js instead of using Nextra or Fumadocs? I want to setup and host docs for AppLib and am not happy with the options I've tried so far.
Latest macOS Mail doesn't have a button to fetch mails anymore. I use this all the time, because I don't like waiting for the mails to arrive with over 10 mail accounts.
Now I need to click through the top menu or remember the hotkey.
Another tool I can’t live without is Raycast / Spotlight. On Linux, nothing really compares.
So I’m building one. Partly because I need it, mostly because the best way to test a Linux AppKit alternative is to use it for real work.
@mygnu Thanks! Haven't published it yet, but will do it in a week or two from now.
I'm so happy to read Howard's comments on the latest macOS updates. This is why I finally made the switch to Linux and I'm working on my own desktop environment and UI library. I want the same experience back, adjusted for today's possibilities.
https://eclecticlight.co/2025/12/28/last-year-on-my-mac-look-back-in-disbelief/
A lot of disappointment with AI coding comes from vague use, not bad models.
There are two mistakes: banning AI outright, or asking it to solve problems you don’t understand.
The useful approach is boring: understand the problem, write a clear spec, let the model fill in the obvious parts, then review. It reliably saves time, **but it doesn’t replace thinking**.
