# Satellite Eyes: a macOS app that repaints your wallpaper from orbit

> Satellite Eyes is a small Swift application for macOS that lives in the menu bar and keeps the desktop wallpaper pointed at the satellite or map view overhead. It suits people who like a map as their desktop, and it is distributed as a built app rather than a package you install with a tool.

**tomtaylor/satellite-eyes** — Mac OS X app to automatically set your desktop wallpaper to the satellite view overhead.

- Repository: https://github.com/tomtaylor/satellite-eyes
- Website: http://satelliteeyes.tomtaylor.co.uk
- Stars: 683 · Forks: 64
- Language: Swift
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/tomtaylor-satellite-eyes

## A menu bar app that repaints the desktop

Satellite Eyes does one thing: it keeps your desktop wallpaper showing the satellite or map view overhead. The README describes it as a macOS application that sits in the system tray next to the clock and automatically updates the wallpaper, and the repository description says the same thing in one line.

The small size of the description is the point. There is no server component, no account, no configuration service. It is a native application that talks to a map tile service and a wallpaper API, and it keeps the picture current as the world moves. The audience is a narrow one: people who want the view from above as their desktop and who want it to stay current rather than being a screenshot you refresh manually.

The interesting engineering is not in the idea but in the constraint. macOS does not hand applications a public wallpaper API for arbitrary images, and the system treats the desktop as a place the user owns. Building a macOS app that survives that constraint, and doing it as a menu bar utility that a user leaves running, is the bulk of the work here.

## Two ways in: a download or an Xcode project

The README points to a download link, http://satelliteeyes.tomtaylor.co.uk, and that is where a released build lives. Releases exist in the repository too, with version 2.2.0 published on 2026-10-08, and version 2.0.0 with a release candidate 2.0.0-rc.2 both dated 2026-02-23.

For anyone who wants to build from source, the instructions are short. Satellite Eyes is a Swift project targeting macOS 13.0, and you open the Xcode project, SatelliteEyes.xcodeproj, to build it. Dependencies are managed through Swift Package Manager and resolve automatically when the project opens, so there is no separate dependency step to script and no lock file to reconcile by hand.

That is the entire setup story, and it has a consequence worth stating: there is no Homebrew cask, no package manager entry and no command line installer in the repository. The install path is a downloaded application or a local Xcode build, so a team that wants to roll this out to many machines does its own distribution work.

## Building means signing with your own identity

The README warns about one thing during the build, and it is the step that trips people up. You might need to update the project to use your own team and certificates, and the request that follows is not to commit those changes. In other words, the signing configuration is deliberately left in a state where whoever builds signs as themselves, and the repository must not accumulate personal signing identities.

For a developer evaluating the project, that means the first build is not a clean clone and run. You select a development team in Xcode, the bundle identifier may need to be unique to you, and the resulting app is signed with your own certificate rather than the author's. Anyone distributing the result to other machines has to think about notarisation and Gatekeeper, and the README does not document any of that.

The target version gives the other boundary. Targeting macOS 13.0 means the app will not run on Monterey or earlier, which is a reasonable floor for a modern utility and a hard constraint if your fleet of machines is older.

## The repository layout hints at a config driven design

The top level of the repository is small and tells you how the project is organised. There is the Xcode project, a SatelliteEyes directory holding the application code, and a SatelliteEyesTests directory for tests. Alongside those sit Config/, data/ and design/ directories, which suggests that the map configuration, the bundled data and the visual assets are kept apart from the application logic rather than embedded in it.

There is also a CLAUDE.md file, a .claude directory and an .mcp.json file at the root, which is a sign that the project is developed with an AI coding assistant in the loop and keeps that configuration in version control.

The separation of Config and data is the part with practical consequences. If map styles are configuration and the tile data is separate, then adding a style is a configuration change rather than a code change, which is consistent with the contribution wish list in the README. The README does not document the file formats inside those directories, so anyone hoping to extend the app should expect to read the source rather than follow a guide.

## The wanted contributions name the gaps

