Make It Native

There are a lot of advantages of native software over web-based software, when done well. I don’t think that statement is controversial. We usually talk about the obvious: respect for platform idioms and design, alongside performance. But less about integrated accessibility or the unique features each platform provides.

But for years there’s been a trade-off. Writing native meant multiple codebases, more engineers, and feature parity was a constant fight. This usually meant only well-funded teams would have the capacity, or that you’d see native mobile apps but a shared web app on desktop.

A couple years ago, I started asking a question: can agents handle native code and libraries? They’ve always excelled in the web space, which makes sense given the corpus of open-source and well-documented JavaScript to train on. But native has always been trickier. There’s less code out there to train on, libraries are more opaque, and the tooling can be convoluted. When I tried working with Cursor to create a native Windows app in 2024, the results were weak to the point where it took quite a lot of debugging to get what it had written to even build and run.

Skip forward just a year, and I’m back pondering the same thought. But things have moved on. CLI agents are here, the models are stronger. So I pull out Claude Code and throw Opus 4 a task: create a WinUI 3 app for the server platform Proxmox. This time, I got back a working result.

I wouldn’t call the app “well crafted”. Far from it: Claude still didn’t fully understand the native user interface toolkit and was trying to apply a weird mix of Windows and web styling. But the fact it ran and worked was incredible.

This put me into overdrive. Suddenly all the things I’ve wanted to build for years have been unlocked.

Please Do Not Touch

We have a Plex media server at home, but the official Plex app for Windows is just a wrapper around their web app. Serviceable with a keyboard and mouse. Frustrating to use with touch. The buttons are too small, menus don’t respond right, it just doesn’t feel great. I channelled that frustration into creating Hearth, which uses Windows App SDK and WinUI.

Now I’m getting all of those touch behaviours for free with the platform. To the point where it led me down a rabbit hole — could I explore more tailored interactions that extend what’s built in? iOS has a fun interaction model where long-pressing on an item shows a preview of its contents, a legacy of the 3D Touch pattern debuted over a decade ago. Could a design like this be adapted to Windows to, say, show me more details of a music album on long press?

There’s some nice details here too. If the item is partially off-screen, it’ll float up to be visible. And it’ll correctly account for the edges of the window to avoid the preview being clipped. I didn’t create visual designs or even motion specs here. This was all through prompting and describing the behaviours I wanted in detail.

I spent time crafting a few more microinteractions. The titlebar’s back button smoothly animates in and out when it’s needed:

The filter bar on media library pages was fun. The Windows Community Toolkit has a similar control available in the form of an experimental TokenView, but it didn’t support nested filters. For example, I need to be able to drill down into Years -> 2014. But the toolkit is open source, so I was able to craft an alternative using the original control as a reference. Some animation logic later, and there’s now a bar that can work with simple top-level filters and drill-down with quick motion as the subfilters load:

The transition in and out of the full-screen music player also required some choreography. A connected animation hands the album art across, the rest of the page slides up from the bottom, and the titlebar fades through it. The background of the player is a mesh gradient, sampled from the album art to create an immersive feeling:

There’s still a few more features Hearth needs to get to a shippable MVP, but agents are letting me delegate that heavy lifting so I can focus my energy on the visual design and craft.

You Can Just Port Things

I really liked Ryan Stephen’s lil agents project, small companions that wander above your macOS dock for quick access to conversational agents. It’s written as a native Swift app. In the past this would mean there’s no easy way to bring that product to Windows. There is a Swift toolchain for Windows, but no easy translation for the Mac-specific AppKit UI.

In 2026? It’s an agent prompt away. There are caveats though. The initial port is never truly clean, and this is where platform knowledge still goes a long way. macOS has one dock in one place. Windows has a taskbar that can sit on any of four edges, auto-hide, and span multiple monitors. “Float above the dock” suddenly turns into a complex geometry problem. The agent could write the code, but I had to nudge it towards investigating the right desktop APIs and looking into edge cases. About an hour of back-and-forth got me to a functioning proof-of-concept.

Give Ryan’s app a try if you haven’t already. It’s a fun interaction model with cute artwork, and supports all major agent harnesses.

Pushing To Production

Okay, but everything so far could be bucketed as experiments and haven’t shipped in a meaningful way. I wanted to push further.

Earlier this year, the UK Government introduced the Fuel Finder API, with retailers required to submit up-to-date price data. A small wave of fuel-finding products followed, mostly websites in the browser. That’s fine, and it’s the best way to target all platforms. But I wanted something that felt native on iOS.

I had two goals. One was native integrations: notifications and widgets, Siri shortcuts, Spotlight search, an Apple Watch app (why not‽). The other was to be ad-free and privacy-preserving. The leading iOS app for checking fuel prices has ads/promotions. Others collect or store location data. I wanted to create something more respectful.

Range is that app, taken from initial prototype to production in about two months over some late evenings and weekends. This was my first proper go at SwiftUI, and I now understand why some designers really appreciate it. The UI logic reads cleanly, animations are implicit, state lives where you’d expect. I briefly flirted with a native AppKit Mac app but have yet to ship that. Maybe one day.

The speed of iteration wasn’t surprising anymore. What got me was watching agents pick up Apple SDK trivia alongside me. App Intents, WidgetKit, App Attest, Watch Connectivity, they all have their own quirks. I’d describe what I wanted and the agent would point me at the right Apple system to use. A fun collaborative way to learn a platform.

