Native iOS port / GUI

[sloev]

Developing an ios client for syncthing.
right now GO doesnt easily compile using xcode but is compiles manually on-device (requires jailbreak)

What will it take to make an ios client?
should it embed the GO syncthing or be a complete rewrite specific for obj-c?

lets discuss!

---

This issue is closed for discussion. Vote or add bounties etc here: https://www.bountysource.com/issues/7699463-native-ios-port-gui

// @calmh 2016-08-18

[calmh]

That's an awesome initiative!

I don't think it's possible to get an app approved that contains foreign binaries (such as a standalone syncthing written in Go). Go currently doesn't support being linked as a library to other C (or Objective-C) code, due to the runtime. So as it is, I think the only way forward that is guaranteed to succeed on that front is a pure Objective-C implementation.

[sloev]

it would be AWESOME(!!! repeat forever) if you guys included an example of implementing the protocol in another language.

aside yes i guess implementing the protocol in pure obj-c is the way however it seems i have nowhere to start (since lack of third-language implementation).

i am willing to make a big effort on the ios side but the objective would be to keep inside the frames of non-jailbreaked phones and free of course :-)

again "third party" implementation of protocol/functionality is highly needed

[calmh]

Someone has to be the first third party, and it obviously can't be me since I'm the first party. :)

I would start with reading https://github.com/calmh/syncthing/blob/master/protocol/PROTOCOL.md and filing bugs on any ambiguities or other strange stuff.

[sloev]

is there similar docs (have searched but not reaaaaly found any) for the network/transport layers.
i mean documentation on the establishment of lan/internet wide connections.

[filoozom]

Are you talking about the discovery?
https://github.com/calmh/syncthing/blob/master/discover/PROTOCOL.md

[sloev]

yes thanx.
i know its not good githubing to mention issues in issues in .... but that site is not listed from the wiki. :-)

[calmh]

Yeah... Beware that while I always intended the block exchange protocol to be a stable standard, I haven't put nearly as much thought into the discovery protocol. That was always more of a half baked lets-do-something-and-see-what-happens thing that might lead into a DHT or mDNS or something in the long run.

[calmh]

Also a note on the BEP protocol is that the specs kinda vaguely say something about it typically being used with TLS over TCP. I'm considering mandating that or interoperability will be tricky in the future. From the beginning I was considering running it over UDP etc but I'm not sure there is a legitimate use case for anything not TLS/TCP.

[sloev]

yeah i guess an iphone app with "just" the ability to show an index of files using a predefined ip is a starter.
however if the discovery is not soon ot be set in stone then i guess it really disturbes development of third party stuff :-)

[calmh]

Agreed. Lets have a discussion about that when the first third party project is at the point where it's relevant. :)

[calmh]

About the discovery specifically, I really feel that is an area where a single app like syncthing should not have to make up it's own thing. There should be a standard ready to use. I think that standard is mDNS w. DNS-SD and that is where I'd like to go. I just haven't had the time / energy / prioritization to go there when a custom thing was easier to get off the gorund.

[sloev]

mDNS / dns-sd is sweet and extremely transparent in that it delivers knowledge on its services and optionally hints on how to use them.

but it only works locally. you still need a standards solution globally.

[sloev]

by reading:
https://github.com/calmh/syncthing/wiki/Case-Study
i got a better understanding of the global lookup in this case using your announce server. is the announce server sourcecode available?

[filoozom]

It is: https://github.com/calmh/syncthing/blob/master/discover/cmd/discosrv/main.go

[filoozom]

And there are at least two mDNS libraries for Go if you decide to use it for the local discovery:
https://github.com/davecheney/mdns/
https://github.com/armon/mdns

[calmh]

Thanks, the latter looks really nice.

[calmh]

It's funny how I went looking after this around new year and then there weren't any good libraries. Now there are. Things moving. :)

[filoozom]

Yes, guess that's always the case on newer languages.
For the mDNS thing, of course it doesn't work on Windows...
With https://github.com/armon/mdns I get 2014/03/24 17:09:26 [ERR] mdns: Failed to start IPv6 listener: listen udp6 ff02::fb: setsockopt: not supported by windows

EDIT: Never mind, works over IPv4, and it somehow still sends IPv6 paquets despite the error.

[calmh]

That's a bit annoying. I wonder how much is Go just not supporting Windows and how much is just not using the right calls within Go...

[calmh]

It should be fixed in either case, just different places to file the bugs I guess.

[sloev]

Yes mdns does need external stuff. Bonjour tools i think. But that had been
talked thru 1000s og times.
On Mar 24, 2014 5:11 PM, "Philippe Schommers" notifications@github.com
wrote:

