Three Approaches to Offline-First Development

One of the fundamental differences of an offline-first architecture is that the app always assumes data to be local. How that data is stored, accessed, and synced can vary. The following are three development approaches that range from simple to robust.

This is an excerpt from The Offline First Approach to Mobile App Development, in which we discuss the advantages of an offline-first development strategy for both developers and engineering managers. It covers the challenges of developing robust offline functionality in mobile apps and common technology solutions.

1. Caching

The most common approach is to simply cache data locally. Caching stores data for read access. This gives users access to data on their device, renders the UI, and provides a predictable user experience based on a snapshot in time. Caching can provide a smooth offline experience and faster performance—depending on the app, this may be enough to fulfill offline-first objectives.

Get more development news like this

However, many apps are not simply read-only, but also enable data entry and manipulation. The major downside of caching for the user is that he or she is not able to update cached data, and is working in a limited capacity offline. A downside for the developer is that many caching solutions do not support queries, event handling, or server-side business logic, which requires the developer to write their own. Another common downside to caching is that it’s difficult to know when a cache is invalid and data should be obtained again. If a single bit in a large cached document is different, the whole cache may be thrown out due to the lack of fine-grained detail about the freshness of portions of that cache. It’s also often impossible to tell if a cache is out of date without downloading its entire contents from scratch, leading to overuse of a device’s radio and rapid battery drain.

2. Manual Replication

This custom coded approach takes a step beyond caching to give read and write ability to the mobile client. It allows users to manipulate data while offline by marking objects as changed. When a connection becomes available, all changed objects are sent in full by triggering a push and pull operation that pulls the changed objects from the server and pushes the changed objects from the device.

However, the method is unpredictable and can fail for any number of reasons stemming from the app, server, mobile network, or other points along the way. Because data is stored in JSON, ORM (serialization/deserialization into native objects) is required, which adds latency and the likelihood of conversion failures. More importantly, because the push and pull operations are independent, they can include changes to the same object. This forces the developer to worry about conflict resolution and its impact on app performance and user experience. In essence, this creates the same time-consuming headaches for developers as discussed above.

3. Realtime Data Sync by Platform

In this model, data sync is not manual, but automatic, sending changes in realtime. A highly efficient data synchronization protocol passes only the marginal changes in compressed binary format between device and server-side layer. Further, rather than sending complete objects, devoid of what specifically changed, this model focuses on synchronizing the specific operations along with the data. This additional information captures exactly what the user intended, allowing the system to automatically resolve conflicts, leading to predictable synchronization without manual intervention that impedes performance.

The Realm Platform makes this approach feasible by using a platform architecture that handles data synchronization between device and server. Data is stored in a transaction-capable database on device and a lightweight platform layer sits on the server. When the user updates data on the device, the local database and the server-side layer work as one to handle complexities of network state and resolve conflicts in realtime before writing the updates to the server-side database. Conversely, the platform manages data pushes from server to client, as well as broker messaging and collaboration functionality. The platform can also take care of such things as user presence, state events, server errors, and JSON decoding.


Realm’s architecture handles data synchronization between device and server.

Next Up: Offline-First #4 – Eventually Consistent: A Mobile-First Distributed System

General link arrow white

About the content

This content has been published here with the express permission of the author.

Realm Team

At Realm, our mission is to help developers build better apps faster. We provide a unique set of tools and platform technologies designed to make it easy for developers to build apps with sophisticated, powerful features — things like realtime collaboration, augmented reality, live data synchronization, offline experiences, messaging, and more.

Everything we build is developed with an eye toward enabling developers for what we believe the mobile internet evolves into — an open network of billions of users and trillions of devices, and realtime interactivity across them all.

4 design patterns for a RESTless mobile integration »