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.
