syncthing-macos: The Official Native Tray App for Syncthing on macOS

What syncthing-macos solves, and who it is for

Syncthing itself ships as a command-line binary with a web interface. On macOS that means either running it under launchd yourself or leaving a browser tab open to reach the WebGUI. syncthing-macos exists to remove both chores. It is a native application bundle that ships its own Syncthing binary, starts and supervises that process, and exposes a tray icon with the operations a desktop user actually performs: open the WebGUI in the preferred browser, open a shared folder in Finder, and start on login.

The README describes the target audience indirectly through its goal statement: keep the tray "lean but usable", with no graphs and no advanced configuration windows. The project says it wants users to not be aware that Syncthing ships as a command line application. That is a deliberate ceiling. If you want to tune folder rescan intervals from a native pane, this is not that product. The WebGUI remains the place for configuration, and the tray is the place for presence and shortcuts.

How the wrapper, the bundled daemon and Sparkle fit together

The application bundle contains a Syncthing instance rather than connecting to an external one. The README states that the local instance is auto-configured and that the only necessary configuration is setting the API key and URL when provisioning a remote Syncthing instance. So the data flow is: the tray app launches and supervises the bundled daemon, discovers its API key automatically, and drives it over the local HTTP API. The WebGUI is still the Syncthing web interface, opened in your system browser rather than rendered inside the app.

Two mechanisms are worth separating. Updates come from Sparkle, pushed from GitHub Releases, and the README notes that the bundle disables Syncthing's own auto-updater because the app has its own update mechanism. Process scheduling is the second: the preferences window exposes a quality-of-service setting with Normal, Utility and Background values, with Background as the default. The README says Background reduces the process impact on foreground applications but can make large folder scans take longer, and that changing the setting restarts the managed Syncthing process. That restart is a real interruption, not a cosmetic toggle.

The repository layout matches this architecture: an Xcode workspace and project at the top level, a syncthing/ submodule, and a Makefile whose targets are all xcodebuild invocations against the syncthing and syncthing-dmg schemes. The code is a mix of Objective-C and Swift, which the README frames as the native approach.

Installing syncthing-macos with the DMG or Homebrew

The README gives two install paths. The first is the disk image: download the DMG from GitHub Releases, mount it, and drag the application to install. The second is Homebrew Cask, which the README lists as an alternative.

brew install --cask syncthing-app

Before either, read the notice at the top of the installation section. The README warns that this is the official bundle and that you must have no other Syncthing instances or wrappers running, or the application will not work. If you previously set up Syncthing under launchd, remove that first.

After launching, the first real use is opening the WebGUI from the tray to add a folder and a device. The README does not walk through folder setup because that is Syncthing's own documentation, not this project's. What the app adds is the tray menu: open the WebGUI, open a shared folder in Finder, and the login item option so you do not need to set Syncthing up as a service. Logs go to a fixed path, which the README tells you to reach with Finder's Go to Folder command:

~/Library/Application Support/Syncthing/syncthing.log

One advanced escape hatch exists. Extra Syncthing command line parameters are set through application defaults, and the README states the parameters cannot contain spaces. Its example enables the audit log:

defaults write com.github.xor-gate.syncthing-macosx Arguments '--audit --auditfile=/Users/JohnDoe/staudit.log'

The version and compatibility boundary you have to check first

The most consequential constraint is not in the feature list. Syncthing v2 is the supported version since 23 February 2026 and needs at least macOS 12. The README states plainly that Syncthing v1 is deprecated and will not get updates or bugfixes. The release history shows the same line: v2.0.14-1 shipped on 2026-02-23, with v2.1.2-1 and v2.1.5-1 following on 2026-07-12 and 2026-09-17.

The README's FAQ lists the full macOS support ladder, and it is worth reading before you upgrade a working machine. Release v1.27.6-1 was the last compatible with macOS 10.13. From v1.20.0-1 macOS 10.13 or higher was required. Until v1.19.2-1, macOS 10.12 was required. Older hardware therefore has a hard ceiling on the v2 line, and the FAQ adds that auto-update must be manually disabled for unsupported OS versions. If you leave Sparkle enabled on a Mac that cannot run the new build, you have set up a loop you have to break by hand.

Where the frugal design becomes a limitation

The preferences window points to a local running instance; the README says a remote instance is not supported. That is a smaller scope than Syncthing itself, which is happy to manage many remote devices. Here the app is a supervisor for one local daemon, and anything beyond that goes through the WebGUI.

The second limitation is networking. The README's section on the default IP address change explains that when the default address is moved from 127.0.0.1 to a routable one such as 192.168.1.102, the tray preferences must be updated too, or the API cannot be accessed and the status stays Offline. That is a manual two-place change, and the README does not document rollback if you get it wrong. The log file at ~/Library/Application Support/Syncthing/syncthing.log is the first place to look.

The third is the quality-of-service trade-off described earlier: Background is the default for compatibility, and large folder scans can take longer because of it. If your use case is a large photo library that must index quickly, the default works against you until you change it and accept the process restart.

Finally, the README points to the bug-labelled issue tracker for current status rather than enumerating known bugs in the document. There is no compatibility matrix for third-party wrappers, so the "no other instances running" warning is enforced by the user, not by the app.

How it compares with SyncTrayzor and Synctrain

SyncTrayzor is the Windows counterpart people often mention in the same breath, and the difference is not cosmetic. It is a Windows application, so it is not an alternative on macOS at all. The useful comparison is with running the Syncthing binary directly under launchd: that path gives you the same sync engine and the same WebGUI, but you manage the service, the binary updates and the login item yourself. syncthing-macos trades that control for a tray icon, Sparkle updates and a bundled binary.

Synctrain is the other name that comes up, and the README does not discuss it. Based on what the repository documents, the only defensible statement is that syncthing-macos is the official bundle maintained under the syncthing organisation, and its stated goal is a lean tray rather than a full client. Anything beyond that would be speculation about a project this README never mentions.

Maintenance, licence and the cost of keeping up

The repository is not archived, and the last push was on 2026-09-17, the same day as the v2.1.5-1 release. The release cadence visible in the release list runs from v2.0.14-1 in February 2026 to v2.1.5-1 in September 2026, so upgrades arrive as DMG releases pushed through Sparkle rather than as a package-manager stream you can pin.

The upgrade cost is mostly the macOS floor. Each v2 release keeps the macOS 12 requirement, so the maintenance burden is on machines below that line, where the README says auto-update must be manually disabled. Building from source is possible but heavier than installing: the Makefile targets are xcodebuild invocations, including a release-dmg target, and the workspace pulls in the syncthing submodule. That is a developer path, not a user path.

The licence is MIT, which is permissive and places few obligations on redistribution. That is a statement about the licence text, not legal advice; if you ship the bundle inside a product, read the LICENSE file and the bundled Syncthing project's own licensing, which this README does not restate.

Editorial conclusion

Adopt syncthing-macos if you want Syncthing on a Mac without managing a launchd service or a browser tab, and you accept a tray menu instead of a control panel. Do not adopt it if you need a remote instance in the preferences window or advanced configuration in the UI; the project states a remote instance is not supported. Before installing, verify that no other Syncthing instance or wrapper is running, and confirm your macOS version is 12 or higher for the v2 line.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. syncthing/syncthing-macos on GitHub