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
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.
A "hello world" Android starts at ~5MB.
It is possible to make it smaller if choosing some non-default different tools.
The “default” recommendation is clearly Android Studio plus Kotlin/Java.
Other tools are smaller.
Use plain Java, regular Android views, handle yourself the ifdefs for Android versions, and the 5 MB won't be there.
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.
It's not clear if compute can be cheaper than storage still today.
On one hand you can afford to use less storage but you have to use GPU power everytime to draw graphics, if the chip can support the compute requirement you can save on storage, but you pay with higher power draw at every interraction.
On the other hand you can just put more storage, chip assest that are rendered for the device they'll be used on and be ok.
Outside of crisis like now, storage should be cheaper in the long term I think. I doubt there is that much benefit in having assets being able to resize to any arbitrary resolution. The definition used in phones isn't that far away than what is used in laptops, monitors and now even TVs.
Something to think about is that icons/assets often need to change shape slightly as they become smaller or bigger for optical reasons. So even if you manage a fully vector scaled UI, you might still need to have difference depending on DPI to reading distance ratio. Rasterized assests might still be the real answer for a very long time.
Considering how bad is the iOS 26 release on performance, because of its dynamically computed interface, I'm not sure it's worth pursuing vector UIs, it doesn't make a lot of sense to make a more powerfull chip just to draw prettier or more "pure" interfaces...
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
A 6 inch screen doesn't need an 8K logo and all it's variants
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.
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.