Open any list of radio automation software and you'll see the same thing: Windows, Windows, Windows. A dozen companies, all building for the same platform. There's a historical reason for that. There's also a reason we looked at that crowded room and walked the other way.
To understand why nearly every radio automation company builds for Windows, you have to go back to the 1990s. That's when radio stations started replacing cart machines, reel-to-reel decks, and CD players with computers. The transition happened fast, and it happened almost entirely on Windows. Not because Windows was the best platform for broadcast audio. It happened because Windows was there.
In the mid-1990s, Windows had roughly 90% desktop market share. If you were a software developer starting a radio automation company, you built for Windows because that's what stations had on their desks. That's what their engineers knew. That's what the IT guy at the station group could support. It wasn't a technical decision. It was a market math decision.
Apple, at that point, was in trouble. The Mac had a devoted following in creative fields — graphic design, music production, publishing — but its market share was in the single digits and falling. Building broadcast software for the Mac in 1997 would have been a beautiful gesture and a terrible business plan.
Early radio automation systems needed specialized audio hardware — multi-output sound cards that could play multiple audio streams simultaneously. Companies like Digigram and AudioScience built professional broadcast audio cards for PCI slots in Windows PCs. The Mac had nothing equivalent in the broadcast space. If you needed four simultaneous audio outputs with sample-accurate timing in 1998, you needed a Windows PC with a Digigram card. End of discussion.
Once the first wave of automation companies established themselves on Windows — Scott Studios, Prophet Systems, ENCO, Broadcast Electronics, MediaTouch — the momentum became self-reinforcing. Stations bought Windows-based automation. Engineers learned Windows-based automation. Consultants recommended Windows-based automation. When the next wave of companies came along — RadioBOSS, PlayIt Live, StationPlaylist, RadioDJ — they built for Windows too, because that's where the customers were.
Nobody made a conscious decision that Windows was the right platform for broadcast. It became the default by inertia, and inertia is hard to argue with.
The thing about defaults is that you inherit their problems along with their convenience. And Windows, as a platform for running mission-critical broadcast audio 24 hours a day, 7 days a week, brought some significant baggage.
Windows updates have been the bane of broadcast engineers for two decades. A station running unattended overnight does not benefit from an operating system that decides, on its own, to download an update, install it, and reboot. This has happened to real stations. On the air. In the middle of the night. The automation software is running perfectly, the music is playing, and then Windows decides it's time for a restart.
The workarounds are well-documented: disable automatic updates, use Group Policy to defer updates, configure active hours, run Windows LTSC (the stripped-down enterprise version). Every broadcast engineer who runs Windows automation knows these tricks. The fact that they need to is the point.
Windows audio has historically been a layered stack of abstractions. The application talks to DirectSound or WASAPI, which talks to the audio driver, which talks to the hardware. Each layer introduces potential latency, conflicts, and failure points. Broadcast audio cards require specialized drivers that must be kept in sync with OS updates. When a Windows update breaks a driver, the station loses audio. This isn't theoretical. Ask any broadcast engineer how many times they've dealt with a post-update audio driver issue.
The workaround here is ASIO — a protocol that bypasses the Windows audio stack entirely and talks directly to the hardware. It works, but it's a third-party solution bolted onto an operating system that wasn't designed for low-latency audio. It's an engineering patch, not an engineering foundation.
Windows is a general-purpose operating system designed to do everything for everyone. It runs office software, games, web browsers, development tools, and yes, broadcast automation. It does all of these things reasonably well. But "reasonably well" and "unattended 24/7 broadcast operation" are different standards.
Background services, antivirus scans, disk indexing, telemetry reporting, third-party tray applications — any of these can spike CPU usage or disk I/O at an unpredictable moment. On a desktop computer running a spreadsheet, nobody notices. On a broadcast automation system playing audio to a transmitter, a 200-millisecond hiccup is audible. A one-second freeze is dead air.
Broadcast engineers who run Windows automation learn to strip the system down: disable services, uninstall bloatware, turn off indexing, block telemetry, run a lean install with nothing but the automation software. They essentially spend their time making Windows less like Windows so it can be trusted to do one thing reliably. That's a lot of effort to fight the platform you chose.
When we looked at the radio automation landscape, we saw a crowded room. A dozen companies, all building for Windows, all competing on features within the same ecosystem, all dealing with the same platform-level headaches, all telling their customers to disable automatic updates and avoid running anything else on the on-air machine.
We saw a different room. It was emptier. It was quieter. And it had better acoustics.
Apple's operating system was designed, from the beginning, with real-time media as a first-class priority. Core Audio — the macOS audio subsystem — is a low-latency, sample-accurate audio framework that handles multiple applications sending audio to multiple hardware outputs simultaneously. It's not a bolt-on. It's not a workaround. It's the foundation.
Every audio application on macOS talks directly to Core Audio. There's no driver layer to fight, no ASIO equivalent to install, no choosing between shared mode and exclusive mode. It just works — and it works at latencies low enough for professional music production, which means it's more than sufficient for broadcast. For a deeper look at what this means in practice, see our article on why the Mac is the right platform for radio automation.
macOS doesn't force restarts for updates. It doesn't install updates behind your back. It doesn't run background processes that suddenly consume all available CPU. There's no antivirus software fighting for resources, because the Unix security model and Apple's system integrity protections handle security at the architecture level rather than the "scan every file in real time" level.
The practical result: a Mac running automation software can be left alone. For days. For weeks. For months. Without anyone needing to babysit it, tweak it, patch it, or reboot it. That's not a marketing claim. That's the daily experience of stations running TuneTracker.
Apple controls the hardware and the operating system. This means the audio subsystem is tuned for the specific hardware it runs on. There are no driver compatibility surprises because Apple writes the drivers. There are no "which sound card should I buy" questions because every Mac has a capable audio system built in, and any class-compliant USB audio interface works instantly — plug it in, select it, done.
Compare that to the Windows experience of researching which audio cards are compatible with which drivers on which Windows version, hoping the next update doesn't break the chain.
The obvious objection is market share. And it's a fair one. Windows still has the majority of the desktop market. If you're a radio automation company trying to reach the largest possible audience, building for Windows is the safe bet.
But market share isn't the only number that matters. What matters for radio is who's using what, and where the momentum is going.
Mac adoption has been growing steadily, particularly among creative professionals, small businesses, and educational institutions — exactly the demographics that operate community, college, and independent radio stations. Apple Silicon Macs have accelerated this trend by offering performance that exceeds Windows hardware at comparable price points, with dramatically lower power consumption and heat output — both of which matter in a studio or transmitter room that runs 24/7.
More importantly, the stations that would choose a Mac for their automation — if the option existed — have been stuck on Windows not by preference but by necessity. Every year we hear from station operators who say the same thing: "We use Macs for everything else. We wish our automation ran on one too." Those people don't show up in Windows market share numbers, but they exist in large numbers, and they've been underserved for decades.
When you build for Windows, you're competing with RadioBOSS, PlayIt Live, StationPlaylist, RadioDJ, NextKast, Rivendell (well, Linux), and a dozen others. Some are free. Some are cheap. All of them are fighting for the same customer on the same platform. Differentiating on features alone is a treadmill — every feature you add, someone else adds next quarter.
When you build for the Mac, the landscape is different. There are only a handful of options, and most of them are single-purpose tools rather than integrated suites. A station operator who wants to run their entire operation on a Mac — playout, scheduling, library management, streaming, remote broadcasting — has very few choices. We intend to be the best one.
That's not a niche strategy. It's a focus strategy. We don't split our development time across platforms. Every line of code is written for macOS. Every feature is designed around Core Audio, APFS, Apple Silicon, and the Mac user experience. We don't make compromises to maintain Windows compatibility. We don't maintain separate codebases. We build one thing, for one platform, and we build it as well as we can.
Some companies try to solve the platform question by going cross-platform — building one application that runs on Windows, Mac, and sometimes Linux. In theory, this gives you the best of all worlds. In practice, it gives you the compromises of all worlds.
Cross-platform applications typically use abstraction frameworks that sit between the application and the operating system. They can't take full advantage of platform-specific capabilities because they have to work on every platform. The interface feels slightly wrong everywhere. Audio routing is handled through the lowest common denominator. Performance is limited by the abstraction layer.
A native Mac application built directly on Apple's frameworks looks, feels, and performs like it belongs on the Mac — because it does. It talks directly to Core Audio. It uses Apple's native UI paradigms. It takes advantage of Apple Silicon's hardware acceleration. None of that is available to a cross-platform framework.
We chose native over portable. We'd rather be excellent on one platform than adequate on three.
For stations, the choice comes down to this: Do you want radio automation software that was designed around the capabilities of your operating system? Or software that was designed around the limitations of a different one?
Every Windows automation vendor has a knowledge base article about disabling automatic updates. We don't need one. Every Windows automation vendor recommends running nothing else on the on-air machine. We don't — because macOS handles multiple applications gracefully and reliably, which is why many of our users run their entire station on a single Mac. Every Windows automation vendor has dealt with driver compatibility issues after OS updates. We haven't, because Core Audio doesn't work that way.
We're not anti-Windows. Windows is a capable operating system and the radio stations running on it are doing real, valuable work. The automation software built for it serves those stations well. But we believe there's a better foundation for broadcast audio, and we believe the stations that have been waiting for someone to build on it deserve to have that option.
That's why we're here. That's why we chose the room nobody else was in. And after 25 years, we're more convinced than ever that we chose right.
TuneTracker System 7 is built from the ground up for macOS. Free version available — download and have audio playing in minutes.
Download TuneTracker FreeContinue Reading
Practical guides for broadcasters who care about their craft and their community.