Android App Core Metrics at Airtel

Airtel Thanks App is one of the most used apps in India. It is installed base is around 100 Mn with 85 Mn MAU (Monthly Active Users) and 15 Mn DAU (Daily Active Users).

With this much user base it becomes especially important that user experience should be excellent, and our app serves them well in all core metrics.

• What is app core metric? App Core metrics is defined as those critical metrics which gives excellent user experience to the user. There are many core metrics, and we classify them in two categories:

1. App Health: Like Crash Rate, ANR (App Not Responding) Rate, Launch Time
2. App Size

• Why is it important?

1. App Health: These metrics are the most important metrics in Android vitals and affect the visibility of your app on Google Play and these are also linked to your app retention rate.
2. App Size: This metric is important for emerging markets like India as this directly impact uninstall numbers and growing install numbers.

We will try to cover both the categories but, in this article, we will try to cover about App Size.

• Why App Size is important?

App size is a key metric impacting user acquisition and retention: If the app is too large to download, users may skip installation or cancel the installation during downloading; if the app takes too much storage space after use, users may choose to uninstall. Globally, we see a negative correlation between APK size and install conversion rate for apps. To give sense for every 6 MB increase to an APK’s size, we see a decrease in the install conversion rate of 1%. There is a nice article about shrinking app size and growing installs which you can refer from here

• What are we doing in Airtel about size?

As the code base increases it becomes difficult to maintain the code among different teams in dependency increases. So, to do tackle this we did two changes.

• Architecture Changes: We moved to monorepository architecture. Approach here is to create core package and LOB (Line of business) specific code another package and have some restrictions on the dependencies a package can have.

• Governance: As team size increases, they come with new or redesign of existing features and keep on increasing size, but they never remove their old/deprecated features. To handle this, we did follow changes.
• Monitor Usage of modules/features: We put logging about which module/feature is used by how many users. This helps in removing the code of unused/less features in the app.
• Restricting app size increase by each release: So, we built CI/CD pipeline to merge respective team pr into master branch and there we put size check as quality gate along with other gates.
• Our journey of reducing App Size

Last year we worked on making our Android app smaller, learnt a lot about how to do this and achieved impressive results. We would like to take you through our journey, from when we started analysing our app to the changes we made and the improvements we got. We are sharing this with you in the hope that some of the techniques we describe are applicable for you and your apps too.

At Airtel reducing the app size becomes even more challenging as we have a Hybrid app (React Native + Android). Size of a basic “Hello World” react native application is around 20 MB without any optimisations. Over a period of a couple of months we performed multiple activities to reduce our app size. In this article we will walk through the key things we did at Airtel to reduce the app size.

1. Android App Bundles:

Size Impact -> ~5 MB

Before app bundles the simplest approach was to build and upload a single APK that contains everything any user may need to Google Play. All users would download and install the same APK although it contains many things they do not need

This was a widespread problem and Google addressed it with dynamic delivery in 2018, which uses the AAB (Android App Bundle) format for uploading apps to Google Play.

1. On Demand Dynamic Modules

Size Impact -> 4–5 MB

1. 80:20 rule (Pareto Principle): It is a familiar saying that asserts that 80% of outcomes (or outputs) result from 20% of all causes (or inputs) for any given event.
2. Drawbacks: The drawback for this is if user tend to use dynamic features and that is not installed yet will led to bad user experience

So, choice of choosing which features should become dynamic become important

Dynamic feature modules allow you to separate certain features and resources from the base module of your app and include them in your app bundle. Through Dynamic Delivery, users can later download and install those components on demand after they have already installed the base APK of your app.

At airtel we converted 5 modules that were not needed immediately to on Demand Dynamic modules. With this these modules were only downloaded when the user trying to use the feature.

More details on Demand Dynamic modules can be read on this article by Google Android Team — https://developer.android.com/codelabs/on-demand-dynamic-delivery

1. Migrated to Hermes from JSC
   Size Impact — 1.8 MB
   Hermes is a JavaScript engine optimised for React Native. By compiling JavaScript into bytecode ahead of time, Hermes can improve your app start-up time. The binary size of Hermes is also smaller than other JavaScript engines, such as JavaScript Core (JSC). It also uses less memory at runtime, which is particularly valuable on lower-end Android devices. Considering the above points, we at Airtel decided to migrate to Hermes from JSC.

More details on Hermes can be found in official react native doc — https://reactnative.dev/docs/hermes/

1. React Native Fonts Linking
   Size Impact — 1.2 MB
   Airtel being a hybrid app (React Native + Android) the fonts used in RN & Android were kept duplicate in both the places. This led to size increase due to duplicity. To resolve this, we used font linking to pick up fonts from a common location for both android & react native. https://blog.logrocket.com/adding-custom-fonts-react-native/
2. Removed unused code & modules.
3. One time framework and keep on monitoring
   Size Impact — 400–500 KB
   Even after code obfuscation there are Activities & Fragments which are linked to some other generic app level utility class. So, code obfuscation does not work in these cases. To identify these classes, we at Airtel used our inhouse analytics to log the modules that were being used. After a period of 1–1.5 month from release we checked our analytics for the modules that were being logged. Which means that the modules that were not getting logged we can simply remove them.
4. Forced library version
   Size Impact -> 200–250 KB

There are several instances where the main app is using version v1.1 of a dependency and a module or any other library is using version v1.0 of the same library.

To identify these kinds of libraries we can either use “External Libraries” section of Project Explorer inside Android Studio or we can create Dependency Graph to check the dependency versions

External Libraries

In the above image we can see that there are 3 versions of constraint layout being used. Now when the Aab or apk is created then all these versions will be included in the app which will increase the app size unnecessarily.

To fix this we can simply force the library version to the latest version.
Details on how to force the version is added in the link below
https://stackoverflow.com/questions/44404308/android-force-gradle-to-include-only-one-version-of-a-library

Dependency Graph
Alternatively we can create the dependency graph and check the same.

Dependency graph command

. /gradlew app:dependencies > dep.txt

1. Images (resources optimisation)

Size Impact -> 150–200 KB
Migrated Png images to svg or webp. Mostly SVG has less size compared to Png. So, we should use SVG instead of Png to reduce the app size.

More details on why to use SVG instead of Png can be found on the link below.
https://www.growfox.co.uk/blog/5-reasons-you-should-be-using-svgs-over-pngs

Other things that could have been implemented but were not implemented due to limitations

1. Downloadable Fonts — Link to point 3
   
   Downloadable fonts is a feature by Google which allows to dynamically download fonts from https://fonts.google.com/
   
   There are over 1400+ fonts on Google fonts. If the font that is being used in the app is available on google fonts website, we can use this feature. By this way we will not have to keep the font file inside the app and the app size can be reduced.
   
   At Airtel unfortunately our fonts were not available on Google fonts, so we had to keep the fonts locally inside the app. We could have reduced the app size by 1.2 MB if our fonts were available on the repository.
   
   More details on how to use this feature can be found in the below link
   https://developer.android.com/guide/topics/ui/look-and-feel/downloadable-fonts

Special Thanks: Android Platform Team including Ankush Kapoor, Kunal Farmah, Rahul Bareja and Himanshu Gulati for continuous support and guidance.