A significant portion of larger sizes is likely due to how Google handles shared code across its iOS suite. They rely heavily on a shared C++ backend (using tools like J2ObjC or similar internal transpilers) to keep logic consistent between Android, iOS and of course the web.
When you pull in the gmail dependency from the internal monorepo, you are most likely pulling in the entire visual stack for Google meet, chat and spaces, plus the heavy protocol buffer definitions and gRPC libraries that underpin them.
Even if you don't use the "meet" tab, the binary could be including the video codecs, the real-time transmission logic plus the AR filter assets, because the app is compiled as a "Super App" container rather than a modular mail client. I feel it's an organizational artifact as much as a technical one.
This is more like the what causes these apps to be so large, but when you ask why then you see that they simply do not care about the amount of space they take on users’ devices. There’s no obvious effort to reduce app size with modular design, it simply feels like they don’t care.
As a Google engineer, I believe it is largely accurate to say that we "don't care", or at least "not caring" is the emergent behavior at Google. There are many things we don't care about at Google that I think would shock many engineers who have a healthy amount of pride in craftsmanship. It's hard for me to precisely describe why we "don't care", but I will try anyways.
As the parent commenter has pointed out, pulling in client code can be very large. If the backend team owns the client code, they may not be properly incentivized to improve the product of the clients, sadly. And calling it the backend "team" might be overly simplistic. There may be additional layers to the the client code owned by other teams, such as different protocol implementation and definitions of those protocols, etc. Pushing for change can be viewed negatively, since it could leave a poor impression. E.g. if you improve someone else's code, that could make them look bad, and that would have negative consequences for you as you have violated (a variation of) Greene's first law of power: never outshine the master.
Since the code and the organization are so convoluted and complicated, it's a lose-lose proposition. If you mess up your optimization, you will get blamed. Even if you succeed, you may have reduced someone's reputation of someone you can't even identify in the bureaucracy, and thus have made an enemy of someone you can't even identify.
The Google of 2026 is a very different Google of 2006. In 2006, everyone who left Google had only praises to sing about the employer they were leaving! It is very telling when the Google of 2026 has had years of highly reputable engineers voluntarily leaving (even before the layoffs) who are so bold as to openly criticize Google in the social environment that we're in. Openly criticizing Google requires great personal fortitude, since being a critic only burns bridges and reduces your career opportunities. That is to say nothing about the criticisms that never get published outside of Google.
All large organizations are political. Some employees choose to ignore the office politics, but that choice might find their management not ensuring they survive the next round of layoffs.
I think a simpler explanation the some of the others is.. why care? Phones these days, even cheaper ones, have oodles of GB available. They're not losing customers from the size. And I don't think making it smaller is going to draw in new gmail/workspace customers. So why spend time on it when there are tons of new features or active bugs that could be fixed instead?
Right, I wouldn't be surprised of the app includes its own cryptography instead of relying on platform libraries, and/or contains what amounts to a userspace network stack in the form of QUIC (Cronet).
Very insightful, rather than unjustified speculation. Of course it doesn’t explain why many other apps are so big, e.g. Withings, Bunq (bank), and Albert Heijn (supermarket) together eat 1GB of my storage. All 3 are things I need to list data, but somehow are the size they are.
I don't know much about app development, but I was curious and downloaded the Albert Heijn apk for ARM64. Inside the apk, the three largest entities are:
- libflutter.so 140 MBytes (flutter, obviously)
- flutter_assets 29 MBytes (this is a directory. The name is a bit misleading because it mostly consists of AH-specific icons.)
- libapp.so 20 MBytes (also related to flutter, I think)
There is a 640 KByte json file in the assets that stores an animation in base64 format. Now you know what the CPU and storage resources of your devices are used for nowadays...
GP offered one plausible explanation and backed it up with credible points. They’ve done more than the linked blog post which has no explanation to offer.
What about their comment is credible? They brought up possible points, borderline likely points, but it carries no ethos. No app decompiling, no build system analysis. I'm just not seeing what you're seeing
It's pretty much the results of inter-platform competition. None of the actors want to use what the others are making for various reasons which I think are valid. For example, history has showned that being completly dependant on Apple tooling/frameworks/APIs isn't really a good idea because they are not a trustworthy player.
The same thing could be said about the reverse I guess and about most companies in general.
Software really has a big dependency problem because the sellers always bundle it with a service or a hardware in order to make money. I doubt it can be solved, since one has to make money somehow.
When you pull in the gmail dependency from the internal monorepo, you are most likely pulling in the entire visual stack for Google meet, chat and spaces, plus the heavy protocol buffer definitions and gRPC libraries that underpin them.
Even if you don't use the "meet" tab, the binary could be including the video codecs, the real-time transmission logic plus the AR filter assets, because the app is compiled as a "Super App" container rather than a modular mail client. I feel it's an organizational artifact as much as a technical one.