On the middle side of that range, extra features adds up fast.
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.
Android does that already and allows apps to use it (the webview)
> 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.
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.
Compare the size of Safari.app versus Safari Technology Preview.app (which actually ships all the frameworks it needs).
With Safari it's a lot easier to see, as you can get the standalone version.
- They speak of HN as a single thing, so presumably not a third-party implementation but the official one
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.
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.
https://www.securecodewarrior.com/press-releases/secure-code...
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
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...
Frameworks 150MB
Assets for all screen resolutions 50MB
Google Meet/Chat/etc 100MB
AI models 25MB
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.
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.
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."
Yet there is a positive correlation between size and startup time…
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.
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
A "hello world" Android starts at ~5MB.
It is possible to make it smaller if choosing some non-default different tools.
Use plain Java, regular Android views, handle yourself the ifdefs for Android versions, and the 5 MB won't be there.
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.
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.
But there are alternatives that reuse the OS's libraries nowadays.
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
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...
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.
What are the other 310?
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.
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.
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.
Google Meet was launched in March 2017.
I first read about it via this blog post: https://shkspr.mobi/blog/2019/04/banish-the-%ef%bf%bd-with-u...
(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.)
A bit reductionist, but I get it, if it were a priority you could do lots with a hundredth the space
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.
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
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.
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.
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.
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.
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.
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”
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.
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.
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.
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.
This is one of the reasons why these apps grow: because the user doesn't notice!
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.
Phones used to have 4GB of flash memory... Some had 2GB.
In fact, they state the oppposite: To really make it go, they need petawatts of energy and compute. It's like Windows incarnate.
We crossed lunacy long ago.
I agree, that we crossed lunacy long ago, and that LLMs have not helped in the slightest.
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.
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.
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.
* 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
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".
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.
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).
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.
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, 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.
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.
The answer to this one is obvious - to incentivize you to buy iPhones with more storage and/or higher tier iCloud plans.
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.
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).
- 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...
Mystery solved it seems
This is more like the what causes these apps to be so large, but when you ask why then you see that they simply do not care about the amount of space they take on users’ devices. There’s no obvious effort to reduce app size with modular design, it simply feels like they don’t care.
As the parent commenter has pointed out, pulling in client code can be very large. If the backend team owns the client code, they may not be properly incentivized to improve the product of the clients, sadly. And calling it the backend "team" might be overly simplistic. There may be additional layers to the the client code owned by other teams, such as different protocol implementation and definitions of those protocols, etc. Pushing for change can be viewed negatively, since it could leave a poor impression. E.g. if you improve someone else's code, that could make them look bad, and that would have negative consequences for you as you have violated (a variation of) Greene's first law of power: never outshine the master.
Since the code and the organization are so convoluted and complicated, it's a lose-lose proposition. If you mess up your optimization, you will get blamed. Even if you succeed, you may have reduced someone's reputation of someone you can't even identify in the bureaucracy, and thus have made an enemy of someone you can't even identify.
> improve someone else's code, that could make them look bad, and that would have negative consequences for you
(And yes I know it’s a tiny fraction of the size, let me have my fun).
As a regular user, you are probably using 10% of all features available.
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 conversation is always the same, only there is another zero on the end.
We'll have terabyte apps in not too long.
(100% serious)
(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 economic pressure to keep apps small is literally negative.
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”.
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.
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.
There it tends to be mostly due to dependencies, including some native libraries in multiple copies for 2-3 CPU architecture.
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)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...
AFAIK iOS does not offer anything similar.
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.
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?
That one's on the author. Duo Mobile is 2MB and shows the same 6-digit codes just fine.
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...
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".
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.
Could the main issue be Google is shipping apps within apps?
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.
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
Same goes for other other bloated apps mentioned in the blog post
HPsquared•1d ago
simonw•1d ago
Why IS the Gmail app 700MB?
jshchnz•1d ago
compiler-guy•1d ago
https://threadreaderapp.com/thread/1810790280922288617.html
giancarlostoro•1d ago
simonw•1d ago
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
trevor-e•1d ago
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
lynndotpy•1d ago
jeroenhd•1d ago
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.
tonyplee•1d ago
hn8726•1d ago
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
crazygringo•1d ago
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?)
layer8•1d ago
kccqzy•1d ago
simonw•1d ago
trinix912•1d ago
They probably just have lots of leftover localized assets that nobody dares to touch as they aren't sure if it's used anywhere.
Aloisius•21h ago
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.
x0x0•1d ago
adgjlsfhk1•1d ago
Aloisius•22h ago
Since the iOS filesystem uses 4 KB blocks, it looks like about half the space is just wasted.
jonny_eh•1d ago
Pxtl•1d ago
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.
thefilmore•1d ago
[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
Aperocky•1d ago
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.
NuclearPM•1d ago
dieggsy•1d ago
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.
HPsquared•1d ago
anal_reactor•1d ago
WillPostForFood•1d ago
dieggsy•1d ago
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.
toyg•1d ago
ExoticPearTree•1d ago
hadlock•1d ago
suprfsat•1d ago
SaltyBackendGuy•1d ago
afavour•1d ago
tshaddox•1d ago
adastra22•1d ago
gregoriol•1d ago
summerlight•1d ago
lxgr•1d ago
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.
seizethecheese•1d ago
The Gmail app size has to be assets, right?
reactordev•1d ago
chasil•1d ago
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...
reactordev•1d ago
chasil•1d ago
"Note that you can also invoke GoHelloGreetings from Swift by importing Hello."
reactordev•1d ago
tormeh•1d ago
lxgr•1d ago
HPsquared•1d ago
yobbo•1d ago
It doesn't bundle full random external libraries compiled with debugging symbols and "whatever other stuff".
tgsovlerkhgsel•23h ago
Aperocky•1d ago
stonemetal12•1d ago
lxgr•12h ago
lenerdenator•1d ago
Google needs to trim some stuff down.
mrweasel•1d ago
lxgr•47m ago
themafia•1d ago
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.
vrighter•12h ago
(I do realize though that most "apps" are just websites without the browser toolbar, unfortunately)
jama211•1d ago
zamadatix•1d ago
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.
wolvoleo•1d ago
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.
HPsquared•1d ago
dylan604•1d ago
lucianbr•1d ago
watermelon0•1d ago
Mimo app will never support as many devices as Linux kernel does.
ChoGGi•22h ago
dylan604•21h ago
vnorilo•1d ago
prawn•1d ago
MBCook•1d ago
Gmail has no such excuse.
mckn1ght•1d ago
It’s lazy.
nickff•1d ago
mckn1ght•1d ago
HPsquared•23h ago
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.
MisterTea•1d ago
nickff•1d ago
MBCook•3h ago
giancarlostoro•1d ago
ljm•1d ago
cons0le•1d ago
Forgeties79•1d ago
lol remember the Karma?
convolvatron•1d ago
benhurmarcel•1d ago
mbirth•1d ago
techjamie•1d ago
wolvoleo•1d ago
leftbehinds•1d ago
rjh29•1d ago
jason_oster•1d ago
The software crisis never ended. Instead, we also gained a hardware crisis.
encom•3h ago
>RAM lights
I'm not sure which is dumber.
tgsovlerkhgsel•23h ago
If enough people actually did that, the companies would start caring.
ChoGGi•22h ago
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).
layer8•1d ago
achairapart•1d ago
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
bdhtu•1d ago
pfortuny•1d ago
WHAT THE FUCK!
There are 4k videos there...
Just unbelievable.
QuantumNomad_•1d ago
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.
citizenpaul•1d ago
BatteryMountain•1d ago
Gboard 247MB
Google 415MB
Google Play Services 1330MB
Google Play Store 165MB
Messages 321MB
Gmail 233MB
trinix912•1d ago
ChoGGi•21h ago
anthk•23h ago
ThePowerOfFuet•23h ago
https://keyboard.futo.org/