Syncthing for macOS

Thanks for your hard work on this Jerry - I’m using the macOS wrapper very successfully on a number of systems! :slight_smile:

Could I log a feature request: being able to add environment variables and arguments to the Syncthing launch command? I’d like to perform a reset-deltas on my installations - but I don’t know what launch command you currently issue, in order to launch it manually from Terminal without breaking everything. Is it just setting home to ~/Library/Application Support/Syncthing/ ?


Hi @Moisie sorry for the late reply, wasn’t checking the forum for some time. On first start the syncthing daemon is copied to its own folder so we don’t overwrite the syncthing executable which is shipped with the application bundle. It is located here:

 > ls ~/Library/Application\ Support/Syncthing-macOS/syncthing
 syncthing      syncthing.old 

When you start syncthing without arguments it automaticly searches in ~/Library/Application\ Support/Syncthing for the configuration and indexes. So if you need something special you should add some extra arguments. Currently it is not possible to inject environment variables or extra commandline arguments from the wrapper. It is hardcoded for now:

I’m not sure many people will every tweak the arguments. For power users they could also run their own syncthing instance and use the wrapper for connecting to it. It is now tightly coupled.

People do, e.g. setting STTRACE.

FWIW, that can also be done via the API or web GUI nowadays. (It’s still valuable to be able to set it before startup, of course.)

Yeah, I’ve had a few people ask that it can be set as an env var, so that it persists across restarts.


Yeah we need to add some extra checkboxes in the preferences dialog then for appending this kind of environment variables/flags.


I’ve been using syncthing-macos for a couple of months, but today I realized that this client is probably not being maintained (not sure). The latest version is dated January 2019, and the syncthing executables within the application package (when you look into the contents in /Applications) are also dated January 2019. If I use the “Check for updates” button in the About dialog, this client says that it’s the latest (version 1.0.0-2).

Further edits after a little more research:

  1. Does this client download the latest syncthing binary and store it in ~/Library/Application Support/Syncthing-macOS? If yes, what are the syncthing executables within this application package in /Applications?

I think this client could avoid confusion (like mine) if it also listed the underlying syncthing binary version in the About dialog.

Thanks in advance.

1 Like

I agree. Listing the binary version and a message that it auto-updates would be super helpful for instilling confidence in end-users.

1 Like

Is the underlying Syncthing version not sufficiently obvious from the version reported in the Syncthing GUI?

The application in /Applications is just a wrapper, to present the menu bar icon etc. This hasn’t needed to be updated to maintain compatibility with the Syncthing binary, which is stored in ~/Library/Application Support/Syncthing-macOS, hence why it hasn’t been updated in some time.

This was quite easy for me to miss in the browser while I was focusing on the upload/download rates, which folders were syncing (I have several individual ones) and how much data was being synced.

I understand that it’s a wrapper, and also get that it doesn’t need any updates to keep up with the syncthing application changes. Before I got to know where the syncthing binary was stored (under ~/Library), when I was digging into the application package, I saw that there are two “syncthing” binaries within the package. One is “Contents/MacOS/Syncthing” (note the uppercase “S”), which is the GUI wrapper that shows the menu bar icon and works with syncthing. The other is “Contents/Resources/syncthing/syncthing” (note the lowercase “s”). Both were dated January 2019.

I think there is scope for improvement in this wrapper and make it more user friendly (especially to cater to users like me who get confused):

  1. Include the underlying syncthing version in the About dialog, or even better, in the menu itself if feasible. The browser GUI may not necessarily be opened by the user (and is not required to be opened except to monitor things).

  2. Have some indication of when it updates the underlying syncthing binary (seems like it checks for updates on every launch, but if that’s the case, why is there a “Check for updates” button for this wrapper in the About dialog? Does this wrapper autoupdate itself on launch?).

I think the check for updates is to check for updates to the wrapper itself. But then the very fact that I’m not certain probably indicates that there’s scope for making it clearer to end users… :slight_smile:

Hi all,

The Syncthing for macOS bundle will now only use the embedded syncthing daemon resource and will not auto-update the daemon since the new release v1.7.0-1 which is coming soon. Because I do it in my free time it was indeed true the bundle got not updated in a long time and people having issues.

As soon as the release is out I will post a message here.

Kind regards, Jerry

Version 1.7.0-1 has just been released, the auto-updater is broken when upgrading from v1.6.1-1 because of github issue #120

What about syncing package file with Syncthing. I’m using scrivener and the scrivener projects are package files (they appear as a file but when right clicking on show package content we can access a folder tree). What if a file within the package is changed ? Does it sync the whole package « file » or only the changed file in the package? Scrivener (Literature and latte) explains that dropbox is good but not iCloud (see Using Scrivener with Cloud-Sync Services / Cloud Syncing / Knowledge Base - Literature and Latte Support ) And Scrivener is not the only one using packages, Final Cut Pro is also using it

So what about Syncthing

A “package” in this case is just a directory with files in it, that Finder treats specially for display purposes. Syncthing sees into it and syncs the individual items inside, for better or worse.

1 Like

@calmh it seems there is something broken with the code signing on the build server

Build #248-v1.7.0-1-70-g3e9eb48 at 2 Dec 13:56

13:56:50   -- Codesign with Developer ID Application: Jakob Borg (LQE5SYM783)
13:56:50   Developer ID Application: Jakob Borg (LQE5SYM783): no identity found
13:56:50   Command PhaseScriptExecution failed with a nonzero exit code

Yeah that’s not the right identity any more. That cert expired. I have updated it, looks like it passed.

1 Like

Thanks @calmh it seems to work. But for some odd reason the appcast.xml CI/CD server (teamcity) deployer seems to run and generate the correct appcast.xml and latest release is added. But when I curl to the upgrade URL it is not deployed to the upgrade server. Odd… are you using some sort of cron job to copy the file to the webserver? I’m expecting the v1.22.2-1 as latest.

This is the curl:

jerry@coconut syncthing-macos % curl | head -20
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 18142    0 18142  <?xml version="1.0" encoding="UTF-8"?>:-- --:--:--     0
  <rss version="2.0" xmlns:sparkle="" xmlns:dc="">
0   <channel>
     <title>Syncthing for macOS</title>
     <description>Most recent changes with links to updates.</description>
0    <item>
       <title>Upgrade syncthing to v1.22.1 </title>
8<li>Update the bundled syncthing to <a href="">v1.22.1</a></li>

Latest build has the v1.22.2-1 with timestamp Fri, 09 Dec 2022 21:53:24 UTC Here is the build artifact Log in to TeamCity — TeamCity

@calmh the problem still exists with the Syncthing for macOS after trying to create a upgrade package to v1.23.0-1. Whats going on with the infrastructure?

jb@ok:~ % curl -s | grep title | head
    <title>Syncthing for macOS</title>
      <title>Upgrade syncthing to v1.23.0</title>

There’s a 15 min cache in the HTTP proxy, perhaps that’s what you’re seeing, if you’re impatient.

1 Like