At any given time, I’ve got a number of active streaming services (some of which I rotate through during the year). Between the shows Meghan and I like to watch and the shows the kids like to watch, I don’t always know where to find what show or movie any of us are trying to find.
On top of that, this is an all too common song and dance: Someone recommends a show, I open Netflix, it’s not there. Try Hulu. Not there either. Check Disney+. Nope. It’s at a point now where I’ll drop the title in a note and maybe I’ll remember to look it up later. Or maybe not.
This happens enough so I built something to fix it. First, as a web app (which I’ve talked about), and now as an actual iOS app.
Back in March 2025, I wrote about reviving Remove Empty Shortcodes after letting it collect dust for a few years. At the time, I’d rewritten it, added support for multi-line shortcodes, and pushed it back to the WordPress plugin repository.
That was version 0.6.0. This is 1.0.0 and it’s a much more significant release.
Spotify is my preferred music streaming app primarily because it’s discovery algorithm is second-to-none. But there’s one thing the macOS app doesn’t do that I wish it did (and that third-party apps used to do but have since, apparently, languished): tell me what’s playing.
I spend most of my work day with music running in the background. Spotify lives somewhere behind a dozen windows, and unless I deliberately click over to it, I have no idea what track just started. Sometimes I’ll hear something and think “what is this?” then forget to check because I’m working on something else. By the time I remember, three songs have passed and it’s gone.
Yes, I know the iOS app shows a Now Playing widget. And yes, Control Center on the Mac technically shows media info. But neither of those send me a notification when a new track starts. I don’t want to check something. I want to be told.
“I’ve got too many tabs open” or “something something too many tabs across too many browser instances.” It’s a common phrase for a lot of us.
For me, maybe they are for research for a project, a handful of articles I’ll “read later” (even if I have a “read it later” app already), or just the accumulated debris that’s happened throughout the week.
Then I get prompted for an update. Maybe it’s for the browser itself or maybe it’s for the operating system. Regardless, either one requires a restart and though I read “we’ll restore your tabs after the restart,” I find this doesn’t happen consistently.
Maybe its PEBKAC. If that’s the case, though, maybe the solution can EBKAC, too.
The core problem is this: Closing everything means losing context. Sure, it’s possible to bookmark each tab individually, but that’s tedious. I could use a session manager extension, but most of them do far more than I need.
About nine months ago, I wrote a case study about building TuneLink – a web app that converts music URLs between Spotify and Apple Music. The original post covered everything from the matching algorithms to the tech stack to my thoughts on using AI as a development accelerant.
Since then, I’ve made a few updates:
the domain moved,
the UI got a complete overhaul,
performance was optimized for both desktop and mobile as benchmarked by Lighthouse
And I’m currently toying with the idea of converting it into a small service that will expose an API of sorts to allow third-party (well, very limited third-party) access to the site.
If you’ve been using TuneLink or just read about it last year, here’s an update.
Why Change Domains?
TuneLink originally lived at tunelink.io. It now lives at tunelink.tommcfarlin.com.
Why, though? Consolidation and frugality. I have a handful of small utilities and side projects scattered across various domains, and maintaining them all separately was getting tedious. Plus, I don’t want to pay for domains (or other infrastructure) for projects that aren’t yielding any type of return to support them.
Moving TuneLink under my personal domain simplifies things – one less domain to renew, one less set of DNS records to manage, everything lives under a single umbrella, and it costs less.
The functionality hasn’t changed. If you had the old URL bookmarked, you’ll want to update it. Otherwise, everything works exactly as it did before.
The UI Redesign
The more noticeable change is the interface itself. The original TuneLink was functional but utilitarian – a white background, basic input field, and straightforward result display. It worked, but it didn’t exactly feel like something I’d want to use repeatedly. It looked like a standard developer UI but in dark mode (and that’s not a good thing).
The new design is darker, cleaner, and more visually interesting. It actually feels like a more modern single-page web app rather than a quick prototype.
Beyond aesthetics, I added a few quality-of-life improvements:
Service-aware theming: The UI subtly shifts colors based on whether you’re converting from Spotify or Apple Music.
Loading feedback: Instead of a blank screen while waiting for results, there’s now visual indication that the app is working.
Deep linking: Buttons to open the matched track directly in the Spotify or Apple Music app, with fallback to web if the apps aren’t installed.
Better error messages: Clearer feedback when something goes wrong, whether it’s an invalid URL or a track that doesn’t exist on the target platform.
The deep linking piece is particularly useful on mobile. Previously, you’d get a URL, copy it, and manually navigate to your music app. Now you can tap a button and go straight to the track.
What’s Coming Next
The most significant change on the roadmap is making TuneLink’s matching functionality available as a service that other applications can use.
Right now, the only way to convert a music URL is to visit the website and paste it into the input field. That’s fine, but it’s not the only context where this kind of conversion is useful.
Think about clipboard managers, menu bar utilities, or automation tools. Imagine copying a Spotify link from a message and having your system automatically offer to open it in Apple Music instead. Or a keyboard shortcut that converts whatever music URL is in your clipboard and opens the result in your preferred app.
These are the kinds of workflows that don’t need a web browser. They belong in lightweight utilities that run quietly in the background.
To make that possible, TuneLink will expose a simple endpoint that accepts a music URL and returns the matched URL on the other platform. Any application that can make a web request will be able to use it. Of course, I may just lock this down with my own credentials for the obvious reasons that come with exposing a publicly available API.
Regardless, the foundation is already there. The matching logic that powers the website is the same logic that will power the service.
I’m also considering batch conversion for handling multiple URLs at once. My thought process is that it would be useful for anyone wanting to convert entire playlists rather than individual tracks.
Conclusion
TuneLink is a small utility that solves a small problem and was built primarily as a vehicle for learning. It doesn’t need to be more than that. But making it more accessible – through a better interface and availability to other applications – means it can fit into workflows beyond just visiting a website and pasting a URL.
If you’ve used it before, update your bookmark. If you haven’t, give it a try next time someone sends you a music link from the wrong platform or a platform that you don’t use.
Kinsta offers premium managed WordPress hosting for everyone, small or large. Powered by Google Platform and strengthened by Cloudflare, they take performance to the next level. All hosting plans include 24/7/365 support from their team of WordPress engineers. Get startedwith a free migration today.
