I absolutely guarantee that this analysis is missing some significant complexities, and that Facebook understands what's actually going on under the hood.
I'm not saying it would be a 5 second job, but not duplicating files on a read-only filesystem is not a difficult job -- I would never accept it from a student project, never mind one of the biggest tech companies in the world.
Either way, this "analysis" seems pretty superficial. I can run a "du" of almost anything and it won't tell me much. And this author misleads intentionally by giving no explanation, but the implication is very clear from the post that Facebook is lazy and sloppy with disk usage.
It's so much funnier though, that the solution is to just keep throwing in more and more copies of the images.
I feel kinda bad for the poor developer responsible for keeping all of those copies up to date. Very much 'i pass butter' kind of programming.
This could just be the build tool looking at dependencies and including them multiple times in seperate frameworks. No different to how in big Java apps you often will see duplicate code amongst shaded JARs.
Hashing resources is like an intern problem, technically at least. Facebook must have some crazy politics to incur the image dedupe problem.
As far as objective c binaries go, all I can think of are static variables for coroutines, but I'm probably forgetting something. Java doesn't dedupe, but it's not that hard. C has to worry about flag state, so I kind of understand why they don't dedupe binaries.
I'm sure someone would get fired if one subsystem showed the wrong image, but I'd agree it's likely no one person has that in their job description.
Otoh, it's only a couple hundred wasted terabytes, and FB doesn't pay for them, so who cares?
Facebook updates their iOS app on a pretty regular cadence which means it is quite likely that removing duplicate assets (if it's even an issue) could simply have trickled across to the next sprint. You just can't make broad generalisations based on a particular snapshot in time.
But I suspect it isn't even an issue anyway. It seems clear they have one lightweight framework that is required during startup and another which gets dynamically loaded later (FBNotOnStartupPathFramework).
Things that are smaller than Facebook's iOS app:
- Windows, through at least Windows 95, if you count stuff written to disk during install
- The Java Runtime Environment
- Eclipse IDE
- Google Chrome for OS X (beware—updater leaves old versions in the app bundle)
- Firefox for OS X
- Pokémon Go
- A two-disc set encoded in 256kbps AAC
And to add insult to injury, Messenger is another 155MB, and is a separate app for some reason, probably with a second copy of that bigger-than-the-JRE-by-itself FBSharedFramework.
And while the sudden almost 300MB is new, the "I can't believe this is a Web service front-end and not an experimental operating system" bloat has been with us for a while.
then vote with your wallet, and remove the app. If you can't tear yourself away from facebook, the web is the "right" app to use!
I suspect that decision to split the app comes from equal parts marketing and software engineering incompetence.
What other parts are disabled?
> Facebook updates their iOS app on a pretty regular cadence which means it is quite likely that removing duplicate assets (if it's even an issue) could simply have trickled across to the next sprint.
Somebody already expressed this idea more concisely in comment section on the original site:
> This is what happens when your development team is too big and you have a policy of updating your app every two weeks for no particular reason.