We all like fast and nimble apps that are quick to install, load fast and run efficiently. The size of a mobile application is an important factor in the overall experience. There are two facets to application size that affect a potential user’s decision to install and continue to use an application on their mobile device: Download size and Install size.

Download Size

The first hurdle in gaining users for your mobile application is getting potential users to install your application in the first place. Having an application download size that is large can ultimately prevent a potential user from even considering your application in the first place. According to Google, it has been noted that every 6MB increase to an APK’s size decreases the conversion rate by 1%.

Applications hosted by the Apple App Store and Google Play Store are stored and delivered in a compressed format which reduces the size of the package that a user must download to install your application on your device, but the overall size of the package still matters to most potential users. While this may not be that much of a concern for people with unlimited data plans, most smartphone users are still on limited data plans.

According to a Statista Global Consumer Survey from 2021, unlimited mobile data plans are still in the minority across the world. The survey suggests that in the United States alone, which is listed as having the 3rd largest number of smartphone users as of May 2021, approximately 64% or 145.8 million users have limited data plans. When you look at India, which is ranked as the second-largest smartphone user base, the percentage of the 439.42 million users with limited data plans jumps to 78% or 342.7 million users.

Install Size

Once a user decides to install your application, whether they choose to keep it installed and continue to use it may come down to something as trivial as the amount of space it takes on their device. While the average storage space for smartphone devices has crossed the 100GB mark in 2020 for new phones, many older devices are still in use around the world. When a user with limited space on their device has to choose what to keep and what to trash, oftentimes the larger apps are the first to go.

When building your applications you have many important choices to make, including which third-party libraries to use. At Moonsense, we aim to provide you with the best-in-class behavioral data collection tools. Best in class here also includes our responsibility of not bloating the size of your application.

How do we do this?

When we first set out to build the Moonsense SDKs, we agreed upon a set of guiding principles. The very first principle is that we deliver high-quality, full-featured SDKs that are as lightweight as possible. Specifically, the impact the size of our SDKs have on your applications. This is such an important principle to us that tracking this size impact of the SDKs is an integral part of our Continuous Integration/Continuous Delivery system.

Our CI pipeline is configured to automatically generate size reports for each of our SDKs (Android, iOS, and Web) during various phases of release and development. These size reports contain information about how the SDK will impact both your application’s download and install size.

Android SDK

We generate two size reports for the Android SDK, one for the *.aar file generated from the SDK and the other for the impact of the *.aar on the final executable(*.apk or *.aab). For the latter, we’ve created a very simple stripped-down sample application with a dependency only on the Android SDK. The size report for this application provides the final size of the SDK and its third-party dependencies.

In order to generate the report, we make use of the Diffuse tool. This tool generates a detailed report by comparing versions of the SDK *.aar as well as a sample application *.apk file. The SDK and sample app is built and the resulting artifacts are compared against the ones created from the main branch. Below is an example of a size report generated for one of our Pull Requests:

iOS SDK

To generate the size impact report for the iOS SDK, we use a combination of Apple-provided tooling and our own custom scripting. We have a size testing iOS application that includes the MoonsenseSDK.xcframework dynamic library. This application is then built and archived with Xcode. Once the .xcarchive has been created, we export the application for Ad-Hoc distribution, choosing app-thinning for “All compatible device variants”.

This instructs Xcode to produce different variants based on the iOS versions and various devices that the application targets. Choosing app-thinning creates the various .ipa packages in the same manner as the Apple App Store will perform with your own applications as well as the app-thinning.plist file. This file contains information about each of the different .ipa packages that were produced, including which devices and operating systems they target.

Using this information, we examine the .ipa packages to calculate the compressed and uncompressed size of the MoonsenseSDK.xcframework as it would be included in an app from the App Store and generate a size impact report.

The example output below shows the expected size impact for a change in the 0.3.0 development branch of the MoonsenseSDK.xcframework:

Web

To generate the size impact report for the Web SDK, we build the Web SDK and run scripting to compare the uncompressed and compressed sizes with previous versions.

The example output below shows the difference between the code in a PR with a set of optimizations and the main branch:

Pull Requests

Each time a new pull request is open, the CI pipeline triggers a size report to be generated. This size report is then compared with the size report for the PR’s target base branch and the results are automatically posted as comments to the PR. As more commits are pushed to the branch, the report is regenerated and the results updated in the PR comments. Having these metrics available during PR code reviews allows us to gauge whether incremental changes to the SDK are causing unintended or unexpected growth of the SDK.

Releases

When an SDK release is made, the automation kicks in yet again to generate the size report for the released SDK artifact. This report is then automatically posted to the Github Release. For example, have a look at the 0.2.0 release of the Moonsense iOS SDK. The Release Description contains the generated Size Impact report for this version of the SDK.

Wrapping Up

At Moonsense we understand that the size of your application does matter, therefore the size of the dependencies you choose to integrate with matters. We proactively monitor the sizes of our SDKs throughout the development process to ensure that we continue to offer the highest quality SDKs, with the smallest size possible.