Offline app architecture: Why you should build offline-first apps

Why design Offline-First Apps?

Offline app architecture: Creating an offline experience is not something that most developers consider when designing an app. Since smartphones allow users to access the internet from any location or at any time so long as the app communicates to the server, the need for making the app work offline might seem insignificant.

However, mobile networks aren’t always reliable since the strength of coverage varies from one place to another. Therefore, mobile apps should be equipped to handle issues related to network failure and latencies. That’s where offline architecture can make a difference.

Developers are shifting to the ‘offline-first’ approach whereby an app is built to function even without a network connection, thereby providing users with the opportunity to sync their data, get updates and more. Offline architecture also offers advantages such as reducing roaming costs when travelling, minimizing the data usage on maps, saving battery power as well as providing quick loading time.

What are the different approaches to developing offline app architecture?

The primary assumption in offline-first architecture is that the data is local. However, the way the data is stored, synced and accessed can vary, depending on the server type, architecture and device. The three commonly used approaches are: 

• Storing data offline: Caching is the most straightforward approach for helping users access data offline. It involves storing data on a local server or browser from where the device can access it, providing a better user experience in a short time. 

• Edit offline & sync online: Under this approach, users can edit data offline, marking changes in the object. Once the network connectivity is back, the changes get synced through a push and pull operation. 

• Users can edit other users’ data offline: Here, the data sync happens automatically without manual intervention. While changes are transferred in minor binary format between the device and server, only some operations are synchronized after assessing the information intended for a specific user. The system resolves conflicts on its own. 

Offline-First Best practices to communicate app with the backend server

Among the offline architecture strategies that help the IT communicate with the server are:  

Pushing data in –

In this strategy, the server sends a signal, usually a push notification, to the user to alert him that new data is available for download. On receipt of the notification, the client can refresh the local database to get the new and updated version. It works best in situations where the server is the primary source of data, and the client application is a data consumer. 

• Synchronizing databases – The server and the app try to track every change to ensure that the data on both sides are equal. The app can be used to make changes even in the offline mode, and soon as the internet connection is available, data is sent both ways to try to create a new shared state that is equal on both sides. 
• Prefetching – Here, the application tries to predict what the user will use and sends and stores that data in the cache whenever the network connection is active. The application works in the offline mode, but the syncing takes place only when there is a fast network available. It works well for apps that require significant data downloads such as music, videos, images or maps. 

Push-notification based data synchronization 

• Notifications as the only channel for exchanging data – Instead of sending large amounts of data to the application, the relevant information can be sent inside a message that will be pushed to the cloud by the backend. The user gets to decide whether he needs to download the data from the cloud. 
• Notifications as a request to download data – When data is stored on the backend server, instead of sending a message with details of the data, a notification will be sent to the user, informing him that new data is available.  

Database synchronization 

• Using existing databases that self-synchronize – For a new project where migration from the local database to a remote one becomes a challenge due to restrictions or limitations, some existing solutions such as NoSQL or SQL databases that auto-synchronize can simplify the process. 
• Self-developed synchronization procedure – Where auto-synchronization doesn’t work, the option is to design a custom synchronization procedure where you have control over what data, and how much of it, is synchronized. It involves making decisions on how to initiate the process of synchronization, how it will synchronize (time-based, event-based or periodic), how to minimize conflicts between the remote and local keys, and more. 

Prefetching data 

• Based on user behavior – Based on tracking and analyzing user interactions, the application will predict what the user might want next. Using algorithms based on AI solutions, the backend will push data via a notification. This strategy works best for applications such as maps and video/music players that rely on recent user actions to predict what data might be required next. 
• Based on connection speed – Since automatic downloads of huge files using the mobile network should be avoided as far as possible to conserve battery, loading can be delayed until Wifi is available. Alternatively, data can be loaded, using Wifi, based on predictions of the user requirements and cached until future use. 

Caching 

In some cases, the user might revisit recently accessed data. Here, multiple levels of caching from the backend can be considered in the absence of any other synchronization strategy. While the most recent data can be cached in the device memory, additional portions of visited data can be stored using a disk-based cache. 

What to keep in mind when selecting architecture for offline apps? 

Asking the following questions will help in selecting the right type of offline architecture. 

• What strategy should you use, and where will you cache data? 

• Is the method of caching reliable? 
• How will the architecture handle concurrent data? 
• How will data conflicts be resolved? Are there enough safeguards in place for it? 
• How will the architecture deal with changes in network connectivity? 

Recommended tools and frameworks for developing offline-first apps

High-level tools 

