331–340 of 403 posts
> For most of that period, the size of the Gmail app hovered around 12 MB, with a sudden jump to more than 200 MB near the start of 2017... The Gmail app, on the App Store, is currently 760.7 MB in size. With charts: https://www.axios.com/2017/12/15/the-top-iphone-apps-are-tak... I had no idea common apps used to be just 10-30 MB. But are now hundreds of MB. Something like Gmail doesn't have massive hi-resolution bit…
We crossed lunacy long ago.
> For most of that period, the size of the Gmail app hovered around 12 MB, with a sudden jump to more than 200 MB near the start of 2017... The Gmail app, on the App Store, is currently 760.7 MB in size. With charts: https://www.axios.com/2017/12/15/the-top-iphone-apps-are-tak... I had no idea common apps used to be just 10-30 MB. But are now hundreds of MB. Something like Gmail doesn't have massive hi-resolution bit…
We once ran Windows 95 with Encarta in about the same amount of disk space. We crossed lunacy long ago.
> For most of that period, the size of the Gmail app hovered around 12 MB, with a sudden jump to more than 200 MB near the start of 2017... The Gmail app, on the App Store, is currently 760.7 MB in size. With charts: https://www.axios.com/2017/12/15/the-top-iphone-apps-are-tak... I had no idea common apps used to be just 10-30 MB. But are now hundreds of MB. Something like Gmail doesn't have massive hi-resolution bit…
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…
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.
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.
Earlier quoted context omitted.
Not sure how that would help. SVGs aren't natively handled on iOS. They get rasterized during build time and that's what gets shipped with an app.
Historically, raster graphics won out because they used less resources. Perhaps that's changed. If so, it would make sense for various OS's to start working on native support. Irix did it in the 90's. It can be done now.
Earlier quoted context omitted.
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.
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, pulli…
> improve someone else's code, that could make them look bad, and that would have negative consequences for you
Earlier quoted context omitted.
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, pulli…
> 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...
Same goes for other other bloated apps mentioned in the blog post