There's a version of the Spades Audio story that fits on a project card: native macOS audio utility, C++ HAL plugin, SwiftUI interface, shipping soon. That version is true. It's also missing everything that actually makes it worth writing about.
So here's the other version.
Why an audio app, of all things
Karthik and I have been friends since the CricHQ days in Chennai, back when we both joined the new office on day one. We've talked about building something together for years. Most of those conversations went nowhere, which is normal — most of them should.
This one stuck because it scratched a real itch. macOS is weirdly bad at letting you control audio per-app. You can't easily send one app to your headphones and another to your speakers, or set different volumes, without paying for something or fighting the system. We both wanted it to exist. So I started building it.
Fourteen years of experience, suddenly a beginner
Here's the part I didn't expect. I've shipped a lot of apps. I've architected platforms from nothing and led teams. I walked into Core Audio assuming that experience would carry me.
It did not.
Audio on the Mac lives in a different world from the UIKit-and-SwiftUI life I'd been living. You're writing a HAL plugin — an AudioServerPlugin — that the system loads into a separate process. It's C++. It runs in a real-time context where you can't allocate memory or take a lock without risking glitches in someone's audio. The documentation is sparse and old. A lot of what I needed, I learned from reading other people's open-source drivers and from a few forum posts written by maybe five people on earth who understand this stuff.
For the first few weeks I felt like the version of me from 2010, building that music player on a simulator because I couldn't afford a phone. Genuinely lost, genuinely excited, reading everything twice. It's a strange feeling to be senior and a beginner at the same time, and honestly it's the most fun I've had programming in years.
The work after the work
I have a day job. I build the iOS SDK and crash reporters at Dynatrace, which is its own kind of low-level work, and it takes real focus. Spades happens in the gaps — evenings after my son is asleep, weekend mornings, the occasional stretch where an idea won't leave me alone and I lose a Saturday to it.
That rhythm changes how you build. You can't hold a huge mental model in your head across three days of fifteen-minute sessions, so you write things down, you keep the next step small and obvious, and you make the project easy to pick back up. It's made me a more disciplined engineer than any process at work ever did.
What's actually hard
People assume the hard part is the audio math. It isn't, mostly. The hard parts have been:
- The real-time constraint. No locks, no allocation, no surprises on the audio thread. It rewires how you think about every line.
- Distribution and entitlements. Shipping a system plugin through the App Store sandbox is its own multi-week adventure that has nothing to do with audio.
- Being the whole team. I'm the only engineer on the macOS side. Architecture, UI, the engine, analytics, the release pipeline — all me. There's nobody to hand the boring part to.
The SwiftUI interface, which I assumed would be the easy bit, has been a nice break every time I come back up from the C++ basement.
Almost there
We're close to the first release now. I keep resisting the urge to add one more thing, which is the oldest trap there is. The plan is to ship something small and real, get it in front of people, and grow from there. Maybe build a team eventually.
I'll write more as it goes — the actual technical writeups, the Core Audio things I wish someone had told me, the App Store fight. For now I just wanted the honest version on the record: this started as two old friends wanting an app to exist, and it turned into the most beginner I've felt in fourteen years. That turned out to be the whole point.