Trailer: a macOS and iOS app for keeping watch over GitHub pull requests

One list of watched repositories, with the noise turned down per repository

Trailer is a Swift app for managing pull requests and issues for GitHub and GitHub Enterprise, and the sentence in the readme that explains the product is the one about watched repositories.

Trailer lists all your watched repositories. To reduce notification noise and speed up your sync, you visit the Preferences and change the display settings of each repository. To change the settings for all visible repositories there are Set all PRs and Set all issues commands, and you are told to use a filter first if you only want to modify a subset.

That is the product in miniature. The problem is not that GitHub lacks pull requests; it is that watching a repository produces a stream, and a developer who watches thirty repositories has a stream of thirty repositories' worth of noise, most of it not theirs. Trailer's answer is a display filter per repository, applied client side, so what you see is the subset you actually review.

The set-all commands with the filter-first caveat are a small piece of interface design that says something about how the author expects the app to be used. The bulk action is there because reviewing forty repositories one at a time is tedious. The caveat is there because a bulk action that ignores your filter would change settings you meant to leave alone. A feature that is destructive in the wrong direction needs both halves, and both are in the same paragraph.

The speed-up claim is worth noting too, since it implies the app does its own fetching rather than relying on notifications. A filtered list that has to be re-fetched to know what to show is slower than one that receives pushes, so reducing the displayed set is doing work in two dimensions at once.

Four shipping surfaces for one product

The readme lists four separate distributions, and they tell you more about the project than a feature list would.

There is a latest macOS version, hosted on a GitHub Pages site at ptsochantaris.github.io/trailer. There is a latest iOS version on the App Store. There is a Trailer CLI for Mac, Linux and Windows, which lives in a separate repository, trailer-cli. And there is Trailer for Android, which is not the author's project but a third-party one, droidtrailer, in the amencarini organisation.

The CLI being a separate project and the Android app being a third-party port are the two facts that tell you the shape of the effort. The CLI is the part that can be shared, and it is cross-platform precisely because the GitHub API does not care what runs it. The Android app being someone else's work tells you the author did not want to maintain a third platform, which is a normal division of labour in a small independent project.

The watchOS entry is less obvious from the readme. The top-level directory listing includes a `PocketTrailer WatchKit App/` directory alongside `PocketTrailer/` and `Trailer/`, and the topic tags include watchos. So there is a watch client as well, presumably a small companion that shows the same filtered list on the wrist. The `PocketTrailer` name for both the iOS and the watch app suggests the iOS app was renamed at some point, since the directory is `PocketTrailer` while the product is Trailer.

The result is a product that can reach you wherever you are, from a Mac at the desk to a watch on the wrist, with a CLI for the terminal.

The parts are being split out, which tells you where the reusable logic lives

The packages section is the most forward-looking part of the readme, and it changes what the repository is.

Parts of Trailer are being split off into their own Swift Packages to make them more reusable and self-contained. Seven are named.

TrailerQL is the query layer, and TrailerJson is the JSON handling. Lista is a list abstraction, and Semalot is a lot abstraction, both of which are the sort of small generic type that turns out to be reusable once you extract it. KeyVine is the key handling, and Maintini is the maintenance and update logic, which is how the app knows how to check for and apply its own updates. PopTimer is a timer utility.

The naming convention here, with the doubled consonant, is consistent across all of them, which is a sign of a deliberate naming scheme rather than accident.

What matters for an evaluator is the direction. A single app repository is a hard thing to reuse, and the author is dismantling it into libraries with clear names and boundaries. TrailerQL in particular is the interesting one, because a query language for pull requests is the part of this application that another developer might want, and the fact that it has its own repository and its own name means it is intended to be depended on.

So the answer to whether Trailer is reusable as a library is that it is becoming a set of libraries, and the app is the demonstration. Anyone integrating with GitHub pull requests in Swift should look at TrailerQL and the other packages rather than at the app targets.

What is in the repository, and what the tooling says

The top-level listing shows a standard multi-target Xcode project with a few things worth noting.

There is `Trailer.xcodeproj/`, and three application directories: `Trailer/` for the macOS app, `PocketTrailer/` for the iOS app, and `PocketTrailer WatchKit App/` for the watch client. `TrailerLauncher/` is a separate target, which is a macOS helper application, the pattern used for a launcher or updater that runs before the main app and does not show a window.

`Shared/` holds the code common to the platforms, which is where a project that ships the same app on three Apple platforms keeps the parts that are not platform specific. `ImageCache.swift` and `Logging.swift` sit at the root as top-level files, which in an Xcode project usually means they are members of more than one target, and caching avatars and logging are exactly the two things you want shared.

The tooling configuration tells you the project keeps up with the platform. There is a `.swift-version` file pinning the Swift version, a `.swiftlint.yml` for the linting rules, and a `.swiftformat` configuration for the formatter, with a `.gitignore` alongside them. Using both SwiftLint and SwiftFormat is a common combination, and the `.swiftformat` file at the root rather than inside a config directory suggests the formatting rules are minimal and the project relies on the tool's defaults.

There is a `PRIVACY` file at the root, which is a plain text file rather than a document in a docs directory, and given that the app holds GitHub credentials and reads private repository content, a privacy statement kept in the repository root is a reasonable place for it.

The `LICENSE.txt` file is referenced from the readme for licence rights and limitations under MIT, and the copyright runs from 2014 to 2026 for Paul Tsochantaris, with parts copyright 2013-2014 HouseTrip Ltd. That second line is a detail worth reading: the project started inside a company, and the copyright notice records where the code came from, which matters for anyone doing due diligence on it.

Where Trailer is the wrong choice

The first case is a team whose review process lives in the GitHub web interface. Trailer is an individual review tool. It shows you pull requests and issues across your watched repositories and lets you act on them, and it is not a code review platform, it does not do team review assignments, it does not enforce a review policy, and it does not replace the branching model your team already uses on GitHub.

The second case is an organisation that restricts third-party GitHub clients. The app needs a token or credentials for the API, and many companies have a policy about which clients may hold an organisation's credentials. That is a deployment question rather than a technical one, but it can rule the app out entirely for a large employer, and nothing in the readme addresses it.

The third case is a team that has standardised on one notification surface. Trailer's value comes from replacing the GitHub notification stream with a filtered list, and if your organisation has already solved that with a different client, or with a bot, or with a workflow that puts reviews in a chat channel, Trailer is solving a problem you no longer have.

The fourth is a platform question. The maintained binaries are for macOS and iOS, with a watch client and a separate CLI project for Mac, Linux and Windows, and a third-party Android port. A Linux desktop user without the CLI wants a different client.

A maintenance observation. The release history shows 1.8.10 and 1.8.11 from August 2023, then a jump to v1.9.0 in August 2026, and the last push was on 2026-09-18. A three-year gap between the 1.8.x tags and the 1.9.0 tag is worth understanding before you adopt the app, and the answer is probably the package split, since the work during that period went into TrailerQL, TrailerJson and the other libraries rather than into the app.

Editorial conclusion

Trailer fits a developer who reviews pull requests across many repositories and wants one filtered list instead of the GitHub notification stream, and it fits a team that reviews on a phone between other work. It does not fit an organisation whose reviews happen in the web interface with a team review policy, since Trailer is an individual review tool. Before you build on it, note that the useful pieces are being split into separate Swift Packages, so the reusable parts are TrailerQL, TrailerJson and KeyVine rather than the app itself, and check the platform list, since the maintained binaries are for macOS and iOS with a separate CLI for Mac, Linux and Windows.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. ptsochantaris/trailer on GitHub
4. README
5. Releases