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.
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?
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, 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.
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.
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?
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.
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.