ATV Desktop Remote turns your keyboard into an Apple TV remote

A remote living in the menubar

ATV Desktop Remote is described as a simple menubar app that allows you to control an Apple TV from your desktop. The repository description says the same thing in fewer words, a simple app to allow you to control an Apple TV from your desktop.

The scope is deliberately narrow, and the README's own admission sets the tone. It is cobbled together from a few projects the author has worked on, and it works well enough for daily use, so the author figured others might like it. That is an unusual README opening for a packaged application, and it tells you what kind of project this is before you install anything.

The design is an Electron application with a menubar, so the app itself is a small icon in the menu bar rather than a window. On the first run, the application runs in the menubar, you look for a tiny remote icon and click on it, and a right-click gives more options. On macOS the app can be opened from anywhere with Cmd+Shift+R, and on Windows the equivalent is Win+Shift+R.

The audience is narrow and obvious. Someone with an Apple TV on the other side of a room, a working television, and a trackpad, who has lost the small remote three times and would rather not buy a fourth. The device it targets is Apple's, and the platform it runs on is macOS and Windows.

The project is MIT licensed and the homepage for the packaged builds is the GitHub releases page, with a Homebrew formula for the macOS case.

The keyboard is the remote, and Option explains it

The usage section is three numbered points, and the first one carries the whole idea.

Keys are mapped to the keyboard when the application is open, pressing return or enter on the keyboard for select, delete for Menu, and so on. The second point is the part that makes that usable: press Option, or Alt on Windows, to see what the characters are mapped to when the application is open.

So the app is a modal overlay on your keyboard. The Apple TV remote's directional pad and buttons are mapped onto ordinary keys, and instead of asking you to memorise the mapping, the application can show it to you on demand. Holding Option displays the current character to key correspondence, which is a considerably better answer to a bad idea than printing a cheat sheet nobody reads.

The third point is a quality-of-life addition rather than a feature of the protocol. Long press buttons now work to simulate long presses on the remote, and the README includes a small animation showing it. Long presses matter on an Apple TV interface, where holding a button scrolls a list or opens a context action, and emulating them from a keyboard requires deliberate handling rather than a single keypress.

The pairing step is the other half of the setup, and it is a first-run requirement rather than a setting. The first time the app runs it will need to pair with an Apple TV, and you can pair with more than one.

Three ways to install it

There is a package manager route, a download route, and a source route, and they suit different people.

If you have homebrew installed, the command is:

brew install atv-remote

The macOS and Windows versions can be downloaded from the GitHub releases page, which is also where the release tags live. The recent ones are v2.2.1 on 2026-09-07, v2.1.1 on 2026-03-04 and v2.1.0 on 2026-02-09, so there is a steady but unhurried release rhythm on a version line in the twos.

To run it from source, the README lists three steps. Install the dependencies with npm i --legacy-peer-deps, noting that other package managers may also work, then run npm start:

npm i --legacy-peer-deps
npm start

The legacy peer deps flag is a hint about the dependency tree, and the package manifest explains why the project uses it: there is a reset script that runs npm run clean and then npm install --legacy-peer-deps, and a docker-build script that shells out to electron_docker.sh to run the Windows build inside a container.

For most people the Homebrew formula or the release download is the sensible path, since the source route exists mainly for people who want to change the key mapping or the packaging.

Electron, a menubar library, and pyatv underneath

The manifest is small and shows the whole stack. The runtime dependencies are @electron/remote and menubar, and the development dependencies are electron, electron-builder and rimraf. The package is named atv-mac-remote, the product name is ATV Remote, and the entry point is app/main.js.

The interesting dependency is not in the manifest at all. The project is built using pyatv, which is the Python library for talking to Apple TV devices, and the README links its documentation. The application is JavaScript and Electron, but the protocol work is delegated to a Python project, which is a reminder of how much of the Apple TV interface is implemented in a language other than the one the app is written in.

The build configuration is where a packaged macOS app lives or dies. The app identifier is com.electron.atvMacRemote, the macOS category is public.app-category.utilities, hardenedRuntime is enabled, and there are two entitlement files, build/entitlements.mac.plist and the inherited variant, referenced by both the main and the inherit settings. The build scripts cover the mac build, the Windows build, and an arm64 mac build.

Two details in the scripts are worth a note. The docker-build target exists so the Windows build can run inside a container, and the postinstall hook runs electron-builder install-app-deps, which is the step that rebuilds native dependencies for the platform you are on.

Where this remote is the wrong tool

The limits are structural, and they are worth stating before someone installs it expecting a different thing.

The first is the device. This is an Apple TV remote. It is not a generic infrared or network remote, and it does not control a television's inputs, a soundbar or a projector. The pairing step in particular is specific to Apple TV devices, and if your media device is something else the application has nothing to talk to.

The second is the platform and form. It is a menubar application, and while the README says the Windows version exists and the manifest configures a Windows build, a menubar is a macOS idiom. On Windows the same idea becomes a system tray icon, and the keyboard mapping has to switch to Alt because Option is a Mac key. The author handles the difference, but the experience is designed around macOS.

The third is the design of the mapping itself. Turning the keyboard into a directional pad means the keys you use for typing are the keys you use for navigation, and the mode is only active when the application is open. That is workable, and the Option cheat sheet is what makes it workable, but it is a compromise rather than a remote. If you want a remote, a remote is a small object that solves the problem without taking over your keyboard.

There is also a dependency risk that comes with the design. The app inherits whatever the pyatv project supports, so an Apple TV firmware change that pyatv has not caught up with will show up here first, and the fix will be in that project rather than in this one.

Maintenance, licence and how to judge it quickly

The licence is MIT, with the LICENSE file at the repository root, so the code can be read, modified and redistributed with attribution. For a desktop utility that people install on their own machine, that is the right terms.

The last push was on 2026-09-07, the repository is not archived, and the release on the same day is v2.2.1. There is no long gap between the code and the published artifact here, which is a good sign for an application that depends on a protocol implementation living in another project.

The repository listing shows a small, ordinary project. There is an app directory with the source, a build directory holding the macOS entitlements, a script named electron_docker.sh for the containerised Windows build, and fixversion.py, which is presumably the script that keeps the version number in the manifest in step with the release tag. There is a travis.yml for continuous integration, and two screenshots, screenshot.png and screenshot_new.png, plus a buttonpress.gif demonstrating the long press behaviour.

The fastest way to judge whether it fits is to look at the three usage points again. If you use a Mac, own an Apple TV, and have lost the remote, the mapping with the Option overlay and the long press support are exactly the two details that make it pleasant rather than merely possible.

If none of that applies, the Homebrew formula and the release downloads mean you can try it in a couple of minutes without committing to anything, and pairing will tell you within a minute whether pyatv can reach your device.

Editorial conclusion

ATV Desktop Remote suits someone whose Apple TV sits across the room and whose remote has a habit of going missing, and the keyboard mapping with a discoverable cheat sheet makes it usable without learning a layout. It is the wrong tool if you want to control the Apple TV from a phone, if you are on a platform other than macOS or Windows, or if you need a remote replacement for anything other than an Apple TV. Verify first that pyatv can reach your Apple TV on your network, since the README builds the whole thing on that library and the pairing step is where a failure will show up, and check the character mapping by holding Option before you commit to it as your only remote.

Frequently asked questions

Official sources

1. bsharper/atv-desktop-remote on GitHub
2. Issues
3. License: MIT
4. README
5. Releases