The app is currently targeting 17.5 as minimum. I assume you are jailbreaking and need an older iOS 17. If so I will check if I can lower the deployment target. Note however I cannot guarantee support forever for any iOS version that is 1/2 major versions behind.
Hi Tommy, thank you for the great app! Seems to work fine, though it required a restart as it was somehow crashing after the initial setup while syncing. I enabled debug logging but it has been stable since then.
An iOS noob question: when I try to backup the photos, the only folder that makes sense is âRecentsâ. I donât have an option called âCamera rollâ or similar. Have the same problem in the stock Photos app. When syncing with CopyTrans I see a âfolderâ called âAll imagesâ but perhaps that one is created virtually by the software. So, I did a quick test with âRecentsâ and see basically folders with each date. Is this intended behavior? Is there any way to see/sync only the camera roll, including videos but excluding stuff received on WhatsApp for example?
Question 2: I have no problem enabling the âDelete photos after syncingâ once they get moved to the sync folder. My woder is, if everything else would work fine and the stock Photos app would just see them as usual, with the same date and metadata.
Just adding a new post since there might be some useful information.
I used a shortcut (iOS native) to move all the photos taken with my phone to a new album. There is also another shortcut + automation that moves new pictures to that album. In Synctrain I set up a folder which is synchronized with that album. It is set up to remove files immediately but that might not be a great thing, see below.
When the photos are synced with the iOS folder, they are transferred in the usual ugly way, one folder per day. This is how iOS behaves I guess.
When the files are removed (deleted) from that album, they also disappear from the Photos app. Not sure if there is a simple way to move them back. In Photos you also cannot set a way to display a device folder as an album (like on Android). The photo albums/folders and the device folders are completely separate and Files for example cannot access any native photo album (afaik).
So the only workaround seems to be to keep both copies of the photos/videos on the device, one in the Photos storage and one in the Files storage.
Thanks! And strange that a restart was required, but not much to go on⊠(Note that the latest version should fix an issue with the app freezing after doing things in the background. Perhaps this occurred with the previous version)
I will look into this. I am simply using âRecentsâ but that indeed includes everything, but having âCamera Rollâ as an option makes sense and should be possible.
The app basically gets a long list of all photos in the selected album from the system. Then it sorts them by date. In the future this behaviour may become configurable (i.e. have an option to just place everything in a single folder, put things in a sub folder, etc.)
Iâm not sure I understand your question. Pictures that are removed from the Photos albums will not be visible there anymore (and that is what this feature does). The stock Photos app will not see anything in the Synctrain folder.
1 Like
Thank you for the quick reply.
No, the latest version of the app simply exited after a few seconds after the phone was put on the wireless charger with the screen on. It went back to home screen, very strange. This did not happen anymore after I enabled debugging and force-restarted the app.
Not sure this is possible, Camera Roll was removed some time ago. Instagram and WhatsApp have a way of accessing it somehow, but not sure how.
Really cool, though not sure how many are bothered by this.
Good to know. Unfortunately the synced+removed photos just disappear from the gallery and itâs hard without a 3rd party app to see the âoldâ photos. I might leave that option off for now until iOS is updated to support Albums from existing device folders.
Whatâs the best way to get you that information privately?
not jailbreaking, but Trollstore, which allows more flexibility for sideloading as opposed to official allowed free cost methods (maximum 3 apps per developer account, maximum 7 days lifetime of signing an app).
Iâd be happy without any support as long thereâs a tiny chance of doing a sync between iOS client and other clients. I do understand supporting older operating systems is a hard task when you need new features only offered by newer versions, but maybe you find a way to a compromise 
@pixelspark App looks awesome! I have one suggestion: limit synchronization to Wi-Fi only. Many people have mobile data limits including myself, so I think this would be a very useful feature.
I know this can be toggled in Cellular settings, however it will only show up there after use. I think it would be much nicer to have a toggle in the app, and perhaps even separate speed limits for Wi-Fi and mobile data sort of like how YouTube does with video quality:
@pixelspark Cannot find the app from the US or Chinese App Store. Is it only released in the Dutch App Store?
Good idea!
Unfortunately it appears it is not easy to implement properly. The good news is that there are APIs in iOS to detect the current connection type (i.e. NWPathMonitor). When the only connection type available is cellular, the app could thus temporarily suspend synchronization and/or lower bandwidth limits. When both Wi-Fi and cellular are available however, issues arise. The app cannot force Wi-Fi only usage in this case, and iOS may actually use both (when âWi-Fi Assistâ is enabled and your Wi-Fi is slow).
Apple does have higher-level APIs that have the capability to prohibit use of âexpensiveâ networks (cellular but also e.g. personal hotspot Wi-Fi). These (NSURLSession et al) are unfortunately not used by the Syncthing core code. As far as I know there is also no way to tell Syncthing (from config at least) to only ever use specific interfaces (these could be obtaind from NWPath) but maybe the core developers can chime in.
The toggle in system settings actually does what you want (additionally there are system-wide settings to limit data usage for background tasks). It is unfortunate that it only appears after using cellular data once, but triggering that is not difficult of course. I will check to see if I can influence this setting from the app but Iâm afraid it will not be possible.
1 Like
This is more or less impossible from a single application perspective. We can of course control which interfaces we listen on and which addresses we publish to discovery, but outgoing traffic follows the system routing policy and isnât really under our control.
1 Like
Gotcha, thanks for the info. Using the iOS system settings toggle works fine anyways, so itâs not a necessary feature by any means.
On another note, I noticed there is no option to use a custom global discovery server. I would love to see this as an option since I want to use my own discovery server.
Perhaps an option to âModify Configuration Fileâ could be added for manual config modification? Of course a warning should be displayed due to the sensitive nature of an option like that.
thank you for making the testflight available to 17.0 !
1 Like
Scroll down in advanced settings, you can export the config file there. Save it as config.xml in the Synctrain folder and restart the app - it should pick up your config file (although some specific settings are always overwritten/managed by the app, notably folder paths, the global discovery setting isnât)
In a future version I might add a field for setting the global discovery server.
1 Like
Oh perfect, thank you!
Hey,
kudos for opening the source! This gives you a trustworthiness bonus right off the bat.
You enabled something that just wasnât possible before: On demand syncing of files. This is a big deal for sharing things between devices with different use cases, for example laptop (main location for large project files) and phone (mostly doesnât need access to them, but occasionally you want to reference something).
Your app is more than just a SwiftUI version of the Web UI, you came up with UI concepts that just make sense compared to what syncthing originally does, the biggest example probably being what you call âdiscovered foldersâ (which, btw, donât seem to update reactively). Things are just much sensibly packaged. Your app makes the process of setting everything up feel rewarding and easy rather than dreadful and hard.
There are still some paper cuts, for example I donât find it to make sense that the app emphasizes folder IDs instead of their labels. This was the only time I needed multiple attempts to achieve my desired result (whereas I need tons with the web ui even after years of use, lol). Itâs also weird how I have to explicitly âshareâ a folder with the device that just offered to share it with me (I assume thatâs what discovered means).
After 5-10 minutes of freezing the UI thread whenever I opened it and a few crashes while âsynchronizingâ my 50GiB Documents folder, downloading files on demand is actually staggeringly performant. It does occasionally feel unreliable (as syncthing does) and particularly listing directories is slow, which reduces practicality.
Over all the experience is very close to being the simplest way to share files between devices on demand! You built a pretty good iOS app here and transformed the over all accessibility and usefulness of syncthing dramatically.
But. I wish everyone could benefit from this.
Even though the web UI sucks, I like that Möbius Sync is based on it because it just uses the real desktop UI with all its exact same features, no matter how niche. Thatâs powerful and I think you should add an option to access it because it allows configuring things your UI doesnât support. Personally, even as a fan of native and good-feeling apps, I would be 80% as happy of a user (and over 100% as happy in other dimensions) if I had to keep the web view, but it was designed more closely to your UI principles.
I especially think that on-demand sync should be available to everyone. I know itâs some effort to implement a sensible UI for each platform, but first-class support by Syncthing would make doing so comparatively easy (CLI and FUSE would be easy first targets).
I highly commend you for pushing Syncthingâs boundaries here - I really wish to see much of it being integrated right into it.
Thank you for the kind words. Thereâs a lot to unpack here. A few thoughts:
Crucially though these UI concepts make sense specifically for the use case Synctrain was designed for (i.e. my own need to be able to access files on the go and on demand). The Syncthing Web UI is arguably better if the goal is to be able to quickly view and modify all possible settings related to syncing folders, and viewing the current state of sync (Synctrain does not really emphasize this).
Syncthingâs web UI is focused around configuration, Synctrainâs is focused around the global file tree. The latter I think is fundamentally necessary to support on-demand features. That doesnât mean it fits all use cases (nor is on-demand synching in particular useful in all cases).
This is fixed in the upcoming version.
When configuring a folder you absolutely want to be sure it is the one you want to sync. That is why the app shows you folder IDs in this stage.
I am not sure devices actually advertise folder labels - if they do, the app could of course show them in addition to the folder ID (i.e. Folder label (folder-id)).
Agreed, the sharing device (actually: all devices that share the folder, except untrusted) should be enabled by default in the âadd folderâ dialog that opens from clicking a discovered folder.
This unfortunately sometimes happens when somehow a call the app makes from the main thread into Syncthing turns out to be blocking. I try to do most work asynchronously and on background threads, but sometimes even fetching basic information can be blocking. Unfortunately there is no formal API so I have to guess when this is the case (and it could change).
It is also a bit difficult to debug this in the simulator. If you happen to have a developer-enabled iOS device, please enable the âhang loggingâ (in Settings â Developer) and send me the reports. Also please enable submission of crash reports to Apple, these end up directly in my IDE and are very helpful.
Another source of issues is that Syncthing will send a lot of events back to the app when many things are happening (such as during initial scan). In older versions this stalled the UI. Since the the last version of Synctrain the events are rate-limited, which helps keeping the app responsive.
Listing shouldnât really be slow as that is just scanning the local copy of the global file tree. It does becomes slower however if there are a lot of files in there, as basically the app/Syncthing needs to scan by prefix (i.e. to list files in â/A/â the app has to scan over all paths in the database in order between â/A/000âŠâ and â/A/ZZZZâŠâ including subpaths). Also listing the contents of a folder with many files is slow because even though SwiftUI is smart about only drawing the visible part of the list, the list of file entries still needs to be fetched to memory in full.
The unreliability of on demand download usually is related to the temporary unavailability of peers, as well as the fact that it uses the same connection that Syncthing is using for file synchronization (so while it is transferring files, on-demand download may become less responsive). Perhaps the algorithm for picking peers (when there are multiple that have a file available) could be improved.
Well this circles back to the question of what each UI wants to be.
For Synctrain, I figured that to provide a consistent experience (and not get bug reports from people who make stupid configuration choices) it should provide supported settings in UI and nothing else (there is an escape hatch that allows supplying a custom config, but it comes with various warning messages and is unsupported). I also chose to not make the web UI available because it would sort of âmuteâ any issues in the app. If it were available, I could then always say âjust use the web UIâ, and users would perhaps not give me as much useful feedback, because their issue is solved by using the web UI, and the app would end up in worse shape than it could be because of it.
Lastly, if you like the Web UI, just use Mobius - they actually have customized it for mobile a bit (I donât want to rely on their changes so would either have to maintain these myself or use the mainline one).
Up to now Syncthing is used by a ton of users who apparently donât need on-demand file synchronization. As discussed earlier in this thread, my implementation is by no means perfect and requires quite a bit of UI to paper over edge cases. From the discussions on selective sync I get the impression that the core developers are hesitant to build this in the core unless it can be done 100% foolproof.
I do like the idea of a (read-only) FUSE implementation of Syncthing for accessing files on demand (actually relatively simple to make I think, but I donât have the need nor time for it currently)
Hi Tommy ! Iâm experimenting with a shortcut automation that detects new photos and puts them in a folder for synctrain to read and sync with my pc, and I have encountered that using the âSynchronize for a whileâ action isnât working properly or I donât know how to use it. I have set the time to 300 seconds (5 min) and about 30 seconds in, the shortcut stops with a message saying that the action didnât finish executing in time.
Am I doing anything wrong ? What is the expected use case for that action ?
Edit: Also two suggested actions:
- Check if a Device is online and connected
- A way to wait for âCopy new photosâ to end before starting sync
Hi, the action is currently in the test flight build only, so still in development. Notably it doesnât work at all in build 1.7.17.
Basically the action will spin up the app in the background and let it do its syncing thing. Unsurprisingly and unfortunately iOS limits the maximum amount of time a task can take to about 15 seconds. This should probably be documented better.
A possible workaround is to call this action repeatedly in a loop from shortcuts.