Network Connection Required

One thing I see time and again in mobile app development is bugs caused by syncing a local persistent data store with centralized data on a server accessed via API calls. An incredible amount of software development time goes into making the sync process smooth, elegant, and robust. Yet, in a mobile world with nearly-always-on network connections, we need to ask ourselves if the effort makes sense for all apps, especially for MVPs (Minimum Viable Products) of apps focused on content consumption.

Why is sync hard? Generally, it's a matter of the server and the client having radically different data store technologies. The translation that needs to mediate that disconnect can be complicated. A common scenario is for a mobile app developer to use a BaaS (Backend as a Service) like Parse. To take the example and run with it, Parse has an arguably excellent, easy-to-use API. Yet once the mobile app pulls data down from Parse, which will be in the form of Parse objects (PFObjects), he needs to translate it into a format suitable for storage in something like Core Data or SQLite.

This translation needs to happen in two directions (SQLite -> Parse and Parse -> SQLite). Further, consider the situation where the client accesses the application from two different devices simultaneously. Perhaps device one makes changes to the same piece of data as device two in their respective local data stores, and then both are synced with the Parse data store. Which revision should take priority? There are solutions to this problem (of course), and they're not necessarily complicated - but they are intricate when one considers corner cases.

Parse together with SQLite was just one example - perhaps the server-side is using an ORM wrapping around MySQL and the client-side is using Realm. Perhaps the client-side is just using NSUserDefaults... It really doesn't matter. The bottom line is it gets complicated. So complicated in fact that the well-known and highly regarded Mac/iOS developer Brent Simmons wrote a "diary" about his experience implementing sync for the note taking app Vesper.

Is it worth it? I don't believe so for the majority of apps, especially when they're in the get traction phase. It's not worth the potential bugs and it's not worth the development time. What's the alternative? Keeping the local data in a more flexible in-memory store - essentially a cache - and requiring a network connection to do any content creation.

The advantage here is that it takes away a step in the translation process. After the data is deserialized from the remote server, it can be used instantly and we're not beholden to worrying about multiple devices. The copy on the server is always the canonical copy when it's the only permanent data store. If the user tries to post a comment/post a rating when not connected to the net, we simply tell him he needs a network connection. Keep it simple. It's not ideal, but in a content consumption app, it's probably a minor annoyance rather than a deal breaker.

This doesn't work for apps that feature long form content creation (such as a note taking app like Vesper - or perhaps a video sharing app). They need something robust that ensures even if the network connection dies the user will not lose his work. But for apps that are all about consumption of content not produced by the user, or where the user's data input will never be more than a short blurb, perhaps the syncing madness is unjustified. I rather the user have the risk of once in a blue moon losing a star rating than be subject to a crash-prone MVP.

It goes without saying that as apps move from the MVP phase to the "we have more resources" phase, syncing becomes a much larger priority. The point here is that early on, sometimes syncing is just too much of a distraction.