Dev Conversations #11: Finn Voorhees
Dev Conversations is a monthly series where Swift Toolkit features members of Swift work groups, content creators, and people who contribute to the Swift community, focused on tooling, developer experience and Server Side Swift.
In these talks, we discuss open source projects, tips for professional growth, and many other valuable insights and perspectives from other developers.
Finn learned JavaScript as a fun way to build little websites. His programming journey, that started around the age of 12, evolved into programming Arduino projects, as he became fascinated by the idea of controlling physical objects such as LEDs. A few years later, he started learning Swift and alongside academic studies, he started building apps and games for iOS.
But it was only a few years later, when Swift started supporting embedded devices, that he was able to merge all his motivations behind programming, into a new open source project, PlaydateKit: a package that abstracts the complexities of C, and provides a more Swift-like interface to the Playdate SDK.
Another project that Finn has just released is yap: a CLI tool that uses macOS 26’s Speech framework to do on-device speech-to-text transcription. By using Apple’s frameworks and running on Apple Silicon, yap not only runs locally, but it also runs faster than any other transcription tool built on top of OpenAI’s Whisper.
In this episode, Finn tells us about his journey as a programmer, from JavaScript to Arduino, from iOS to embedded devices, and how he’s using Swift to build new tools for the community. We also explore the advantages of building CLIs in Swift, and discuss how Swift is becoming a great tool beyond iOS, with support for Linux, CLI tools, server-side projects, and embedded development.
You can also find the written interview and the podcast links after the video in case you prefer reading or listening, and the relevant links at the end of this page.
Also available in your favorite podcast player 
Swift Toolkit
Hey Finn, how are you? Thanks for joining today!
Finn
Good! Thanks for having me.
Swift Toolkit
As I do in every episode, tell me a little bit about your first steps in programming.
Finn
I was sort of self-taught when I was younger. I started with HTML and JavaScript, going through Codecademy tutorials and making little websites. Then I got pretty interested in Arduino, which uses a slightly modified C++.
I was probably 12 to 14 when I was learning microcontrollers and building simple websites. I was also pretty interested in game development with Unity, which is C#, but mostly laying things out visually in their editor.
It was more when I was in high school and early college where I started looking at making iOS apps - little tools to help me with tasks like a bus schedule or a metronome. Then I studied computer engineering and maths in university, which was more traditional programming courses like C++ with a little bit of electrical engineering as well.
Swift Toolkit
And this already takes us a little bit to the topic of PlaydateKit, which combines a little bit of everything that you mentioned, right? It's a little bit of embedded and games and brings the Swift world of iOS development.
Finn
That's sort of why I like working on it so much. It's not just an iOS app or an embedded thing or Swift - it's combining all of those. It's not something traditionally done with Swift or even as an iOS developer, you sort of think of Swift as just a language for making iOS apps, macOS apps.
The cool thing we're seeing in the past few years is that's kind of changing. All of the past interviews you've done about Swift on server, embedded Swift, it's just really cool to see that kind of ecosystem coming together.
Swift Toolkit
And Swift for Embedded differs from regular Swift? There are a few constraints, right?
Finn
There's definitely constraints. When people think about it, they think it's going to be completely different and you're going to have to do all these workarounds. When I first started working on PlaydateKit, I was running into compiler crashes pretty much every few days.
The team at Apple working on developing embedded Swift were really receptive to all the crash reports. Especially the past year, it's gotten a lot better. You still need to install the nightly toolchains to get all the up-to-date features, but with the release of Swiftly macOS, that got a lot easier.
Language-wise, there are limitations like for advanced Unicode features, you need to bundle Unicode UTF-8 tables which adds some code size. Also things like floating point interpolation - printing out a float isn't currently enabled in embedded Swift because it's hard to do without allocations. So you need to convert it to an Int or handle it in a different way.
There's also the no allocations mode of embedded Swift where it disables any functionality that requires allocations. But for hobbyist embedded development, you wouldn't really run into that because the difference between a little microcontroller with a small amount of RAM versus a bit more is maybe a dollar for the chip.
Swift Toolkit
Would you have any tips for people who would like to get a little more into this? Are there any kits that are more compatible with Swift or any tutorials that you might know?
Finn
The Swift Embedded Examples is the best place to start, which is linked to on Swift.org with their new redesign now. It's featuring embedded front and center alongside server side, which is really nice.
There are a few ESP boards like ESP32C6, which is kind of like a smart home board with Wi-Fi and Bluetooth. There's an example for creating a HomeKit LED, which is pretty cool because it's interacting with HomeKit on iOS. And there are a few for Raspberry Pi Pico as well, which is more aimed at hobbyist and education.
I think probably just picking one of the boards where there's already an example for, then you don't really have to worry about compatibility or figuring out the build system. You can just copy and paste the example and start playing with it.
Swift Toolkit
And back to PlaydateKit. Can you tell us a little bit more of what you've been adding support for in the recent months?
Finn
Mostly one of the biggest things is just trying to wrap as much of the Playdate C API as possible. The Swift PlaydateKit is based on the C SDK - it's really just Swift wrappers around the C API, which means you can do anything you can with the C API or the Lua API just in Swift.
The goal of PlaydateKit was to make it more idiomatic when using Swift. The whole inspiration was the blog post on Swift.org by Rauhul who is working at Apple on Embedded Swift. It was kind of the proof of concept showing you can use the C API, use Embedded Swift, run it on a Playdate.
I wasn't even really interested in Playdate before that. I didn't own one, but I just saw it and immediately thought it was really cool to be able to run Swift on what's essentially like a modern Game Boy. It had a few nice Swift wrappers around things, but I kind of wanted to wrap the whole SDK, make it simpler so you don't have to deal with C pointers, memory addresses.
Swift Toolkit
And can you tell a bit more about how the life cycle of a game works for people who might not be so used to it?
Finn
With the C SDK for Playdate, you just define an entry point. You get a pointer to the API basically, and then you call like Playdate.drawRect. With PlaydateKit, there's currently a limitation where you have to copy and paste this external C declared Swift function which is just setting everything up.
Once you do that, you just have your class of a game and you can override the update function, the paused function. So update is called each frame and you can do all your drawing, there's sprites, audio, MIDI, stuff like that. It's really simple once you get started. It's definitely similar to SpriteKit where you can create sprites with custom draw functions, custom update, and you have position, scale, rotation. It's kind of like a very simplified game engine almost. There's nothing for scene management.
Another cool aspect I've been working on lately is the build system evolution. When it started, the Swift.org blog post was just showing how a Makefile can be used with a bunch of Swift C and Clang invocations with all these flags to build the executable. I just copied that at first.
And then I converted it to a Swift package plugin just to make it a little bit simpler. I just didn't want to have to use Makefiles really. And then recently, thanks to all the advances with Swift Build and the Swift Package Manager, I was able to migrate PlaydateKit pretty much entirely over to the Swift Build system.
So you just run `swift build -c release`, and then you pass it this toolset, which is defining all those flags that it needs to build for the right platform and everything. Because of that, it's now using the Swift package manager build system and you can do things like use external dependencies. So you could essentially define a game engine Swift package, host that on GitHub for anyone to use, use that in your game. We're sort of already seeing a few people create Swift packages for various things that people were already using C and Lua. For example, there's one for audio where someone created a Swift package for playing back MIDI songs.
Swift Toolkit
And what about running on the device? Is it by build plugins or it's more manual?
Finn
Right now it is still a package plugin just because once you run swift builds, there's one other step which is converting it to a playdate executable using a tool they provide. I was talking to people about this at WWDC this year - it would be interesting if you could hook into the Swift run commands and have post actions.
The goal there is to just be able to run Swift run and either build and debug on a Playdate or a Raspberry Pi or whatever you want. But we're not quite there yet. Right now it's kind of a little hodgepodge together where if you run it from Xcode, it calls to this external script which builds everything and then launches the Playdate simulator.
Swift Toolkit
And changing topics a little bit, I've also noticed that you are a big fan of CLIs. And just this week you launched yap, and also some contributions to Noora, the design system for CLIs by Tuist. You also have a few pull requests there.
Finn
I wasn't even really interested in command line tools until maybe two years ago when I was sick of writing bash scripts where it's kind of hard to figure out the language. I never really got used to it. So with Swift argument parser, it's really easy to just write Swift and have a command line tool.
One of the first I made was fx-upscale, which is just using metal effects to upscale video on the command line. As part of that, I saw things like the GitHub command line interface have this rendered terminal interface with colors, spinners, loading bars, pickers. I thought that was really cool.
I looked into it, it was only for Go and Python, there wasn't really any library for that in Swift. So I ended up making my own little TUI library for Swift, which worked well enough. But then I saw Tuist released Noora, which is kind of their version, and it was a hundred times better than mine.
So I ended up switching all my command line tools over to that. There were a few missing features that mine had that theirs didn't and I kind of wanted, so I just opened pull requests and they were really receptive to those.
Swift Toolkit
And you mentioned metal and upscaling. And I think that also connects with yap a little bit because one of the huge advantages of CLIs in Swift is that if you are targeting macOS, you can leverage all the OS frameworks for free, right? And as you did with yap, have transcription even faster than Whisper from OpenAI on device. Nothing leaves the device.
Finn
That's kind of what I realized after making fx-upscale. I was like, you can just use any macOS API and your command line tool can be basically just an app, but interacted with through the command line. I think a lot of those Apple APIs, they make these really cool APIs, but then if no developers use it or create an app for it, then it's hard for normal people to just use them.
So things like yap which is using the new speech to text model, which I'm sure apps like Mac Whisper will adopt soon. I think it's just really interesting to have a way to just directly interact with this Apple API, which is local on device, super fast. And you can just pipe input in, put it into whatever other command line tool you want.
Swift Toolkit
And another thing that you mentioned is I think that CLIs are the minimal UI for trying something or for playing with something and something that I've done recently with my own packages. And I think for any package, it's interesting to add an executable target, depending only on the argument parser. So you can show people what your package does.
Finn
It's gotten so simple to implement with Swift argument parser. And if you want to go with a more advanced UI, it's just way easier for me, at least, than trying to figure out the bash syntax to make the same thing.
Swift Toolkit
And to finalize, what are your thoughts on the future of Swift? For embedded, for server, for CLIs, as a language as a whole.
Finn
I'm really optimistic about Swift. You can see from the redesigned Swift.org website, which is featuring everything we talked about today - cloud services, embedded, the command line, and that's all above iOS. And then you even have Windows apps on there.
There's definitely a really big push for just this completely cross-platform language, as well as on the tooling side with the open-source Swift build from a few months ago, which is kind of also working towards cross-platform on the tooling side.
A lot of this interacts together really well. Embedded, Swift on server, you have things like Swift WebAssembly, which you can use embedded Swift for to reduce the code size. So I think it's just all kind of coming together slowly into this one language for everything.
I love it, I am very biased towards Swift, but it's what I write all day. And especially just talking to everyone at WWDC about it, I had even more fun this year just talking to people in the Swift ecosystem about things like this versus even just Apple's APIs.
Swift Toolkit
Yeah, we're all excited to see what else is coming and being able to push for this. I think that the whole community gains from it as a whole.
Thank you so much Finn! It was very nice talking to you and see you in the future.
Finn
Yeah, thanks for having me on!
Swift Toolkit
Bye bye!