iSyncthing iOS client for Syncthing now in beta

General
1

iSyncthing iOS client for Syncthing now in beta

Hi Syncthing family,

Pickup Infinity is happy to announce we’re now releasing a beta version of iSyncthing, a new iOS client for iSyncthing. You can install the beta through Apple TestFlight using the link below.

The modifications to Syncthing for iOS are published at https://github.com/isyncthing/syncthing/ under MPLv2 but the iOS wrapper around it is closed source. We do plan to modestly monetize the app when released publicly (paid download, in-app-purchases and/or ads) and would appreciate your feedback on which model you’d prefer.

iSyncthing uses Golang Syncthing natively internally and as the basis of the GUI, with only a small number of changes, most of them to work with peculiarities of the iOS ecosystem - e.g. sandboxed filesystem, inability to run separate background processes, disabling upgrades.

Of course, due to the security “features” of iOS, you are limited to syncing files within the sandbox environment of the iSyncthing app itself, but these can be moved in/out and opened/viewed using the iOS Files app. In the future, we hope to add photo library support (probably Send Only).

Another challenge with iOS is that (for battery performance reasons), Apple prevents apps from running indefinitely in the background. In this release the app makes some efforts to be restarted in the background sporadically, but be aware this is of limited use when syncing between multiple iOS devices, so the best usability will be where there is an “always on” remote device amongst the set of devices sharing any particular folder. We do have ideas about how to further improve background behaviour.

Please note that this beta uses Google Analytics (for usage reporting, with no app-specific data collected) and Firebase Crashlytics for crash reporting. Privacy policy is at https://www.isyncthing.com/privacy

At this stage, iSyncthing disables Syncthing’s own usage reporting and crash reporting, and we’re interested to hear from the Syncthing maintainers whether you would wish to receive such reports from iSyncthing. We’re also keen to know whether you’d like to include iSyncthing on the syncthing.net website, forum, issues, etc or whether we should set up completely independently.

Whilst we’re planning to provide iSyncthing as a commercial product, we are looking for ways we can support the Syncthing project. We know it would have been nicer to have iSyncthing available completely open-source, but it seems to have been too large a hurdle to date, and we hope the availability of a modestly priced iOS client will help benefit the ecosystem as a whole by bringing in new users. Certainly on a personal basis, I have not used Syncthing seriously until now due to the lack of an iOS client, and am proud to be able to fill this gap.

We will look to see what changes in the Syncthing core can be contributed back into the main codebase, and will look to see what can be done to release the funds in Bountysource for the iOS client to otherwise benefit to the Syncthing community.

Please download the beta here: https://testflight.apple.com/join/Z4dmMzO4

We look forward to your feedback here, on Twitter @iSyncthing, or on IRC channel #syncthing on Freenode as SimonPickup.

5 Likes
2

My first impression is that I’m not thrilled about you using the Syncthing name for a commercial and potentially ad-supported (i.e. likely privacy-invasive) product. Apart from taking advantage of the code in a commercial context, which is your right, I feel this is capitalizing on our brand (such as it is) in a way contrary to that brand. Given that your thing is essentially just a thin wrapper around Syncthing I see how the name came to be, and if your thing were open source it would make sense. As it is … it rubs me the wrong way.

(My second impression is that I’m not sure how useful this will be; I too have had Syncthing running on iOS with the mentioned limitations and files being available through Files only … but that’s not terribly useful.)

8 Likes
3

Likewise, my first impression is that you chose an incredibly poor name that will confuse the heck out of people.

I suspect we’ll get people barging down our door complaining about iSyncthing, which we have nothing in relation to.

7 Likes
4

Fully agreed on the naming. I get wanting to commercialize, no problem with that per se, but rather not with our name. An ios client is definitely high on the wishlist for a lot of people. As you noted yourself and calmh too, there’s lots of limitations on ios that go against the way syncthing works. Thus a half-baked solution might might disappoint a lot of people and thus hurt the Syncthing “brand” more than it helps (and we couldn’t even really judge how well-baked it is, being closed-source).

At the same time thanks for seeking the discourse with the community by posting to the forum.

9 Likes
5

Thanks to each of you for your replies. I did an ambivalent response, and I’ve thought through the concerns raised and am happy to adapt to suit; it’s just a matter of how.

I did think a lot about the name (and the use of your Syncthing logo, which nobody mentioned explicitly but goes hand-in-hand with the name), and I actually felt it was more respectful and beneficial to you for me to use the name and logo, than obscure the fact that our product is making use of your hard work. I’d rather be up-front. I also noted that almost all of the existing community contributions have “Syncthing” in their name, so I presume it’s the closed-source nature of ours that triggers your concern? I deliberately chose not to include our company logo in the app in order to show respect and support to you.

I certainly don’t want to cause any more concern than a closed-source client necessarily will, so happy to change names. I had originally thought of “Syncithing”, but realised that was too confusing. I’ll come up with a new name that will likely include “sync” but not “thing”. I’m interested in your thoughts on our use of the logo and look-and-feel too. I really do want to come to a mutually benefical outcome here.