Yes, guess that's always the case on newer languages.
For the mDNS thing, of course it doesn't work on Windows... (at least not
without an external program if I understood it right).

Reply to this email directly or view it on GitHubhttps://github.com/calmh/syncthing/issues/102#issuecomment-38463953
.

[filoozom]

For the moment syncthing is standalone, so I don't know if it's good to add a dependency?

[sloev]

Dont worry people use banjo ur for Windows all the time for different
services like printer discovery,airplay etc.
On Mar 24, 2014 5:31 PM, "Philippe Schommers" notifications@github.com
wrote:

For the moment syncthing is standalone, so I don't know if it's good to
add a dependency?

Reply to this email directly or view it on GitHubhttps://github.com/calmh/syncthing/issues/102#issuecomment-38466560
.

[filoozom]

var ipv6Addr = &net.UDPAddr{
    IP:   net.ParseIP("ff02::fb"),
    Port: 5353,
}

_, err = net.ListenMulticastUDP("udp6", nil, ipv6Addr)
if err != nil {
    fmt.Println(err)
}

returns listen udp6 ff02::fb: setsockopt: not supported by windows, so it's neither the library nor Go, it's just Windows?

I personally don't have Bonjour installed and still have a lot of programs on my computer. The only program I'm aware of that uses Bonjour is iTunes and apple programs, which I don't use.

[calmh]

