Why is the Gmail app 700 MB?

436 points by thefilmore 132 days ago | 393 comments

crazygringo 132 days 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 bitmap graphics. Since the article doesn't give any answer, I'm assuming it's a hand-wavy "frameworks", but that's an enormous amount of compiled code.

Aachen 132 days ago | |

> I had no idea common apps used to be just 10-30 MB.

More like a few dozen kilobytes to a handful of megabytes. If you look in F-Droid you can find some good old apps where graphics are either small or it uses the default styles for buttons and the like

Looking at a tiny utility app I made 6 years ago, it's 9KB, most of which will be the default things the compiler includes

koyote 132 days ago | | |

I recently made a tiny utlity app with a single screen, one dropdown and a few lines of text (it makes a single API call to populate the text).

According to my phone it's 25MB.

There's no assets, not even an app icon.

I have no idea what would be taking up more than a few hundred kb, let alone 25MB.

throwaway81523 131 days ago | | |

I remember hearing that even a trivial React Native app is around 100MB on Android.

paulddraper 132 days ago | | |

> a few dozen kilobytes

A "hello world" Android starts at ~5MB.

It is possible to make it smaller if choosing some non-default different tools.

jorams 132 days ago | |

> I had no idea common apps used to be just 10-30 MB. But are now hundreds of MB.

This is Android, but: 13+ years ago I had an HTC Desire. I was really struggling with internal storage space, regularly uninstalling and replacing apps just to be able to update others. Eventually I moved to custom ROMs just because they allowed some apps to be moved to the SD card.

I remember the biggest problem was WhatsApp, which was somehow over 7MB while the average was closer to 1MB.

On my current phone WhatsApp is 231MB. It's still pretty high up in the rankings, but doesn't stand out, and barely any apps are below that then-huge 7MB.

hn8726 132 days ago | | |

On Android most apps started bundling androidx/jetpack compat libraries that help deal with various API versions, and generally make the development much, _much_ easier. These days apps will also bundle the entire new Android UI framework (Compose) while in the past all the UI code was using framework classes.

Other than that, some popular and useful libraries will bundle native libs (for example for sql), and some ad/analytics/corporate SDKs will use native libs to share code between platforms and for obfuscation. These corporate SDKs (like Zendesk) will also notoriously break Android minification tools, because why bother

Dylan16807 131 days ago | | |

One of the struggles on my first android phone was fitting updates for the multiple google docs apps since they were all getting bigger and didn't share their redundant data. That phone had about 150MB for apps.

It's sad the laziness that happens when there's no pushback. The devs gain barely anything from leaving things this bloated, but barely anything isn't zero so now a million people have to deal with big files and wasted RAM.

kstrauser 132 days ago | |

My back-of-my-head benchmark is still my old Amiga. Here's[0] a full-blown GUI email app that was perfectly nice to use. The entire package, complete with all its custom GUI classes and 3 sets of icons, took 1.4MB uncompressed.

I know the thousand legitimate reasons why modern apps are larger. It's not all bloat and inefficiency, either, except in the harshest sense that old apps tended to use byte-optimized data structures like linked lists instead of faster, but less space-efficient structures like hash maps. They have to deal with higher resolutions, although the command to draw an empty white 320x200 square on the screen should be approximately the same size as to draw a 2000x1500 one. And yet, wow, it doesn't seem like it should need to be that much bigger.

[0] https://aminet.net/package/comm/yam/YAM20

jeroenhd 132 days ago | | |

Thunderbird for Android supports pretty much everything Gmail supports and probably more, but it's "only" 40MiB in size. Even on Android, that's a 3x size reduction.

I don't know why iOS apps in general are so much larger than Android apps (that doesn't just seem to be a Google problem) but you certainly don't need the full size of the Gmail app.

zffr 132 days ago | |

It’s probably frameworks + localized assets.

With dynamically linked frameworks you bear the cost of the entire framework (and its dependencies) even if you just use a few functions.

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

amluto 131 days ago | | |

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.

itopaloglu83 131 days ago | | |

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”

rerdavies 131 days ago | | |

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.

pjmlp 131 days ago | | |

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.

ksec 131 days ago | | |

>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.

renrutal 132 days ago | |

> a sudden jump to more than 200 MB near the start of 2017

Google Meet was launched in March 2017.

londons_explore 132 days ago | |

For a while there were app size limits for downloading over mobile data. That meant that if your app was too big you'd have terrible growth metrics.

recursivecaveat 130 days ago | | |

I remember Uber hit this pretty hard: https://news.ycombinator.com/item?id=26277501 & https://news.ycombinator.com/item?id=25376346 For them though the mobile-data thing was extra important since a first-time Uber user is likely to not be at home and needs the app in order to get home.

orthoxerox 132 days ago | |

I remember when Windows 95 was around 10-30 MB, ten whole diskettes or so.

paulddraper 132 days ago | | |

Now I can't even install Ubuntu without 4 GiB+

yieldcrv 132 days ago | |

