I have been following Brent Simmons’ diary on Vesper sync. It’s particularly interesting to me, because I am developing my own sync framework, and it helps to see how other developers solve similar problems, and possibly catch blind spots in my own approach.
In general, I haven’t been particularly surprised by anything in the first six parts. It seems to be the standard approach most take when developing with a central server, and this approach is already available to Core Data developers via pre-packaged solutions like Wasabi Sync, Simperium, and the Dropbox Sync API.
There is nothing wrong with this approach at all. In fact, I would say it is preferred where it fits your app’s model. A central server vastly simplifies the problem of sync, and should be the first place you look when considering adding sync to your app.
But it isn’t a solution to every problem. There are definitely some downsides to centralized sync, and it is important to understand what they are before you jump in.
The first problem is that it can be expensive, depending on what you are syncing. For a list app like Vesper, which is mostly syncing text and some attachments, it is not a problem. For media-intense apps like Yojimbo from Bare Bones, it could become an issue, especially if you are charging a one time fee for purchase of the app. You have to keep in mind you are effectively going to be hosting a copy of all of the data of all of your customers. That could be a lot of data, and a non-negligible expense. (Yojimbo syncs via Wasabi Sync, but Bare Bones require a subscription to cover the costs of the sync service.)
Second, you are going to have to develop a server. These days that is a lot easier than it was, with cloud services handling the difficult hardware interactions and scaling, and scripting languages making the development approachable. But it is still a service, and you have to maintain it. When it comes time to upgrade your app’s model, you have to do that in two places: in your client app, and in the cloud. If you listen to someone with plenty of experience in this area, like Marco Arment, it sounds like quite a responsibility for a solo developer. Enjoy your next vacation, because it may be the last you enjoy.
Third, you are going to have to duplicate your whole data model in the cloud. With a four entity model like Vesper’s, this is no big deal, especially because the model is so simple it is impossible for it to ever become invalidated by conflicting changes. But if your model has 20-30 entities, and requires conflict resolution more advanced than simply picking the most recent property value, a custom server might not be the simple solution it first appears.
(The Vesper data model is about as simple as they come. Conflict resolution is typically made difficult by relationships, and the relationships that exist in the Vesper model can be merged automatically. The example app in the Ensembles project, Idiomatic, has a very similar model. Sync was added to that project with less than 50 lines of code, and no custom conflict resolution.)
Once again, I am forced to conclude that there is no one-size-fits-all solution. What works for Vesper will work badly with a more complex data model, or an app which has to store much more data per customer. Building your own server is the right solution for many apps, but by no means for all apps.