How To Reduce Your App’s APK Size, Even If You Use Realm
Slim apps mean faster downloads which means happier users
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.
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.
Android phones have processors that support the following architectures:
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.
This can be done in two ways:
- ABI Filters (less effective)
- 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.
mips64 architectures are now obsolete, let’s focus on building separate APKs for
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:
Then, your version codes for your app would look something like 2000 (
x86), 2001 (
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
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:
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.