Slim Down Your Mobile Apps!
With the increasing storage capabilities of iOS devices, the size of our applications has inevitably followed the same trend. This observation was highlighted in a report by Sensor Tower. Between 2013 and 2017, the size of the top 10 apps on the App Store increased on average by over 1000%.
Apple has also adapted its initial rule regarding the maximum size limit for downloading applications over the cellular network, doubling this limit within two years, setting it at 200 MB.
Despite this “natural” market trend, reducing the size of applications offers numerous advantages:
- Reduced data consumption on networks, allowing users to download their updates more quickly (especially in the case of mandatory updates) and contributing to a more environmentally friendly and resource-efficient digital environment.
- Optimization of the space occupied by the application in the phone’s memory.
- Lower technical maintenance costs: the heavier the application, the more it incorporates code and/or third-party libraries, which are sources of maintenance costs (but also bugs).
Today, a report on application size already exists on App Store Connect. Thanks to the optimizations already enabled by default on your project, the size of your application will be optimized according to the target platform. It’s common to have a larger application on iPad or on an older OS compared to the latest iPhones or up-to-date OS.
This report can also be generated directly from Xcode when deploying the application to the App Store. To do this, once the archive for the application is created, you simply need to export it as Ad Hoc, Development, or Enterprise application and select the following options. The detailed size report (App Thinning Size Report) will then be provided along with the application artifacts.
However, it is possible to go further with these optimizations or ensure their implementation. Here are some ways to achieve this on iOS.
The Main Lever: Introduce Bitcode
Since iOS 9, Apple introduced the concept of Bitcode into the development flow of iOS applications. Bitcode is an intermediate representation of a compiled program, halfway between source code (Swift, Objective-C) and machine code (0 and 1). iOS applications that enable Bitcode will be recompiled by the App Store upon upload.
What does it allow?
Similar to slicing, which removes assets not intended for our device, Bitcode allows the removal of compiled code that is not useful for our device’s architecture.
This can result in up to a 50% reduction in the application binary size.
But the advantages go beyond that. Apple will optimize the application (this Bitcode), and it can repeatedly optimize it automatically without the need for resubmission when compiler optimizations (LLVM) are made. Those who don’t publish regularly can benefit from the latest optimizations. This is also why Bitcode is mandatory for watchOS and tvOS applications, to enable regular optimization for these specific platforms.
However, there is a major constraint for enabling Bitcode on iOS: all dependencies used by the application must also have it enabled. This can be problematic for proprietary private dependencies.
Swift 5 to Reduce Size and Future Technical Debt
The arrival of Swift 5 in March 2019 further established its predominant role in the iOS ecosystem, introducing the concept of “binary stability.” Until then, applications using Swift suffered from a significant limitation. Due to the young age of the language, it was not stable; it was in constant evolution. To avoid compatibility problems between versions, Apple decided to embed the Swift binaries used by the application (Foundation, etc.) in every iOS application. The major drawback of this approach was the cost in terms of size; all applications had to include several megabytes of Swift binaries.
With Swift 5, the language was made stable. Thus, applications no longer embed Swift binaries and can use those directly included in iOS. This also means that an application compiled with a certain Swift version will be compatible and can use an external library compiled with a different Swift version.
This can lead to saving several megabytes, with a minimum of 5 to 7 MB or even more if multiple Swift libraries are used.
Some applications can thus reduce their size by nearly 10%.
Assets
The Assets Catalog has been introduced for a few years with Xcode 5 and iOS 7 (2013). They allow, among other things, to:
- Adapt image resources according to the targeted device type. For example, screens with higher pixel density (iPhone X) will use images provided in @3x, while screens with lower pixel density (iPhone XR) will use @2x images.
- Define resizable areas on certain images, making it possible to obtain lighter button backgrounds adaptable to any size.
- Benefit from compression options depending on the resource types.
With all these combined elements, the App Store can offer applications containing only resources intended for the relevant devices.
However, it’s important for publishers to ensure that only resources genuinely used by the application are effectively integrated. Xcode and the use of the Assets Catalog do not guarantee that integrated resources are actually used by the application.
On-Demand Resources
For a resource-intensive application path or for resources that are rarely used, it’s possible to adopt mechanisms for on-demand resource downloads. A simple implementation, for example, is to initiate the download of the relevant resources before displaying the related content or performing these actions in the background.
For Apple platforms, it’s also possible to adopt a specific solution: “On-Demand Resources.” With this implementation, the publisher can create a resource pack to submit to the App Store. These resources are not integrated into the application, reducing its size. The application can then retrieve them separately when needed.
However, the adoption of On-Demand Resources will require specific work for Apple platforms on the application side and on the server side during development. It will be necessary to adhere to Apple’s prerequisites for hosting these resources in the production environment of the App Store. However, the benefits after deployment are undeniable:
- Resources can be hosted on the App Store.
- The download size of these resource packs will be optimized with the same mechanisms as the Assets Catalog (if they are used).
- Lazy-loading of resources: their download is only initiated when needed.
- It complements well with features only active during in-app purchases (e.g., a pack of emoticons available only to users with a subscription).
Optimize Differential Downloads by Only Modifying Necessary Files and Folders
During application updates, the App Store compares the installed version on your device and the version you want to install, creating a delta package. This package contains only the changes between the two versions, minimizing its size.
To maximize the use of this feature, it is recommended to modify only the necessary files and folders, whether it’s the code itself or the assets. For significant code refactoring that doesn’t necessarily bring new features, it’s better to keep these changes for major updates, which will create a larger delta package.
Clean Up Third-Party Dependencies
For most applications, the majority of their size is concentrated in their dependencies. It’s essential to question whether you are fully leveraging each of your dependencies or if you genuinely need them. For example, if your application makes few network GET calls, it’s probably unnecessary to integrate a network library, as iOS provides plenty of resources in this regard that have proven themselves.
Reactive programming is trending, and you might integrate one of the many dependencies implementing this principle, even if you only use a fraction of their capabilities. This could be an opportunity to switch to Combine, Apple’s new framework offering equivalent features (assuming you support iOS 13 or newer).
These are just two examples among many, but it’s interesting to apply the same reasoning to each of your dependencies. Optimizing third-party dependencies will not only reduce the size of your application but also decrease the maintenance costs incurred by successive updates, bug fixes, security vulnerabilities, or the need for replacement when they become outdated.
Conclusion
At the inception of the App Store and mobile applications, the size of applications was quickly pushed down the list of technical priorities. Nevertheless, it is an excellent indicator of the healthy technical management of an application: a significant increase in your application’s size often results in expensive technical debt and increased user dissatisfaction.
Optimizing the size of mobile applications can be an excellent way to combine user satisfaction, digital sobriety, and reduced technical maintenance costs.
We encourage you to conduct a study on optimizing the size of your applications and ensure that it does not significantly increase over time.
