I don’t think this fully explains it. In the nineties you could build a whole application using a toolkit like MFC, and you could ship the entire .dll, which bundled a whole bunch of (low-res, remarkably tasteless even for the time) bitmapped UI assets, and the resulting package didn’t hold a candle to modern bloat. Nor could it: you wanted that self-extracting installer (this predated MSI!) to be reasonable to download on a 56k modem, and even if you used a CD, you wanted room for something else on that CD.

Of course, there were multi-hundred-MB software packages in that era, but they were complex, multifunctional, and highly capable. And IIRC all of Microsoft Office (RIP!) except for some rarely used extras still managed to fit in one CD for a long time.

I'm wondering what the source for these apps were. Google Store downloads strip unnecessary localized assets at download time. This used to be a BIG deal back when icons were bitmaps; but compiled binaries do provide COMPLETE pre-rendered sets of bitmap icons if your downlevel minimum version (Android 5.0? Android 6.0?) extends that far. Which are then stripped whenever you download to modern phone. Assuming that you have SVG replacements for all legacy bitmap icons. Perhaps Gmail does not. So if there are multiple localizations, that would suggest that either the user is measuring the pre-installed app (which almost immediately upgraded and is therefore effectively replaced), or has obtained the APKs from a different source.

The publicly available email app in the Android sources is NOT gmail (and is therefore likely to be unloved and uncared for, and probaly will contain massive blobs of bitmap icons. So if it was that...

Any native code ALSO bloats compiled binary size dramatically (since binaries include code compiled for each processor you have selected when you performed the native build). Unnecessary binary blobs are stripped by the Play Store when you download. It is conceivable that gmail carries ancient crusty pieces of native code, I suppose, given its long heritage.

And also includes pre-compile maps to speed up startup. Very strange process. Apparently, the Google Play Store profiles the startup of the first 20-odd users who download your app, and then transmit the pre-compile map to all subsequent downloads. I'm not sure whether apps are pre-jitted at install time or whether the pre-jitted code is downloaded from the Play Store.(Play Store does tells you they are going to do it when you upload, and -- sure enough -- load time "magically" improves by a significant amount shortly after you push the binary to production. I don't honestly know whether pre-jitting has taken place before first load. (And whether that code shows up as cache space or app size).

Compat frameworks, on the other hand.... absolutely yes! I'm not sure that native Android framework code EVER gets executed on a modern app, to be honest. Almost all compat layers, and extensions, I think.

That’s a lot, a lot, of compiled code and text, especially when you consider some of it is likely compressed.

Also, afaik, it is possible to ship an iOS app in a way certain modules can be downloaded as needed.

It would be nice if Google paid some respect to user devices, or at least go back to “don’t be evil”

Which is why on iDevices static libraries should be used instead, as the linker can throw away the extra stuff.

Likewise on Android, on the NDK, and R8/D8 take care of removing all the extra stuff as well.

Sandboxed applications don't make sense to have dynamic linking beyond what is required by some OS workflows, e.g. loading native code into ART.

>iOS apps also need to include all localized assets in each app bundle.

Is this a hard requirement? I use two languages or at best three. The other 100 language don't matter to me. Why do I have to waste space on my smartphone. This adds up if I have hundreds of apps.