iOS App Size & Launch time optimization

At Halodoc, we are very agile in our SDLC and do app release every 2 weeks and we keep adding new features and improvements in every release. With this feature velocity, the app size increased and was reaching around 150 MB. Also, there was negative impact on app launch performance. Optimizing the app size and app launch time became the priority problem to be solved.

So how to reduce the app size and launch time?

Here are the some of the things we have done:

1. App Thinning
2. Remove unused assets
3. Clean up the Localized.string files
4. Enable static library build mode

1 . App Thinning

App thinning process helps in reducing the size of the app. There are many different iOS devices, many different processors, screen sizes, resolutions. Before app thinning, when we built an app, we built a universal app. Meaning, our universal app could run on an iPad and on an iPhone or on an iPod Touch. So, if you built an app that supports iPhone and iPod Touch and you run it on an iPod Touch, you would get all the image assets for all supported resolutions as well as a big binary that’s built for all supported architectures.

The App thinning process involves using one or a combination of two processes, known as

1. Slicing
2. BitCode

Slicing

Slicing enables mobile app developers to pack assets based on the device for which the app is being downloaded, meaning the user only installs the relevant assets. If the same user downloads the same app on another device, then assets required to run on that device will only be installed.

This makes it easy for the users to manage their storage and enjoy apps with fewer restrictions.

For example, on an iPod Touch (1st generation) you’ll only need this:

While on an iPhone XR you’ll need this:

This brings us to the essence of app thinning. Slicing up your app so it’s optimised for the device it’s going to be running on. This will decrease the size of the app quite a bit and decrease the download time. It’s also a way to keep your app under the OTA(Over The Air) size limit.

Enable bit code

We enabled bit code, as it is required for 2 reasons: 1) it is required by AppStore to build different versions of the app, 2) it is required for App thinning. Go to build setting of your target and make sure it’s enabled.

Now when you submit your app for review, it will be compiled into an intermediary language and not a machine language. When your app gets approved it will be recompiled from bitcode to machine language for every supported architecture. So your one executable can actually produce several smaller executables. When your user installs the app, they will get one of these smaller executables. All this is going to happen behind the scenes and the only thing you or your users will notice is a smaller size of your app.

2. Remove unused assets

We were using 1x, 2x and 3x (.png format) images to support different resolutions and in some places we were using .pdf format. Since we had some old unused images, we cleaned all unused images. Also, since 2x and 3x images were bigger than pdf images and pdf with single scale looks good with all the resolutions, we started using .pdf format images across the app, thus helping us in reducing the app size.

3. Clean up the Localized.string files

We had some old unused strings and duplicate strings, we cleaned up all the unused strings and duplicate strings, which helped us to reduce the app size.

4. Enable static library build mode

We were using dynamic library setup for linking the dependent library. With Dynamic library (.dylib), The libraries are loaded into memory when they are actually needed. This could happen either at load time or at runtime. As a result, invoking code and data from dynamic libraries happens slower than from the static ones.

Our average app launch time with Dynamic libraries:

With Static library (.a), The libraries are linked at Compilation time. It will merge the object files from the library and package them along with the application object files into one single executable file. As a result, app launch will be much faster.

Our average app launch time with Static libraries:

Steps to enable static library mode:

Since we are using Cocoa-pods for dependency management, in the Pod-file, replace line below to enable the stricter search paths and module map generation for all of your pods

with this

And if you are using post_install, enable bitcode flag should be set to YES

When you enable static library mode, and if you are using development pods,  you need to handle the resource bundle for the development pods. Because in development pod, Bundle.main will be pointing to AppTarget bundle. To handle this, in your .podspec file, you have to set resource_bundles instead of ios.resources as shown bellow:

Replace

with below line

You can access the bundle path of the development pod with

You can use this bundle to access any resources like images, localisation strings, XIB files etc in your development pod.

Conclusion:

Having smaller apps footprint offers many benefits for the end users. They don’t waste space on their devices and due to the smaller footprint, the app downloads faster. This also enables them to accept newer updates for the app more often. With above mentioned steps, we were able to significantly reduce the app download size by ~25% and installation size by ~75%.

In addition to app size reduction, by switching the dynamic to static library linking mode, our app launch got ~50% faster. This faster load time has improved the overall experience for our users.

As we've outlined here, investing in modern techniques such as App slimming, static library linking has helped us in optimising our app size, and has helped us improve the overall experience for our iOS end-users.

Join us

We are always looking out to hire for all roles for our tech team. If challenging problems that drive big impact enthral you, do reach out to us at careers.india@halodoc.com

About Halodoc

Halodoc is the number 1 all around Healthcare application in Indonesia. Our mission is to simplify and bring quality healthcare across Indonesia, from Sabang to Merauke. We connect 20,000+ doctors with patients in need through our Tele-consultation service. We partner with 1500+ pharmacies in 50 cities to bring medicine to your doorstep. We've also partnered with Indonesia's largest lab provider to provide lab home services, and to top it off we have recently launched a premium appointment service that partners with 500+ hospitals that allow patients to book a doctor appointment inside our application. We are extremely fortunate to be trusted by our investors, such as the Bill & Melinda Gates Foundation, Singtel, UOB Ventures, Allianz, Gojek and many more. We recently closed our Series B round and In total have raised USD$100million for our mission. Our team works tirelessly to make sure that we create the best healthcare solution personalised for all of our patient's needs, and are continuously on a path to simplify healthcare for Indonesia.