The README asks for contributions and then says which ones would be especially appreciated. Two are listed: controls for configuring each Space independently, and more map styles. A third instruction is about process, and if you are planning to land a major feature you should raise an issue to discuss it first.

Read as a feature list, this is a short and revealing paragraph. The ability to configure each Space independently is not there, which means the wallpaper behaviour across macOS Spaces is not yet something the user can shape, only whatever the default happens to be. And more map styles being wanted says the style set is currently narrow, which is consistent with a project where styles live in configuration.

The single maintainer also says plainly that they will do their best to review contributions and include them where possible. That is a fair expectation to set for a personal macOS utility: review capacity is one person, so pull requests that follow the existing structure will move faster than large ones.

## The image pipeline was built in pieces

The README credits three contributors by name, and each credit points at a different layer of the app. James Bridle is credited for the icon, Alex Forey for Retina compatible icons, and Justin Hileman for work on the image effects pipeline.

The third credit is the informative one. An image effects pipeline is the stage that turns a map tile or satellite view into a finished wallpaper image, and having it separated out as a distinct piece of work suggests the app treats rendering as a layer of its own rather than something welded into the update loop. That separation is what makes effects like shading or tinting plausible as future additions without disturbing the download and scheduling side of things.

Retina compatible icons get their own credit because macOS displays the menu bar item at different pixel densities, and a menu bar app lives or dies by whether its icon looks correct on a modern display. It is a small detail that tells you the project has been used on the hardware it targets.

## A custom licence, recent releases, one maintainer

The licence on this repository is the thing to check before you redistribute anything. GitHub classifies it as a custom licence that it cannot categorise, and the README does not summarise the terms, so the LICENSE file itself is the only source. Unlike a permissive open source licence, a custom licence can carry conditions that are not obvious from a one line label, and the standard MIT or Apache grant cannot be assumed. This is not legal advice, but it is a reason to read the file rather than assume the package is MIT.

On maintenance, the repository is not archived and the last push was on 2026-10-08, the same day as the 2.2.0 release, and the gap from the 2.0.0 line in February 2026 shows that work is still landing. The release history is short and the versions move in whole numbers, so a jump from 2.0 to 2.2 in a single push cycle should not be read as a stable API contract.

The project is also a single maintainer's work with a welcoming contribution process and a documented build path, and for a macOS utility of this size that is a reasonable thing to adopt if you are willing to own the signing and distribution steps yourself.

## Conclusion

Adopt Satellite Eyes if you want a native macOS app that keeps a satellite or map view as your desktop and you are happy to run a small Swift project rather than a packaged tool. Do not adopt it if you need per Space wallpaper control, extra map styles, a Homebrew formula or a command line installer, since none of those exist in the repository today. Verify first that you can open SatelliteEyes.xcodeproj in Xcode and sign it with your own development team, because the README says you will need your own team and certificates, and check the download page before building, since a signed build is published there.

## FAQ

### What does Satellite Eyes do on macOS?

It is a macOS application that sits in the system tray next to the clock and automatically updates your desktop wallpaper to the satellite or map view overhead.

### How do I build Satellite Eyes from source?

Open SatelliteEyes.xcodeproj in Xcode and build it. The project is Swift, targets macOS 13.0, and its dependencies are managed through Swift Package Manager and resolve automatically.

### Why does the Satellite Eyes build need my own signing team?

The README says you might need to update the project to use your own team and certificates, and asks that you do not commit those changes. Signing with your own identity is therefore part of the normal build.

### Can I configure a different map style or per Space wallpaper in Satellite Eyes?

Not yet. The README lists controls for configuring each Space independently and more map styles as contributions that would be especially appreciated, so both are on the wanted list rather than shipped.

## Sources

- [Issues](https://github.com/tomtaylor/satellite-eyes/issues)
- [Project website](http://satelliteeyes.tomtaylor.co.uk)
- [README](https://github.com/tomtaylor/satellite-eyes/blob/main/README.md)
- [Releases](https://github.com/tomtaylor/satellite-eyes/releases)
- [tomtaylor/satellite-eyes on GitHub](https://github.com/tomtaylor/satellite-eyes)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tomtaylor-satellite-eyes