How To Reduce Your App’s APK Size, Even If You Use Realm

Slim apps mean faster downloads which means happier users

Bapusaheb Patil
Jul 23, 2018 · 4 min read
Image for post
Image for post
Pic from the official website:

This article is for the developers who’ve heard of or have been using Realm Database in their Android apps.

This is a tutorial that aims to help you set up your Android project in a way that takes less space than it normally would.

For this article, I’m gonna take my app, SilverScreener, as a case study.

You can find the source code on Github here:

A Time Before Realm…

Let’s go back to a time when I’d implemented a normal, boring SQLite database in my app. The APK size of the app was 4MB.

But as most of you know, writing a SQLite database is quite boring and consists of a lot of boilerplate code. Changing the database schema meant making a lot of changes in other parts of the code as well.

Enter, Realm

When I first heard about Realm from someone on Reddit, I was blown away by how easy it was to set it up and get a database up and running, one that even came with cloud syncing functionalities! It was easy to make changes to the database schema without having to change much of the code I’d already written.

It was super easy and quick to perform CRUD operations. Every single line of Realm code was effortless to read and understand, even for a newbie. It was hassle-free to work with threads as well. Database encryption? Just write two extra lines of code and you’re done!

Now, of course, this article is neither an advertisement for Realm nor a tutorial for Realm. So let’s move on to the problem at hand with using Realm.

What’s Wrong With Realm?

Once I added the dependencies for Realm in my app, set up Realm, and removed all SQLite code, my app’s APK size increased from 4MB to 12MB! Now, for a simple app like mine, this difference might not be a lot. But what if your app had a huge database with a lot of entities? The increment would be much higher.

Image for post
Image for post
SQLite vs Realm: APK size comparison

The Cause

Android phones have processors that support the following architectures:

  • x86
  • x86_64
  • armeabi-v7a
  • arm64-v8a
  • armeabi (Obsolete)
  • mips (Obsolete)
  • mips64 (Obsolete)

When you build your app’s APK, the Realm library gets compiled for all of these architectures. That’s why the APK size is so huge.

Your APK that’s being built by Android Studio has native Realm code for all of the above-mentioned architectures. But your users’ phones only need an app that has native Realm code for their processor’s architecture. They don’t need an app that has Realm compiled for all architectures. That would only increase the size of the app they’d have to download from the Play Store.

The Solution

This can be done in two ways:

  1. ABI Filters (less effective)
  2. APK Splitting (more effective)

For brevity purposes, in this article, I’ll cover only APK splitting. Here’s what it really means:

APK splitting is building multiple APKs, specific to each architecture, for your app.

This can be done in the app-level build.gradle file of your Android project.

Since the armeabi, mips, and mips64 architectures are now obsolete, let’s focus on building separate APKs for x86, x86_64, armeabi-v7a and arm64-v8a architectures.

If you’re doing this for an app that you need to upload to the Play Store:

Since multiple APKs will be generated, the version codes for all of them need to be different, because the Google Play Console doesn’t let you upload APKs with the same version codes.

So, if your current version code for the single APK is 1, the next version of your app with multiple APKs shouldn’t be 2 (x86), 3 (x86_64), 4 (armeabi-v7a), and 5 (arm64-v8a). That’s a bad practice and would be harder for you to manage.

Instead, it’s better to have a huge decimal number and assign “codes” to each architecture, as follows:

  • x86: 0
  • x86_64: 1
  • armeabi-v7a: 2
  • arm64-v8a: 3

Then, your version codes for your app would look something like 2000 (x86), 2001 (x86_64), 2002(armeabi-v7a), and 2003(arm64-v8a), and the next version codes would be 3000, 3001, 3002, and 3003. You get the idea.

Now, let’s get to the practical part and dive into our app-level build.gradle file:

Here’s how your app-level build.gradle file, enabled with APK splitting should look:

Now, generate your new APKs, and you should see a significant decrease in the size of the individual, architecture-specific APKs!

You can upload the 4 APKs generated onto the Google Play Console for the same release of the app since they all have different version codes.

The users will only be able to download the version of the APK from the Play Store that’s specific to their phone’s architecture, all of it happening behind-the-scenes, thanks to the magic of the Google Play Console.

The best part? The APK size for my app, SilverScreener, was now 3.1MB!

Here’s a comparison of before and after APK splitting:

Image for post
Image for post
SQLite vs Realm vs Realm with APK Splitting: APK size comparison

The Takeaway

Realm is a great database, but it’s also one that increases the APK size significantly.

Go ahead, start using APK splitting in your app without compromising the file size.

Better Programming

Advice for programmers.

Bapusaheb Patil

Written by

I tell stories, design things & build stuff. Storyteller. PSM I. IDF Certified UX Designer. Google Certified Dev. I work here:

Better Programming

Advice for programmers.

Bapusaheb Patil

Written by

I tell stories, design things & build stuff. Storyteller. PSM I. IDF Certified UX Designer. Google Certified Dev. I work here:

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store