As for benefiting/hurting the Syncthing brand, I do now see your concern. Re your inability to judge the quality of the product, I did deliberately choose to leave the Syncthing logs (and debug settings) visible so people can validate that the internal behaviour matches core Syncthing. This also helps for those concerned re privacy, as does including the git commit-id in the About screen.

The extent to which an iOS client in this form is useful, I guess we will see over time. It certainly is useful to me. But I can now see that its inherent limitations could cause an extra support burden for you, which is definitely not our intention.

We are really not trying to make this a big commercial undertaking. We just want a modest income stream to motivate ongoing enhancement and support. As I mentioned, we do want to find ways to contribute back to Syncthing, but I realise these are hollow promises for now, especially as a newcomer to the community.

Re privacy, I have been re-thinking the use of Google Analytics and Crashlytics and I have decided I will remove them completely. I added them based on habit from previous apps I have worked on, but on further consideration (understanding that privacy is a key driver for many Syncthing users), I have no real need for Google Analytics other than vague plans of using trends in usage patterns to be able to prioritise future changes, and we can forego this in the name of privacy. Crashlytics would be useful for crash reporting but it seems impossible to use without Google Analytics, so we’ll forgo that too and make do with Apple’s basic offering.

This returns me to the question of Syncthing’s built-in usage reporting, which I have disabled until:

  1. you confirm whether you’d like to receive the standard reports from iOS,
  2. we can tailor when it gets sent so you don’t get flooded every time the app starts, and,
  3. we (and you) consider whether we can (optionally) proxy them so we can get a view of the usage of our app that way but still provide useful data to you.

I hope I’ve understood and addressed your concerns here. Happy to chat further. Thanks again for making all this possible.

Simon

4 Likes
6

Yes. That some open source wrapper/derivative/combo is called $platform-syncthing for whatever value of $platform is traditional and non-confusing in the open source world. Platform specialisations enrich the entire Syncthing community by adding choice and breadth. If your iOS app were open source I would think iSyncthing an excellent name for it.

For a commercial project the values and drivers are different. Marketing is important to any commercial venture. Using the Syncthing name gives you exposure and marketing for free, while not contributing back to the Syncthing community in a significant way. Your app, being not available to the open source community, can’t be considered a part of that community or really a contribution to it, so being named as part of it isn’t great.

To me, it would be ideal if the app were called PickupSync or whatever, and had your company logo or something else as the icon. Inside the app, somewhere, it could and should be noted that it’s based on Syncthing, and if you present the web interface I think retaining the name and such there would be fine – the user is then interacting with a component of your work, which is Syncthing. (You can change the name and logo there as well, but you do need to retain the original copyright and author lists, in addition to your own additions.)

Or, shorter, I don’t mind some open source integration being somehow “confused” with Syncthing “proper”, because we’re all in the game together and that’s how open source works. I do mind someone confusing your for-pay thing with unknown privacy properties with us, the Syncthing community, as we are not the same.

It’s no big deal to me either way. You’re welcome to enable it and have the user stats be part of those we collect, of course after getting the appropriate user consent. You’re welcome to disable it unconditionally. You can proxy it, but then the user consent needs to specify that the data also goes to you in addition to the Syncthing project.

4 Likes
7

I think this app would be very nice to have, even if it doesn’t provide the full experience that you get on Android.

I would happily pay for the app if it doesn’t include advertisement (but would not install it at all nor recommend it if it’s ad-supported). I believe Syncthing’s crowd are fairly ad-skeptical, so I think staying away from ads (and unnecessary analytics) with this user-group would be a good idea :wink:

2 Likes
8

Why not consider a % donation from iSyncthing sales? At least it’s contributing to the running costs.

2 Likes
9

Yes, absolutely, that’s very much on the table.

10

That (revenue) is not really at the core of the issue about the name voiced here. It’s mainly the closed-source nature. For me the second problem is the limitations of such an app on ios. And personally I don’t really oppose (sensible) monetization, without adds or otherwise privacy invading practices, e.g. publishing the app with a prize tag - regardless of the Syncthing community partaking in that profit or not (though considering that is definitely nice).

3 Likes
11

My preference is simple: a one-time paid purchase, either in-app or up-front (allowing for at least a preview).

  • I’d be perfectly happy with paying $25~60 for the app, if my security could be assured. A closed-source wrapper doesn’t give me that feeling. Open-source reproducible builds do.
  • Any subscriptions means an app is immediately deleted for me.
  • Any ads mean an app is likely deleted for me, as I’d have to assume tracking is involved.

(as an aside, opening your source wouldn’t cause most people to bypass payment, as it is a royal pain to keep apps authorized on a factory iPhone without an Apple dev account. I’d rather pay for the compiled and supported product.)

Hope this anecdotal feedback helps :slight_smile:

EDIT: to be clear on my tone here, I’m happy and excited for this! Not a fan of the iSyncthing name, and I would be far more comfortable with a fully-open-source project, but if the open-source hurdle were fixed I think you’d be pleasantly surprised on how many iOS users would be willing to pay handsomly to bring their beloved phones into the secure Syncthing ecosystem. I’m certainly one of them.

3 Likes
12

Thanks, yes I appreciate it greatly. I’ve started a new thread with the new app name here. I’ll respond re the risk of open source there.