Most big iOS apps have huge localization files, taking up lots of space. Airbnb cut theirs by 82% using two tricks: compressing files for only the needed language and removing duplicate keys across languages. This reduces app size and speeds things up. Tools like Emerge help simplify this process. Smaller files mean better performance and less storage used.
The largest iOS apps all have a common problem
Localization files account for
23% (74 MB) of @Uber
23% (30 MB) of @WhatsApp
17% (53 MB) of @MicrosoftTeams
17% (50 MB) of Nike Run Club
🧵 Here's how Airbnb reduced the size of localizations by 82% with the help of Emerge
First, a quick primer on localization files
Localization files are used to store translations of text in your app. Each file is a list of key-value pairs for text that need translating. These files exist for every language your app supports
When a user downloads your app, every localization file is included in the app bundle
At runtime, the OS loads the localization file of the user's preferred language
So despite most users only using one language, the files for all supported languages are downloaded
Pictured are all the localization files for WhatsApp version 22.24.81
On iOS, WhatsApp supports 40+ languages 🌐
In all, WhatsApp's localization files take close to 30 MB
Airbnb supports 60+ languages on iOS. For apps of this scale, localizations can have a significant size footprint
There are two optimizations Airbnb used to go from ~60 MB of localization files to ~10 MB (install size)
1. String File Compression
2. Key Deduplication
[String File Compression]
B/c users typically only need one language for their session, significant savings can be had by compressing all localization files at build time and then decompressing only the needed language at runtime
Airbnb used LZFSE - a data compression algorithm by Apple to compress & decompress
It's important to note that decompression takes time and can negatively impact app launch. We'll discuss how Airbnb mitigated this shortly
[Key Deduplication]
The same keys are duplicated across all language files.
This duplication scales the more translations (key/values) & languages an app supports
To avoid key duplication, Airbnb has a json file with an array of translations for each language + one json file with an array of corresponding keys
Each key will now appear only once in the app. This requires the order of translations and keys to be maintained across all files
At runtime, the user's preferred language file and translation keys are zipped to recreate the original Apple format
The main idea with these approaches is to minimize the size of files not used by the user
Only decompress and zip key-values for the user's preferred language
Compression and deduplication happens at build time. Decompression and zipping happens at run time
One note is that the runtime operation should not be performed at each launch.
After the initial build time process for a user, the decompressed & zipped file should be cached to avoid impacting launch time.
See video linked at end of thread for full implementation details
If you're curious at the impact of localizations in your app, please get in touch with us for free Size Analysis!
Lastly, we absolutely recommend checking out the full presentation from @miguel_jimemigu given at the @baswiftable conference
This talk goes over the entire process in much more depth and explains pros / cons + potential pitfalls
The largest iOS apps all have a common problem
Localization files account for
23% (74 MB) of @Uber
23% (30 MB) of @WhatsApp
17% (53 MB) of @MicrosoftTeams
17% (50 MB) of Nike Run Club
🧵 Here's how Airbnb reduced the size of localizations by 82% with the help of EmergeFirst, a quick primer on localization files
Localization files are used to store translations of text in your app. Each file is a list of key-value pairs for text that need translating. These files exist for every language your app supportsWhen a user downloads your app, every localization file is included in the app bundle
At runtime, the OS loads the localization file of the user's preferred language
So despite most users only using one language, the files for all supported languages are downloadedPictured are all the localization files for WhatsApp version 22.24.81
On iOS, WhatsApp supports 40+ languages 🌐
In all, WhatsApp's localization files take close to 30 MBAirbnb supports 60+ languages on iOS. For apps of this scale, localizations can have a significant size footprint
There are two optimizations Airbnb used to go from ~60 MB of localization files to ~10 MB (install size)
1. String File Compression
2. Key Deduplication[String File Compression]
B/c users typically only need one language for their session, significant savings can be had by compressing all localization files at build time and then decompressing only the needed language at runtimeAirbnb used LZFSE - a data compression algorithm by Apple to compress & decompress
It's important to note that decompression takes time and can negatively impact app launch. We'll discuss how Airbnb mitigated this shortly[Key Deduplication]
The same keys are duplicated across all language files.
This duplication scales the more translations (key/values) & languages an app supportsTo avoid key duplication, Airbnb has a json file with an array of translations for each language + one json file with an array of corresponding keys
Each key will now appear only once in the app. This requires the order of translations and keys to be maintained across all filesAt runtime, the user's preferred language file and translation keys are zipped to recreate the original Apple formatThe main idea with these approaches is to minimize the size of files not used by the user
Only decompress and zip key-values for the user's preferred language
Compression and deduplication happens at build time. Decompression and zipping happens at run timeOne note is that the runtime operation should not be performed at each launch.
After the initial build time process for a user, the decompressed & zipped file should be cached to avoid impacting launch time.
See video linked at end of thread for full implementation detailsSo where did Emerge come in?
Emerge's Size Analysis validated size improvements
Performance Analysis tooling was then used to measure launch time impact in Airbnb's CI workflowFor the optimizations
String File Compression reduced localization files from 22% of the Airbnb app to 8%.
Key Deduplication further reduced it to 4%If this seems like a significant effort, it's because it is. That's why we have an open source library that does most of the heavy lifting for youUsing this approach, an app like @Garmin Connect could reduce its localization size by ~63 MB
(Garmin Connect has the largest localizations of any app we've measured - 81.6 MB of install size)There are also low hanging fruits when it comes to localization files. These files are often duplicated in the app bundle
Many apps have also have unnecessary whitespace & comments in localization files. These are used for translators, but don't need to be in productionThe Nike Run Club iOS app duplicates localizations in each plugin, the Watch app, and in multiple dynamic frameworks
Nike Run Club could also save 12.7 MB from minifying their string files
These optimizations are less involved than what Airbnb did, but still impactfulHere are links to all apps mentioned
Uber
WhatsApp
Microsoft Teams
Nike Run Club
Garmin ConnectIf you're curious at the impact of localizations in your app, please get in touch with us for free Size Analysis!Lastly, we absolutely recommend checking out the full presentation from @miguel_jimemigu given at the @baswiftable conference
This talk goes over the entire process in much more depth and explains pros / cons + potential pitfalls
yes
The largest iOS apps all have a common problem
Localization files account for
23% (74 MB) of @Uber
23% (30 MB) of @WhatsApp
17% (53 MB) of @MicrosoftTeams
17% (50 MB) of Nike Run Club
🧵 Here's how Airbnb reduced the size of localizations by 82% with the help of Emerge ... First, a quick primer on localization files
Localization files are used to store translations of text in your app. Each file is a list of key-value pairs for text that need translating. These files exist for every language your app supports ... When a user downloads your app, every localization file is included in the app bundle
At runtime, the OS loads the localization file of the user's preferred language
So despite most users only using one language, the files for all supported languages are downloaded ... Pictured are all the localization files for WhatsApp version 22.24.81
On iOS, WhatsApp supports 40+ languages
In all, WhatsApp's localization files take close to 30 MB ... Airbnb supports 60+ languages on iOS. For apps of this scale, localizations can have a significant size footprint
There are two optimizations Airbnb used to go from ~60 MB of localization files to ~10 MB (install size)
1. String File Compression
2. Key Deduplication ... [String File Compression]
B/c users typically only need one language for their session, significant savings can be had by compressing all localization files at build time and then decompressing only the needed language at runtime ... Airbnb used LZFSE - a data compression algorithm by Apple to compress & decompress
It's important to note that decompression takes time and can negatively impact app launch. We'll discuss how Airbnb mitigated this shortly ... [Key Deduplication]
The same keys are duplicated across all language files.
This duplication scales the more translations (key/values) & languages an app supports ... To avoid key duplication, Airbnb has a json file with an array of translations for each language + one json file with an array of corresponding keys
Each key will now appear only once in the app. This requires the order of translations and keys to be maintained across all files ... At runtime, the user's preferred language file and translation keys are zipped to recreate the original Apple format ... The main idea with these approaches is to minimize the size of files not used by the user
Only decompress and zip key-values for the user's preferred language
Compression and deduplication happens at build time. Decompression and zipping happens at run time ... One note is that the runtime operation should not be performed at each launch.
After the initial build time process for a user, the decompressed & zipped file should be cached to avoid impacting launch time.
See video linked at end of thread for full implementation details ... So where did Emerge come in?
Emerge's Size Analysis validated size improvements
Performance Analysis tooling was then used to measure launch time impact in Airbnb's CI workflow ... For the optimizations
String File Compression reduced localization files from 22% of the Airbnb app to 8%.
Key Deduplication further reduced it to 4% ... If this seems like a significant effort, it's because it is. That's why we have an open source library that does most of the heavy lifting for you ... Using this approach, an app like @Garmin Connect could reduce its localization size by ~63 MB
(Garmin Connect has the largest localizations of any app we've measured - 81.6 MB of install size) ... There are also low hanging fruits when it comes to localization files. These files are often duplicated in the app bundle
Many apps have also have unnecessary whitespace & comments in localization files. These are used for translators, but don't need to be in production ... The Nike Run Club iOS app duplicates localizations in each plugin, the Watch app, and in multiple dynamic frameworks
Nike Run Club could also save 12.7 MB from minifying their string files
These optimizations are less involved than what Airbnb did, but still impactful ... Here are links to all apps mentioned
Uber
WhatsApp
Microsoft Teams
Nike Run Club
Garmin Connect ... If you're curious at the impact of localizations in your app, please get in touch with us for free Size Analysis! ... Lastly, we absolutely recommend checking out the full presentation from @miguel_jimemigu given at the @baswiftable conference
This talk goes over the entire process in much more depth and explains pros / cons + potential pitfalls
Missing some Tweet in this thread? You can try to
Update