4 ms·

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 too

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.

jeffbee 9mo ago
> and gRPC 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).
port11 9mo ago
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.
- tralarpa 9mo ago
  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...
  - az09mugen 9mo ago
    So it seems flutter by itself takes 200-ish MBytes. Flutter alpha is 2017 according to https://en.wikipedia.org/wiki/Flutter_(software) https://en.wikipedia.org/wiki/Flutter_(software) Mystery solved it seems
- ThePowerOfFuet 9mo ago
  bunq 30.0.2 on Android is 380 MB by itself.
- Neywiny 9mo ago
  But this is still unjustified speculation
  - port11 9mo ago
    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.
    - Neywiny 9mo ago
      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
j45 9mo ago
I guess so much has already been built they wouldn't have just recreated it in Flutter or something.
itopaloglu83 9mo ago
Thank you for your explanation. 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.
- etruong42 9mo ago
  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.
  - andrekandre 9mo ago
    > improve someone else's code, that could make them look bad, and that would have negative consequences for you i would never have thought google of all companies would be this political...
    - simfree 9mo ago
      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.
zbentley 9mo ago
Hilarious. “The public’s phones don’t run google3, you say? Then we’ll ship google3 to them!” (And yes I know it’s a tiny fraction of the size, let me have my fun).
seec 9mo ago
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.

jeffbee 9mo ago

> and gRPC 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).

port11 9mo ago

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.

tralarpa 9mo ago
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...
- az09mugen 9mo ago
  So it seems flutter by itself takes 200-ish MBytes. Flutter alpha is 2017 according to https://en.wikipedia.org/wiki/Flutter_(software) https://en.wikipedia.org/wiki/Flutter_(software) Mystery solved it seems
ThePowerOfFuet 9mo ago
bunq 30.0.2 on Android is 380 MB by itself.
Neywiny 9mo ago
But this is still unjustified speculation
- port11 9mo ago
  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.
  - Neywiny 9mo ago
    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

j45 9mo ago

I guess so much has already been built they wouldn't have just recreated it in Flutter or something.

itopaloglu83 9mo ago

Thank you for your explanation. 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.

etruong42 9mo ago
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.
- andrekandre 9mo ago
  > improve someone else's code, that could make them look bad, and that would have negative consequences for you i would never have thought google of all companies would be this political...
  - simfree 9mo ago
    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.

zbentley 9mo ago

Hilarious. “The public’s phones don’t run google3, you say? Then we’ll ship google3 to them!” (And yes I know it’s a tiny fraction of the size, let me have my fun).

seec 9mo ago

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.