When I doing mobile app development a decade ago, I found that many interviewers and clients were evaluating my experience more like an artist's portfolio, alongside a couple of arbitrary metrics to determine app scope

One of those arbitrary metrics was bundle size, how many megabytes on the app store was the app. The bigger the better and more serious it was.

At the time I was knee deep in optimizations, using SVGs, doing compression, even bitshifting, to make apps smaller for the companies I worked for. Reducing how many people would be bounced from downloading or installing the app.

And yet, that impressive 12MB app from a venture backed company with hundreds of thousands of users was getting me penalized for taking up so little space

I literally started putting dummy files in the app bundles and it worked for my professional goals. All kinds of premium marketing has similar fictions in them to convey value

so I can emphasize how its the difference between $50/hr upwork gigs inconsistently, and $500,000/yr at Google

ksherlock 132 days ago | | |

Back in the time of 3.5" demo disks, I know one group that filled up their disk image with random numbers so it wouldn't compress so it would look bigger and more impressive in file listings.

andy99 132 days ago | | |

This seems to be true for writing code generally. Why do something simple when you can show off how complex you can make a project?

I keep seeing tools that should be a for loop inside a script that instead are a sprawling project with all sorts of different files and class hierarchies and abstractions...

kjkjadksj 132 days ago | |

Having a sub 5mb app is still the strongest quality signal there is for ios. A shame you can’t sort and filter results by size.

nine_k 132 days ago | | |

As long as you don't need a lot of hi-res graphics. One of the no-frills icon themes installed on my Linux laptop (from which I'm typing) is 170M, just because it has a pack of icons rendered for each of the 8, 16, 18, 24, 32, 48, and 64 pixel sizes.

(And no, vector icons are not equally useful in this whole range of resolutions; you need to lower the level of detail for small resolutions to avoid pixel sludge, and increase the level of detail for high resolutions to avoid the barren look. Still, say, 3 versions in SVG format could be sufficient.)

allthetime 132 days ago | | |

If your app is 5mb to download but then needs to download 100mb of content your app is 105mb.

tarentel 132 days ago | |

Part of it is resolution. The icons and such in apps are much larger now than they were in 2013. Besides that I mentioned this in another thread but rarely will a team clean up after itself. There's probably tons of dead code and what not in a lot of these larger apps. I know all the ones I've worked in had a lot of bloat just from years of work. Some feature gets added 5 years ago by a team that no longer exists, it was turned off and no longer used but who is going to remove it?

Besides that, there's just a lot of garbage that gets added by various people with different interests. An unoptimized version of the app I'm currently working on has a ~15mb binary, the core app not including all the "extras" people have asked for. It has about 75mb of assets, probably 10-15% are unused but I have no idea. The download size is about 400mb.

BugsJustFindMe 132 days ago | | |

> An unoptimized version of the app I'm currently working on has a ~15mb binary, the core app not including all the "extras" people have asked for. It has about 75mb of assets, probably 10-15% are unused but I have no idea. The download size is about 400mb.

What are the other 310?

vbezhenar 132 days ago | | |

Icons should use vector format.

BobbyTables2 131 days ago | |

We once ran Windows 95 with Encarta in about the same amount of disk space.

We crossed lunacy long ago.

grugagag 131 days ago | | |

I remember my first PC had a HD of around 20Mb. It was vast at the time, I had so much software to keep me busy for a while that I I felt overwhelmed. Amongst those there was Windows 3.0, taking probably a whopping 3mb

vrighter 131 days ago | | |