• Progressive web apps – The benefit of PWAs is that they blend the best of web and native apps by combining discoverability with power. As a result, the user gets the experience that is near that of browsing a website. Moreover, the more the app is used, the more native-app like capabilities it acquires. While Google is the most well-known proponent of PWAs, several other Progressive Web apps are also being built. 

• Polymer AppToolbox – A part of Google’s Polymer Project, this app toolbox includes components tools and templates. As a progressive enhancement, it also uses service workers to offer offline caching.
• Couchbase Mobile – Another set of tools that allows the offline-first approach, it includes Couchbase Lite that provides an API for storing data locally on Android and iOS platforms and Couchbase Sync Gateway for replication of data between the database and server. 
• Hoodie – An open-source project, Hoodie offers a complete backend solution for mobile apps, including tools for developing frontend code, which can be plugged into the API to get the app ready. It was one of the first frameworks to adopt the approach of ‘offline first with no backend architecture.
• Ionic – Ionic allows developers to use Angular for creating hybrid apps. The apps can be deployed on iOS and Android with PhoneGap or Apache Cordova. Alternatively, you can even deploy it to the browser as a PWA. For extending the offline-first capabilities of the app, PouchDB can be used. 
• Mapbox Mobile – An open-source SDK, Mapbox allows developers to add detailed maps as well as turn-by-turn navigation features that work offline. 

• Realm Mobile Platform – This platform offers real-time sync between the embedded Realm Mobile database in the app (iOS and Android) and the Realm Object Server. Soon, this functionality will also be available for Xamarin and React Native apps. 

Low-level tools 

• Service workers – The latest and most significant development in Offline-first, the Service Workers approach aims to provide a browser mechanism that allows caching content and assets that can be used offline. While AppCache was the first tool that worked towards providing it, there were numerous issues, which Service Workers are aiming to solve with the new approach.
  They intercept client requests to return cached results when offline. Progressive Web Apps depend heavily on Service Workers for offline-first. Google Chrome, Opera and Firefox currently support service Workers, while Microsoft Edge also plans to extend support soon. 

• localForage – In some cases, where there is more merit in having an actual database instead of Service Workers, localStorage, IndexedDB, and WebSQL are more helpful, especially with consistent implementation of standards by browsers. However, the challenges in browser support and implementation make it challenging to use these technologies. That’s where localForage steps in to provide a unified API to support localStorage, IndexedDB, and WebSQL. 
• PouchDB – Although it cannot compete with localForage in terms of being lightweight, PouchDB offers additional features that make it worth the increased overhead. Besides allowing data syncing with anything that implements the CouchDB Replication Protocol,  including Apache CouchDB and IBM Cloudant.
  It allows direct reading and writing data on the device, which is then synced to the cloud as soon as internet connectivity is available, thereby making the process of creating, reading, updating and deleting exceptionally fast as the data is all accessible locally. PouchDB has the capability not only to run in a web browser but also in any JavaScript environment such as Node.js. Besides, it runs in Ionic (for hybrid mobile apps), Electron (desktop apps) and Tessel (for IoT apps). 
• Cloudant Sync – For building native mobile apps with offline-first, Cloudant Sync is ideal. It comes in separate versions for iOS and Android. Cloudant Sync has different APIs compared to PouchDB, but the libraries can store data locally on the device and sync when CouchDB Replication Protocol is implemented. 
• Cloudant Envoy – When using PouchDB or Cloudant Sync for creating databases, usually, each user has a local database on their device that only they can replicate in the cloud. It works well so long as each user’s data is well segmented in a one-database-per-user pattern. The issues crop up when you need to allow a user to access another user’s data or when you try to create aggregate queries that need to access data from multiple users.
  Here, Cloudant Envoy helps to simplify the process by providing the benefits of a single database per user while eliminating the disadvantages of the pattern. It achieves this by providing the illusion of one-database-per-user to the database (PouchDB or Cloudant Sync) on the user’s device while storing all the data in one database (either CouchDB or Cloudant). Moreover, it provides access control that limits who can access what type of data. 

Conclusion

In the end, good user experience is essential for a mobile app, and the unreliability of network connectivity and low battery constraints often result in poor user experience, causing frustration and disinterest among users. By creating an app that provides an offline experience that replicates the online one, your business can gain a competitive advantage.

While it will require some initial investment towards backend and frontend development, it is well worth the cost and effort to enhance user experience. At TechAhead, our development team is geared to take your app to the next level by helping to implement the ‘offline-first’ approach.

With several years of experience as a mobile app development company for clients, including progressive web apps and hybrid solutions, our developers are skilled at employing the tools that enhance the offline-first experience.