On Syncthing iOS port (again)

Hi all, I’ve checked the existing threads on the forum and am aware of the threads/projects below [1].

I’d like to take a stab at starting a syncthing implementation that will work on ios.

What do you think is the best approach to look at first? – Go mobile (github.com/golang/go/wiki/Mobile)? – Objective-C (possibly picking up/contributing to the existing objc library)? – Swift – C++

Off the top of my head, I was going to attempt a C++ library and if that succeeds, an app/UI in swift.

Disclaimer: I don’t have that much knowledge on the project, but I’m eager to gain it.




If this is what you’re the most comfortable with, that’s what I would do. When I looked at it a while back it seemed like most advanced socket programming in Swift ended up being a fairly thin layer on top of the C APIs. Doing the abstraction in C++ might make sense in that case.

Depends on your appetite. If you don’t want to reinvent the wheel, maybe Go Mobile is lowest effort to get something going. I suspect you could have something up and running with a few hundered lines of code, especially given gobind:

Alternatively, a C++ solution would probably make most sense as could be reused on Android, Windows phone and whatever else comes next. You could even slap a C++ Qt UI on top of it, or have higher level bindings to the library making it easier to consume.

Plus I’d probably be interested in contributing to the C++ part, as I started working on syncthing to learn Go, and C++ is also on the list of things I’d like to have more exposure to.


Or if you are feeling even more adventurous and want to learn something new, Rust?


Regarding this I recalled fsync developer’s blog post: iPhone Syncthing Client (or Rust in the Wild)

Yeah but its closed source

1 Like

I bought fsync() but it seems development has stalled. The current version crashes frequently for me on iOS 10.x and has some shortcomings. I would really love to see an actively developed, modern Syncthing client for iOS. Is any such thing being worked on?


Ok :neutral_face: Is this just seen as unimportant? I do need occasional access to my synced files and was using fsync() before but lately it is not reliably working. I hate the idea of moving back to btsync/resilio.

Its most likely a rewrite in a different language and nobody wants to dedicate that much of their personal time for such a big undertaking, for pretty much no reward apart from being awesome. And then maintain feature parity/compatibility with syncthing as it moves forward.


Yes, unfortunately.

@lukehamburg, did you send some reports to developer?

Yes, I have reported some bugs to the fsync() developer last year. I got a response a while back but nothing recently. It’s been a while since any updates were released, so I don’t know if he is working on fixes.

I did some napkin math:

• 20,265 active (v0.14+) users (source: https://data.syncthing.net/)

• Assume ~12% of them have iOS devices (source: IDC)

• Assume of these 2,431 users, ~10% of them would purchase a mobile app (source: making it up)

• Of those 243 users, each pays $9.99 (fair price?)

• Of that $2,427, dev keeps 70% (Apple’s cut)

• Profit: ~ $ 1,700

I guess it isn’t a lot of money. But depending on developer’s skill it could be a (slightly) rewarding, fun project.

1 Like

I rather we crowdsourced/ran a campaign for this, so those who can, can chip in more, and those who cannot afford are still able to use the end result if it ever gets there.

I’d probably make sense to write the core libraries in C++ so it could be reused.

To be real cross-platform and bind do different languages the core could be better written in C (or C++). I have created a objective-c systray application (github.com/xor-gate/syncthing-macosx) bundle for macOS but writing the whole protocol encoding/decoding in plain C is a different job (or for Apple only in Objective-C). Binding between languages is always pain. Except for integrating C into higher level languages.

The difficult part is the BEPv1 and Crypto (e.g OpenSSL or some sort) and sockets. And then you only have a library.

There is no simple solution.

How does writing the core in objective-c make it cross-platform?

You are right, I have corrected my comment.

Please do :slight_smile: Crowdfunding campaign sounds like a good idea, too (or even just a Patreon thing).

Hi guys,

I just had a play and fight with gomobile to generate native iOS applications from Golang. The examples just to seem work fine. I think reusing exiting code is far easier than rewriting in language X,Y or Z. If it where that easy to write a core library in a “random language” they would have been spread around github or somewhere else. Most languages are not as expressive as Golang and have finetuned tooling which don’t fight with the developer.

@calmh I know you own a mac and have a developer account to sign executables. What would you think to write the iOS part in gomobile?

For more info: https://github.com/golang/go/wiki/Mobile#building-and-deploying-to-ios

Don’t shoot yourself in the foot with XCode 8 which has an known issue with the development team: https://github.com/golang/go/issues/17407

1 Like

I think getting something to run is fairly trivial, but the bigger problem I suspect will be the inability to integrate with all the mobile things, such as battery settings, being able to run in the background and not get killed, escape the iOS sandbox for file access and so on. I don’t know if these will be actual problems, just speculating.

1 Like

Yes that is totaly true, but you can build two types of gomobile apps. A 100% native golang .app. And a “Syncthing.framework” which can be integrated and bind with Objective-C and build with Xcode which can use all native facilities. But the framework of course mapped between objective-c and golang has some performance impacts. Still the time to market is lower.

The iOS sandbox for file access probably can’t be escaped as this is security by-design.