My first PC (my parents splurged on a high-end machine (for the time, of course) only had 8MiB of memory and a 1 GiB HDD. It ran windows 95 and encarta just fine.

thedeadgamer 131 days ago | | |

Whoa, Encarta was such a great thing back in the day for me. Brought back memories.

I agree, that we crossed lunacy long ago, and that LLMs have not helped in the slightest.

amelius 132 days ago | |

> I had no idea common apps used to be just 10-30 MB. But are now hundreds of MB.

This is one of the reasons why these apps grow: because the user doesn't notice!

cyanydeez 131 days ago | |

Guys, do you think AI is like newage bloatware? Like, it's gigabytes of just things you're never going to need, and now ram prices are skyrocketing because they have no idea how to make it efficient.

In fact, they state the oppposite: To really make it go, they need petawatts of energy and compute. It's like Windows incarnate.

FpUser 131 days ago | |

>"I had no idea common apps used to be just 10-30 MB"

I wrote native Windows desktop application 10 years ago that still brings me some money. It has boatload of functionality and the size is 12MB. Competitors have similar app written in .NET. The install is about 1GB.

Marsymars 131 days ago | | |

.NET apps are relatively small until/unless you start pulling in many/large dependencies.

marcosdumay 131 days ago | |

> I had no idea common apps used to be just 10-30 MB

Phones used to have 4GB of flash memory... Some had 2GB.

wakawaka28 131 days ago | |

There are full-featured operating systems that fit on like one or a few floppy disks. Standard Linux distros would fit on a standard 600-700 MB CD, with some made for mini CDs being much smaller.

SirMaster 132 days ago | |

Hmm, mine is currently 673MB on iOS 26.

Fiveplus 132 days ago |

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.

kccqzy 132 days ago |

The table at the end is seriously misguided. You can’t compare the sizes of an iOS preinstalled app against a non-preinstalled app. It’s just a thin UI shell where the code for all the functionality is inside system frameworks. The Photos app is quoted at 4.2MB. Guess what, if you delete that, you still have system components to render photos, UI for a photo picker, perform analysis on photos such as face recognition, all the iCloud networking code to support iCloud Photo Library, etc.

tarentel 132 days ago | |

You can though because a lot of those things you're talking about are available for any app. Sure Apple does have some private frameworks and what not that aren't available to everyone but I imagine if you wanted to recreate what the photo app is doing you'd be able to in 4.2mb or less.

kccqzy 132 days ago | | |

The iCloud Photo Library doesn’t have any public APIs that I know of. You simply can’t recreate the Photos app completely, regardless of app sizes. Apple values deep integration into the system more than it values giving third party developers a fair chance at cloning their app.

loloquwowndueo 132 days ago |

> why is the Gmail app almost 80x the size of the native Mail app?

Apple Mail leverages libraries and frameworks already present on the device.

Google uses libraries and frameworks very likely already present on say Android, but on iOS they have to ship a gigantic runtime that implements those things the app depends on; this way they only have to write the app once for several supported platforms.

I’m just speculating by the way but it sounds like the likely reason.

You’ll notice Google Docs or sheets are equally gigantic because each also ships a copy of those enormous runtimes.

miki123211 132 days ago | |

There's actually a bit more to it than that. A lot of what Apple apps actually do is hidden in frameworks made for that one specific app, which, unlike with 3rd-party applications, are part of the system, not of the app itself.

Compare the size of Safari.app versus Safari Technology Preview.app (which actually ships all the frameworks it needs).

HPsquared 132 days ago | | |

Sounds like how Internet Explorer used to be integrated in Windows. That was quite contentious at the time!

loloquwowndueo 132 days ago | | |

If you have those apps handy and could share the sizes it would be very useful. I don’t have a way to check this. (Or do I? All I have is an iPhone )

stefanfisk 131 days ago | | |

I don't think that Safari should be used for comparison here since web views have a special place in the OS. Which of the other stock apps have a similar architecture?

morshu9001 132 days ago | | |

Reminds me of when people were clamoring for the ability to delete 1P apps to save space

HPsquared 132 days ago |

The article doesn't answer the question. The content can be summarised as "The Gmail app is 700 MB!"

HendrikHensen 132 days ago |

Well, something fishy is going on because there is literally no way that Safari, in its entirety, is 5.1 MB. The numbers for the others app seem similarly off.

It would be really hard to believe that somehow Apple has found some magic formula to make their apps 100x smaller than Google and Microsoft.

Much more likely is that the reporting by the OS is off somehow (probably most of the app functionality is tied up in shared resources counted towards system files, and not counted towards the app's size).

With respect, I would expect more from articles posted on Hacker News. More thorough research, and in fact an answer to the question.

jacobp100 132 days ago | |

Safari probably is that size because WebKit is a system framework, so it’s just the size of the UI code

afavour 132 days ago | |

Safari is just a wrapper around the system webview framework so it does make sense, although it makes the comparison very misleading.

nckh 118 days ago | | |

Safari is not a WebKit wrapper. Out of the box, WebKit can only display web views inside rectangles, and nothing else. A web browser is a lot more than its rendering engine.

akho 132 days ago | | |

So are the other browsers on iOS.

HumblyTossed 132 days ago |

The article compares the native (iOS) mail app which is (from the article) 8.7MB. What I believe is happening is that the gmail app is not a native app, it is some cross-platform monstrosity, so Google has to bring all the widgets and doo-dads that they wrote so that it looks just like it does on all the other platforms. The native iOS mail app is so tiny because part of iOS that the article mentions taking up 25GB contains all the native widgets and doo-dads that the native mail app can use.

mattacular 132 days ago | |

I think that's true and it's also a convenient way to "smuggle" in Google's most important doodads: their tracking apparatus which includes all of the single sign on and MFA stuff on top of the usual analytics

oenton 132 days ago |

It’s wild when you put it into context. I remember when Gmail first opened to the public with a whopping *1 GB* of storage… now the app alone almost exceeds that.

NelsonMinar 132 days ago |

On Android vs iOS, it's worth noting Android apps are smaller than iOS apps. The details are complicated but this report says after installation Android apps take up about half the space as iOS. https://www.safetydetectives.com/blog/app-storage-usage-rese...

One specific complication: Apple's store reports install size, Google Play reports compressed download size. https://www.emergetools.com/blog/posts/are-android-apps-real...

landr0id 132 days ago | |

Android also allows developers to split up their APK so features can be delivered on-demand: https://developer.android.com/guide/playcore/feature-deliver...

AFAIK iOS does not offer anything similar.

CGMthrowaway 132 days ago |

AOT overhead 200MB (ensuring app loads fast)

Frameworks 150MB

Assets for all screen resolutions 50MB

Google Meet/Chat/etc 100MB

AI models 25MB

taeric 132 days ago | |

I find "ensuring app loads fast" to be absolutely hilarious, here. What has to be done to help a mail app load fast?

And, snarkily, can they do this for the web page? On my decent connection right now, loading a new tab to gmail takes about 3 seconds to visibly load. Another few seconds to get so that I can interact with it. Is kind of hilarious to see how long it takes to load the compose window if I press "c" as soon as I see any of the app has loaded.

CGMthrowaway 132 days ago | | |

Starting with machine code expands lines of code 2-10x.

It's also taking helper functions and pre-evaluating them putting results inline, and unrolls loops (could be 5-50x increase where they exist?)

And it precalculates lookup tables (takes up space) for virtual methods.

xigoi 131 days ago | |

> OT overhead 200MB (ensuring app loads fast)

Yet there is a positive correlation between size and startup time…

einpoklum 132 days ago | |

AOT = Ahead Of Time? Attack On Titan? Something else?

wiseowise 132 days ago | | |

Mobile applications need to be AOT (Ahead of Time) compiled for the target device to have optimal performance.

kachapopopow 132 days ago | | |

it's ahead of time and AOT compilation is done at OS startup, not sure if that is being measured here.

CGMthrowaway 132 days ago | | |

https://en.wikipedia.org/wiki/Ahead-of-time_compilation

paxys 132 days ago |

I genuinely struggle to understand how apps can get that large. Games with hi-res graphics, sure. But Gmail barely has any assets. And they aren't shipping with custom runtimes or anything of that sort (like an Electron app) because Apple doesn't allow it. So how much code can you possibly write that compiles to 700 MB?

lostmsu 132 days ago | |

Could be similar to https://news.ycombinator.com/item?id=46134178 (code duplication for locality for a tiny perf gain).

ChrisMarshallNY 132 days ago |

I'm assuming one reason is frameworks. They can get quite big.

Another reason, is rusty code (not Rust. It's a play on the saying "Code doesn't rust", which I used to hear, last century).

It does, indeed, rust. Actually, "rots" is probably more apropos.

I'll bet that's the reason that Xcode is such a pig (makes GMail look like an anorexic).

Code is created that people no longer understand, so they are loath to make large changes. They just do enough to fix a bug, and pray that they don't need to dig any deeper. One of my first software jobs, was exactly like that.

When that happens, the code never shrinks. It just accretes.

csoups14 132 days ago |

The easy answer: Google simply does not care. Some mix of: they don't measure it, they don't look at it, they don't goal around reducing it, nobody's performance review is going to be better because they reduced it, no director is asking product teams why they're increasing the app size. It's not surprising why these companies don't care, because it's a tragedy of the commons. The better question is why is Apple allowing these companies to ship apps that unnecessarily take up a meaningful amount of storage space?

paxys 132 days ago | |

> why is Apple allowing these companies to ship apps that unnecessarily take up a meaningful amount of storage space

The answer to this one is obvious - to incentivize you to buy iPhones with more storage and/or higher tier iCloud plans.

roesel 132 days ago |

It might have to do with the fact that (at least on iOS), you can participate in a Google Meet call with just the Gmail app, as well as authenticate sign-ins, and who know what more.

Could the main issue be Google is shipping apps within apps?

RachelF 132 days ago |

Mine is not 200MB on Android - the base apk is 67MB + 32MB for the ARM v8a specific libs. This is the code, the local caching and other data might make up the rest.

For Android, you can check [1] Download the apk, rename it as a zip and look inside to see the files.

A quick file analysis of the 67MB shows around 58MB of java code and some 32MB of ARM libs, 31MB of this is the libvideochat.

[1] https://www.apkmirror.com/apk/google-inc/gmail/gmail-2025-11...

tonymet 132 days ago |

I’ve noticed most popular apps are pushing 500+MB. Most likely they are shipping debug builds, with loads of third party deps, so they can send crash reports from production with meaningful stack traces.

Until Apple penalizes app developers for app size, nothing will happen. Most consumers are not aware of the impact , until they go to clean up their phone.

There isn’t much usable free space on the device after the OS, and now having 50+gb of used space from apps, means your own content (photos, music, videos) doesn’t fit.

There isn’t much incentive regardless, since Apple merchandise’s iCloud storage. Bloated apps actually drive iCloud sales. A lose-lose for the consumer.

jmclnx 132 days ago |

The question why is almost all modern apps pushing around 1G.

It is dependencies, if you ever compiled almost any GUI application via prots/pkgsrc on a BSD, you will be shocked by the dependencies that application needs, it is obscene.

tarentel 132 days ago | |

It is dependencies but not from the GUI. As someone who has worked on several very large apps I can tell you 99% of the bloat is garbage. Someone somewhere wants this SDK from their friend's company in the app. Some manager wants to track X using this very specific framework. Some designer decided to add in animations in one screen that requires another framework to run and also 10mb in assets. etc, etc, etc. If your app is 10+ years old this all adds up and no one ever cleans any of it up. There's probably like 100mb of crap you can delete that doesn't even work anymore but who has time to remove that?

burnt-resistor 132 days ago |

The Facebook and Instagram iOS apps were/are enormous codebases. Absurd, sprawling monsters with tons of dead code, duplication, and old stuff.. like being written in mostly Objective-C.

I imagine the Gmail app also suffers from having zillions of engineers touch it without being incentivized to make it better or smaller, only to add features and impact for the all-important performance review.

Add zillions of instrumentation and third-party frameworks, each with piles of dependencies, and apps will grow without bounds like molecules of gas to fill the container.

lkurtz 132 days ago |

I believe it is because it includes a suite of enterprise management features in addition to Gmail-related features. (Search for "google basic mobile device management" for more info.)

arjie 131 days ago |

One of the reasons the Facebook app was large was that they were using Thrift or something and generating a tremendous amount of code for their API interop. Protobuf+GRPC is similarly heavyweight, so I wouldn't be surprised if some megabytes were dedicated to the generated code. But hundreds of megabytes is wild. It has to be one-package compatibility as opposed to specialized app packages for different form factors etc.

kccqzy 132 days ago |

People need to reread this classic piece from 2001 every so often: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...

As a regular user, you are probably using 10% of all features available.

wackget 132 days ago | |

Don't blame the users. Unless Google have hidden a copy of Crysis inside the Gmail app there's no hidden functionality which should come even close to requiring hundreds of megabytes.

esafak 132 days ago | |

Gmail barely has any features, which haven't changed since it's inception. Most of the code is in the cloud.

kccqzy 131 days ago | | |

A lot of features are configurable by the domain administrators. As a user of the @gmail.com email, you won't see any.

fx1994 132 days ago | |

This might be true but most of time its just bloat no one uses.

fooblaster 132 days ago |

10 MB mail app. 690 MB local llm to write snarky emails for you.

ineedasername 132 days ago |

I know that in some cases, apparent bloat like this is related to needing to support so many potential devices and versions of the underlying OS. Google has to support, on iOS, roughly 6 years of devices and their variations + OS variations on them. Each of these may require their own libraries compiled against it, for optimal performance or because it simply is less practical to engineer non-breaking updates against new SDK and HW versions in the same codebase without introducing complexity.

Apple, on the other hand, doesn't have to do this. They can integrate at lower levels and even with all else being equal can develop updates with perfect insight on the ecosystem and foresight on things to come.

Somewhat supporting this possible explanation is that, similar to Apple on iOS, Google's apps on android are significantly smaller.

datadrivenangel 132 days ago |

Google and others are putting 2FA notifications in their regular apps like gmail. I had to open my gmail app to get a 2FA code instead of my google authenticator app today... which is very weird and probably increases the needed security of the gmail app in addition to the size

SoftTalker 132 days ago | |

They use the YouTube app for this also.

inetknght 132 days ago | |

You really think 2FA notifications cause so much bloat?

datadrivenangel 132 days ago | | |

Google Auth on ios is 38MB. Assuming the core code is probably ~5-50%, which would be 2-20MB added to the gmail app.

On the middle side of that range, extra features adds up fast.

calin2k 132 days ago |

maybe because we need to be pushed to buy minimum the 256GB versions of phones. it is a wintel deja vu

aaronbrethorst 132 days ago | |

Why would Google try to maximize Apple's revenue?

mNovak 132 days ago | | |

Bloat the apps, push users into a high tier iPhone, some % of users settle for a more affordable Pixel. Not that Android apps are that much better.

dewey 132 days ago | | |

Google is also selling phones? Not a great point as it's probably not really a revenue driver for them though.

wiseowise 132 days ago | | |

Duopoly. Both get richer.

Etheryte 132 days ago |

For me, the most important takeaway from the article was that the Passwords app supports 2FA codes! I was not aware of this, that's nice and getting rid of Authenticator is one less Google thing to worry about.

paxys 132 days ago | |

Having both your password and 2nd factor in the same place isn't the best idea however.

Etheryte 132 days ago | | |

They're both on my phone anyway, so I don't really see the difference? Whether it's in one app or spilt across two apps makes no difference if there's no extra layers between. Having it all in Passwords is better in that regard, since it requires you to use Face ID to open the app.

dangus 131 days ago | | |

I don’t think it matters much. In 1Password you still need your secret code to login in addition to your password. It essentially acts like a second factor.

I could give you my 1Password username and password right now and you wouldn’t be able to access it.

Being logged in to my 1Password essentially verifies that you have a physical device of mine.

dangus 131 days ago |

I’m surprised so few comments have pointed out how this doesn’t matter at all to anybody. The “apps are too bloated” debate is a dessicated horse.

1. You don’t even have to use the Gmail app to use Gmail. Pick whatever flavor of client you want, they all support Gmail. Apple Mail, Outlook, or something else entirely.

2. If you buy the shittiest available new iPhone it has 128GB of storage. Used iPhone 15 on Swappa with 512GB is <$500. How many of you need hundreds of apps installed on your phone?

3. Nobody’s forcing you to use Gmail. Email is an open federated standard. Use something else.

nottorp 132 days ago |

Incidentally, the last ssd i bought at the beginning of last year now costs double what i paid for it.

Ram is what, 3-4x?

It's a great time to ship more bloated apps, the suckers will enrich the hardware manufacturers, won't they?

asadotzler 132 days ago | |

Closer to 2.5x right now, likely to hit 3x this year.

elpakal 131 days ago |

I maintain an app size inspection tool that runs locally on your macOS and added the file inspector (Sunburst chart) for Gmail if anyone is interested in exploring its contents.

As others have pointed out, the main executable is huge (~300MB) and there are a lot of localization files, but not too much traditional asset duplication.

You can click into different slices of the app and see what it's made of if interested: https://dotipa.app/?app=Gmail#examples

ramsj 132 days ago |

This is why I use installable PWAs wherever possible. On my Android phone right now, the Outlook PWA uses 281kB. You still get notifications, but I haven't measured if data usage is higher.

heisenbit 132 days ago |

Maybe, just maybe should Apple vary the amount they charge by app size.

maratc 132 days ago |

> Also, can someone explain why Microsoft Authenticator is 150 MB to show 6-digit codes?

That one's on the author. Duo Mobile is 2MB and shows the same 6-digit codes just fine.

josefresco 132 days ago |

1.15 GB for me - dear god.

There's a comment in the article with two helpful links:

https://news.ycombinator.com/item?id=30443570 https://www.emergetools.com/app/example/ios/com.google.Gmail

The bloat? Mostly "localization".

kuekacang 131 days ago | |

Except the text is stored as image, I can't imagine localization would be that large.

charles_f 131 days ago |

Until someone stops installing gmail because it's too big (and it's coming back as a signal), I doubt anything will be done about it. In the absence of constraints, things just keep growing... without constraints. The costs of pruning/shaking embedded frameworks, refactoring, optimization, etc. cannot be justified if it's not signaled as a problem by customers.

nromiun 132 days ago |

I just looked at Gmail on my Android phone and it is only 164 MB. That is a big difference.

Also, one thing that annoyed me when I used iPhones is that you can't remove an app's cache without reinstalling it and losing all your data. And most modern applications think cache is free so they use a lot of it. Many times it will exceed even your installed apps or data size.

tgma 132 days ago |

For perspective, the entire iPhone OS 1.0.x ipsw image was around 100MB in 2007 (and there was a 4GB iPhone SKU for a brief period.)

popoflojo 131 days ago |

The real reason is Google has no incentive to make it smaller. In fact there is incentive to make it bigger. If your phone runs out of space you need to get a new phone with more memory, or move pictures and the like to the cloud, both of which are good news for Google. So why spend any effort keeping the size down.

lifestyleguru 132 days ago |

Sometimes I allow App Store to use mobile data because how much an app can weight, 50MB? Then suddenly 1GB of mobile data is gone.

pmontra 131 days ago |

My guess: phone get more storage so we can build fatter apps. With RAM and storage getting more expensive maybe developers will face some pressure to deliver slimmer apps but I don't have many hopes for that. It's going to take at least a couple of device replacement cycles with lower and lower RAM and storage for that to happen.

neuroelectron 132 days ago |

Of course it's self-hosted intelligence gathering or metadata auditing. This is Google we're talking about. They're "pushing compute to the edge," taking advantage of more powerful mobile processors to reduce their own infrastructure cost while still providing that sweet sweet Big Data, as they used to call it.

3ple_alpha 132 days ago |

Android seems to be a bit better in that regard: not in the sense that applications are smaller (though I think they are, slightly), but rather that you can easily unpack or decompile most of them and see what's inside.

There it tends to be mostly due to dependencies, including some native libraries in multiple copies for 2-3 CPU architecture.

waldrews 132 days ago |

My whole cat is, what, a couple gigs of DNA?

elpakal 132 days ago |

If you're interested in iOS app size analysis, I build and maintain this https://apps.apple.com/us/app/dotipa/id6742254881 ($4.99). Happy to share download codes, HMU at info [at] dotipa.app

neop1x 131 days ago |

Software has gotten out of control. A simple Gmail client is now larger than an entire operating system was just a few years ago. And their “web apps” like Google Cloud Console, are so slow that they’re practically unusable in Firefox. Pinnacle of software engineering at Google :/

urbandw311er 132 days ago |

I’m just guessing but probably because it’s not just GMail, it’s likely chock full of all Google’s other walled garden nonsense. Hey, you installed GMail? Great, here’s a 2FA client for all federated Google logins everywhere too. hell i’m surprised it doesn’t contain the entire chrome browser as well.

mskogly 131 days ago |

I haven’t made iPhone apps but my guess it that the size comes from bundling libraries and dependencies needed, sort of like how venv includes as snapshot of python and all dependencies into your project folder. Apple core apps probably uses iOS libraries (25GB) already on the device

rekabis 132 days ago |

Maybe because it’s an Electron app?

Sure, Electron does not come natively for iOS. But with tools like Capacitor, you can take a web app (even an Electron one) and package it for iOS/Android, adding native features and running in a native WebView, allowing it to be an “Electron for Mobile”.

conradkay 132 days ago | |

usually electron apps are 150-300MB

transcriptase 132 days ago |

You just need to check the version history for mobile apps to see what the developers are doing! It’s a wealth of information on new features and changes.

For example here’s the Facebook app for iOS:

  543.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (2w ago)
  542.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (3w ago)
  541.1 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (1mo ago)
  541.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (1mo ago)
  540.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (1mo ago)
  539.1 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (1mo ago)
  539.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (1mo ago)
  538.1 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (1mo ago)
  538.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (2mo ago)
  537.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (2mo ago)
  536.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (2mo ago)
  535.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (2mo ago)
  534.1 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (2mo ago)
  534.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (2mo ago)
  533.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (3mo ago)
  532.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (3mo ago)
  531.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (3mo ago)
  530.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (3mo ago)
  529.1 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (4mo ago)
  529.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (4mo ago)
  528.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (4mo ago)
  527.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (4mo ago)
  526.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (4mo ago)
  525.0.0 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (4mo ago)
  524.1 — Our teams have solved many crashes, fixed issues you’ve reported and made the app faster. (5mo ago)

innagadadavida 131 days ago |

Size should be a product metric so that it is tracked and optimized. Same goes for memory consumption. It's easy for product to come up with features and run the enxt cool experiment but your users don't care about any of that.

tgsovlerkhgsel 132 days ago |

Android is slightly less horrendous but still bad - probably because at least in some markets enough people have low end phones that size does somewhat matter. I suspect Uber made optimizing app size a priority once they realized that their 1 GB behemoth was hovering on the top of the "things you can delete instead of your wedding photos if you want to be able to continue to use your phone" list, and they were losing customers over it. But there are still apps that are hundreds of MB with no valid reason to be that fat.

Meanwhile, well-written browsers - which are essentially whole operating systems - are in the dozens, so this is 100% bloat.

There simply is little incentive to optimize apps for size, because someone else pays the price and there is little consequence for making it big. Slapping another data collection or ad SDK into the app is easy and free.

If the EU was serious about it, it would consider it part of the ecodesign rules since it forces people to buy new phones for more storage much earlier than needed.

If the app stores were serious about it, they'd either re-introduce the hard cap and stick to it, or at least show the size prominently. Or start charging fees for bloaty apps. At least on the mobile version of the Play store, I don't think you can even see the app size without starting an install - let alone search or filter by it. It's as if they want to encourage bloat.

danielktdoranie 132 days ago |

I just use the gmail mobile website on my smartphone and put a link to it on my Home Screen. So many of these services you don’t necessarily need an app for, unless you just enjoy giving them your personal data or something ha ha

didip 132 days ago |

Because big enough tech companies always shipped their org charts in their products.

MagicMoonlight 131 days ago |

And every single update to every single app is another 500MB. Even if the notes are just “we love enhancing our app, so here’s some tiny bug fixes or something. We won’t actually tell you what we have changed”

anal_reactor 132 days ago |

Because most phones have enough memory to handle all the bloat, and when they don't, Google can sell those people cloud space. Not to mention that adding more memory is how phone manufacturers earn money - out of my ass example just to illustrate the concept: 100GB phone costs $400, same phone but with 200GB memory costs $500, 100GB memory chip costs $20, manufacturer pockets the difference. Having bloated apps and no SD card (iOS doesn't support SD Cards, Android makes them work like shit on purpose) justifies in the eye of the consumer the necessity of extra memory. Most people have fast internet connection so download time is always acceptably small, no matter how much bloat you put, not to mention that updates are in the background anyway.

The economic pressure to keep apps small is literally negative.

unsupp0rted 132 days ago |

It does do a lot of auth / security stuff for the entire Google Account... not 700 MB worth, but still thinking of the Gmail app as "just an email app" doesn't do it justice either.

metalman 132 days ago |

even though I have more data than I ever use on my plan, after 15yr's exclusivly on mobile data, I reflexivly look at the size of anything before I download something, 700mb is bonkers for email, and I have started to reject many other apps, based on there improbable sizes. useing android my phone has gmail iremovably installed on my phone, but was disabled before I even put a sim in it, but in spite of this, having just checked, it has user data, something in cache, and has used some internet data. how creepy is that.

pgib 132 days ago |

This may finally drive me to just use Apple Mail for my Google Workspace account. I know it's not a fair comparison, but an app I made that's in the App Store is only 8MB.

isaachinman 131 days ago |

On the flip side, our iOS app which _uses the Gmail API_ and also supports raw IMAP is ~14MB:

https://marcoapp.io

titzer 132 days ago |

My prediction is that this will continue to occur indefinitely.

The conversation is always the same, only there is another zero on the end.

We'll have terabyte apps in not too long.

(100% serious)

drnick1 131 days ago |

Why are such apps needed at all? The point of open standards like IMAP is precisely to avoid the need for multiple clients.

phplovesong 132 days ago |

Framework mania. This has been the problem for years. Webapps bloat like crazy, and now with AI the sloplevel has gone berzerk.

Digit-Al 132 days ago |

On my Android phone, just the calculator app is 13MB. How in hell is it 13MB just for a calculator? It beggars belief.

atmosx 132 days ago |

Not sure how many ppl know this: you can use another email provider, e.g. user@yahoo.com, to register to YouTube.

adzm 132 days ago | |

Still need a phone number though

atmosx 131 days ago | | |

Phone number for youtube? I don't think so, need to double-check.

j45 132 days ago |

I didn't use the Gmail app for the longest time, always used third party, not sure why I started..

1vuio0pswjnm7 131 days ago |

Why is the Gmail app not open source

Same goes for other other bloated apps mentioned in the blog post

pacifika 131 days ago |

If the AppStores would consider app size in ranking we might see an improvement.

pavel_lishin 132 days ago |

I was just wondering why the Adobe Acrobat installer is nearly a gigabyte in size.

transcriptase 131 days ago | |

Personally I always wonder why a pdf tool puts 3-6 background processes on startup that are constantly doing something with my CPU and internet connection when my PC is otherwise idle.

xnx 131 days ago |

Good news(?), storage is expensive now, so this may get more attention.

culebron21 132 days ago |

Not surprising, sadly. In 2022, a friend who did trekking, asked how to view files with national parks borders on a map. I recommended installing QGIS desktop (geospatial viewer/editor of files/database tables). He replied: "1 GB of download?! Seriously?!" I was surprised, because last time I had paid attention, maybe in 2016, it was ~200 megs. I checked, and indeed, it weighed 1 gig. I checked in 2025, and it's beyond 1,3 gig now. And it's FOSS, not commercial bloatware you might think. I have no idea what they stuff it with.

Just yesterday, I wanted to generate a GeoTiff on a macbook. To do it in a simple way, you need libGDAL, a geo-spatial abstraction library that exists since maybe the '90 and supports all thinkable formats. Under Linux, you just install it together with QGIS as a dependency. Mac is still unix, so you may think, a 3-decades old library, with few patches to support modern formats, should be just a couple of megs, right? Brew suggested downloading ~2 GB of ~100 packages!!!! Half of them were aws-* (yes, AWS tools), and 1 GB of LLVM!!! (is it their whole GIT repo with 10M SLOC?)

For geotiff, I ended just using standard Tiff library, inserting my 4 geospatial tags with a few lines of code.

ChoGGi 132 days ago |

Bloated libraries and support for multiple versions of iOS/phones?

bigbuppo 132 days ago |

Probably because it has three embedded versions of libcef

David_Osipov 132 days ago | |

Spot on! We tried to somehow reduce the libcef size in our B2B app - barely could do that. We had to employ some fancy compression techniques, but still this thing is huge!

esafak 132 days ago |

Perhaps someone can decompile the app and find out.

theLegionWithin 130 days ago |

not having 512gb of storage on your phone in 2026 is the definition of failing

agumonkey 132 days ago |

2nd order Jevons paradox I guess

dbacar 132 days ago |

It is bloatware for a reason, to force you a cloud subscription, not for your money (which helps though) but your data.

rconti 132 days ago | |

Google writes bloatware for iOS to force me to buy a cloud subscription (?) from... Apple?

dbacar 131 days ago | | |

Gmail android size is also ~750MB.

n4bz0r 132 days ago |

Why is my banking app 1.5GB?

tqian 131 days ago |

Bigger than Windows 98

wrs 132 days ago |

Not only is the YouTube iOS app huge, it uses an atrocious amount of additional storage. It was using over 2GB on my iPad for...something...and the only way to clean that up was to delete the app and reinstall.

eYrKEC2 132 days ago |

Can we get dark-mode for another 5MB possibly?

(700 MB more is also an acceptable increase for this feature)

On second thought, I love looking at on-duty page emails in the middle of the night with 7 million lumens blasting my retinas.

kernal 132 days ago |

The Apple vs Google app size comparison is so disingenuous. It doesn't take into account all of the preinstalled iOS dependency libraries used by these Apple apps.

turtlebits 132 days ago |

I'm sorry, but that "table" at the end of the article is infuriatingly confusing.

sprinfo 131 days ago |

Love how it ends with "Why you ask, your guess is as good as mine" lol.

mbesto 132 days ago |

Hacker News is currently sitting at 130 MB. I simply do not understand how these things are calculated but I suspect the calculated amount that the Chrome tab diagnostic isn't a consistent way of comparing to other application memory usages, or at least a mental model that makes sense to most people (e.g. whats a lot of memory consumption? what should it be? is it too high, is it too low? etc.)