Creating apps that work without the Internet

We've become a bit lazy in the United States when it comes to developing apps. It's nothing for us to stuff in a healthy dose of remote content downloads for our games, mobile ad networks for our full-screen videos, analytics so we can track user activity, and other fat-pipe code that works well in the land of gigabit connections.

But did you know that almost half of the nations in Africa have experienced internet shutdowns in the past 5 years, and only 24% of people in Africa even use the internet? Plus, about 1.6 billion people still live in places where mobile broadband networks (3G and 4G) are not even available. They have to chase down the distant wifi hotspot to even get into the app store.

With that being said, it can be a challenge for app developers trying to cater specifically to markets where Internet connectivity is scarce. They have to think about how to make their app "data-light" but still worthwhile for users with low internet speeds and intermittent connections.

20-year old Nigerian tech prodigy Elvis Chidera is an engineer at Careem. He has developed several apps to specifically serve African markets from a very young age. He taught himself to code on a Nokia 2690, and has worked with an MIT backed startup dot Learn. We recently chatted with Elvis about some of the challenges of building data-light apps for users with low internet speeds, but high expectations.

ADM: In which cases might developers want to consider making their app data-light, globally i.e. outside of developing markets?

The reality is that data-light apps can lead to a significantly better experience – even in developed markets. Because your app will be using less data, it will be blazing fast on a good internet connection.

Sometimes the internet connection is limited even in developed regions and you don’t want your users to be locked out when this happens.

ADM: What approach would you advise developers to take when embarking on making a data-light app?

If you are working on a new app right now, then you should actively factor in data size while building the app. You should ask questions like, do we really need to add that 8MB splash screen video into the app build?

By actively thinking about data size, you will end up making decisions that don’t unnecessarily bloat the app. For example, rather than adding the heavy splash screen video into the app build, you can download the video on demand only when you detect that the user has a fast internet connection. For users on a slow connection, they most likely care more about accessing the core functionality of your app than that fancy video.

If you have an existing app, you could do one of two things:

1. Create a light version of your original app: I don’t recommend this approach as there is an added maintenance cost. You have to maintain two apps which would be difficult to do if you work for a small company.

2. Optimize the original app: This is my recommended approach as there usually is no long term overhead.

Whether you choose to build a light version or optimize the original app, the processes are similar. You should first start by profiling the app to determine what are the biggest components and what is the quickest win for your team.

Usually, the whole team including non-developers need to be involved in the effort as building a data-light app can mean settling for a lower resolution image or getting rid of a big feature that largely.

ADM: Are there any specific tools, integrations or coding languages you’d recommend that would help with this?

The good thing is that most of the tools you will need are free and/or open source. Two important tools are:

1. Image compressing tools like TinyPNG. There are a hundred other image compression tools which you could easily use.

2. A tool like Proguard (Android specific) to optimize and minify your codebase.

You can choose to split your app resources based on device features and distribute them separately in different app builds. On Android, this can be easily achieved using App Bundles or ABI splits.

Also, you can use a lint tool to analyze your project and detect unused code or resources. You will be surprised how much data you can save by following this simple process.

The above tools are only used to reduce the size of the app. But building a data-light is not about the pre-install experience alone. The post-installation experience is equally important; your app shouldn’t be data hungry.

Whatever data that is exchanged between the app and your backend needs to be heavily compressed. For example, the team at Facebook are using LZMA2 compression for their Facebook lite app because of its compression ratio and low resource usage on the device while decompressing.

Some processing, such as image resizing, should be shifted to the server. There is no need to send a 5000x5000 pixel image to a device that has a very low resolution. Instead, you should resize images based on the user device. This saves both money and battery for the user.

ADM: What would you say are the main challenges in making apps that work without the Internet, or that only require low-speed connections?

I think getting used to saying ‘no more’ is often challenging. You get so many awesome ideas to bloat the app, but you can’t add the majority of it because you are restricted by data size.

Quoting E.F Schumacher, “Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius—and a lot of courage to move in the opposite direction”.

Also, teams might not be motivated to work as hard as possible. Often, they simply don’t know the impact their app data-light will have because they live in a completely different market. Therefore, it helps to share the statistics and help the team understand why their work is important.

ADM: What would you say are the main limitations that result in a data-light app’s capabilities?

Usually, data-light apps don’t come with all the bells and whistles available in a regular app. For example, many don’t come included with beautifully crafted animations or high-resolution images. These are meant to delight the user and are usually not available in a data-light app.

There are ways to compensate for this. For example, you can use and reuse a simple set of animations or offer users the functionality to load images in their full resolution.

ADM: Are there any industries you would say should particularly consider making their apps data-light? Why?

I think every company can really benefit from having a data-light app. Being restricted is bliss and forces you to focus on only the important functionalities that matter.

One category of apps that might be exempted are apps built for power users like developer tools, hi-resolution games, etc.

Elvis Chidera is an engineer at Careem