Range went live in April, and UK users can download it and give it a try.

Music To My Ears

I’ve been seeing more ads in public for “retro” tech. Though I use that term loosely, are mid-2000s iPods considered retro yet? Anyway, this resurgence of offline tech has been interesting to follow. I have a 2009 iPod classic which I like to pair with an old iPod Hi-Fi to listen to music. But if if you buy lossless music from sites like Bandcamp, or rip CDs you own, you might have run into a niche problem: the stock firmware on iPods doesn’t support FLAC — a popular lossless file format.

You can solve this with a third-party firmware like Rockbox. I tried that but found that the iPod lost some of its charm. There’s a beauty to the stock firmware. Its design, the sound of the click wheel, swiping albums using Cover Flow. This leaves someone with a library of FLACs with a tough choice:

1. Convert all the FLACs to Apple Lossless (ALAC). The iPod natively supports this format. But then you have two copies of the same file, unless you re-standardise on ALAC.

2. Allow iTunes to auto-convert the FLACs to AAC, an option available in the sync settings. Ouch.

If you cared about audio quality to have your files in a lossless format, you probably wouldn’t accept 1. And 2 results in duplication or mass-conversion of existing files. And either way, you’re left needing to rely on Apple’s somewhat limited software.

The space here is interesting. There are plenty of music library managers that claim to offer iPod sync functionality. But I could never get any of them to work right, they either straight up refused to sync or relied on a weird connection to iTunes that was unreliable. Time to build my own.

Thankfully others have done the work of creating libraries that can work with the custom file structure and iTunesDB of these iPods. I was able to create a simple Rust TUI that pointed to a folder, used ffmpeg to convert into ALAC format, then copy it with any added metadata and album art to the iPod. It’s a slow process, my iPod still has its original mechanical hard drive and the connection is USB 2.0 only. But success! I have an iPod full of my music.

But what about background or automatic syncing? If I add more music to the library, I need to remember to run that TUI again. A tray app would be great, something I can set up to point to the folder and it’ll just sync the iPod whenever it’s connected.

Everything comes back to WinUI in some fashion.

It’s simple by design. I didn’t want to create a media library manager — that’s for other apps to fill. Just a lightweight status panel and setup wizard on top of the Rust library we already built.

I’m calling this Classick for now and it’s open source, so you can give it a try. Though it’s an alpha at best. There’s still bugs and I only have one iPod model to test with…maybe it’s completely broken with others. The GUI app is Windows only, but the Rust TUI should function on any platform (hopefully).

It’s All In The Fun

Yes, that’s a Windows XP application. The idea came about one weekend: “Could Claude write and deploy a native app for XP, using period-correct tooling? Maybe it’d be fun to make a Cowork clone for all those agentic tasks you want to get done on your twenty-plus-year-old operating system.”

I didn’t really expect the idea to have legs. There’s not even a way to run Claude Code on such an old system. It helpfully suggested workarounds though, and soon I was using SSH to connect to an XP virtual machine and building a .NET 2.0 program using Visual Studio 2005. It’s got to be period-correct of course.

It required getting the agent to think in and design for a system of this age. It kept reaching for PowerShell, which didn’t exist at XP’s release. I eventually had to add an explicit instruction to its system prompt forbidding it — a small reminder that even modern agents have muscle memory.

This was never a serious project, and that’s almost the point. A lot of the AI narrative centres around the grind. What about using a coding agent for something silly, like this? Playing with the UI and bumping into the limits of the framework, taking a stab at scripting Office automation. The best bit was wiring up the forgotten Microsoft Agent API so that Merlin the Wizard would react to what the AI was doing: reading a file, writing a file, running a command. He’d animate accordingly. A Clippy-era mascot reanimated by a modern language model. I chuckled a bit.

Okay. One last thing.

Macintosh System 7 was first released in 1991. I assumed writing anything new for it was far off the table.

But there’s a tiny OLED display on my partner’s desk that pays tribute to the original 1984 Macintosh. Most of the time it just shows Prometheus metrics through a terminal interface. Which led to an idea… why not render those metrics as a native System 7 app, running in an emulator on a Raspberry Pi? I chose System 7 as it’s one of the earliest Classic Mac operating systems to have a usable networking stack.

The tooling required is ridiculous. Retro68 to cross-compile 68k binaries. MacTCP for HTTP. A handwritten JSON parser, because there isn’t one for the platform. QuickDraw to render. hfsutils to assemble the disk image. Basilisk II to actually run the thing. With agents, I waded through it and ended up with a working app.

My favourite moment was a bug that ate an afternoon. After a layout change, every window drew its title bar but the contents stayed blank. We eventually traced it to a hidden window that had been left as the active QuickDraw drawing port, so QuickDraw was happily sending the redraws to somewhere nobody could see them. The kind of bug an old-school Mac developer would’ve recognised in seconds.

Does this need to exist? Not really. It takes no input. It’s a kiosk. But it has real menu bar items, multiple views, an About box. It feels like a System 7 app, and that’s the fun part.

I’m excited for this renaissance of native software. With agents handling the heavy lifting of platform APIs and boilerplate, there’s more time to be spent on the details and craft that matter. What will you build?