They have a neat treemap breakdown here: https://www.emergetools.com/app/example/ios/com.google.Gmail
130MB is localization data.
This detail was interesting too: https://twitter.com/emergetools/status/1810790291714314706
> There's over 20k files in the app, 17k of which are under 4 kB. In iOS, the minimum file size allocation is 4 kB, so having many small files causes unnecessary size bloat. Gmail could save 56.4 MB by moving their small files to an Asset catalog
The small filesize issue is something we commonly see in games, was surprised to see it for Gmail.
And btw we open-sourced much of our analysis after being acquired by Sentry: https://github.com/getsentry/launchpad
That doesn't seem right. Localization feels like it should add a few MB. Not over 100. (Plus shouldn't it be compressed, and locally uncompressed the first time a language gets used?)
Since the iOS filesystem uses 4 KB blocks, it looks like about half the space is just wasted.
Android traditionally puts resources into a compressed archive, though, so by simply using an archive for storage, Google may be avoiding the 4k size problem.
I now see the article is about iOS app, but it looks like the Android app is anywhere between 50mb and 100mb (depending on the apk download side I look at) which is much more reasonable
[1] https://x.com/emergetools/status/1943060976464728250
[2] https://github.com/google/bloaty
So compression/deduplication is probably the better option. Rather than storing as 1 zip per language, though, you'd probably want a compression format that also eliminates duplication that may occur between languages if you're storing all languages compressed on the system. That means you'd need compression to handle the entire language complex being in one massive compressed blob and you'd just extract out the languages you needed. I assume there are some forms of zipping that do this better than others.
