> 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.
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.
> 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
Hello world Android app includes a lot of dependencies like compat libs, constraint layout, kotlin runtime. These are not essential and can be removed.
> 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.
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
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.
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.
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.
> I don't know why iOS apps in general are so much larger than Android apps [...]
Rough guess: It probably wouldn't be this dramatic of an increase, but could it be something to do with iOS disallowing Just-in-Time compilation, and forcing Ahead-of-Time? I've always wondered.
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.
>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.
You could get localizations OTA, but that's engineering you need to do to make that happen.. or a product you purchase, as there's various localization managers offering these options in their software.
Proper unicode font support is like 1.2GiB (noto, but I haven't found any complete unicode font collections that are significantly smaller). There's bloat for sure, but supporting universal text is one that I think is not a waste of space.
Maybe not proper support, but when I tried NetBSD recently my entire installation was around 1.5 GB on disk and seemed to handle Unicode well enough for me (for languages I care about). Not doubting some more packages would be needed to support every language, but happy everything wasn't installed by default.
Ye by proper i mean being able to render unicode in any language without tofu. I get that not everyone needs that, but its a reasonable thing to have on your disk in 2025.
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
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.
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...
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.)
I have a couple that are honest sub 5mb apps. Some of my favorite apps on my phone. Limited featureset that does what it says on the tin. Loads instantly. Hardly uses battery at all. I wish everything was like this.
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.
> 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.
Frameworks from other companies. A lot of it is analytics/tracking, some payment processing, etc. There are a few open source libraries we're using as well but those probably are <5mb if I had to guess although I never checked.
Again, a lot of these companies have also been around so if my app has a ton of bloat from years of work, we're bringing in frameworks from other companies who have been around for years as well and probably have a similar amount of crap in their code. Plus they probably want to track everything we're doing so they're bringing in their own third party libraries. It's kind of ridiculous but that's where we're at.
Bigger companies won't have as many third party libraries as they can afford to do it in house but they're still bringing in similar sized libraries to do the same things.
Imagine, it's not just making sure your code is secure, but your also counting on all those libraries's being secure. Let alone all these frameworks as you say - payment, advertising, analytics... You could have the most secure code ever, but when it is just one link in a chain outside your control, best not overthink it or you won't sleep.
You can see why bug bounties get rewarded well. Though mindful, money is not what drives everyone. Then there are the greedy, in which such exploits value on the black market can be higher. Not forgetting government agencies level.
I wonder which email client will break the 1GB mark, and when we will see a resurgence in reducing bloat. I'm sure that phase will come, did for Microsoft once.
Woof. This is just so wild if one ever stops to think about it. ~300mb of tracking for a single app is bigger than the entire hard drive of a fully internet-capable desktop computer in the mid '90s.
Huh, is there a requirement that they be rasterized at build time? If I had a choice, I'd rather ship the SVGs in the bundle alongside a renderer like ThorVG and render at runtime. The renders could even be cached if the rendering itself was expensive.
If you’re including these assets as UI elements, they would be rasterized anyway and copied to a GPU bound buffer for the frame blit. Doing so at compile time increases runtime performance.
You can of course override this behavior and redraw your vector every 8.3 ms if you want, but I promise you that this is not faster. For sparse pyramid-tiled vector images like Google/Apple maps, this is a two step process using the latter method followed by the former.
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.
we've been able to "preserve vector data" with pdf and svg image resources on ios for a long while now... compile-time rasterization is the default though...
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
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.
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.
>"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.
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.
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
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.
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.
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.
I'd bet my money that you can roll your own iCloud-esque Photo Library and it still won't be near the 100MB territory if you just use native libraries for the UI. Everything you'd have to do from scratch: cloud auth, encryption, syncing, compression, transcoding, etc. is all at most a few MBs combined, not to mention that all of these except cloud auth are already in the built-in libraries on iOS that any app can freely use.
What the apps here are doing is shipping whole (UI) frameworks and tons of old code and assets that aren't really used anymore but nobody dares to remove.
You can access iCloud from an iOS app, it has its own public framework called CloudKit, so you could create your own version of it. If you don't like that example Chrome and Edge are both forced to use WebKit on iOS but are still much larger so.
If the point of a Google Photos app is to access / back up your photos via Google Photos (web), then it seems rather dubious that making API calls to a cloud server is an endeavour that takes hundreds of megabytes of code and resources.
If, rather more accurately, the point of a Google Photos app is to provide a photo editor and various other photo-adjacent functionality coincidentally including the ability to back up photos to Google's servers, then again that raises the question of why Apple's equivalent app is so much smaller. Are there image-related system frameworks that Google cannot use that Apple is using? Then sure, feel free to count them in Apple Photos' "true" size. But if Google simply won't use them then IMO it's fair to ask if the size of what they're shipping is worth it.
> 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.
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).
'90s Microsoft was like early christians: harshly persecuted, only for everyone else to eventually adopt their ways. In this metaphor, emperor Constantine is probably Steve Jobs.
Harshly persecuted how, exactly? They got a slap on the wrist, still continued to ship IE as the default browser and stayed dominant browser vendor until another monopoly started to abuse its position.
The verdict significantly hamstrung their internal developer processes. Yes, IE didn't go anywhere, but the path of tight integration of web and OS was effectively abandoned for several years, and they generally toned down integration features between their products.
Which brings up another point: the total used disk space of a Windows install with Internet Explorer and Outlook Express used to be way smaller than Gmail alone is now.
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?
To add to the comparisons. Protonmail is showing as 180 MB on GrapheneOS. Add in user data and cache and it's 495 MB. I don't consider myself a big email user so I am a bit appalled.
> Product Requirement: Even if the user deletes the Chrome app, the Gmail app must work to display HTML emails, the authentication screen including 2FA options, etc. Can’t rely on WebViews for security reasons.
It doesn't, that's Android Webview which is distributed separately. It may however bundle its own instance of the Chrome networking library which is a few MB itself.
For apps like Gmail and a handful of others, they are big enough that they need multiple layers of fallback. e.g. they can't just use a networking layer, they need a fallback separate implementation in case that breaks, so that they can recover. They might have 2 or even 3 options for some of the critical parts, all so that if stuff goes wrong they can as close to guarantee recovery as they can get.
Mobile is quite specific in this regard, because you don't have hardware access, network is heavily restricted, battery reduces the amount you can do, etc.
Windows 98 and Office 97 in their entirety are less than 700MB combined. How have things gotten so out of hand that a single email client needs more than an entire OS and office suite used to?
I’m sorry but ~700MB of compiled code, text, and vector graphics is a lot of assets, almost a truck load. It doesn’t look like they care about how much space they take in users’ devices at all.
There's a few other apps that are ridiculously big. Like the DJI Mimo app. It's an app I need for my DJI Mic, to change 4 settings on it. It needs 800MB for that which is absolutely ridiculous. Also I need to sign up for an account to use it even though the Mic works completely locally and it just changes the settings over USB.
It's absolutely fucking ridiculous to have an 800MB app for this and the reason is just marketing. It's full of stupid videos promoting their stuff. And the account just causes stupid spam. I should have returned the damn thing to be honest.
Ps pardon my french but I'm really annoyed about this and in this case it's warranted in my opinion. 800MB is ridiculous.
I call it Marketing Driven Development, having lived through it at a previous job. It really sucks. They give engineers no time to breathe and do maintenance code changes.
Doesn't the Mimo app work for many devices not just your mic? While your mic might not need a lot of the code, someone using one of their other devices might not need your mic's code either. I can totally see why DJI would want a single app to control any of the DJI branded devices rather than dealing with multiple app store approvals. It would also be confusing for the end user as in "Which device am I using so which app do I need to use" would be a nightmare for all involved.
Just for the comparison, Damn Small Linux is still around 700 MB, and contains Linux kernel, desktop environment, web browser, office suite, and other software.
Mimo app will never support as many devices as Linux kernel does.
Feels like we are able to build software solutions for much more challenging problems than "only download the part that the user needs instead of everything and the kitchen sink". The explanation you provided doesn't make me feel even a tiny bit better about the problem. It just details how it came to exist.
Yes!! I was thinking of doing that myself but I don't have the chops to create an android app and no time to learn right now. But the protocol can't be that hard.
DJI lost the plot years ago unfortunately. They reeeeally wanted their app to be this whole bespoke platform experience thing and it’s been downhill ever since.
I did a DFU firmware update app for Jawbone once. after a bit of screwing around trying to figure out some of the reset paths we were good. and then the marketing people got involved. this was a customer touch point, and opportunity to reenforce the brand that just couldn't be ignored.
Apps like that often contain (many?) short high resolution videos to show how to do an initial connection or something that can take up a ton of space.
They could decouple the video download from the app download. Then they could even update the video independently if needed. Not everyone that downloads the app needs the videos, and even the ones that do I’m sure would be happier to reclaim the disk space after viewing them.
I often use the DJI MIMO app while out of WiFi, and would rather not download a large video separately. For the record, I do not like the DJI MIMO app (because it is the only app for their 'Pocket' products, and MIMO doesn't support tablets well), but I think this decision is a reasonable one.
I did consider this, but I'm curious: what are you doing that you need to watch a video out of internet range, that you couldn't have done while testing things out while in range? Isn't it risky trying something for the first time in the field without having already practiced it? I do understand that not all things can be anticipated.
Logi Options+ is 500 MB to configure a few extra buttons on a keyboard or mouse. Back in the days things like these were a few kilobytes(!) control panel extension.
The article is the question though, the question deserved to be asked.
And Gmail deserve to be shamed for shipping almost a gigabyte of stuff for a mailbox. Wouldn't be surprised if they accidentally/intentionally built the whole youtube client in there.
I think this might be closer to the truth than you might think.
Due to the absence of (cross-app) shared libraries on at least iOS, developers often end up building big company-internal libraries that then have to be shipped with all of their apps.
Tree shaking isn’t perfect, and the result are these > 0.5 GB monstrosities.
Static linking will do that. Imagine you have 400mb of binary objects your app depends on. Libraries your company uses for app analytics, SSO, 2FA, Corporate service bus api, etc.
You statically link all those for your 50mb Swift UI app and bam, you’re in the 700mb range.
You'd be surprised what ends up dragged into where when you have a build system that makes it easy. Just look at the npm.js mess (and what kind of things ended up depending on what kind of other thing) if you want an example.
On Android, sharing code is much more feasible than on iOS as far as I understand it, especially if you're Google and can demand that everybody using your apps has Play Services installed.
I've been using gmail since the early beta days and was never aware of this functionality. But on closer inspection there appears to be a highly stylized (unrecognizable) camera icon there that takes me to, I guess the long lost cousin of Google Meet?? Why are these apps welded together? What a bizarre decision. I thought Meet went to The Graveyard along with Allo and Duo and Wave.
My work uses GSuite so I’m using Meet every day. I find it mildly useful to have the functionality built into the Gmail app but at the same time I see zero loss in having it be a separate app.
Meet still works on Pixel phones as a solution/parity for FaceTime. I wonder if it's bundled in the web build or they're the same build under the hood.
We don't need that to be pre-loaded on the device, do we? how often are they used? and when one is set to be used, the user is definitely online already, just grab the one then
Gmail started by giving 1 GB of free storage to users as a carrot. Over 2 decades later, how much does it really matter if the app goes from 70% of that down to even 10% of that, and would that outweigh what else people actually want to see done instead?
I mean, it's certainly not anything to boast about from a technical perspective. I just don't know whether it's really enough to warrant any shame for the product though.
It's quite common in UK English (and maybe others, I don't know), to refer to "singular" or collective non-people entities (such as companies, I know Gmail itself isn't one) using the plural form of verbs.
This isn't in my natural speech, but I quite like it; it seems to kind of imply "the people behind [company]" rather than anthropomorphizing the company itself. ...generally though I think it's just colloquial convention and not that deep.
There's something funny about someone trying to be smart and pointing out a typo or some other minor irrelevant error only to be proven completely wrong.
Gmail is a product, but the comment wasn't saying "Gmail the product deserves to be shamed... ", more like "the Gmail team/devs/company deserves to be shamed...", which is why the plural still made sense to me (given the omission of an explicit "team"). The singular makes sense to me too.
In any case, I wasn't really interested in correcting or proving anyone right or wrong, just pointing out an interesting linguistic detail and where the grammar may have come from.
Can you "shame" a product, though? Obviously not. So you're shaming the people who built Gmail, the organization - hence the plural form is acceptable.
> There's over 20k files in the app, 17k of which are under 4 kB. In iOS, the minimum file size allocation is 4 kB, so having many small files causes unnecessary size bloat. Gmail could save 56.4 MB by moving their small files to an Asset catalog
Yep, localization is a huge size bloat for enterprisey apps that support many locales. There is no Apple provided way to dynamically download select localization packs based on the device locale. Meta came up with their own solution: https://engineering.fb.com/2022/05/09/android/language-packs...
The small filesize issue is something we commonly see in games, was surprised to see it for Gmail.
130 MB for localization? At 50 languages that would be 2.6 MB/language. If we assume an average 50 bytes per string and another 50 for an identifier, that's 27,000 strings.
That doesn't seem right. Localization feels like it should add a few MB. Not over 100. (Plus shouldn't it be compressed, and locally uncompressed the first time a language gets used?)
Localization doesn’t just mean string translations. Apple platforms give you the freedom to redo the UI to fit the language. For example, parts of System Preferences (not sure about Settings) would look completely different in languages with long words because the original design for English simply didn’t fit. The translators rearranged buttons to make the text fit.
I just looked. In this case, it is just string translations.
In the version I'm looking at there are 27,470 .strings files totaling 69 MiB, but they take up 155.9 MiB of disk space due to the 4 KiB filesystem block size.
The keys for the strings take up 39% of the space while the values take up 61%. About 12% of translations are duplicated (the word "Cancel" is translated like 53 times)
So 55% of the space used for strings localization is just pure waste due to having so many small files. The long keys are rather wasteful too and about 12% of the translations are duplicated (i.e. the word "Cancel" is translated 50+ times per language).
Some of this is arguably Apple's fault. Their whole .string file per table per language is incredibly space inefficient by default.
Android traditionally puts resources into a compressed archive, though, so by simply using an archive for storage, Google may be avoiding the 4k size problem.
Google Play offers such functionality already, it's called App Bundles. Instead of uploading an entire APK, the developers can upload the app assets that get bundled into device-specific APKs containing only the resources necessary for the end device. So you'd only get native libs for your phone CPU architecture, translations for the device language and image assets matching the device resolution for example. In fact, I think it's mandatory now to use the app bundles format (but you're still free to configure it to some extent)
I now see the article is about iOS app, but it looks like the Android app is anywhere between 50mb and 100mb (depending on the apk download side I look at) which is much more reasonable
Author here. Thanks for sharing this. It seems they released an updated version of this analysis last year [1]. It matches what I saw when analyzing the IPA. I tried to do a deeper analysis on the code itself using several tools, including Google's own bloaty [2] which was not very useful without symbols, classdumpios [3] which revealed something like 50k interfaces starting with "ComGoogle", and Ghidra [4], which I left running for a day to analyze the binary, but kept hanging and freezing so I gave up on it. Perhaps comparing the Android and iOS code could lead to something more fruitful.
Looks like it's mostly strings, probably due to localization. They should consider compressing each localization/language, and decompressing the needed bundle on first startup (or language change). Even better: Download the language bundle when needed.
Well, that's a question for OS level. If the OS doesn't require the user to download the language and so language-switching to a new language is doable as an offline operation, I could see it being frustrating that switching to a new language must be done online.
So compression/deduplication is probably the better option. Rather than storing as 1 zip per language, though, you'd probably want a compression format that also eliminates duplication that may occur between languages if you're storing all languages compressed on the system. That means you'd need compression to handle the entire language complex being in one massive compressed blob and you'd just extract out the languages you needed. I assume there are some forms of zipping that do this better than others.
It's not just Gmail. Most of the popular apps on iOS are literally 10x bigger than their Android versions. It's hard to find a popular iOS app that's smaller than an Electron app.
They use those videos on the lock screen for example.
Not saying it’s a good idea that they ship all of those big video files. Believe me, my MBP M1 with 256GB SSD barely has space left even when I go and clean up various files I no longer need.
Foolish as I was, I believed that doubling the amount of storage compared to the MacBook Air I had before it would leave me with plenty of space for years to come. In reality it did not take much time before I was using most of the storage available.
So when I bought my latest iPhone not long after I bought that MBP, I opted for the iPhone model that has 1TB storage. And at least on my phone I consistently have a good amount of space left. Every couple of months I move pictures and videos from the phone to an external hard drive. So since it was only a week or so since last I moved pictures and videos from the phone, I am currently using 350 GB of storage on the phone.
Out of those currently used 350 GB, just under 40GB is accounted for by music I have downloaded in the SoundCloud app, which is ok even though maybe a little bit silly on my part. I have it set to download all songs that I favourite, and I sometimes manually download whole albums and whole playlists. Not because I want to listen to all of it offline but so that when I am offline I still have a wide selection to choose from. For example on the occasion that I fly by plane once or twice a year.
Another 20GB of storage space is used by maps I’ve downloaded in the Organic Maps app to have locally saved maps for various places I’ve been to or want to go to. Again, a little bit silly to keep that much map data even for the places that I am not going to visit for at least 6-12 months, and which will need to be updated again when I do go there to ensure I have up to date maps. But all in all, I can “afford it” with a terabyte total storage. And both the songs in SoundCloud and the map data is data that I could manually go through and delete as much of as I’d like to if I ever were in a pinch and needed to free up space.
At times I will hoover around 700 GB of storage used on the phone if it’s been a while since I moved pictures and videos and I have filmed some longer videos.
My phone being a few years old now however, it doesn’t have USB-C. So it takes a bit of time to move pictures and videos from it. Even if I transfer over the network it doesn’t seem much faster than USB 2.0, weirdly.
Instead of Gboard, get Anysoft keyboard from https://f-droid.org, enable Gestures in the settings. You'll thank me later.
Also, F-Droid has different keyboard layouts for Ansyoft such as better ones for SSH and OFC language related layouts.
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.
It's not just the WebKit bit, basically the entire app implementation is actually shipped as a "Private Framework" which lives outside the .app bundle. e.g. on macOS
% otool -L /Applications/Safari.app/Contents/MacOS/Safari
/Applications/Safari.app/Contents/MacOS/Safari:
/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari (compatibility version 528.0.0, current version 623.1.14)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
There's a bunch of other private frameworks (SafariCore.framework, SafariFoundation.framework, SafariPlatformSupport.framework, SafariShared.framework, SafariSharedUI.framework, SafariSwift.framework) as well. I haven't checked but I assume it's similar on iOS.
While alternative browsers are legally usable on iOS, nobody has really published one yet.
Maintaining a browser is expensive and with the way Apple implemented their obligations, it's not worth it for existing browser companies to ship their own engines (and have twice or more the maintenance).
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.
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
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.
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...
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.
Right, I know what sort of things happen in that process. And to be fair, I'm mainly poking fun at how bad the web page has become.
I do feel that this bloat is, far and away, the worst offender when it comes to why things feel slower nowadays. The application just flat out does way more than most people assume it can. Which means it almost certainly has way more capabilities than it needs for many of us.
Would be neat to see a metric on "how much of the code is never loaded" in typical use. Akin to some game medals of "played more than x% of players."
AOT is unique because you want to compile it with all the capabilities your device has, so there still has to be some complication done, especially when you have processors that have brand new instructions to make operations significantly more efficient.
That's not the approach they're referring to, iOS doesn't support that. They're referring to delivering the compiled native code as part of the app package.
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?
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.
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?
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?
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.
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.
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.
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?
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.
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.)
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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 :/
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.
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.
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
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.
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.
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.
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”.
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)
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”
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.
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.
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
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.
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.
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.
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.
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.
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.
The brew LLVM situation is crazy and even more noticeable when you're on older macOS for which they no longer ship precompiled stuff.
I know they don't want stuff breaking because users have a GCC version that's 6 months behind and the homebrew folks can't be sure that package XYZ doesn't use any newer features. But when installing anything built with C++ I really don't expect to wait half a day for the whole LLVM+CMake toolchain to compile from scratch.
You can pin LLVM but it's useless as there's no bypass to the version check. They've also closed all relevant issues as "won't fix" as it's not "their way of doing things".
I just downloaded QGIS to take a look. On my Mac, it takes 2.1GB of disk space after installation, which has some notable space sinks:
* 562mb of Python 3.11 and libraries (of which 240mb goes to the qgis python library, 101mb goes to duckdb, and 50mb to PyQt5)
* 130mb to i18n
* 140mb to `libclntsh.dylib` which I think is the Oracle DB client library?
* 80mb to libduckdb.dylib, separate from the Python version
* 80mb to libQtWebKit
Oh, nice. Yeah, Python got gazillion new versions, incompatible, in million folders in sys.path, and sys.path different in different places, and recently they started to menace you to shutdown old versions (I get such warning, that 3.9 will stop working in October 2026). So, since you can't rely on system Python anymore, they made essentially a docker container. Sigh.
I am not sure QGIS is a good comparison to this. The projection information dataset is nearly 800 MB on its own. But it's not really PROJ's fault that there are so many projections to manage.
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!
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.
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.
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.)
>Gmail isn’t even the worst offender, it’s just a more popular one. The Tesla and Crypto.com apps are around 1 GB each.
One reason is those are typically apps which need to be heavily secured. So behind the seemingly "simple" user interface and functionalities, there's so much security related code to ensure their "safety".
More importantly, it's difficult to code without dependencies.
I think the joke is going over my head ^^; Maybe you mean 'just' a regular developer as opposed to a cryptobro?
Edit: I see you added in a link. "The research found that more than half of the 1200 developers surveyed are unable to ensure that their code is protected from seven common vulnerabilities", hmm maybe it was not a joke? The article (or the survey it's based on) sounds extremely misguided though, sounding comparable to saying that only X% of farmers never had a single rotten apple so clearly it's not a 'top' priority for them to produce quality at all cost
Oh, and I just noticed you're the same person as whom I was responding to above. That explains
Fwiw, I do security audits as a day job so I have some idea of which coding practices lead to good security and it's not download size. You can try this "you're just a developer" again on someone else maybe
> The article (or the survey it's based on) sounds extremely misguided though
Unfortunately the entire Internet is bloated with such extremely misguided jokes. Here is another extremely misguided joke:
"We have a fundamental problem in the way we develop software. A large percentage of software is created by people who were never trained on the basics of security. " [1]
Generally the larger the codebase the harder it is to secure. I am less worried about security vulnerabilities on small tightly focused apps than I am on gigantic monstrosities with hundreds of different attack surfaces.
According to looking at a 1,000 line code file on my machine right now, a million lines is about 48mb. You think > 10 million lines of code are required for security in an app?
> 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.
> 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
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.
There are ways to analyze the content of your app so you know exactly what's taking all the space.
Tools can vary depending on what language you used. For example i wrote a small app using flutter and i used the flutter's app size tool.
Is it for iOS? Then, it could be the Swift runtime library.
Maybe your compiler isn't pruning dead code?
I think it could be all the compat /support libraries that try to give you the same API across different Android versions.
I remember hearing that even a trivial React Native app is around 100MB on Android.
If you use Electron, yes, any application starts from around 100MB.
But there are alternatives that reuse the OS's libraries nowadays.
React Native doesn’t use Electron
Why Electron? React Native doesn't even use HTML.
How does a web application reuse browser system-native libraries?
Electron ships a version of Chrome. Other frameworks like Tauri use the device's webview.
The entire discussion is about native applications, not web.
> 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.
https://github.com/cnlohr/rawdrawandroid
25Kb
> non-default different tools
The “default” recommendation is clearly Android Studio plus Kotlin/Java.
Other tools are smaller.
Hello world Android app includes a lot of dependencies like compat libs, constraint layout, kotlin runtime. These are not essential and can be removed.
I am quite sure that isn't using the plain Android APIs, and has a bunch of needless libraries.
Use plain Java, regular Android views, handle yourself the ifdefs for Android versions, and the 5 MB won't be there.
Outch… and I though an ~8KB "Hello, World!" here on my rusty Mac is HUGE already.
Idk what to tell you but my "hello world" + a few dozen lines of functionality are 9.6KB. Haven't done anything special to shave things off
> 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.
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
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.
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
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.
More than 3x: GMail is 194 MB on my Android phone and the old K9 (which Thunderbird built upon) is 10.60 MB.
> I don't know why iOS apps in general are so much larger than Android apps [...]
Rough guess: It probably wouldn't be this dramatic of an increase, but could it be something to do with iOS disallowing Just-in-Time compilation, and forcing Ahead-of-Time? I've always wondered.
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.
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.
It is the default.
You could get localizations OTA, but that's engineering you need to do to make that happen.. or a product you purchase, as there's various localization managers offering these options in their software.
> a sudden jump to more than 200 MB near the start of 2017
Google Meet was launched in March 2017.
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.
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.
I remember when Windows 95 was around 10-30 MB, ten whole diskettes or so.
Now I can't even install Ubuntu without 4 GiB+
Proper unicode font support is like 1.2GiB (noto, but I haven't found any complete unicode font collections that are significantly smaller). There's bloat for sure, but supporting universal text is one that I think is not a waste of space.
Unsure if this is useful to you but have you heard about GNU Unifont? It’s not as nice and comes with some asterisks but damn it’s very compact.
I first read about it via this blog post: https://shkspr.mobi/blog/2019/04/banish-the-%ef%bf%bd-with-u...
To be fair it wouldn't really be doing its job if it didn't come with any asterisks
Maybe not proper support, but when I tried NetBSD recently my entire installation was around 1.5 GB on disk and seemed to handle Unicode well enough for me (for languages I care about). Not doubting some more packages would be needed to support every language, but happy everything wasn't installed by default.
Ye by proper i mean being able to render unicode in any language without tofu. I get that not everyone needs that, but its a reasonable thing to have on your disk in 2025.
For English capitalization is a trivial problem. I think for Hungarian or something similar the rule set is like 6mb.
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
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.
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...
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.
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.)
You don't need "hi-res graphics" in an app.
Why?
Small screen, lots of system components that should get drawn dynamically, etc
A bit reductionist, but I get it, if it were a priority you could do lots with a hundredth the space
Small screen (iPhone) that could also be a medium screen (iPad) or even a large screen (Macbook), no?
Yes but with Vector based logos, and considereing you don't actually need all sizes for most apps there's a lot of margin there
A 6 inch screen doesn't need an 8K logo and all it's variants
Someone was saying that Apple OSes don't do vector logos.
If your app is 5mb to download but then needs to download 100mb of content your app is 105mb.
I have a couple that are honest sub 5mb apps. Some of my favorite apps on my phone. Limited featureset that does what it says on the tin. Loads instantly. Hardly uses battery at all. I wish everything was like this.
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.
> 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?
Frameworks from other companies. A lot of it is analytics/tracking, some payment processing, etc. There are a few open source libraries we're using as well but those probably are <5mb if I had to guess although I never checked.
Again, a lot of these companies have also been around so if my app has a ton of bloat from years of work, we're bringing in frameworks from other companies who have been around for years as well and probably have a similar amount of crap in their code. Plus they probably want to track everything we're doing so they're bringing in their own third party libraries. It's kind of ridiculous but that's where we're at.
Bigger companies won't have as many third party libraries as they can afford to do it in house but they're still bringing in similar sized libraries to do the same things.
Imagine, it's not just making sure your code is secure, but your also counting on all those libraries's being secure. Let alone all these frameworks as you say - payment, advertising, analytics... You could have the most secure code ever, but when it is just one link in a chain outside your control, best not overthink it or you won't sleep.
You can see why bug bounties get rewarded well. Though mindful, money is not what drives everyone. Then there are the greedy, in which such exploits value on the black market can be higher. Not forgetting government agencies level.
I wonder which email client will break the 1GB mark, and when we will see a resurgence in reducing bloat. I'm sure that phase will come, did for Microsoft once.
> A lot of it is analytics/tracking
Woof. This is just so wild if one ever stops to think about it. ~300mb of tracking for a single app is bigger than the entire hard drive of a fully internet-capable desktop computer in the mid '90s.
Icons should use vector format.
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.
Huh, is there a requirement that they be rasterized at build time? If I had a choice, I'd rather ship the SVGs in the bundle alongside a renderer like ThorVG and render at runtime. The renders could even be cached if the rendering itself was expensive.
If you’re including these assets as UI elements, they would be rasterized anyway and copied to a GPU bound buffer for the frame blit. Doing so at compile time increases runtime performance.
You can of course override this behavior and redraw your vector every 8.3 ms if you want, but I promise you that this is not faster. For sparse pyramid-tiled vector images like Google/Apple maps, this is a two step process using the latter method followed by the former.
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.
we've been able to "preserve vector data" with pdf and svg image resources on ios for a long while now... compile-time rasterization is the default though...
[0] https://useyourloaf.com/blog/xcode-9-vector-images/
We once ran Windows 95 with Encarta in about the same amount of disk space.
We crossed lunacy long 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
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.
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.
> 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!
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.
>"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.
.NET apps are relatively small until/unless you start pulling in many/large dependencies.
> I had no idea common apps used to be just 10-30 MB
Phones used to have 4GB of flash memory... Some had 2GB.
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.
Hmm, mine is currently 673MB on iOS 26.
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.
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).
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, 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.
This is a result of doing “rounds of layoffs” as a solution to bad organisational decision making, so not quite a root cause.
The process to retain and advance your career at Google is incredibly political, and these are the results.
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?
> 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).
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...
So it seems flutter by itself takes 200-ish MBytes. Flutter alpha is 2017 according to https://en.wikipedia.org/wiki/Flutter_(software)
Mystery solved it seems
bunq 30.0.2 on Android is 380 MB by itself.
But this is still unjustified speculation
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
I guess so much has already been built they wouldn't have just recreated it in Flutter or something.
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.
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.
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.
I'd bet my money that you can roll your own iCloud-esque Photo Library and it still won't be near the 100MB territory if you just use native libraries for the UI. Everything you'd have to do from scratch: cloud auth, encryption, syncing, compression, transcoding, etc. is all at most a few MBs combined, not to mention that all of these except cloud auth are already in the built-in libraries on iOS that any app can freely use.
What the apps here are doing is shipping whole (UI) frameworks and tons of old code and assets that aren't really used anymore but nobody dares to remove.
You can access iCloud from an iOS app, it has its own public framework called CloudKit, so you could create your own version of it. If you don't like that example Chrome and Edge are both forced to use WebKit on iOS but are still much larger so.
> You can access iCloud from an iOS app, it has its own public framework called CloudKit, so you could create your own version of it.
How is this relevant?
The point of having a Google Photos app is to access / back up your photos via Google Photos, not to make an alternative frontend for iCloud.
If the point of a Google Photos app is to access / back up your photos via Google Photos (web), then it seems rather dubious that making API calls to a cloud server is an endeavour that takes hundreds of megabytes of code and resources.
If, rather more accurately, the point of a Google Photos app is to provide a photo editor and various other photo-adjacent functionality coincidentally including the ability to back up photos to Google's servers, then again that raises the question of why Apple's equivalent app is so much smaller. Are there image-related system frameworks that Google cannot use that Apple is using? Then sure, feel free to count them in Apple Photos' "true" size. But if Google simply won't use them then IMO it's fair to ask if the size of what they're shipping is worth it.
> 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.
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).
Sounds like how Internet Explorer used to be integrated in Windows. That was quite contentious at the time!
'90s Microsoft was like early christians: harshly persecuted, only for everyone else to eventually adopt their ways. In this metaphor, emperor Constantine is probably Steve Jobs.
Harshly persecuted how, exactly? They got a slap on the wrist, still continued to ship IE as the default browser and stayed dominant browser vendor until another monopoly started to abuse its position.
The verdict significantly hamstrung their internal developer processes. Yes, IE didn't go anywhere, but the path of tight integration of web and OS was effectively abandoned for several years, and they generally toned down integration features between their products.
Which brings up another point: the total used disk space of a Windows install with Internet Explorer and Outlook Express used to be way smaller than Gmail alone is now.
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 )
Safari on MacOS is 66M, Safari Technology Preview is 226M
Yikes thanks. I remember when a full browser fit in a 1.44MB floppy disk.
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?
All of them (except the downloadable ones like Xcode on Mac).
With Safari it's a lot easier to see, as you can get the standalone version.
Reminds me of when people were clamoring for the ability to delete 1P apps to save space
The Gmail app takes 175 MB on my Android phone. That’s better than iOS, but still a lot for an e-mail app.
To add to the comparisons. Protonmail is showing as 180 MB on GrapheneOS. Add in user data and cache and it's 495 MB. I don't consider myself a big email user so I am a bit appalled.
Pixel OS16 with fastmail is 20MB for app, 60 for usercache and 7 for cache. I use it once or twice a week if that
Probably bundles its own copy of Chrome just in case :)
I can totally imagine someone doing just that.
> Product Requirement: Even if the user deletes the Chrome app, the Gmail app must work to display HTML emails, the authentication screen including 2FA options, etc. Can’t rely on WebViews for security reasons.
It doesn't, that's Android Webview which is distributed separately. It may however bundle its own instance of the Chrome networking library which is a few MB itself.
For apps like Gmail and a handful of others, they are big enough that they need multiple layers of fallback. e.g. they can't just use a networking layer, they need a fallback separate implementation in case that breaks, so that they can recover. They might have 2 or even 3 options for some of the critical parts, all so that if stuff goes wrong they can as close to guarantee recovery as they can get.
Mobile is quite specific in this regard, because you don't have hardware access, network is heavily restricted, battery reduces the amount you can do, etc.
Source: I work on mobile SRE things at Google.
No need to.
Android does that already and allows apps to use it (the webview)
K-9 mail (aka Thunderbird) is a nice 12MB, 70MB installed.
The app size is 44 MiBs for me. With user data just above 70 though.
Windows 98 and Office 97 in their entirety are less than 700MB combined. How have things gotten so out of hand that a single email client needs more than an entire OS and office suite used to?
I’m sorry but ~700MB of compiled code, text, and vector graphics is a lot of assets, almost a truck load. It doesn’t look like they care about how much space they take in users’ devices at all.
The article doesn't answer the question. The content can be summarised as "The Gmail app is 700 MB!"
There's a few other apps that are ridiculously big. Like the DJI Mimo app. It's an app I need for my DJI Mic, to change 4 settings on it. It needs 800MB for that which is absolutely ridiculous. Also I need to sign up for an account to use it even though the Mic works completely locally and it just changes the settings over USB.
It's absolutely fucking ridiculous to have an 800MB app for this and the reason is just marketing. It's full of stupid videos promoting their stuff. And the account just causes stupid spam. I should have returned the damn thing to be honest.
Ps pardon my french but I'm really annoyed about this and in this case it's warranted in my opinion. 800MB is ridiculous.
I call it Marketing Driven Development, having lived through it at a previous job. It really sucks. They give engineers no time to breathe and do maintenance code changes.
Growth hacking is a polyp on the arsehole of technology, to paraphrase
First software ate the world. Then software sales ate software. Now its time for AI to eat software sales.
It doesn't inspire confidence in privacy when things are so huge, connected and opaque.
Doesn't the Mimo app work for many devices not just your mic? While your mic might not need a lot of the code, someone using one of their other devices might not need your mic's code either. I can totally see why DJI would want a single app to control any of the DJI branded devices rather than dealing with multiple app store approvals. It would also be confusing for the end user as in "Which device am I using so which app do I need to use" would be a nightmare for all involved.
Just for the comparison, Damn Small Linux is still around 700 MB, and contains Linux kernel, desktop environment, web browser, office suite, and other software.
Mimo app will never support as many devices as Linux kernel does.
Logitech and creative do the same with bloated user apps, filled with what I assume is duplicated high res images for each device.
This would be my assumption about bloat as well. Possible to also be storing video clips so no delay from trying to stream parts of the UI.
When something is hundreds of megabytes, it is very unlikely to be mostly compiled code. A lot of that fits in each megabyte.
Feels like we are able to build software solutions for much more challenging problems than "only download the part that the user needs instead of everything and the kitchen sink". The explanation you provided doesn't make me feel even a tiny bit better about the problem. It just details how it came to exist.
Yes, I have used Mimo for a separate DJI product. They also have at least two drone control apps each used by multiple models of their drones.
Corsair iCUE. 1.1GB to control your RAM lights...
Beautiful example of bloat. Bravo!
The software crisis never ended. Instead, we also gained a hardware crisis.
>1.1GB
>RAM lights
I'm not sure which is dumber.
That's like saying Christmas lights are dumb. Each to his or her own though!
Sounds like a ripe opportunity for someone to reverse engineer their USB protocol and create a free/open alternative.
Yes!! I was thinking of doing that myself but I don't have the chops to create an android app and no time to learn right now. But the protocol can't be that hard.
DJI lost the plot years ago unfortunately. They reeeeally wanted their app to be this whole bespoke platform experience thing and it’s been downhill ever since.
lol remember the Karma?
I did a DFU firmware update app for Jawbone once. after a bit of screwing around trying to figure out some of the reset paths we were good. and then the marketing people got involved. this was a customer touch point, and opportunity to reenforce the brand that just couldn't be ignored.
Apps like that often contain (many?) short high resolution videos to show how to do an initial connection or something that can take up a ton of space.
Gmail has no such excuse.
They could decouple the video download from the app download. Then they could even update the video independently if needed. Not everyone that downloads the app needs the videos, and even the ones that do I’m sure would be happier to reclaim the disk space after viewing them.
It’s lazy.
I often use the DJI MIMO app while out of WiFi, and would rather not download a large video separately. For the record, I do not like the DJI MIMO app (because it is the only app for their 'Pocket' products, and MIMO doesn't support tablets well), but I think this decision is a reasonable one.
You'd rather just keep every tutorial video in your phone's limited storage, forever?
The more likely outcome: because the app is huge, you'll uninstall it to save space. Then when there's no signal, you have no app at all.
I did consider this, but I'm curious: what are you doing that you need to watch a video out of internet range, that you couldn't have done while testing things out while in range? Isn't it risky trying something for the first time in the field without having already practiced it? I do understand that not all things can be anticipated.
800 MB High resolution video explaining how to connect a microphone is still bonkers. There's no justifying this garbage.
I’m not saying it’s a smart use of space. Just that it absolutely happens.
MIMO also manages many different DJI cameras (badly).
Oof.
The past year or so I've stopped buying stuff with an app before checking out how big the app is (if I plan to use it).
> I should have returned the damn thing to be honest.
If enough people actually did that, the companies would start caring.
Roborock is 900 MB just to control a robot vacuum
Logi Options+ is 500 MB to configure a few extra buttons on a keyboard or mouse. Back in the days things like these were a few kilobytes(!) control panel extension.
that is fucking rediculous! companies should be banned for such neglegence.
[dead]
The article is the question though, the question deserved to be asked.
And Gmail deserve to be shamed for shipping almost a gigabyte of stuff for a mailbox. Wouldn't be surprised if they accidentally/intentionally built the whole youtube client in there.
I think this might be closer to the truth than you might think.
Due to the absence of (cross-app) shared libraries on at least iOS, developers often end up building big company-internal libraries that then have to be shipped with all of their apps.
Tree shaking isn’t perfect, and the result are these > 0.5 GB monstrosities.
> Tree shaking
Modern development is insane to me. "Let's do it badly, and hope a tool can fix it for us."
"Is anyone keeping an eye on the tools? No? Perfect!"
Particularly for developers inside the company that owns the platform. At some point they have to recognize they've completely screwed all this up.
Is it plausible that the libraries are so big? I mean, for example, NodeJS is in the order of 100mb and contains the whole v8 engine.
The Gmail app size has to be assets, right?
Static linking will do that. Imagine you have 400mb of binary objects your app depends on. Libraries your company uses for app analytics, SSO, 2FA, Corporate service bus api, etc. You statically link all those for your 50mb Swift UI app and bam, you’re in the 700mb range.
The use of Go will definitely do that, as it prefers to statically link everything.
https://go.dev/wiki/Mobile
If we had an entire POSIX OS built with Go, then we would be back to statically-linked UNIX prior to BSD.
https://www.freecodecamp.org/news/golang-statically-and-dyna...
can you build a Swift UI in go?
There is a single mention of Swift on the developer page that I posted.
"Note that you can also invoke GoHelloGreetings from Swift by importing Hello."
Oh lord…
That's a lot of code, though. I can't imagine common libraries so big. The Linux kernel is less than 100mb.
That would be the source code. The default debian kernel is around 12 MB but it could be much smaller.
It doesn't bundle full random external libraries compiled with debugging symbols and "whatever other stuff".
The neat thing about code is that there's no upper limit on how inefficient one can get.
It's literally "work expands to fill the available time" (s/time/cycles and memory/)
You'd be surprised what ends up dragged into where when you have a build system that makes it easy. Just look at the npm.js mess (and what kind of things ended up depending on what kind of other thing) if you want an example.
On Android, Gmail reports as being under 200 MB. So I agree, they probably include way to much for portability.
On Android, sharing code is much more feasible than on iOS as far as I understand it, especially if you're Google and can demand that everybody using your apps has Play Services installed.
It's one thing to have common internal libraries and another thing to have the compile process blanket include everything that's in it.
Tree shaking is insane to me too. Just use a language that can actually do proper DCE, if you're not building a website.
(I do realize though that most "apps" are just websites without the browser toolbar, unfortunately)
For what it's worth, Outlook for iOS on my iPhone has an executable that weighs in at 368.8 MB.
Google needs to trim some stuff down.
Apple Mail on macOS is 16-30MB, so something is still clearly of.
To be fair, Apple is the only developer in the world that can ship (cross-app) shared libraries on iOS, so they have a bit of an advantage.
It is also a conferencing app. That might explain some of the size.
I've been using gmail since the early beta days and was never aware of this functionality. But on closer inspection there appears to be a highly stylized (unrecognizable) camera icon there that takes me to, I guess the long lost cousin of Google Meet?? Why are these apps welded together? What a bizarre decision. I thought Meet went to The Graveyard along with Allo and Duo and Wave.
My work uses GSuite so I’m using Meet every day. I find it mildly useful to have the functionality built into the Gmail app but at the same time I see zero loss in having it be a separate app.
Meet was discontinued; its functionality was merged into Duo and the resulting app renamed to Meet.
Meet still works on Pixel phones as a solution/parity for FaceTime. I wonder if it's bundled in the web build or they're the same build under the hood.
That's something that I would (very generously) expect to add 5 megabytes.
The background images alone would be more than that.
We don't need that to be pre-loaded on the device, do we? how often are they used? and when one is set to be used, the user is definitely online already, just grab the one then
Yeah, meet and chat (where each has their own bloat) are now integrated into the mail app as well. This contributes a lot.
Why? It’s obviously not a problem for them
Gmail started by giving 1 GB of free storage to users as a carrot. Over 2 decades later, how much does it really matter if the app goes from 70% of that down to even 10% of that, and would that outweigh what else people actually want to see done instead?
I mean, it's certainly not anything to boast about from a technical perspective. I just don't know whether it's really enough to warrant any shame for the product though.
Deserves.
It's quite common in UK English (and maybe others, I don't know), to refer to "singular" or collective non-people entities (such as companies, I know Gmail itself isn't one) using the plural form of verbs.
This isn't in my natural speech, but I quite like it; it seems to kind of imply "the people behind [company]" rather than anthropomorphizing the company itself. ...generally though I think it's just colloquial convention and not that deep.
I wonder how this language quirk changes how people think about the statement "a corporation is a person".
There's something funny about someone trying to be smart and pointing out a typo or some other minor irrelevant error only to be proven completely wrong.
He isn't wasn't wrong, and the parent post wasn't even correcting him. Gmail is not a corporation, it is a product - singular.
Gmail is a product, but the comment wasn't saying "Gmail the product deserves to be shamed... ", more like "the Gmail team/devs/company deserves to be shamed...", which is why the plural still made sense to me (given the omission of an explicit "team"). The singular makes sense to me too.
In any case, I wasn't really interested in correcting or proving anyone right or wrong, just pointing out an interesting linguistic detail and where the grammar may have come from.
Can you "shame" a product, though? Obviously not. So you're shaming the people who built Gmail, the organization - hence the plural form is acceptable.
Ironic.
Right! I was looking forward to some insight into what's in that thing, but there was nothing.
Why IS the Gmail app 700MB?
Emerge Tools has an old thread on why it's actually so big: https://x.com/emergetools/status/1810790280922288617
Thanks, that thread is great!
They have a neat treemap breakdown here: https://www.emergetools.com/app/example/ios/com.google.Gmail
130MB is localization data.
This detail was interesting too: https://twitter.com/emergetools/status/1810790291714314706
> There's over 20k files in the app, 17k of which are under 4 kB. In iOS, the minimum file size allocation is 4 kB, so having many small files causes unnecessary size bloat. Gmail could save 56.4 MB by moving their small files to an Asset catalog
Yep, localization is a huge size bloat for enterprisey apps that support many locales. There is no Apple provided way to dynamically download select localization packs based on the device locale. Meta came up with their own solution: https://engineering.fb.com/2022/05/09/android/language-packs...
The small filesize issue is something we commonly see in games, was surprised to see it for Gmail.
And btw we open-sourced much of our analysis after being acquired by Sentry: https://github.com/getsentry/launchpad
130 MB for localization? At 50 languages that would be 2.6 MB/language. If we assume an average 50 bytes per string and another 50 for an identifier, that's 27,000 strings.
That doesn't seem right. Localization feels like it should add a few MB. Not over 100. (Plus shouldn't it be compressed, and locally uncompressed the first time a language gets used?)
Localization doesn’t just mean string translations. Apple platforms give you the freedom to redo the UI to fit the language. For example, parts of System Preferences (not sure about Settings) would look completely different in languages with long words because the original design for English simply didn’t fit. The translators rearranged buttons to make the text fit.
I just looked. In this case, it is just string translations.
In the version I'm looking at there are 27,470 .strings files totaling 69 MiB, but they take up 155.9 MiB of disk space due to the 4 KiB filesystem block size.
The keys for the strings take up 39% of the space while the values take up 61%. About 12% of translations are duplicated (the word "Cancel" is translated like 53 times)
So 55% of the space used for strings localization is just pure waste due to having so many small files. The long keys are rather wasteful too and about 12% of the translations are duplicated (i.e. the word "Cancel" is translated 50+ times per language).
Some of this is arguably Apple's fault. Their whole .string file per table per language is incredibly space inefficient by default.
Sure, but that's a few KBs for each locale at most. Still a long way to 100 MB.
They probably just have lots of leftover localized assets that nobody dares to touch as they aren't sure if it's used anywhere.
Thank you! I've been wondering about exactly this, your explanation makes complete sense.
Any rtl language will probably require a lot of different assets. If for no other reason than gradients. Plus anything asymmetric.
The version I'm looking at has 27,470 strings files, mostly of them less than 4 KB each.
Since the iOS filesystem uses 4 KB blocks, it looks like about half the space is just wasted.
It probably isn’t just text that is localized.
images also may need localization.
4kB is also the minimum file size on Linux, so I imagine a similar issue could exist on Android.
The Gmail app on Android is 150MiB in size.
Android traditionally puts resources into a compressed archive, though, so by simply using an archive for storage, Google may be avoiding the 4k size problem.
Wonder if it is better to create separate localized app download such as gmail-japanese, etc.
Google Play offers such functionality already, it's called App Bundles. Instead of uploading an entire APK, the developers can upload the app assets that get bundled into device-specific APKs containing only the resources necessary for the end device. So you'd only get native libs for your phone CPU architecture, translations for the device language and image assets matching the device resolution for example. In fact, I think it's mandatory now to use the app bundles format (but you're still free to configure it to some extent)
I now see the article is about iOS app, but it looks like the Android app is anywhere between 50mb and 100mb (depending on the apk download side I look at) which is much more reasonable
Non X version:
https://threadreaderapp.com/thread/1810790280922288617.html
Author here. Thanks for sharing this. It seems they released an updated version of this analysis last year [1]. It matches what I saw when analyzing the IPA. I tried to do a deeper analysis on the code itself using several tools, including Google's own bloaty [2] which was not very useful without symbols, classdumpios [3] which revealed something like 50k interfaces starting with "ComGoogle", and Ghidra [4], which I left running for a day to analyze the binary, but kept hanging and freezing so I gave up on it. Perhaps comparing the Android and iOS code could lead to something more fruitful.
[1] https://x.com/emergetools/status/1943060976464728250
[2] https://github.com/google/bloaty
[3] https://github.com/lechium/classdumpios
[4] https://github.com/NationalSecurityAgency/ghidra
Looks like it's mostly strings, probably due to localization. They should consider compressing each localization/language, and decompressing the needed bundle on first startup (or language change). Even better: Download the language bundle when needed.
Well, that's a question for OS level. If the OS doesn't require the user to download the language and so language-switching to a new language is doable as an offline operation, I could see it being frustrating that switching to a new language must be done online.
So compression/deduplication is probably the better option. Rather than storing as 1 zip per language, though, you'd probably want a compression format that also eliminates duplication that may occur between languages if you're storing all languages compressed on the system. That means you'd need compression to handle the entire language complex being in one massive compressed blob and you'd just extract out the languages you needed. I assume there are some forms of zipping that do this better than others.
So is the extra space not accounted for from then to now AI related pieces?
It's not just Gmail. Most of the popular apps on iOS are literally 10x bigger than their Android versions. It's hard to find a popular iOS app that's smaller than an Electron app.
Then you look at the desktop backgrounds folder in your Mac and say:
WHAT THE FUCK!
There are 4k videos there...
Just unbelievable.
They use those videos on the lock screen for example.
Not saying it’s a good idea that they ship all of those big video files. Believe me, my MBP M1 with 256GB SSD barely has space left even when I go and clean up various files I no longer need.
Foolish as I was, I believed that doubling the amount of storage compared to the MacBook Air I had before it would leave me with plenty of space for years to come. In reality it did not take much time before I was using most of the storage available.
So when I bought my latest iPhone not long after I bought that MBP, I opted for the iPhone model that has 1TB storage. And at least on my phone I consistently have a good amount of space left. Every couple of months I move pictures and videos from the phone to an external hard drive. So since it was only a week or so since last I moved pictures and videos from the phone, I am currently using 350 GB of storage on the phone.
Out of those currently used 350 GB, just under 40GB is accounted for by music I have downloaded in the SoundCloud app, which is ok even though maybe a little bit silly on my part. I have it set to download all songs that I favourite, and I sometimes manually download whole albums and whole playlists. Not because I want to listen to all of it offline but so that when I am offline I still have a wide selection to choose from. For example on the occasion that I fly by plane once or twice a year.
Another 20GB of storage space is used by maps I’ve downloaded in the Organic Maps app to have locally saved maps for various places I’ve been to or want to go to. Again, a little bit silly to keep that much map data even for the places that I am not going to visit for at least 6-12 months, and which will need to be updated again when I do go there to ensure I have up to date maps. But all in all, I can “afford it” with a terabyte total storage. And both the songs in SoundCloud and the map data is data that I could manually go through and delete as much of as I’d like to if I ever were in a pinch and needed to free up space.
At times I will hoover around 700 GB of storage used on the phone if it’s been a while since I moved pictures and videos and I have filmed some longer videos.
My phone being a few years old now however, it doesn’t have USB-C. So it takes a bit of time to move pictures and videos from it. Even if I transfer over the network it doesn’t seem much faster than USB 2.0, weirdly.
Biggest Google Apps for me:
Gboard 247MB
Google 415MB
Google Play Services 1330MB
Google Play Store 165MB
Messages 321MB
Gmail 233MB
Instead of Gboard, get Anysoft keyboard from https://f-droid.org, enable Gestures in the settings. You'll thank me later. Also, F-Droid has different keyboard layouts for Ansyoft such as better ones for SSH and OFC language related layouts.
Futo Keyboard.
https://keyboard.futo.org/
Holy... What kinda heavy lifting is Google Play Services doing with those 1330 megs?
Dunno but my userdata for play services is 623MB.
I've noticed in general android apps have been shrinking in size for several years. I'm not sure if recent LLM trends are changing that again.
As usual, the answer to a question in the title is “no”. ;)
Correct, as in Betteridge's law of headlines:
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
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.
Safari probably is that size because WebKit is a system framework, so it’s just the size of the UI code
Safari is just a wrapper around the system webview framework so it does make sense, although it makes the comparison very misleading.
So are the other browsers on iOS.
It's not just the WebKit bit, basically the entire app implementation is actually shipped as a "Private Framework" which lives outside the .app bundle. e.g. on macOS % otool -L /Applications/Safari.app/Contents/MacOS/Safari /Applications/Safari.app/Contents/MacOS/Safari: /System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari (compatibility version 528.0.0, current version 623.1.14) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
There's a bunch of other private frameworks (SafariCore.framework, SafariFoundation.framework, SafariPlatformSupport.framework, SafariShared.framework, SafariSharedUI.framework, SafariSwift.framework) as well. I haven't checked but I assume it's similar on iOS.
Not in the EU...
While alternative browsers are legally usable on iOS, nobody has really published one yet.
Maintaining a browser is expensive and with the way Apple implemented their obligations, it's not worth it for existing browser companies to ship their own engines (and have twice or more the maintenance).
Yes in the EU. Apple made the alternative browser requirements impossible to meet, and somehow got away with it.
Yes also in the EU.
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.
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
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.
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...
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.
AOT overhead 200MB (ensuring app loads fast)
Frameworks 150MB
Assets for all screen resolutions 50MB
Google Meet/Chat/etc 100MB
AI models 25MB
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.
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.
Right, I know what sort of things happen in that process. And to be fair, I'm mainly poking fun at how bad the web page has become.
I do feel that this bloat is, far and away, the worst offender when it comes to why things feel slower nowadays. The application just flat out does way more than most people assume it can. Which means it almost certainly has way more capabilities than it needs for many of us.
Would be neat to see a metric on "how much of the code is never loaded" in typical use. Akin to some game medals of "played more than x% of players."
> OT overhead 200MB (ensuring app loads fast)
Yet there is a positive correlation between size and startup time…
AOT = Ahead Of Time? Attack On Titan? Something else?
Mobile applications need to be AOT (Ahead of Time) compiled for the target device to have optimal performance.
it's ahead of time and AOT compilation is done at OS startup, not sure if that is being measured here.
OS startup? AOT compilation happens in the build pipeline, before the app is distributed.
AOT is unique because you want to compile it with all the capabilities your device has, so there still has to be some complication done, especially when you have processors that have brand new instructions to make operations significantly more efficient.
That's not the approach they're referring to, iOS doesn't support that. They're referring to delivering the compiled native code as part of the app package.
Wouldn't compilation during the build process be ROT? As in, "Right On Time" compilation? Build is where the compilation step is usually performed.
I don't think iOS does any on-device or in-app-store compilation since Apple deprecated Bitcode.
https://en.wikipedia.org/wiki/Ahead-of-time_compilation
Didn't this use to be called "compilation"?
Yes, but then JIT (just in time) compilation became commonplace, so now it is often useful to distinguish between AOT and JIT.
Yes, and landline phones used to be called "phones".
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?
Could be similar to https://news.ycombinator.com/item?id=46134178 (code duplication for locality for a tiny perf gain).
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.
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?
> 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.
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?
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...
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.
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.
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?
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.
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.)
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.
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.
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.
Gmail barely has any features, which haven't changed since it's inception. Most of the code is in the cloud.
A lot of features are configurable by the domain administrators. As a user of the @gmail.com email, you won't see any.
This might be true but most of time its just bloat no one uses.
[dead]
10 MB mail app. 690 MB local llm to write snarky emails for you.
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.
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
They use the YouTube app for this also.
You really think 2FA notifications cause so much bloat?
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.
maybe because we need to be pushed to buy minimum the 256GB versions of phones. it is a wintel deja vu
Why would Google try to maximize Apple's revenue?
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.
Google is also selling phones? Not a great point as it's probably not really a revenue driver for them though.
Duopoly. Both get richer.
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.
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
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.
Having both your password and 2nd factor in the same place isn't the best idea however.
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.
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.
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?
Closer to 2.5x right now, likely to hit 3x this year.
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.
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.
Maybe, just maybe should Apple vary the amount they charge by app size.
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.
> 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.
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".
Except the text is stored as image, I can't imagine localization would be that large.
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 :/
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.)
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.
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.
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.
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
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.
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.
My whole cat is, what, a couple gigs of DNA?
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.
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
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”.
usually electron apps are 150-300MB
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:
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”
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.
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.
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
Because big enough tech companies always shipped their org charts in their products.
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.
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.
Why are such apps needed at all? The point of open standards like IMAP is precisely to avoid the need for multiple clients.
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.
On the flip side, our iOS app which _uses the Gmail API_ and also supports raw IMAP is ~14MB:
https://marcoapp.io
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.
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)
Framework mania. This has been the problem for years. Webapps bloat like crazy, and now with AI the sloplevel has gone berzerk.
On my Android phone, just the calculator app is 13MB. How in hell is it 13MB just for a calculator? It beggars belief.
Not sure how many ppl know this: you can use another email provider, e.g. user@yahoo.com, to register to YouTube.
Still need a phone number though
Phone number for youtube? I don't think so, need to double-check.
Good news(?), storage is expensive now, so this may get more attention.
I didn't use the Gmail app for the longest time, always used third party, not sure why I started..
If the AppStores would consider app size in ranking we might see an improvement.
Why is the Gmail app not open source
Same goes for other other bloated apps mentioned in the blog post
I was just wondering why the Adobe Acrobat installer is nearly a gigabyte in size.
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.
Bloated libraries and support for multiple versions of iOS/phones?
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.
The brew LLVM situation is crazy and even more noticeable when you're on older macOS for which they no longer ship precompiled stuff.
I know they don't want stuff breaking because users have a GCC version that's 6 months behind and the homebrew folks can't be sure that package XYZ doesn't use any newer features. But when installing anything built with C++ I really don't expect to wait half a day for the whole LLVM+CMake toolchain to compile from scratch.
You can pin LLVM but it's useless as there's no bypass to the version check. They've also closed all relevant issues as "won't fix" as it's not "their way of doing things".
I just downloaded QGIS to take a look. On my Mac, it takes 2.1GB of disk space after installation, which has some notable space sinks:
* 562mb of Python 3.11 and libraries (of which 240mb goes to the qgis python library, 101mb goes to duckdb, and 50mb to PyQt5) * 130mb to i18n * 140mb to `libclntsh.dylib` which I think is the Oracle DB client library? * 80mb to libduckdb.dylib, separate from the Python version * 80mb to libQtWebKit
Oh, nice. Yeah, Python got gazillion new versions, incompatible, in million folders in sys.path, and sys.path different in different places, and recently they started to menace you to shutdown old versions (I get such warning, that 3.9 will stop working in October 2026). So, since you can't rely on system Python anymore, they made essentially a docker container. Sigh.
The most fun part about trying to run any modern AI tool is the 14 different python installations that tag along.
I am not sure QGIS is a good comparison to this. The projection information dataset is nearly 800 MB on its own. But it's not really PROJ's fault that there are so many projections to manage.
Probably because it has three embedded versions of libcef
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!
not having 512gb of storage on your phone in 2026 is the definition of failing
Perhaps someone can decompile the app and find out.
Bigger than Windows 98
2nd order Jevons paradox I guess
It is bloatware for a reason, to force you a cloud subscription, not for your money (which helps though) but your data.
Google writes bloatware for iOS to force me to buy a cloud subscription (?) from... Apple?
Gmail android size is also ~750MB.
Why is my banking app 1.5GB?
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.
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.
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.
Love how it ends with "Why you ask, your guess is as good as mine" lol.
I'm sorry, but that "table" at the end of the article is infuriatingly confusing.
[dead]
[dead]
[dead]
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.)
Do you mean the RAM used by the tab? The article is talking about disk space
There's an app. https://play.google.com/store/apps/details?id=com.emergetool...
- They mention Google Chrome tabs
- They speak of HN as a single thing, so presumably not a third-party implementation but the official one
That's some third party app. And if you look at the Github it's basically an advertising vector for that companies set of mobile development tools.
ah I misunderstood...because hilariously my chrome tab is also ~700MB!
Pretty wild. Mine (Chromium on Raspberry Pi) was 52mb, bumped up to 58mb to write this response.
This thread 56MB on Firefox on Windows, 54MB on Edge.
That's not the same metric here. 700mb is the size on the App Store. What you're saying is the size in RAM.
>Gmail isn’t even the worst offender, it’s just a more popular one. The Tesla and Crypto.com apps are around 1 GB each.
One reason is those are typically apps which need to be heavily secured. So behind the seemingly "simple" user interface and functionalities, there's so much security related code to ensure their "safety".
More importantly, it's difficult to code without dependencies.
Pardon? I can't tell if you're serious. How would adding more lines of code in a program (or assets or whatever make up this size) add security?
(Anna Delvey voice) ... LOC is always better.
https://en.wikipedia.org/wiki/Anna_Delvey
You must be a developer only :)
https://www.securecodewarrior.com/press-releases/secure-code...
I think the joke is going over my head ^^; Maybe you mean 'just' a regular developer as opposed to a cryptobro?
Edit: I see you added in a link. "The research found that more than half of the 1200 developers surveyed are unable to ensure that their code is protected from seven common vulnerabilities", hmm maybe it was not a joke? The article (or the survey it's based on) sounds extremely misguided though, sounding comparable to saying that only X% of farmers never had a single rotten apple so clearly it's not a 'top' priority for them to produce quality at all cost
Oh, and I just noticed you're the same person as whom I was responding to above. That explains
Fwiw, I do security audits as a day job so I have some idea of which coding practices lead to good security and it's not download size. You can try this "you're just a developer" again on someone else maybe
> The article (or the survey it's based on) sounds extremely misguided though
Unfortunately the entire Internet is bloated with such extremely misguided jokes. Here is another extremely misguided joke:
"We have a fundamental problem in the way we develop software. A large percentage of software is created by people who were never trained on the basics of security. " [1]
[1]: https://buildingacareerinsecurity.com/why-developers-dont-kn...
Generally the larger the codebase the harder it is to secure. I am less worried about security vulnerabilities on small tightly focused apps than I am on gigantic monstrosities with hundreds of different attack surfaces.
According to looking at a 1,000 line code file on my machine right now, a million lines is about 48mb. You think > 10 million lines of code are required for security in an app?