Nice that there is finally an app for iOS.
I tested it and it works (just few files for now for testing). I tested with LAAN and WAN sync.
But there is a problem. There is no setting in the app to sync over a VPN such as Tailscale in my case? The listening address cannot be changed. The listening port is not even known.
Is there a workaround to hard code IP addresses?
By default (when âlisten for incoming connectionsâ is enabled) the app will listen on the âdefaultâ listen address. So it should be reachable even from inside the VPN.
You can actually place a config.xml file in the Synctrain root folder, however the app will likely overwrite any set listen address when you toggle the âlisten for incoming connectionsâ setting. (Also it will overwrite certain other variables such as the folder paths).
I will consider adding UI to customize addresses for listening and e.g. discovery servers.
https://www.icloud.com/shortcuts/f39b5d111ef24d6bb140154b138ec944
(Has some Dutch text but it should be rather obvious how it works and what the texts mean. There is a workaround in there for slowmotion videos, somehow the Shortcuts app is unable to export those).
It might be a better idea to provide support for custom config. An easy way if you donât want to merge options in GUI and config: options in GUI will be frozen and only custom config is loaded.
Right now there are a lot of options that are not exposed.
Another point: the other peer has the Tailscale Ip address of the phone hard coded, but phone has the Ip address of the other peer as dynamic. It takes 30-90 seconds for the other peer to appear online. Every time the app is closed it takes this much time to establish connections. Actually even if the app remain closed but the screen is locked, it stops. Not very practical.
By the way: each file added to the folder has to be manually approved for sync?
I should add: even with a custom config with Ip address of both sides hard coded, it takes 30-60 seconds for devices to appear online.
Every time the app is closed, or minimized in the background while checking another app, this time is reset.
Itâs not usable this way.
Is this how others use it?
I agree that would be nice, but it would also add significant complexity to the app to support scenarios that in the end would be better served with proper support in the app. The app is designed to fit certain usage scenarios with a user friendly interface and nice integration with iOS. We can discuss new scenarios of course but development capacity is limited. If you want something not offered, try MobiusSync (access to all features but less user friendly).
Iirc, the phone side does not have an IP for the other peer, so it has to sit and wait for the peer to contact it. This can take a while depending on the reconnection intervals. The phone will try to find an IP for the peer through discovery (and that should work rather quickly using LAN discovery, so check out whether that is properly working over your Tailscale network). Global discovery can take a while longer, also when the peer has many IP addresses it will take a while to try them all.
To get a quick connection, you should hardcode the peer address on the phone side as well so it can immediately âdial outâ. Iâm not sure this is possible yet without custom config).
Note that the iOS app is not allowed to do much while it is in the background (all listening sockets are suspended as soon as you open something else). The app is only allowed to wake up every now and then (when on the charger, and then only typically 5 minutes each hour) to try and do as much syncing as possible. Unfortunately this is an iOS limitation I canât work around.
If you configure the folder as selectively synced, then yes. You can go to folder properties and tell it to sync everything (this disables selective sync functionality but will auto-sync any new files). There is currently no way to do opt-out selective sync or to auto-add new local files when selectively syncing (the latter is because the feature as implemented requires to âignoreâ all files except the selected files).
If your use case is photo synchronization: I am working on a feature for periodically (also in the background) saving photos from a configurable photo album to a configurable folder (also auto-adding it when selective sync is enabled for that folder). The feature as it is now will also not copy a photo again if it was copied before and then removed from the folder, so it should be useful for back-up/ingest scenarios (the copy function will copy over new photos, these will be synced, and if you remove them on the other side will not be copied to the folder again. So you could have a cron job moving photos out of the folder on the other side for instance). This could later be extended with a mechanism that automatically deletes local copies of photos once the app detects they are present on N other devices. Keep your eyes on TestFlight, I expect it to be there in a few weeks.
In this interest does it make sense to invest in an âadvancedâ option that uses the existing syncthing code to open a browser window to manually configure the settings? In this way only the most basic settings need the âsimpleâ UI but more advanced settings can be handled via the web browser.
I played with the app heavily for few days.
I have a Tailscale network and syncthing syncs over Tailscale IP addresses. For devices that have static IP addresses, also encoded in syncthing GUI (like tcp://100.xxx.xxx.xxx:22000), all other connectivity options (global and local discovery, relay, and NAT transversal) can be disabled. This set up worked well in my network, except for iPhone. The desktops devices connect quickly, but the iPhone had problems connecting to any peer.
This app does not have functionality to specify a static IP address for the phone, or other peers. However, you can nevertheless provide the Tailscale IP address of the phone in other peers. Ideally, this should be enough for other peers to find and connect to the phone app almost instantaneously (permitted by Tailscale ACLs).
That said, if all connectivity options are disabled in the phone app (regardless of the connectivity options enabled in the other peers), the app takes a long time to connect to other peers, 30 second to few minutes. The amount of time is also random, and can be short or very long. This makes no sense, since the peers have the IP address of the phone and should be able to connect to it almost instantaneously.
I played with different settings in the app. Indeed, the connectivity options in the app can all be disabled, except for the global discovery. With that enabled (regardless of the connectivity options enabled in the other peers, which do not matter because other peers have the static IP address of the phone), the app connects to other peers in few seconds which is acceptable. However, global discovery seems unnecessary when syncing over VPN, and I prefer if it could be disabled.
I used a custom config in the root folder of the app (specifying the static IP addresses for the other peers, etc), but could not get it to work well.
Currently, there is a need to expose more of the useful Syncthing options in the web interface (such as support for specifying the IP address of the phone and other peers, required when syncing over a VPN), or support for custom configs, and test that it connects to peers fairly quickly in different cases.
Considering iOS restrictions, I am not quite sure. Resilio Sync iOS app connects quickly and syncs fast. Unfortunately, itâs closed source, so itâs unclear how they do it. Since itâs closed source, I canât use it, because its security can not be verified.
@Eli123 thanks for the feedback, will take into consideration for future versions. There are a lot of ideas.
Note that if you want open source, this also implies you accept the nature of open source, which is that without any financial support there is no guarantee with respect to the functioning of the app or future feature development. I would encourage code contributions and will gladly review them. We all want this to be as good or better than closed source stuff but time and resources are limited. Just to set your expectations.
Correct. I think this is a general issue with FOSS (that FOSS is not sustainable, and users have got used to free software). There has been a lot of discussions around this lately. Mobius is like $5 which is almost zero, price of a coffee or two. I canât imagine someone unable paying $5. It could be due to payment friction.
You could set a fee, and that makes sense.
But the security parts of the app should be open source. You canât run an opaque long running binary on all your devices, nobody can verify what itâs doing. Thatâs the problem with Resilio.
Syncthing itself is amazingly free, but maybe because the work is distributed over tons of developer.
No, not really, I think.
Sure, but the remotes are not retrying connections every second. Because that would be foolishâŚ. Why if a device has been offline for 24 hours would a device try to initiate a connection with a previously offline device every 1 second? I suspect retry attempts end up spaced out and may perhaps happen every minute or two or 5âŚ. Especially since newly turned on devices can usually initiate their own connections without any delay.
Correct, spaced out, from what I see. I Suppose that could be adjusted perhaps per peer.
For an always on peer in the cloud it should be okay!
The proper way to do it is by phone contacting out, but that option doesnât exist in the app.
hi, would it be possible for you to add ios 16+ so those phones can also test this app? currently this is restricted to ios 17.5 and above
Currently the app does not build for iOS 16 as it uses a few features that were only introduced in iOS 17. It would take some effort to work around these. I currently do not have a need for this so it is not my priority. Anyone is free to contribute a PR to this end however.
The question is also for how long iOS 16 should then be supported. Maintaining support means newer iOS features cannot be used and more maintenance work will be required, so at some point iOS 16 support (or even 17) will be dropped. (Note that even while iOS apps are typically forward compatible, they can have some weird behaviours - i.e. the current iOS17 version of the app shows the tab bar in a weird position on iPadOS 18).
We might consider building a âlegacyâ version of the app that gets no new features but works for iOS 16 (Iâm not sure though if this can then be distributed in the App Store as it would basically be a duplicate app - but perhaps it could work through AltStore. Or you could compile it yourself with some specific flags set).
In addition it might be good to share a bit about the current development plans. I am working on a new version (1.3) that will have the following main changes:
Aiming for a release in october, a first version is available on Testflight right now.
Really cool!
It doesnât seem to work for me for very large folders though.
I have a very large folder (~700GB) containing pictures.
This folder is synced between my laptop and a very weak ARM device (Allwinner A20, around 10 years old with 2GB RAM), where it works without issue.
Synctrain reports an empty folder , regardless of whether I share between computer and Synctrain, ARM device and Synctrain, or both.
I am not sure where to report issues.
It works well for small folders! Thanks a lot for your work and time!
Is it possible to add a field for the static IP address of the device like tcp://1.2.3.4:22000 ?
TestFlight users can submit feedback by screenshotting the app (iOS wil present a feedback UI). There is no public issue tracker right now, as I am currently the sole developer and would like to keep my issue list clean. For now, just share any issues on this forum or on the Github discussions page (or even e-mail me). Iâm happy to work out the issue with you.
The app shouldnât have any issues with large folders like this (Iâve personally added folders totalling to 3TB on my phone - most of which is not fully synced of course - but still the file listing works fine. It may of course be a bit slower)
What is the app showing you exactly? Are you able to find files using the search function in this folder? Is your other peer showing the iOS device as connected, and also showing the iOS device as device sharing the specific large folder?
When no peers have been added to the folder yet, or the other peer hasnât shared the folder with your iOS device, the app will show the folder as empty with a message. After both peers agree to share the folder, the app must download the folder index from the other peer(s). During this time period the folder may appear empty or even incomplete, but it should eventually show up.
(I should probably add a way to turn on logging and export to a file, this would help me see whatâs going on in your case.)
This is on my list (a screen to configure listen addresses, so you can also configure e.g. private relays, as well as a list to configure remote device addresses). I hope to include this in v1.4 (v1.3 is currently in testing and will be submitted to Apple soon)