How to Build an Offline-First Mobile App

Introduction

It’s no longer enough for apps to only work when they’re online.

When your mobile app loses connectivity and fails to synchronize data seamlessly, users abandon your app. A 2020 Google study found that a slowdown of just 1 to 3 seconds caused a 40% loss of users, and an Amazon study from more than 10 years ago found that every 100ms of latency cost it 1% in sales. Imagine the consequences today.

That’s why apps today should be built with an offline-first approach, ensuring an experience where the app keeps functioning and syncing data, regardless of connectivity.

If you’re building apps for use by consumers, offline-first delivers a better experience. And if your business relies on frontline employees using your app — whether they’re in retail, logistics, food services, or manufacturing — consistent connectivity is not guaranteed, and you too need to build an offline-first app.

Whether you’re a single developer working to stand up your idea or part of a larger team shipping your latest release, you already know that building an offline-first mobile app is filled with a number of challenges.

How do you ensure a consistent user experience when a connection drops? How do you design and architect for full connections, dropped connections, poor connections, and no connection at all — all in the same app?

How do you ensure that your data stays synchronized, your users can continue to work, your data stays secure, and your app just keeps working, even as connectivity changes?

What is offline-first?

Offline-first is a development principle that emphasizes designing apps, from the beginning, to work without an internet connection. With offline-first, data is synchronized between multiple devices, and your app keeps working, regardless of connectivity or connection speed.

Offline Apps That Work

Wi-Fi goes down, your flight takes off, or you’re in an Uber moving through a city and flipping from 5G to 4G to LTE. Whatever the reason for a change in connection, your mobile app will start to lag, stop syncing data, or cease to load. You’re stuck waiting for your phone to reconnect and your work to resume.

When dropped and slow connections hobble an app, it kills productivity — and revenue. That’s why in 2015 Facebook introduced 2G Tuesdays — an initiative where engineers’ internet speed was massively reduced so they could experience what many of their actual users do every day: slow, unreliable service.

Consider that, even beyond the dreaded dead zones that exist in warehouses, schools, and offices, in early 2021 30% of states in the U.S. still have less than 90% coverage for mobile broadband. For businesses with large frontline workforces that rely on mobile apps to
do their work, or that would benefit from replacing manual processes, this has significant implications for app architecture. That’s why most modern apps — whether used by your employees or your customers — are increasingly built with an offline-first approach.

Benefits of Offline-First

An improved user experience is just the start.

The benefits of apps that work well offline are clear. For consumer apps, users have a better experience. They can continue using your app through interruptions and outages, and may enjoy better performance when apps are online.

Outside of the consumer space, businesses invest in apps for their workforce with the expectation that the app will be widely adopted and boost worker productivity.

But if an app doesn’t sync correctly, or frequently fails because of lost connectivity, then workers may abandon the app and revert to whatever method they were using to fulfill their tasks before the introduction of the app.

One of the defining features of an offline-first app is a local store of data, allowing for reads and writes directly on the mobile device.

Offline-first apps:

Run faster. An app with server-based data must make a round trip to the server with every request. Accessing local data has near-zero latency, so an app that only calls on the client server for data when absolutely necessary is much faster to respond.

Better conserve battery life. The less CPU, screen usage, and bandwidth used by the app, the better the battery usage. Battery usage
is another key factor impacting app adoption and user retention, and is important for both consumers and frontline workers who rely on a device to do their job.

A good user experience — a significant factor in positive app reviews — creates a positive feedback loop of further app usage. According to a study by Apptentive4, users are twice as likely to download an app that has five stars versus those with three stars.

Have better user adoption and retention.When an app runs faster and efficiently uses battery life, users are more likely to continue using it for the long term.

Design Concerns With Offline-First

The essential concepts of designing for offline-first are easy to understand:

° Assume the user is offline.
° Offer a seamless UX experience to the user when the app does

go offline, making sure they can continue to use critical functionality. ° Cache data locally and sync that data when the app reconnects.

But implementing these concepts can be complex, expensive, and time-consuming. And only a successful implementation will satisfy your users.

Mobile apps often replace current processes, meaning adoption isn’t a given. Poor implementation of your mobile app — if it fails to sync data correctly or is non-responsive when connection drops — will limit the adoption of your mobile app and the expected productivity gains of your workers. If your app is built for customers, they may leave negative reviews and fail to be retained.

So where do you start? Before beginning your transformation to offline-first, consider these four key factors:

1. Functionality: When your app disconnects, how will you ensure continuity of workflow so that the user’s work is minimally interrupted and their data is not lost? What will you allow the user to continue to do while offline, and which functionality will you consciously limit, such as search or uploading large amounts of data?

2. UI/UX: How will you let the user know what does and does not work when the app is offline? If the user reconnects and there are there are data conflicts, will you give your user options to resolve those conflicts? If so, how?

3. Code: When is it safe to update your application? How do you handle user authentication? Will you keep the user authenticated and reauthenticate when they reconnect? Will you log them out of the app?

4. Data and data synchronization: This is the most difficult question with offline-first: How do you handle data synchronization and guarantee that key business or user data is not lost? How will you ensure a consistent view of data across multiple platforms, users, and devices when connectivity is inconsistent? How will you handle conflict resolution when a device comes back online? You also need to consider data sync when building real-time and collaborative features in your apps.

In this article, we’ll focus on the critical issue of data and data synchronisation.

How to Design for Data Synchronization

Building the data and data synchronization solution yourself is the less common choice since it involves a major technical effort in both creating a local datastore on the device, and syncing and resolving conflicts with the server when reestablishing a connection.

To begin, you must select and implement your device-side datastore.

There are numerous options. The simplest and fastest is to store data in a cache on the device. This assumes that you’re comfortable defining a schema for your data and don’t expect your data to be queried very often. Even a JSON format, structured as it is, can be difficult
to navigate. Caches also often have to be updated as a whole, even when small pieces are outdated, leading to overuse of the device’s bandwidth and battery.

A cache might be appropriate for simple apps that don’t require merges or conflict resolution. Your app can assume that the server is always the source of truth and overwrite any local data when full connectivity returns.

But most applications are more complex and will require a local database. Databases used on mobile devices have unique requirements:

They must have a lightweight storage system, as storage space is limited.

They require low memory (and energy) consumption.

They must be cross-platform compatible (iOS and Android).

There are several traditional relational databases that meet some but not all of these requirements.

SQLite is a popular choice, but due to its design, performance can be an issue. Core Data is another option. It consumes more memory than SQLite, offset by its greater performance, but is only available for iOS apps.