How 7 iOS Apps Could Save You 500MB of Storage
Read the full version of this post on the Emerge Tools Blog
Background
Many mobile developers can attest to the problems of app size increase.
Sometimes it’s a quick feature release with an uncompressed image that adds 5%. Sometimes it’s a slow, steady increase of 0.5% each week.
I worked on these issues as a software engineer at Airbnb for 4.5 years, and in my own apps with ThnkDev. Recently, I personally analyzed over 150 apps to try to solve the issue of app size once and for all. I wanted to share my findings about common mistakes with everyone so we can all build lighter and faster apps! 🚀
Knowing exactly what goes into your app is tricky for fast moving teams, thats why automated testing and alerts around best practices makes apps more efficient. Emerge aims to do this for your apps.
Why?
App quality is always top of mind for developers and one of the most important factors is what actually gets shipped to users. However, it’s not easy to validate what goes into your final .app and bugs can often slip through unnoticed. Developers can easily get into situations where duplicate files need to be kept in sync, extra code delays app startup, or file fragmentation bloats the install size. Your app’s size is a user’s first impression of your app, longer download times can lead to missed users or failed installs. Not to mention, uninstall rate goes up as app size increases and users look for ways to free up space on their devices.
Experiments indicate as much as a 0.5% drop in install conversions per megabyte added.
What is app size anyway?
App size can be tricky to measure, there are many places that display size which can be contradicting and enough context isn’t always provided. In general there are 2 measurements to know: install and download size.
Users most often see install size. It’s on the App Store page and shown in system settings. Install size is how much storage your app takes up on a user’s phone. To keep things simple in the rest of this post when we refer to size, it’s install size, because we care most about what users see. You can read all about the different ways to measure size in the Emerge documentation.
Now let’s get started!
Dropbox has the most savings of any app we’ve measured. Weighing in at 269 MB, our tool’s analysis shows potential size reductions of 40%. Most of this extra size is coming from duplicate localization files. As you can see from their app breakdown, each app extension has the same copy of Localizable.strings as the main app bundle, for all 21 supported languages. In addition to duplicates, the Localizable.strings files contain comments used to provide context to translators. These aren’t needed in the production app, stripping comments in production would save ~46mb. With the current setup, every new language will account for about 4mb. There are a few other things that could be improved, but let’s go on to some other apps.
The Spark app is almost 10% font files. Taking a closer look at the fonts you might notice some familiar names:
- SF-Pro-Text-Semibold.otf
- SF-Pro-Text-Light.otf
- SF-Pro-Text-Medium.otf
- SF-Pro-Text-Heavy.otf
- SF-Pro-Text-Bold.otf
- SF-Pro-Text-Regular.otf
Each of these font files appear twice in the app, once in the main app bundle and once in the sharing extension. These are the default fonts included in iOS, and can be downloaded here. According to the license agreement shown when installing these fonts:
IMPORTANT NOTE: THE APPLE SAN FRANCISCO FONT IS TO BE USED SOLELY FOR CREATING MOCK-UPS OF USER INTERFACES TO BE USED IN SOFTWARE PRODUCTS RUNNING ON APPLE’S iOS, iPadOS, macOS OR tvOS OPERATING SYSTEMS, AS APPLICABLE.
They shouldn’t need to be included in any app targeting iOS 11+, as they can all use the default system font. Removing them would reduce Spark’s size by ~20mb.
Edit: Some have pointed out that the SF fonts change even in later iOS versions. There still may be some license agreement violations for using these, and even if they are needed it doesn’t change the total savings for Spark which is calculated assuming the duplicate copy of the font is removed and only one is kept.
The Ebay app has an interesting architecture where the main app’s executable is only ~150kb although 86% of the app size is executable files. This is because most of their app consists of frameworks, the biggest one (34mb) is EbayApp.framework. Almost 100mb of these frameworks are unnecessary swift symbols. When you build a swift framework, the binary contains a symbol table which you can read with the nm command.
nm -m eBayApp.framework/eBayApp
...
s7eBayApp28SettingsViewControllerLegacyC13viewDidAppearyySbFToEbay has tens of thousands of these non-external symbols. After stripping them using the method described here the size is greatly reduced.
