syncthing-macos states its minimum macOS version three different ways, and its updater disables the other one

Three places, three minimum macOS versions

The note at the top of the file says the supported v2 line needs at least macOS 12, and that the v1 line is deprecated and will get no further updates or bug fixes. The installation section says macOS 11 or higher is necessary to run the latest version. The compatibility list says macOS 12 has been required since release v2.0.14. So two places say twelve and one says eleven, and the eleven is the sentence a new user reads first. The compatibility list itself is good documentation: seven entries walking the requirement upward from macOS 10.11 through 10.12 and 10.13, then 11, then 12, most of them with a link to the issue that raised the floor. It reads like a changelog of requirements. It just does not agree with the paragraph above it, and the paragraph is what gets quoted in support answers.

The bundle and the command line cannot both run

The installation section opens with a notice rather than a step. This is the official macOS bundle, and you must make sure you have no other Syncthing instance or wrapper running, or the application will not work. That is a real constraint with a real consequence, because the bundle starts and owns a Syncthing process of its own. It also explains a limitation further down: the preferences window can only point at a local running instance, and a remote one is not supported, because the wrapper assumes it is talking to the process it launched. If you have been running Syncthing as a launch agent, or through a different tray application, installing this bundle means turning that off first, and the file does not tell you how.

It updates itself, and it turns the other updater off

Automatic updates are one of seven listed features, delivered through the Sparkle update framework with releases pushed from the project's GitHub releases. The installation section then adds that the bundle disables Syncthing's own auto-updater, because the bundle has its own update mechanism. So there are two update paths in the stack, and one of them is switched off in code rather than by configuration. The compatibility notes add a third instruction: for an unsupported macOS version, the update check must be disabled manually. That last one points at a section in the same file which is not present in the part visible here, so a reader on an older system follows a link and may not find what they need.

The cask is not named after the repository

Installation offers two routes and leads with the first. Download the disk image, mount it, and drag the application into your applications folder, with the only necessary configuration being the API key and address when you provision a remote Syncthing instance, since the local one is configured for you. Then, as an alternative, a Homebrew cask. The cask is not named after this repository, so somebody searching for the project by its own name will not find it by the same string, and the two install paths also behave differently in one visible way: the disk image route is a drag operation you can undo, and the cask route is a package manager that now owns the file. Pick one deliberately rather than installing both.

Configuration is hidden, and so is the escape hatch

The stated goal is a lean tray application that is usable, with no graphs and no advanced configuration windows, on the reasoning that most users should not have to know Syncthing ships as a command line application. The preferences window matches that: it points at a local instance, it says a remote one is not supported, and it warns you to change settings only if you know what you are doing. It also offers a process quality setting with three values, where background is the default because it reduces the impact on foreground applications at the cost of slower folder scans, and changing it restarts the managed process. Then the FAQ documents a hidden feature for passing extra command line parameters, written through the macOS application defaults system instead of through any window. Its one stated limitation is that the parameters cannot contain spaces, which is why the audit-logging example passes two flags as one quoted string:

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

The application identifier points at another domain

The example command for that hidden feature writes to an application identifier whose domain part is a GitHub Pages project rather than the project's own site, and whose last component carries an extra trailing character. Identifiers like that are what decides which preferences file your settings land in, which is exactly how the hidden feature works. They are also what produces the paths the FAQ tells you to use, so the log and configuration files are where that identifier puts them and nowhere else. It is a small thing to notice once and then never think about, and an annoying one to work out from scratch if a tutorial points at a different path.

A build that writes into the repository root

The Makefile is short and every build target is the same shape: an invocation of the Apple build tool against a workspace, with the derived data path pointed at the current directory, which means build products land in the repository root rather than in a sibling directory. The default target builds only the debug application, and building a disk image is a different scheme from building the application in both the debug and the release configuration, so there is no single flag that produces an installable image. The release step is not a build recipe at all but a call into a program in a commands directory, written in another language than the application it ships. And the clean target removes the build, index and logs directories, a module cache and an Info.plist from the root, which is a wide net for a directory that also holds a readme, a licence and an authors file.

Editorial conclusion

Syncthing for macOS is the right choice if you want Syncthing to behave like a Mac application rather than a command line tool with a browser tab, and the wrapper is deliberately small: no configuration windows, no graphs, and a preferences pane that points at a local instance and refuses a remote one. Three things to check before you install it. Decide what to do with any Syncthing you already run, because the file states plainly that another instance or wrapper must not be running or the application will not work. Find the minimum macOS version in the compatibility list rather than in the installation prose, since the two disagree. And know that the bundle updates itself over the network and switches off Syncthing's own updater to do it, so the version on your Mac follows the releases without a package manager in the loop. Licence terms are MIT, the default branch is v2, and the last push is dated 2026-09-17.

Frequently asked questions

Official sources

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