Ever since I released Atsumeru the number one feature I wanted to add was syncing. Mainly to not being restricted to using Atsumeru on the iPhone I always have with. Occasionally it would be great on the iPad as well. Besides that, a Mac version of the App is also on the very top of my list of features I want.
Originally, I wanted to be able to bring syncing shortly after the release of iOS 8, but as it mostly goes with deadlines and estimations that wasn’t meant to happen. On the one hand due to other fixes and features I needed to work on first, and on the other hand due to the fact that I became father around the same time, which took more of my available time as expected.
When working on an App besides the normal day-to-day work it becomes extremely important to use the time wisely and as efficiently as possible. This includes choosing technologies that are easy to work with and fast to iterate upon. Restricting oneself like this also brings the danger of becoming stagnant, losing the connection to what is new. I don’t want to risk that of course which makes me implementing new features in Swift instead of Objective-C were it makes sense. For example, extensions are a perfect place to do so as they are nicely encapsuled from the main App.
I looked into several options to realise data synchronisation for Atsumeru and would like to quickly go through my considerations. Finally I will explain on which one my choice fell and why.
Core Data in iCloud
Since Atsumeru is already using Core Data to save meta information about the user’s image library, this seemed to be the lowest hanging fruit. However, research quickly brought a lot of reports to the surface with complaints about Core Data in iCloud being quite unreliable.
There were a few people using it without problems as well, but the sheer amount of negative reports coupled with the anouncement of the new CloudKit SDK was enough to make me dropping this option very quickly.
I have been very excited about CloudKit when it was announced during last year’s WWDC. However, since it was very new my fear of it becoming another disappointment in the long list of subpar Apple web services outweighed the initial excitement even though first dives into CloudKit were quite promising.
As it is common with Apple’s SDKs, they can only be used from Apple hardware. Using CloudKit would make it necessary for me to still look for another solution to share content with the web. The CloudKit SDK can also only be used for Apps that are distributed through Apple’s own App store.
Ensembles sounds extremely interesting and I would have probably been my number one contender. It is a backend agnostic framework with support for major backends like iCloud, CloudKit and Dropbox.
But it comes with a price (rightfully so, I suppose) which unfortunately disqualified it for use in a low-income side project.
Parse (and similar other web services)
You really only are in charge when owning the full stack, of course. But creating my own web service also comes with a huge cost both in time and money as servers need to be maintained and paid for.
Services like Parse take a lot of these efforts away from a developer, but when used as a backend for syncing it is not enough. All the syncing logic and especially conflict resolution would have been necessary to be done by myself, which is unfortunately not feasible time-wise. Additionally, data saved in Atsumeru can become rather huge and these kind of services typically charge a lot of money for storage.
Dropbox, being a rather popular service, made it a very attractive option for users to store there data. Atsumeru can use Dropbox for sharing images publicly to the web. This can be especially useful when one would like to include animated GIFs in a post to an online service where it is not natively supported. Twitter, for example converted animated GIFs to static images until about a year ago. They now support animated GIFs, but only up to a file size of 2 MB and forcefully convert them into videos, which makes resharing of animated GIFs ugly. When creating a share link to an image on Dropbox, this problem doesn’t occur.
Having this share feature already in Atsumeru made the Dropbox Datastore service pretty attractive. It’s SDK is very easy to integrate and work with and it conveniently does all the heavy-lifting syncing. A very important point for a small-scale project such as Atsumeru.
I would have gone with CloudKit if Atsumeru would already generate more income, but that’s unfortunately not the case. It would be a bit easier to use since there wouldn’t be the necessity for the user to login with the additional account like it is the case with Dropbox. But the freshness of the CloudKit SDK, which brings the element of uncertainty about its reliablity into play as well as as the limitation of being able to only distribute the planned OS X App through Apple’s App Store lead me to decide against it in the first round.
My choice fell on the Dropbox Datastore and Dropbox Sync SDK to integrate the syncing feature in Atsumeru. The main reasons where the ease of integration as well as the popularity that Dropbox is already enjoying, even though I initially wanted to avoid users having to enter additional credentials. But given the development time saved I figured it is better to have syncing this way rather than keep going forward without any syncing in the App.
By the time I finished the basic implementation of syncing (and it was actually working pleasingly well), Dropbox announced they will drop support for the sync and datastore APIs and drop it completely by the beginning of 2016. That’s currently the main reason why there is still no syncing available in Atsumeru. Taking this into account I decided not to release the version with the Dropbox sync, but instead go back to the drawing board.
I am probably going to implement a data sync based on Apple’s CloudKit. I have started the plans for this already, but will wait until this year’s WWDC to see what announcements Apple has to make which might be interesting.