This is really unacceptable and so easy to solve, had they even bothered.
But it has been known for years that Facebook just cannot (or will not) manage its application development process. I remember reading somewhere that they developed build tools that take multiple versions of the same static library and mangle the symbols so that all versions can be linked into a single binary and there are no symbol collisions - all this to allow developers to use whatever version they started of, and god forbid, require some sort of review or cooperation between developers.
It is very sad to me that so many companies (start up or otherwise) aspire so much to have the same work methodologies as this company.
The fact that you think this third-party analysis has discovered an incredibly easy way to radically reduce the size of the Facebook app - but that Facebook has not "discovered" the same "fix" - reveals an oversimplified perspective of iOS, app development, and large tech companies.
I absolutely guarantee that this analysis is missing some significant complexities, and that Facebook understands what's actually going on under the hood.
What? I'm sorry, normally I defend "you don't understand the complexity", but in this case, it's the same file, and it's fixed!
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.
I'm no ios dev but my thinking was that it was done this way for flexibility. So one internal framework could be developed entirely separate from the other app code. And maybe one framework gets updated with a new dependency before the others.
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.
The use of frameworks is a good practice, no one is arguing against that. The improper duplication of resources and code is the problem. Any development process that requires resource duplication in order to be flexible is broken at the core, and developing such systems are enables of bad practices.
It's funny, because there seems to be a lot of effort to get exactly the right version of asset in every circumstance. I'd wager showing an old version of the thumbs up really would get someone fired.
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.
I wouldn't assume anyone is responsible for keeping them up to date.
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.
It's not code though. In this case a resourceBundle would solve the duplicate image problem in java.
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?
Has nobody worked on a decent sized, agile project before ?
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).
I did not buy 64GB of flash storage so Facebook could be lazy. I bought 64GB of flash storage to store media that gets noticeably better, to a point, when you throw more bits at it.
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.
Fair enough. But people will decide not caring even slightly about binary size is admirable (move fast and make users buy new phones, I guess) and eventually everything will be huge. Already the number of sub-60MB apps is dwindling and the 100-and-up club is growing, if my recent updates list is any indication.
That's intentionally awkward. If I tap the messages icon on Facebook.com on mobile, I get redirected to a page telling me to download the app. Similarly, messenger.com points me to the App Store.
On the contrary: You can even enable push notifications with Chrome for Android. Chat included. I haven't touched the native apps for ages and everything works just fine.
> Has nobody worked on a decent sized, agile project before ?
> 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.
It takes just a little discipline, but nobody wants to do it. You're completely right - it's a shame how often products are made without any sense of deliberateness.
I guess one question to ask is 'does it matter if the app is inefficient?' i.e. are these problems going to stop people from using Facebook? I'd argue that the platform is way too big and too sticky for this to be a concern; they could ship an app that crashes every hour and people would still use it.
> all this to allow developers to use whatever version they started of
That sounds like exactly the same reason everybody's crazy about containers ... and I do mean crazy, because it's a maintenance and security nightmare, but the whole industry seems hell-bent on going that way.
There must be a lot of people out there with 16GB iPhones that are constantly out of space. I don't think Apple publishes stats, but I guess >50% buy the cheapest model. The Facebook app also likes to use 500 MB for cache with no way to clear it other than deleting the app.
Lots of apps are like this and I don't understand why. They should be using the caches folder and "the system may delete the Caches/ directory to free up disk space". However I have never seen this happen. When my phone runs out of space I have to manually delete these apps. Are they not using the correct folder, or is the system not deleting the caches?
I have a 16GB iPhone 6 and the Facebook app was the first I culled from my phone ~2.5 years ago. At that time I was getting annoyed that the app had slowly creeped up in size from between ~60MB and ~80MB to over 100MB. I have no intention of ever installing it again as I don't think FB have any interest in reducing the size back down to that level.
Why do you have to download all localizations? Isn't it possible to download only the required one after install? As far as I know Waze does this, for example.
(Honest question, I'm not a mobile developer)
Sure you can! Downloading the localizations is a large extra complexity in development though, while simply bundling them all is a minor bother in increased download size, for the customer.
I thought our apps were fat, this is ridiculous. But clearly they belong to the school of never rewrite just keep adding more and more and more. Eventually you wind up having no idea what you are shipping and the quality goes in the dumpster. At least you can use the web if you hate the mobile app (I do).
This is a side-effect of the current app business model, which sacrifices software quality to deploy it fast to the market... who expends 1 month optimization while a new app comes every 6 months ?
We use it as a joke name for functions/modules that are deprecated or dangerous, or that otherwise should be avoided. It works pretty well even though it's (probably) an empty threat.
Also, I take it that the described duplication is due to isolation and compartmentalization (which I can appreciate). I'm curious if some kind of "final dedupe" could be tacked onto the end of the build process that just runs a bunch of fixed algorithms on the assets to find and remove duplicate resources - and maybe even code fragments, like Courgette (https://www.chromium.org/developers/design-documents/softwar...) does.
FWIW, doing something like this would probably take a lot of pressure off the dev teams and make everyone's lives easier. On the current track, the app will be 300MB in a few months. lol
The same reason why you otherwise deprecate stuff. Because it's still used. As for React, they have such a variable to allow interop with the react dev tools.
In a twisted kind of way, I'd call that a feature.
If you're aware you don't know what you're doing, but still want to do it, that's kind of ok. Problem is when you're not even aware you're about to jump into some pretty hot water.
I find it fascinating that they managed to get to this much disk footprint so soon without any of us having much of an idea about what is going on below the good.
Despite weekly updates with nonsensical generic descriptions we still don't have actual features like support for devices like the iPad Pro.
Especially with all the frequent A/B testing bull they're pulling recently, the quality and usability of their software is dropping on a weekly basis. It just seems like a bad combination of everything on a level Microsoft at their worst couldn't even come up with.
The funny part is even if you do interview at Facebook, they only ask algorithm whiteboard questions. So it doesn't really matter if you have the sort of aesthetic values that cause this horrible app or not. If anything they might be actively selecting for it by filtering out experienced hires.
That's assuming the on-disk compression deduplicates. ZIP does not and 7z only does in 'solid' mode. Compression is not a silver bullet for this either - if you have a repeated 8MB sequence in 8 different parts of a 250MB file, whether or not the sequence gets deduplicated depends on the compression algorithm, dictionary size, speed setting, etc.
The solution to all the duplicated files is to dedup at build time.
But it has been known for years that Facebook just cannot (or will not) manage its application development process. I remember reading somewhere that they developed build tools that take multiple versions of the same static library and mangle the symbols so that all versions can be linked into a single binary and there are no symbol collisions - all this to allow developers to use whatever version they started of, and god forbid, require some sort of review or cooperation between developers.
It is very sad to me that so many companies (start up or otherwise) aspire so much to have the same work methodologies as this company.