Yeah, I wouldn't want to force that (Bonjour and co) on anyone either. Do you have v6 enabled (or not disabled, or whatever :) on that computer? If so, that means the syncthing 0.6.6 discovery doesn't work on Windows either, again. Sorry about that. :(( Will need to either figure out what the problem is in Go or not use v6 or find some workaround. This is all not so related to iOS anymore though. :)

[filoozom]

Yes, I have IPv6 enabled, but I can test on an other computer.

net.ListenPacket("udp6", "[ff02::]:21025")

works

net.ListenMulticastUDP("udp6", nil, "ff02::fb")

doesn't work

Globally I think net.ListenPacket on IPv6 is not a problem, but net.ListenMulticastUDP is.
So maybe there's no issue in the discovery.

[sloev]

Implementeret both and Add a token to the config whether a node Accepts
mdns. Mdns is great. Keep your own discover going for legacy (Windows)
support.
On Mar 24, 2014 5:48 PM, "Philippe Schommers" notifications@github.com
wrote:

Yes, I have IPv6 enabled, but I can test on an other computer.

net.ListenPacket("udp6", "[ff02::]:21025")

works

net.ListenMulticastUDP("udp6", Iface, ipv6Addr)

doesn't work

Globally I think net.ListenPacket on IPv6 is not a problem, but
net.ListenMulticastUDP is.
So maybe there's no issue in the discovery.

Reply to this email directly or view it on GitHubhttps://github.com/calmh/syncthing/issues/102#issuecomment-38468934
.

[filoozom]

But why should there be two discovery systems when the current one works for all operating systems (I mean maybe, still not sure that it works correctly on Windows)?

[sloev]

The only reason is that third party apps using your protocol on linux/osx
has one less custom protocol to navigate. Mdns is heavily used in
linux/osx.
On Mar 24, 2014 6:05 PM, "Philippe Schommers" notifications@github.com
wrote:

But why should there be two discovery systems when the current one works
for all operating systems?

Reply to this email directly or view it on GitHubhttps://github.com/calmh/syncthing/issues/102#issuecomment-38471157
.

[hyiltiz]

It would be extremely sad to re-implement the whole library in Ocjective-C just because its language was not allowed/restricted by some company. Going the other way, isn't there any way to petition it s.t. Go will be somehow supported in the iOS "ecosystem"?

[AudriusButkevicius]

It's not really restricted, you can compile go to C compatible ABI, and even access parts of ObjC/iOS SDKs from go via go-mobile, etc.

[hyiltiz]

Oh, I have never seen this option in any of the forums or threads on this topic before. Maybe it has been mentioned but I missed it. Anyway, this does seem like a very plausible approach, as opposed to re-implementing the protocol in another language for another platform.
I wonder if anyone have tried compiling syncthing to C compatible ABI and test it from within a thin C (or even Objective-C) wrapper. And since syncthing already has a web interface, we may be able to provide the UI wrapped in a WebView-like app or (can you host local sites from 127.0.0.1 in iOS?) even directly from the browser.

I am not quite sure how much we would gain from a native gui implementation or a native protocol implementation. We barely interact with the GUI, since once it is set up, the GUI is (mostly, except for things like backups) out of the way and all that matters are files. And an independent implementation of the protocol has arguably as much pros as its cons (e.g. pros: standardizing protocols vs. cons: protocols standardized thus hard to change when necessary).

[calmh]

Yes, I've done this - Syncthing can run just fine on iOS when compiled to a C library and started by a thin wrapper application that provides a web view for the GUI. But it's not a very useful thing.

• To access data from other applications (such as a password manager whose database we wish to sync) we need to use a specific API, accessible from Swift/Objective-C
• To access photos or media, same thing
• Applications cannot run in the background (essentially), so to sync you need to start the app and wait for it to connect and sync, while watching it do so

So you could use Syncthing as a foreground app to sync files that are then accessible in the Files app. This covers a few use cases, sure, but it's very limited.

[hyiltiz]

Ah, so iOS file system and process restrictions... It is a sad thing to work extra just to comply with their policy that "enhances security/privacy" by restricting stuff they didn't have to. But I'll stop here so we can discuss technical details instead.

[WhyNotHugo]

Some apps work around the background restriction by asking the user for background location permissions, and triggering jobs in response to location changes, etc.

Regarding filesystem access, access to photos seems to be pretty unrestricted. I'd love to see the ability to sync photos via syncthing.
There no real user-accesible filesystem other than that really.

[calmh]

Location background hacks, which are indeed hacks, let the app wake up now and then and get a slice of time (on the order of 30s) to do its business. That's fine for polling a web service for status updates and stuff, but not useful for Syncthing.

Photos are not available at all except via the dedicated APIs. This makes sense, because on many phones by default now photos are in iCloud with only small previews actually stored on the phone. Accessing a photo requires an API request that will go download the photo from iCloud etc.

[ellnic]

I know this is an old issue, but after the recent privacy concerns with Android apps breaching user data to FB even if you don’t have a FB account, I feel I should comment..

// Soapbox warning

It’s a crying shame that Apple feel the need to restrict iOS so much... the lack of apps being able to ‘just access’ data is a frustration I work around daily. For example - offline viewing of media ie. chucking a quick couple of movies or some music on my pad is needlessly laborious and time consuming.... Having to boot a workstation, import to iTunes then sync is, quite frankly, very sucky and not something I would expect from the “worlds most advanced mobile operating system”. So what are the alternatives? A cloud player? No. Emby or Plex? Maybe. Android? Well yeah.. on Android, I can grab files from anywhere, transfer them by any means, store them in any location and open them in any app. Sync music via Syncthing and play in Phonograph for example.

But it’s a trade off: I don’t trust the security of Android. At all. I love Linux. But Android is, for lack of a better description, a real monstrosity of an ecosystem on top of something great. Not that I am saying that the iOS ecosystem is any less monstrous, but for completely different reasons. iOS is undoubtedly safer but constantly ties down the user and bleeds them dry financially - what you get for your life savings though is a secure and mostly bug free smooth experience. On Android, users are empowered but left with buggy and ugly apps, insecurities and with next to zero privacy rights if they want it’s full potential (root and Google). The recent analysis of Android apps sending data to Facebook whether or not you have a FB account makes me cringe - as do the recent iDevice prices and Apple’s continued arrogance. I almost couldn’t believe that apps would be allowed to communicate user data to FB post GDPR, so I grabbed a couple of the mentioned apps, installed a firewall apps and sure as anything - most of them tried to communicate with a Facebook server before the user was asked anything and nearly always as soon as the app was opened!

Apple: you need to improve file management/importing/syncing and cut prices by 20%. Your ‘pre-trillion dollar’ jail breakable devices were awesome, with reasonable pricing.

Google: you need to pay more attention to the awful code allowed to exist on your store and take a long hard look at how your platform protects [or doesn’t] user data from things like the Facebook SDK.

Will either happen? No. Not a chance in hell. Also, let’s hope the lawyers start raining down those 4% fines on FB sooner rather than later.

// Ok, off soapbox

Going back to Syncthing for iOS: I would love this. But it presents a massive issue if the iOS system isn’t going to change. I use Syncthing on Android to sync and play music / movies. For Syncthing to be useful for this purpose, it would need a player built into the app. Without it, the device would sleep between music tracks, they’d be no playlists file support etc. It’s moving the app into being something it’s not. I am not sure how it would be possible to use any syncthing app for anything more than a ‘holding cell’ unless it had some extra functionality to make use of some of the stuff. If Apple would allow the import of files within the files app into the Music app on device, this would be solved.. but I seriously doubt it’ll ever happen. It also doesn’t address the problem with apps being suspended. I would probably ditch iOS and move entirely to Android if it wasn’t such a liability. Again though, never gonna happen. 😞

[hyiltiz]

@ellnic Ditch iThings and grab a phone and install your own OS if you care so much about privacy but need power as well, so we can remain constructive here.

[calmh]

Halt. Cease fire.

[x9921]

@hyiltiz what custom OS and device are you referring to exactly? Droid based? Did you read anything in the linked study before you hit the keyboard? It's the apps like Shazam and Kayak that are causing the issue. Everyday apps. It doesn't matter what custom ROM you install. If you use the apps, you get the breech. Maybe you should read before you comment.

@ellnic you should probably leave the Soap Boxes for Reddit ;)

