Make your React Native app 3x smaller with one simple command

Krzysztof Magiera
Software Mansion
Published in
5 min readApr 26, 2019

--

Title photo credit @Alexas_Fotos

First, I’d like to apologize for a clickbaity title but I believe the important cause of saving your user’s time and device storage is worth the attention. To make up for that I’ll go straight to a short summary of how to achieve what is promised in the title.

In this post we show how to reduce the size of your React Native Android app, or to be more precise, the size of what your users need to download and then keep on their device when installing or updating your app. This can be achieved thanks to a new file format introduced by Google last year called Android App Bundle. Thanks to this new format Google Play Store is able to prepare a customized version of your application binary (APK) depending on the user’s device characteristics such as CPU architecture or screen pixel density. Then, to serve such a binary to the user instead of distributing the fat version of the APK you’ve submitted to the store. This makes a huge difference especially in case of React Native app which ships with a relatively large amount of native (c/c++) libraries (main contributor here is the JavaScript runtime that is bundled with the app). As of version 0.59, React Native supports four CPU architectures: armv7, arm64, x86 and x86_64 — this means that the APK you submit to the store contains four builds of Javascript runtime out of which only one can actually be used. It also means that if you are upgrading to 0.59 your APK size will grow by roughly 10MB. In this article we show how to use Android App Bundle with your React Native app in order to shave off at least 20MB from the compressed size of an APK your users download.

Migrating to Android App Bundle

If you’d followed React Native’s official guide about publishing your app to Google Play Store you are likely creating an APK file using the following command:

./gradlew assembleRelease

The above command would output the APK file under android/app/build.outputs/apk/release/app-release.apk which you’d then submit to Google Play Store. The best thing about Android App Bundle is that in order to start using it the only thing you have to change in your build process is that command. Instead of using` assembleRelease` you should now run:

./gradlew bundleRelease

Now instead of an APK file being generated we will get a new file with an extension .aab located under android/app/build/outputs/bundle/release/app.aab— this is the file you want to submit to Google Play (either manually or using Google Play API). Here is more or less what you should expect when publishing an update using Android App Bundle on top of an old app that’s been submitted as a single APK:

Android App Bundle format allows for the download size to be significantly smaller

Are we done here?

We are almost there — for the above to work we need to make sure your app uses App Signing by Google Play feature. Chances are you’ve already migrated your signing configuration as that feature is available for quite a while. Also, if your app has been submitted for the first time after September 2017, it is likely that you’ve purposefully or not enabled that feature already. In order to check that, visit Google Play Console and navigate to “Release management > App signing” section in your app’s settings there. If App Signing by Google Play is enabled you should see the following text at the top of that page:

This is what shows up if your app already uses App Signing by Google Play

If your app is not enrolled with App Signing by Google Play you will need to go through a few extra steps in order to take advantage of Android App Bundle.

This is how people react when I mention signing in a context of mobile app development

Thankfully, the process of enabling App Signing by Google Play is relatively painless and also brings other benefits beyond the ability of using app bundles. With App Signing by Google Play you will no longer need to manage the key you use for signing releases. This is good because if you don’t keep the key, you don’t risk having it lost or compromised, which under such circumstances would essentially prevent you from publishing updates of your app.

Step-by-step instructions for migrating an existing app to App Signing by Google Play can be found here: https://support.google.com/googleplay/android-developer/answer/7384423

I’ve been doing APK splitting before it was cool

Some of you may already have their app configured to do per ABI splitting. If you have no idea what that means you can skip to the next paragraph. If you do, we still recommend that you migrate to using Android App Bundle format and to App Signing by Google Play. Doing that would not give you 3x APK download size reduction (as the most significant factor was JSC binary anyways), but will be less of a hassle to maintain even if you have your upload automated with some CI system. Remember that you will need to make adjustments to your splitting configuration regardless, as soon it will be required that you submit APKs for arm64 and x86_64 architectures — so why don’t take this opportunity and migrate to a more sustainable solution?

Final thoughts

We hope you will have no problems adopting Android App Bundle format and that your users would enjoy smaller APKs. We’ve opened a pull request to update Android app publishing instructions on the official React Native docs. If you find helpful tips in the process of migrating your app it would be awesome if you decided to contribute to these instructions too 🙌

--

--

Director of engineering at Software Mansion. React Native contributor and former member of React Native team at Facebook.