On Syncthing iOS port (again)

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?

No.

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.

2 Likes

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.

I haven’t tried gomobile, but I hear it’s supposed to work. I’d probably steer clear from trying to do it all in Go and at the very least do all GUI and similar work with the regular tooling in Swift. Some sort of integration would need to happen for it to be able to access the camera and iCloud Drive libraries (which I assume would be the most interesting)… No idea how that would work, really.

Believe it or not I have almost zero interest in having Syncthing on my phone so I’m not going to pick up this one. :wink:

2 Likes

Re interest having ST on the phone:

I’m actually happy that it’s available on Android and this is actually one reason why we don’t use iPhones. A smartphone becomes the workhorse for road warriors, more and more.

We actually didn’t buy any new Tascams and do band interviews and photographs on Android phones nowadays. The quality is acceptable and it’s just great to have Syncthing upload the interview WAV files and camera pictures directly to the studio machines … :grin:

Just to make a point for Syncthing on smartphones.

Hi

I have been watching this for a while and I am quite intrigued.

I am happy to implement the protocol in C++ and keep it open source. I am also happy to make it to work for iOS, Android etc that is write the native layers to use the C++ code. For instance swift 3.1 for iOS.

4 Likes

And I am happy to provide you with any guidance or support in the process. I might even want to contribute here and there to brush up my C++.

4 Likes

Can anyone suggest a nice open source iOS sync tool? I’d like to synchronise an iphone with my home server. Meanwhile, the home server stores my data and uses Syncthing to synchronise among the linux- windows- and several android-devices.

Great! The thing is on then. :slight_smile: I have created an empty repo here https://github.com/reveo/syncthingpp. I start working on it this week.