My constructive bit: I have been learning Swift for the past few months with a colleague. It started as a bet, funnily enough but we're enjoying it a lot so we decided to continue. I would love to contribute to this in any way I can, but we are literally Swift rookies. Perhaps we could try and fill in some blanks if someone else here gets the Objective stuff done?

[calmh]

Let’s take another timeout on discussion of this issue.

[JPenuchot]

Hey' I've been looking for ways to run Syncthing on iOS as Mobius isn't available in France. Turns out it's available on Alpine Linux, which you can run using the iSH app. While it's definitely not ideal since iSH is basically like running x86 QEMU on an iPhone CPU, you actually get a full blown version of Syncthing running on Linux, and iSH is fully open-source.

While the app cannot access your pictures, it still has a filesystem which you can explore and copy files from/to as it is explorable from the iOS file explorer. It's not ideal since you can't just have it running in the background and passively sync your stuff, but it's still better than nothing I guess?

Anyway, too bad iOS sucks that much.

And btw massive thanks to Syncthing devs because if you didn't made data sync so easy I would have lost a whole life worth of personal data. <3

[zjDrummond]

Any thoughts on revisiting the iOS/iPad OS port? Apple gave us a file browser on iPad a while ago, and I have been using Resilio Sync with it, and all my other devices for a while. I fully expect that app to start demanding money as all these tech companies shill out for software as a service, and I would way rather use an open source app for security reasons.

I'm kind of out of luck without the iOS app though.

[calmh]

I don't think any of the usual suspects are in any way interested in doing this, and be assured that doing it properly is a major piece of work. So I don't think there's anything to revisit, really.

[zjDrummond]

Doesn't this fit the expressed goal of the project to be universally available? iOS is still a major platform. I really wish I knew how to code. I would love to help in some way.

…

On Sun, Dec 26, 2021 at 3:09 AM Jakob Borg ***@***.***> wrote: I don't think any of the usual suspects are in any way interested in doing this, and be assured that doing it properly is a major piece of work. So I don't think there's anything to revisit, really. — Reply to this email directly, view it on GitHub <#102 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHC3Y33AF3RCJHH6MKFBILUS3LVBANCNFSM4ANQ4EFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

-- Zachary Drummond

[calmh]

If it didn't fit our goals the issue would be rejected. Still needs someone willing and able to do it.

[DivineDominion]

Yes, I've done this - Syncthing can run just fine on iOS when compiled to a C library and started by a thin wrapper application that provides a web view for the GUI. But it's not a very useful thing.

@calmh Could you document how to compile into a C library? I'm a capable enough Swift developer to add the module map myself and export this as a proper Swift package, but I'm no good at understanding the build system of Go :)

[calmh]

It's been many years, I don't remember. I'm sure the info is out there, though.

[fuzihaofzh]

It's 2022 now. Seems it still not not come out. I just wonder resilio also has a ios version. Is there any particular reason that syncthing still not support ios?

[bezmi]

If it didn't fit our goals the issue would be rejected. Still needs someone willing and able to do it.

I think it's pretty clear why. People are expecting an iOS port to materialise out of thin air. It's an immense amount of work and no one is willing to volunteer the time needed to do it.

[OliverCole]

The $515 bounty obviously isn't sufficient. Perhaps the issue needs to be broken down into smaller pieces people might be more able to help fund in the near term?

[pySec710]

What about creating a mobile web client and then making it an iOS app by embedding it in a frame? It wouldn’t interact with your file system obviously so no syncing but it would allow you to view the file system, down files, and maybe even add a built in file viewer like google drive. That way you get some interaction with syncthing and could be a good start to a full iOS client. It would also give users the option of a google drive style way to access their files without needing a client app installed.

[ivankovnatsky]

I think this is what: https://github.com/MobiusSync/MobiusSync closely to what you suggest does, I guess.

[imsodin]

I locked the issue as the intent here is clear. More comments that it's needed or how it might be done don't help. Someone "just" needs to do work. For any discussions or even better, if you'd like to work on it, reach out on https://forum.syncthing.net.