I cannot guarantee anything about availability or even maintenance, sorry. As stated multiple times before in this thread, this is a volunteer effort.
I completely understand!
Regardless, it makes sense to charge a fee, for whatever App Store itâs available. There has been recent debates that volunteer efforts and FOSS are not sustainable.
I donât know if the revenue will be enough to sustain development. I would be interested in this topic, if those with experience could chime in.
I did consider charging a fee for the app (and also discussed this with some of the Syncthing core developers) but came to the conclusion that it is simply not a good idea:
- It is unlikely that charging a one-time fee would even nearly recover my development effort (at regular rates).
- Actual operating costs are rather low right now (just the developer program costs money).
- I would have to use a subscription model to be able to cover maintenance costs. Iâd hate this as an end-user!
- Actually charging and earning fees involves various legal issues (i.e. the encryption declaration stuff), fiscalities and additional work for my accountant, which will likely cost more than the earnings.
- Charging a (high) fee would lead to higher expectations on the level of support, higher than I am willing to provide.
- Some of the revenue would probably be expected to be shared with the Syncthing developers, as well, this is the core of the app. Thatâd lead to a (probably endless) discussion on how much contribution is appropriate. Would I be (morally) allowed to make money off this at all?
- This is a hobby project, I want to fully decide on how I spend my own efforts on it, and Iâd like to give back to the community.
The current deal is this: I make an app to scratch my own itch and share it with you and everyone else for free. As it is now handling pretty much all of my personal files you can be somewhat sure it will take good care of yours as well 
It represents many, many hours of free development effort. Consider it a gift and nothing more. If you want any sort of guarantee, have any sort of wish, want to plan or commercially deploy this: you can always ask me the thing you need, and I may quote a price. Your other option is: fork the code and build it yourself, possibly hire some other developer (and give back/abide the MPL of course).
Note that I still think it would be great if we could offer some more guarantees to users. This may be an area where the Syncthing Foundation could step in (although obviously also their resources are limited). To be clear, even the core project doesnât offer you any guarantees - just more momentum.
The app will not delete the original photo from the album unless configured to do so.
The app will not delete the copies of the photos made. In the future there may be a feature to delete a photo once successfully transferred to N other devices.
The app tries to export as much metadata as possible. Iâd say just try itâŚ
Hi @pixelspark, great effort and work here to bring this to the iOS platform. I have two suggestions here:
-
Regarding the Photos sync, why not instead of copying the phots from the album to another folder, then to have a option to keep them or delete them, you can same the images name (like a unique ID) to a key/value pair local database. Benefits ? a. Save the extra space on device. b. Same read/write time which makes it faster.
-
You are doing great effort by keeping this project open source and free as well. You can consider âBuy me a coffeeâ link as an appreciation for this and may be at least to pay for the Apple dev. account.
1 Like
Thinking about what you have commented and the issue of iphone space being used to duplicate existing pictures⌠how does this sound?
Server â receive only
Iphone â sent only
We say we want x days of history (say 2days, 1week, 1month, all, and date range start and end; as options)
It copies those files over from oldest first till x% space full
These sync from iphone to server
Once synced, the app then deletes copies folder on iphoneâŚ
The oldest first because if space if filled on phone and it cant copy all, then the date range can be shortened.
The date range selection is because you can copy stuff that didnât sync in a specific date. (say I needed to resync a set of birthday snaps)
A default of 1 week means that if you have the iphone sync automated when on wifi, your snaps are always going to be backed up unless you are away from internet for more than a week.
Wouldnât this work, so as long as your iphone has space your snaps will always backup on the server.
Why is it not available on my region? Wanna try your amazing apps
What region would that be?
Synctrain is currently available in most EU countries except France.
The reason for excluding France and the unavailability in the US is that there is a requirement by the respective governments to submit a declaration on the use of cryptography (which for the US has been submitted but is still pending approval).
For other countries I simply havenât verified the legal/regulatory requirements yet to be confident to flip the switch on distributing there. If you think you can help, just let me know. TestFlight should be available in more regions by the way.
2 Likes
I donât know about France, but for everyone else you can just check the âno non-exempt encryptionâ checkbox as all established industry standard algorithms (which are the only ones we use) are fine.
1 Like
Well, that checkbox is more like a wizard these days
Even if Syncthing only uses standardized algorithms, the fact that it includes some crypto of its own (even if only by means of standard Go libraries) puts it in a slightly different category than apps that just use iOS crypto implementations.
Long story short: for France I absolutely need to declare before making the app available.
For the U.S., the app is eligible for an exemption (because only standard algorithms are used). Technically I am only required to do a âself-declarationâ at the end of each year. The better option is to request a âcommodity classificationâ, which I only need to do once and be done with it. This is the request currently pending, and me waiting for it to be approved is a matter of prudency.
As for the other territories, I have yet to do some basic research on whether there are any issues at all (regarding crypto restrictions or other things).
If you happen to be in one of the currently excluded regions - sorry - I have limited time. You can download the source and build yourself or use the TestFlight build, which I will update frequently so it doesnât expire. For macOS I may be able to provide a Developer ID signed and notarized build.
3 Likes
Right, I was looking at Export compliance documentation for encryption - Reference - App Store Connect - Help - Apple Developer where it looks like Syncthing should fit the middle case and not require a commodity classification (though I guess one wouldnât hurt):
As for France, I love France, but on this specific issue, fuck France. 
4 Likes
Yeah itâs annoying, especially since publishing the whole flipping source code is the best kind of declaration theyâre ever going to get
4 Likes
Indonesia
Hi, any chance you could make it compile and work for iOS 17.0? I donât have access to Xcode, but I am able to sideload an IPA file, if you built one. Thank you!
Firstly, Iâd just like to say youâve done amazing work and I think the app is really well thought out and well implemented. Great job!
Iâm having an issue which Iâm uncertain is due to my specific setup or some other cause, and the logs the app currently generates arenât verbose enough for me to get a handle on it. Itâs also something a screenshot wonât really capture so Iâve decided to bring it to you here.
Potential Gotchas: I am using a private syncthing relay, not any public one.
What Iâm seeing is that the app will only sync with instances on the same LAN segment as it is on. It seems to connect to the relay server without issue, but does not connect to any non-local devices. This issue has been present since I started testing it on 1.6 (7? Iâm not sure) and was definitely still present on 1.6 (8).
When I first upgraded to 1.6 (9), it would not connect to any devices at all. I downgraded to (8) and then came back up to (9) and now it seems to behave as though âOne device is enoughâ is enabled, even though it is disabled. That is to say, in addition to only connecting to local-segment-LAN devices, it will only connect to 1 device even when 2 or 3 are present and all communicating with one another.
Please let me know what other information would be useful in helping track this down and if I can help in any other way.
Strange. This is related to core Syncthing behavior, although of course it is possible that Synctrain somehow configures Syncthing the wrong way to cause this.
It would be helpful to have a (possibly anonymized) export of the configuration (config.xml, can be exported from the settings screen) and a debug log (this can be turned on from the settings screen, then after a restart it will be placed in the Synctrain folder).
As youâre seemingly running a non-standard config, have you changed any discovery server options? Running with global discovery disabled would fit the description somewhat.
Just came here to leave my cudos! Great app, and I am a big fan of the âon-demandâ file feature, protecting my phone storage from being completely blocked. I used to have dedicated folders with a limited amount of files which I needed online on my phone, but the management of that sucks. Now I can just pull whatever I need when away from my laptop, and I love it! Thank you!
1 Like
hey @pixelspark maybe you missed my question, any chance to publish an iOS 17.0 compatible IPA build? not necessarily in Store, I can sideload it.